PiFex: JTAG Hacking with a Raspberry Pi
voidstarsec.com
voidstarsec.com
It costs 145$ instead of 50$, and you can interface with it via Python3 over USB. It is quite flexible due to a reconfigurable FPGA and has some nice features such as automatically detecting UART baud rates, JTAG pinouts, ESD / Under / and Over-Voltage protection on the I/O pins and more.
According to https://www.reddit.com/r/raspberrypipico/comments/1aut3l2/co... , pico-uart-bridge turns a pico into 6 TTL UARTs; https://github.com/Noltari/pico-uart-bridge
In which case a methodology is needed to reverse engineer this protocol, treating the device like a black box.
I really liked how a solution to this was found for x86 processors and hidden instructions
https://github.com/cyphunk/JTAGenum
Good to see an web interface to go-jtagenum via Jupyter Notebooks :-)
It's not at all hard to blow the JTAG enable fuse in most chips. And you can give away a ton of info from your device if you don't do this. That potentially includes really sensitive info - through backdoors like this. People keep all kinds of stuff on their hard drives.
(Full disclosure: I'm the HW eng who reviewed this design. Hi Matt! Reverse engineering is still magic.)
And, lets be honest, your smart IoT coffee maker doesn't really have any secrets that need protecting from you, despite whatever the business team thinks.
Seems like the wrong solution to an already absurd/niche threat model.
Having separate "guest wifi" is a great idea and provides much better security than trying to ensure none of your IoT devices expose your password.
My new water heater came with WiFi, and I just cannot understand why my tank needs-do anything more than just heat water..?
Lots of interesting suggestions/applications in response to my initial comment. My local electric utility has a smart grid, but offers me as a consumer none of the so-far-listed reasons to connect to WiFi for electricity savings (e.g. no time of use metering)... but it would be cool if the anode deterioration could be monitored [I'll check the manual].
For a water heater, participating in a utility program where they modify your temperature sweeping in exchange for a reduced rate or similar incentive.
Those are the first reasons I can think of.
Some people have solar installations, but do not have 1-to-1 net metering from their power company. For these people, having a connected hot water heater allows them to use their own solar power for heating water when they can, lowering their power bill.
Essentially any high-consumption electrical device can similarly benefit, especially ones that store energy such as hot water heaters and electric car chargers.
The only downside is companies trying to scoop up that data for their own purposes and when companies disable perfectly working products because they claim the servers are too expensive. The Home Assistant community makes a big point of recommending products that guard against issues like that.
But most of the "pizza-box-shaped" things I've worked on in telecom have jtag enabled even when in the field. I've never thought about it much, but to actually get to a jtag interface requires a level of physical access that would be far-fetched unless you're talking about "James-Bond-level" bad actors or "inside-job" people who are already entrusted with an enormous amount of privileges anyway.
JTAG is super useful for troubleshooting and in general, for things that aren't throw aways and that can be repaired, re-calibrated, or re-configured, it makes sense to keep it available.
The vast majority of microcontrollers aren't hardened against physical attack - especially not anything with wifi capability.
"disable jtag" is intended to make it harder to make modchips (ie. bypass the coffee subscription), but doesn't help against someone willing to do a one-off glitching attack or similar to dump secrets.
Or do you think that physical access does not mean you own the device?
To secure a thing, you are supposed to literally secure the thing, as in, placing the equipment away from walls, bolted down to the floor, chassis locked and rigged for self destruction, perimeters patrolled and monitored by armed guards.
Software security is additional parts that build on top of that physical security. Hardware root of trust, Secure Boot, code signing, all helps, but physical security has to come first.
If you're throwing out the coffee maker not securely erased(military guys call it zeroizing - cool), or not maintaining custody of it by either keeping it to yourself or having dogs and your grandsons taking part watching it at all times, then the coffee maker is technically not secure, by any of those alone.
flash for microcontrollers such as ESP, Rpi pico etc is usually saved on an 8-pin flash chip which most people forget about and is easy to unsolder and pop into a reader. bigger devices using bootloaders sometimes store a whole FAT32 filesystem in one of these, you can even unsolder most flash and re-mount it with a little skill and suitable hardware.
I once read an AWS private key stored in plain text from an IOT board once. Go figure!
And even if it did, a good chunk of debugging involves running the system live in the target environment and looking at traces. Eg. "the device doesn't work properly when on the customers wifi network because their router responds to ARP requests too fast and we miss the response packet because we're still busy reconfiging the radio from TX mode into RX mode"