
Shedding Too Much Light on a Microcontroller's Firmware Protection (2017) - kw71
https://www.aisec.fraunhofer.de/en/FirmwareProtection.html
======
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.

------
nneonneo
It looks like many of STM’s newer chips (at least STM32F4, STM32L1) use a fuse
to protect RDP level 2 (per e.g.
[https://www.st.com/content/ccc/resource/technical/document/a...](https://www.st.com/content/ccc/resource/technical/document/application_note/89/12/c5/e2/0d/0e/45/7f/DM00186528.pdf/files/DM00186528.pdf/jcr:content/translations/en.DM00186528.pdf)),
making the downgrade attack significantly harder to pull off. It would be nice
to know if this was indeed the case, because then there would be a viable
mitigation for these exploits (move to a different chip family and enable RDP
2 there).

~~~
duskwuff
I'm not sure there's actually any difference. The language describing memory
protection in the reference manuals for STM32F0 and STM32F4 is largely
identical; the only difference is that the F4 manual mentions that JTAG
boundary scan is disabled (which is irrelevant to F0, as that family only
supports SWD).

Some newer ST parts, like the F7 series, have OTP fuses which can be
programmed in addition to the flash option bytes (which control read
protection, among other things). However, the OTP fuses have no hardware
effect -- they're just for use in user applications. Additionally, it isn't
even clear they're truly OTP, or if they're just flash with weird write
protection.

~~~
flyinglizard
SWD and JTAG are both disabled in RDP2. The OTP bytes were there on the F4
too.

~~~
duskwuff
Right; the specific quote I'm referring to is:

> The JTAG port is permanently disabled when Level 2 is active (acting as a
> JTAG fuse). As a consequence, boundary scan cannot be performed.

(RM0385, page 89)

I'm pretty sure that this quote is only intended to mean that setting RDP2
disables JTAG boundary scan, _as if_ a JTAG fuse were blown. I don't believe
there is any actual fuse involved; AN4701 (the document you're quoting) may be
the result of another ST employee misinterpreting the reference manual as a
statement that there is an actual fuse.

~~~
nneonneo
That's too bad - I would call that misleading documentation. Is there a
reliable way to check for sure whether they mean a physical fuse, or a
"virtual" fuse derived from the flash bits?

------
bri3d
I believe the escalation attacks and especially the race attack is both novel
and fascinating, but the UV bitflipping attack for STM32 specifically has been
known for quite some time - see for example this 2015 StackOverflow comment:
[https://electronics.stackexchange.com/a/198395](https://electronics.stackexchange.com/a/198395)

~~~
bacon_waffle
Bunnie Huang made a nice post describing the UV process for a different micro:
[https://www.bunniestudios.com/blog/?page_id=40](https://www.bunniestudios.com/blog/?page_id=40)

------
delfinom
With the ARMs I use, once you enable code protect, the entire JTAG/SWD
interface goes dead. Only a hardware erase triggered by a auxiliary pin can
clear it and re-enable the interface. And its not just reduced functionality,
its complete disabling of the debug interface that occurs.

~~~
Phlarp
But this protection is meaningless if "code protect" is a single bit flip that
can be downgraded with a clever mask and UV light.

------
bawse1
This is pretty cool. I expect to see many proprietary firmware for many
projects released on github soon.

~~~
CapacitorSet
Eh, it still requires to de-encapsulate the controller, make a mask and expose
the controller to UV light, it's not a super easy process.

~~~
duskwuff
I know someone who's able to reliably perform the deprotection attack in their
home lab. It takes some practice, but it's well within reach for an attacker
with even modest resources.

