Here at Hackaday, about the only thing we like more than writing up tales of reverse engineering heroics is writing up tales of reverse engineering heroics that succeed in jailbreaking expensive widgets from their needless IoT dependency. It’s got a real “stick it to the man” vibe that’s hard to resist.
The thing is, we rarely see a reverse engineering write-up as thorough as the one [James Warner] did while integrating an IoT air purifier into Home Assistant, so we just had to make sure we called this one out. Buckle up; it’s a long, detailed post that really gets down into the weeds, but not unnecessarily so. [James] doesn’t cloud-shame the appliance manufacturer, so we can’t be sure who built this, but it’s someone who thought it’d be a swell idea to make the thing completely dependent on their servers for remote control via smartphone. The reverse engineering effort started with a quick look at the phone app, but when that didn’t pay off in any useful way, [James] started snooping on what the device was talking about using Wireshark.
One thing led to another, wires were soldered to the serial pins on the ESP32 on the purifier’s main board, and with the help of a FlipperZero as a UART bridge, the firmware was soon in hand. This gave [James] clues about the filesystem, which led to a whole Ghidra side quest into learning how to flash the firmware. [James] then dug into the meat of the problem: figuring out the packet structure used to talk to the server, and getting the private key used to encrypt the packets. This allowed a classic man-in-the-middle attack to figure out the contents of each packet and eventually, an MQTT bridge to let Home Assistant control the purifier.
If it sounds like we glossed over a lot, we know — this article is like a master class on reverse engineering. [James] pulled a lot of tools out of his kit for this, and the write-up is clear and concise. You may not have the same mystery fan to work with, but this would be a great place to start reverse engineering just about anything.
Thanks to [ThoriumBR] for the tip.
Seems like it would have been a lot easier to just figure out the i2c protocol that it uses to read the sensor and flash esphome/tasmota to fully replace the firmware.
In hindsight, yes. When you know nothing about the device and is trying blindly, not so.
It’s like playing a difficult game for the first time without a wiki, a manual, and without watching anyone on Youtube. You may travel for an hour until you reach the destination and find a shortcut 3 minutes away.
He started by the app, seems a logical step. The app uses encryption, so he started looking at the decryption. It went nowhere, so next step would be look at the firmware. It uses encrypted UDP, so maybe it’s mtls. It is not, so what this is? And one thing links to the next.
Not even in hindsight, he doesn’t say which device it is, but chances are the protocol has already been reversed engineered. Maybe it’s because the full reverse engineering is beyond my skills, but esp32s are easy to work with and figuring out the protocol seems a lot easier than everything he did. That said, maybe my way was too easy for him and it would ruin the fun. Sometimes the journey is the destination.
Most likely datasheets are available for each part on the board. Personally I would have found it easier to just write a program that does everything I want it to instead of reverse engineering the software and having to set up a dummy server to keep that wretched firmware running.
We all have different strengths. Learning to hack like this does seem fun and useful. I’ll have to open up my iot air filter and see if the board looks identical.
I am glad he didn’t, or else we wouldn’t have this marvelous write-up ;)
… and the people who made the garbage in the first place are rewarded with another sale.
If device had secure boot turned on he would have gotten nowhere.
Beat me to the punch! Yeah it’s kind of baffling to see a commercial product not leverage those readily available tools. I know it can be a real dick-punch for development work, but still…
Interesting that the manufacturer didn’t bother to implement any of the flash encryption tools on the ESP32. It’s not exactly much effort to set it up to automatically encrypt the flash contents after first boot and leveraging the OTA library to update it afterwards it just as easy.
“[James] then dug into the meat of the problem: figuring out the packet structure used to talk to the server, and getting the private key used to encrypt the packets.”
One would think at this point DRM would be seen as a failure.