The microcontroller described in the article, on the PCB taken out of the kettle

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.

Continue reading “Dumping Encrypted-At-Rest Firmware Of Xiaomi Smart Kettle”

The Cheap Way To Glitch An STM8 Microcontroller

Reverse engineering or modifying a device often requires you to access the firmware stored on a microcontroller. Since companies are usually not fond of people who try to peek into their proprietary data, most commercial devices are readout protected. [rumpeltux] ran into this problem when he tried to dump the firmware on an HC-12 wireless serial communication module for yet undisclosed reasons. Hacking into the device was a challenge that he gladly accepted and in the end, he succeeded by building a low-cost setup for voltage glitching.

Voltage glitching is a form of fault injection that has, e.g., been successfully used to hack the Playstation Vita. It involves the injection of voltage spikes on the power line in order to force the bootloader to skip security checks. The hard thing is trying to find the right shape of the waveform and the best way to inject the signal.

While there are already open-source boards for fault injection like ChipWhisperer, [rumpeltux] chose to build his own setup around an FPGA. By using a cheap EPM240 board, some MOSFET, and a USB-to-Serial converter, the total costs of the glitching setup were under 20 Euros. [rumpeltux] then recorded a larger number of voltage traces on the VCC pin around the reset phase and analyzed the differences. This helped him to pinpoint the best time for injecting the signal and refine the search space. After some unsuccessful attempts to glitch the VCC and GND pins, he got lucky when using one of the voltage regulator pins instead.

Be sure not to miss Samy Kamkar’s talk at Supercon 2019 if you want to know more about hardware attacks or how to eavesdrop on people using a bag of potato chips.

Breaking Into A Secure Facility: STM32 Flash

In a perfect world, everything would be open source. Our current world, on the other hand, has a lot of malicious actors and people willing to exploit trade secrets if given the opportunity, so chip manufacturers take a lot of measures to protect their customers’ products’ firmware. These methods aren’t perfect, though, as [zapb] shows while taking a deeper look into an STM microcontroller.

The STM32F0 and F1 chips rely on various methods of protecting their firmware. The F0 has its debug interface permanently switched off, but the F1 still allows users access to this interface. It uses flash memory read-out protection instead, which has its own set of vulnerabilities. By generating exceptions and exploiting the intended functions of the chip during those exceptions, memory values can be read out of the processor despite the memory read-out protection.

This is a very detailed breakdown of this specific attack on theses controllers, but it isn’t “perfect”. It requires physical access to the debug interface, plus [zapb] was only able to extract about 94% of the internal memory. That being said, while it would be in STM’s best interests to fix the issue, it’s not the worst attack we’ve ever seen on a piece of hardware.