[jerryr]

The tl;dr is that researchers found 3 weaknesses in an STM32's flash protection scheme. For those not familiar, these chips offer three protection levels:

RDP 0 - unlocked, all flash/ram is accessible via the debug interface

RDP 1 - flash locked, you can connect a debugger and read out RAM/peripherals, but not flash. This is intended to prevent you from dumping the flash firmware image, but allow you to perform some diagnostics via the debugger.

RDP 2 - everything's locked down. The debugger cannot access RAM, Flash, or other peripherals.

The 3 exploits are roughly:

* In RDP 1, you can't read flash directly, but you can read anything that the firmware puts in RAM. The researchers were able to extract an entire flash firmware image by watching the results of a CRC self-check that the firmware performs upon boot. By resetting the microcontroller and very precisely controlling the amount of time it's allowed to run before halting it and dumping RAM, the researchers were able to back out the firmware image by observing the CRC progression in RAM.

* The researchers noted that the bit patterns used to represent the different RDP levels in flash were sub-optimal in that only a single bit needs to be flipped to downgrade from RDP 2 to RDP 1. By deencapsulating an RDP 2 microcontroller and exposing it to UV using a carefully-constructed mask, they were able to perform such a downgrade.

* The researchers crafted their own SWD debugger interface that performed less initialization than ST's stock debugger and thus didn't immediately lock down a microcontroller in RDP 1 mode when the debugger was attached. With this modified debugger, they discovered that they could issue a flash read that would lock down the micro as expected, but would also occasionally result in the protected flash data actually appearing in the read buffer (likely due to some internal race condition bug in the microcontroller's hardware). Thus it's possible to automate a brute force extraction of the entire flash in RDP 1 mode.

Edit: Changed RDP 2 to RDP 1 in description of 3rd exploit.

[duskwuff]

Mostly correct, except for a few points:

1. RDP2 completely disables the debug interface. The microcontroller doesn't respond to debug requests in this mode.

2. As the third attack requires the microcontroller to have a working debug port, it requires it to be in RDP1. (Which could be accomplished using the second attack.)

[jerryr]

Ah, you're correct. I did think it was odd that they were able to make the debugger do anything in RDP2, but I misread it. That attack was indeed performed in RDP1.

[makomk]

A related attack (not documented here IIRC) is that if the bootloader supports encrypted firmware updates, depending on the implementation it's sometimes possible to dump the key from RAM and decrypt the firmware update itself.

[nine_k]

Thank you very much for compressing the article down to this.