Dumping Encrypted-At-Rest Firmware Of Xiaomi Smart Kettle

[aleaksah] got himself a Mi Smart Kettle Pro, a kettle with Bluetooth connectivity, and a smartphone app to go with it. Despite all the smarts, it couldn't be turned on remotely. Energized with his vision of an ideal smart home where he can turn the kettle on in the morning right as he wakes up, he set out to right this injustice. (Russian, translated) First, he tore the kettle down, intending to dump the firmware, modify it, and flash it back. Sounds simple enough -- where's the catch?

This kettle is built around the QN9022 controller, from the fairly open QN902X family of chips. QN9022 requires an external SPI flash chip for code, as opposed to its siblings QN9020 and QN9021 which have internal flash akin to ESP8285. You'd think dumping the firmware would just be a matter of reading that flash, but the firmware is encrypted at rest, with a key unique to each MCU and stored internally. As microcontroller reads the flash chip contents, they're decrypted transparently before being executed. So, some other way had to be found, involving the MCU itself as the only entity with access to the decryption key.

[aleaksah] considered the SWD interface, a powerful debug interface and a fairly common go-to for internal data access of many MCUs. Sadly, this microcontroller has lock bits for blocking SWD, intended to be set as your product leaves the factory floor. Of course, not every manufacturer sets those bits, but after checking the SWD interface anyway, it wouldn't respond, and he decided to go the other way. He rejoiced, finding documentation on the MCU's internal bootloader, and decided to load his own code into RAM that would dump the flash contents from the inside. However, the read command seems to have triggered the bootloader to either scramble or erase the flash, leaving him with a dead unit.

He persevered, and decided to study the bootloader code itself, loading yet another RAM stub that would dump the bootloader code. After decompiling the bootloader, apart from a few undocumented but uninteresting commands, he found out that loading any kind of program, indeed, sends the flash chip a command to perform a flash erase. From here, he could theoretically do a tweezer hack, write-protecting the flash by short-circuiting its data pins - yet, he decided to find a proper dumping method that would extend to the chips with built-in flash, should one of those appear on our desks.

His key discovery came soon thereafter. Different SPI flash chip families have different commands for read/write/erase and other operations, and the bootloader exposes a structure you can modify to use different commands for the kind of flash chip you have connected. Simply substituting the flash erase command in that structure with something harmless resulted in the flash contents staying intact even after new code was loaded externally into RAM. As a result, [aleaksah] has discovered a method for dumping encrypted-at-rest firmware from any QN902X series MCU, using nothing but a USB-UART, the chip's built-in bootloader and a small code dumping stub (GitHub).

Another day, another firmware readout protection mechanism circumvented! Finding such exploits is beneficial for a lot of fun journeys, like the recent hack that helps us tap into myriads of STM32-powered devices out there. You can even use the abundant ST-Link programmers as your training ground! If the SWD interface isn't unlocked on your device, check out this educational journey about modding a third-party Xbox controller using SWD. Wonder how to modify the firmware you dumped? We've just covered a hacker modding their Kurzweil synthesizer's firmware with Ghidra!

#microcontrollers #reverseengineering #securityhacks #attack #firmwaremodding #lockbits #memoryreadoutprotection #microcontroller #patching #readprotection #security #swd

Xiaomi Cryptographically Signs Scooter Firmware – What’s Next?

[Daljeet Nandha] from [RoboCoffee] writes to us, sharing his research on cryptographic signature-based firmware authenticity checks recently added to the Xiaomi Mi scooter firmware. Those scooters use an OTA firmware update mechanism over BLE, so you can update your scooter using nothing but a smartphone app - great because you can easily get all the good new features, but suboptimal because you can easily get all the bad new features. As an owner of a Mi 1S scooter but a hacker first and foremost, [Daljeet] set up a HTTPS proxy and captured the firmware files that the app downloaded from Xiaomi servers, dug into them, and summarized what he found.

Confirming this update will indefinitely lock you out of any third-party OTA updates

Unlike many of the security measures we've seen lacking-by-design, this one secures the OTA firmware updates with what we would consider the industry standard - SHA256 hash with elliptic cryptography-backed signing. As soon as the first firmware version implementing signature checks is flashed into your scooter, it won't accept anything except further firmware binaries that come with Xiaomi's digital signature. Unless a flaw is found in the signature checking implementation, the "flash a custom firmware with a smartphone app" route no longer seems to be a viable pathway for modding your scooter in ways Xiaomi doesn't approve of.

Having disassembled the code currently available, [Daljeet] tells us about all of this - and more. In his extensive writeup, he shares scripts he used on his exploration journey, so that any sufficiently motivated hacker can follow in his footsteps, and we highly recommend you take a look at everything he's shared. He also gives further insights, explaining some constraints of the OTA update process and pointing out a few security-related assumptions made by Xiaomi, worth checking for bypassing the security implemented. Then, he points out the firmware filenames hinting that, in the future, the ESC (Electronic Speed Control, responsible for driving the motors) board firmware might be encrypted with the same kind of elliptic curve cryptography, and finds a few update hooks in the decompiled code that could enable exactly that in future firmware releases.

One could argue that these scooters are typically modified to remove speed limits, installed there because of legal limitations in a variety of countries. However, the legal speed limits are more nuanced than a hard upper boundary, and if the hardware is capable of doing 35km/h, you shouldn't be at mercy of Xiaomi to be able to use your scooter to its full extent where considerate. It would be fair to assert, however, that Xiaomi did this because they don't want to have their reputation be anywhere near "maker of scooters that people can modify to break laws with", and therefore we can't expect them to be forthcoming.

Furthermore, of course, this heavily limits reuse and meaningful modification of the hardware we own. If you want to bring a retired pay-to-ride scooter back to usefulness, add Bluetooth, or even rebuild the scooter from the ground up, you should be able to do that. So, how do we go around such restrictions? Taking the lid off and figuring out a way to reflash the firmware through SWD using something like a Pi Pico, perhaps? We can't wait to see what hackers figure out.

#securityhacks #transportationhacks #digitalsignature #electricscooter #ellipticcurvecryptography #escooter #firmwarehacking #firmwaremodding #scooter #scooterhacking