Hagan Fritsch Unlocks Readout Protection on the STM8 with a Low-Cost Voltage Glitching Setup

Hagen Fritsch has published a guide to overcoming the readout protection functionality of the popular STMicro STM8 microcontroller family, glitching the chip's voltages to inject a fault and dump the otherwise-locked firmware.

"As part of my HC-12 hacking project I needed to acquire the firmware of an STM8 microcontroller that had readout protection enabled," Fritsch explains. "I was long-time intrigued by fault-injection attacks, most recently triggered by this 35C3 Talk on PS2 Vita Hacking which used voltage glitching to overcome protection measures."

"[The STM8 readout protection] looks like a great target for voltage glitching. Thus: challenge accepted! While others reported doing similar projects with an Arduino, I thought I need the timing precision of an FPGA (and wanted to try writing hardware anyways). Not wanting to spend too much on this, I went with an EPM240, which is a really inexpensive CPLD devboard (~5€ [around $6) capable of toggling IO pins at up to 50MHz, which I hoped would be sufficient."

Fritsch's approach to the problem was to first isolate the STM8 microcontroller from capacitors and other power supply hardware that could interfere with the voltage-glitching process — though a first attempt to de-solder chip resulted in critical damage, and was replaced with a simpler removal of the ground pin and attachment of a new wire.

Initial results were not promising. "My setup seemed to work and I was able to cause seemingly undefined behavior," Fritsch notes, "but I wasn’t able to glitch the option byte loading despite brute-forcing time offset and glitch duration for many nights. I eventually realized that I’m more likely glitching the UART transmission part or my USB-to-serial converter."

Fritsch needed more data, turning to a borrowed UT2052 oscilloscope with custom-written Linux drivers to capture power data from the reset phase with different protection bit settings. "I aligned the traces," he adds, "averaged them, did consistency checks and removed too noisy ones."

That allowed Fritsch to narrow down the problem space: "Trying again with different mosfets and a refined search space I not only tried glitching the VCC and GND pins, but also the exposed voltage regulator PINs," Fritsch explains. "In hindsight this is a really obvious target, but I was very surprised when my attempts worked on first try within seconds of bruteforcing. Using the now-enabled SWIM debug interface I could simply dump the firmware. This means: STM8S readout protection is broken (though not really a surprise there)."

The full write-up is available on Fritsch's website, though the source code for the attack has not been publicly released.