Shedding Too Much Light on a Microcontroller's Firmware Protection (2017) | Hacker News Reader

Shedding Too Much Light on a Microcontroller's Firmware Protection (2017)

aisec.fraunhofer.de

189 pointskw7123 comments

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.

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.)

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.

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

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.

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...), 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).

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.

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

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.

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?

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

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

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.

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

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

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.

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.

Besides the copyright issue limiting the lifespan on GitHub specifically, I expect this attack to be undertaken mostly by highly resourced organizations in pursuit of competitive intelligence, not hobbyists in pursuit of dumping flashes to the Internet. This approach is not particularly novel - see for example the exact description of this attack in this 2015 StackOverflow comment: https://electronics.stackexchange.com/a/198395

And said github repos immediately DMCAed and if the companies vengeful enough, subpoenas issued to hunt down the uploader.

It's fairly easy to just ignore dcma requests on private systems though. You throw the letter in the garbage.

You are aware that in this case you become legally vulnerable to lawsuits from the issuing party, yes?

(Or if not in the US, there is plenty similar laws around, the EU makes you legally touchable the moment you are aware that it's a copyright violation and don't react ASAP for example)

Yes I am aware, but I am also not concerned. Honestly I can't count how many notices I've received over the last 22 years. Sometimes legitimate and sometimes not. They all go straight into the garbage. I received one when I was out of town and there was no possibility someone else was using my internet connection.

It's not good advice to give others either way even if you got lucky. Or rather, it's not good advice specifically because you got lucky. Consumer ISPs are very quick to shut down your entire connection if you get too bothersome with DMCA requests incoming.

Reply on news.ycombinator.com