8 ms·

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

189 points by kw71 8y ago

jerryr 8y ago
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 8y ago
  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 8y ago
    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 8y ago
  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 8y ago
  Thank you very much for compressing the article down to this.
bawse1 8y ago
This is pretty cool. I expect to see many proprietary firmware for many projects released on github soon.
- CapacitorSet 8y ago
  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.
  - deleted 8y ago
    [deleted]
  - duskwuff 8y ago
    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.
- bri3d 8y ago
  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 https://electronics.stackexchange.com/a/198395
- delfinom 8y ago
  And said github repos immediately DMCAed and if the companies vengeful enough, subpoenas issued to hunt down the uploader.
  - paulie_a 8y ago
    It's fairly easy to just ignore dcma requests on private systems though. You throw the letter in the garbage.
nneonneo 8y ago
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/application_note/89/12/c5/e2/0d/0e/45/7f/DM00186528.pdf/files/DM00186528.pdf/jcr:content/translations/en.DM00186528.pdf 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).
- duskwuff 8y ago
  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 8y ago
    SWD and JTAG are both disabled in RDP2. The OTP bytes were there on the F4 too.
    - duskwuff 8y ago
      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.
deleted 8y ago
[deleted]
bri3d 8y ago
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 8y ago
  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 8y ago
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 8y ago
  But this protection is meaningless if "code protect" is a single bit flip that can be downgraded with a clever mask and UV light.

189 points by kw71 8y ago

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 8y ago
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 8y ago
  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 8y ago
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 8y ago
Thank you very much for compressing the article down to this.

bawse1 8y ago

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

CapacitorSet 8y ago
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.
- deleted 8y ago
  [deleted]
- duskwuff 8y ago
  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.
bri3d 8y ago
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 https://electronics.stackexchange.com/a/198395
delfinom 8y ago
And said github repos immediately DMCAed and if the companies vengeful enough, subpoenas issued to hunt down the uploader.
- paulie_a 8y ago
  It's fairly easy to just ignore dcma requests on private systems though. You throw the letter in the garbage.

nneonneo 8y ago

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/application_note/89/12/c5/e2/0d/0e/45/7f/DM00186528.pdf/files/DM00186528.pdf/jcr:content/translations/en.DM00186528.pdf 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).

duskwuff 8y ago
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 8y ago
  SWD and JTAG are both disabled in RDP2. The OTP bytes were there on the F4 too.
  - duskwuff 8y ago
    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.

deleted 8y ago

[deleted]

bri3d 8y ago

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 8y ago
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 8y ago

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 8y ago
But this protection is meaningless if "code protect" is a single bit flip that can be downgraded with a clever mask and UV light.