It's a Sunday.
Kids are playing Lego
Wife is chilled
Guess this means it's teardown and tinker time with IKEAs indoor pollution sensor
Ok it's pretty well-designed. David Wahl is the designer, who's responsible for a lot of pretty damn good designs. Has usb-c to power but doesn't come with a cable.
Inside the beast.
Main heart is a Eastsoft ES7P001FGSA MCU. So far can only find the datasheet in Chinese. But it has the pinouts so that's all I need I guess for now
Connected to the PCB is the PM 2.5 sensor and fan. This is a PM1006 v1.1 sensor
Always handy when they silkscreen the test points
Soldered on a wire for easier access to GND and plugged in the PCBites
Added some wires to make it easier later on
Slight delay due to kids wanting to go and BMX.. box back together with wires and I'll hopefully work out what and how later on
Normal healthy reading
Unhealthy smoke reading
Amber reading
The PM1006K receives 11 02 0B 01 E1 from the MCU and sends out the results
I guess tomorrow I could add some wires to the following pins on the MCU but not 100% sure what else it would give me, but hey, I'm on holiday so...
Scratching around I've managed to find this.
This means I can take those readings and push them into this and up to @adafruit's IO
The design of this is actually super impressive. It's easy on the eye, the LED panel works very well and the MTTF is + 5 years, which for a tenner is bloody amazing.
and it used usb-c and not the funny older ones like most do.
It's a sunday and many friends sent me this paper by Maryam Motallebighomi and Aanjhan Ranganathan delving deep into their security assessment of Shimano's Di2 wireless shifting architecture and hardware
Needless to say, with the football on, I delved deep into understanding it a bit more
1: Replay Attacks - let me change gear for you
2: Targeted Jamming - now you can't change gear
3: Information Leakage - gear selection leakage (meh dude i can SEE this
Ok they are meh bugs
The researchers were able to execute replay attacks from a distance of up to 10 metres using software-defined radios without amplifiers
They note that beyond this distance the signal falls outside the effective range
I'm going on a web app security rant, so bear with me.
23 years ago OWASP was formed and it tried to help the web application space and those building apps to do so in a secure way. Session management was one of them.
If you had a token, in a header/cookie, make it secure
We've evolved this over the decades, we collectively got better with understanding the nuances and complexities of this identity being thrown around and the consequences of not doing it right.
and yet, even with all this VC cash thrown at people wearing Patagonia vests and wearing apple watches, I still see most SaaS solutions doing stuff we did when Rain Forest Puppy was hurting SQL
Patch ALL teh things we constantly tell CISOs and CIOs.
Thing is, let's be honest with each other right? we can't and this graph is telling.
Patching is a pain, we get it and we do need to revolutionise the approach. Two years ago, @LargeCardinal wrote a phenomenal paper
where, in essence, the idea was to prioritize patches by expressing the connectivity of various vulnerabilities on a network with a QUBO and then solving this with quantum annealing.
Strap in, we's going on a ride, a static analysis ride. I recently came across this paper, which looked at a wide variety of SAST tools against a number of Java apps.
Java being the choice of enterprise, and often not the best Java approaches out there, so it's a good choice
First up, what did they use and what did they benchmark it against?
They looked at free tools, tools that specifically supported Java and most importantly, are being actively maintained.
The target was the @owasp project, a good choice imho. They also looked for Java apps with bugs with disclosed CVEs which was around 680 programs.
Bugs happen but it's rare you see a bug that grabs you so hard and makes you nod like a little dog..
CVE-2023-44487 did that for me
good god what a bug and here's why
First up is understanding the key differences between HTTP 1.1 and 2, especially how requests work
HTTP 1.1 is a text-based protocol that uses a single connection for each request/response pair. Every time you request the / from , it will be a diff request NSA.gov
for each element of that page (CSS, images etc)
HTTP 2 is a binary protocol that utilises multiplexing, which allows multiple requests and responses to be sent simultaneously over a single connection
An interesting new feature found in @Apple’s latest privacy and security report is that of Link Tracking Protection and I’ve not stopped thinking about this
First up it’s pretty cool. My views on the pervasive nature of the tracking industry are not something I’ve hidden away: it’s an ugly industry with no real oversight, so any efforts to put a finger in their eye is one to applaud
The approach by Apple is interesting
First up is the deeper inspection (I’m assuming client only) that intercepts any url and does a regex on it to strip out utm and other crap added to the url
If it works like that, I’m impressed. However, how much stuff will it break in the process? I guess time will tell