6 ms·

Exceptional failure: breaking the STM32F1 read-out protection

103 points by bcantrill 7y ago

deleted 7y ago
[deleted]
leggomylibro 7y ago
I think you can thank this sort of hack for the widespread availability of cheap cloned "ST-Link" debuggers. They use STM32F103 or F102 chips inside, with firmware that was probably lifted from the debuggers on ST's evaluation boards. As recently as a few years ago, it was unusual to see standalone debugging hardware in the $2-20 range. Sometimes I wonder if ST bristled at the...reuse...of their IP, but it probably did more to promote STM32s as a learning platform than anything that ST did in that time period.
- saagarjha 7y ago
  > They use STM32F103 or F102 chips inside, with firmware that was probably lifted from the debuggers on ST's evaluation boards. I wonder if it was lifted using a ST-Link debugger…
- osamagirl69 7y ago
  I am not sure if it was always the case, but at least with ST and NXP/freescale you can download the firmware for their debugger from the website for free. I suspect that it was a strategic decision by ST to release their dev kits for cheap (<$10 for a stm32 dev board with programmer!) to drive developer/hobby/edu interest in hopes of people using their chips in production. Come to think of it, I think it was actually TI and the MSP430 that started the trend with the $4.30 kits with a socketed msp430 micro and onboard programmer. ST was the first to try it with an ARM as far as I know...
  - nrp 7y ago
    Both were likely a response to Arduino presumably increasing the adoption of AVR without Atmel having to do anything. I recall the MSP430 kits being pitched that way in any case.
- userbinator 7y ago
  but it probably did more to promote STM32s as a learning platform than anything that ST did in that time period. ...and thus drive further product sales in the future. If you think about it, sales of development hardware are not going to be frequent nor recurring, while sales of the actual product dominate their profits. I'm personally glad that companies are starting to see the advantages of freely available documentation and cheap development hardware, and the days of 4/5-figure development boards with secret NDA documentation are slowing passing; ST was (and in some ways still is) one of the notoriously closed ones.
- markrages 7y ago
  There is an open-source firmware that is better in many ways. https://github.com/blacksphere/blackmagic https://github.com/blacksphere/blackmagic You can even debug on a $2 "blue pill" or wirelessly on a $1 esp8266 board. It has certainly not hindered STM32 popularity.
- fest 7y ago
  There's actually even more than this to low price. I have seen knock-off ST-Link dongles with STM32F103C8 MCUs that are not supposed to have enough flash memory for the stlink firmware, yet they functioned. How? Turns out they physically have more flash memory, but the accessible flash area is limited by programming tools and documentation to 64KiB (most likely price segmentation, but maybe there's a flash page remapping mechanism that would allow to bin devices based on manufacturing yield).
kosma 7y ago
I've talked to Johannes Obermaier in the past... very nice guy. It's not their first bypass, and hopefully not the last either. PS. I actually have yet another STM32F1 RDP bypass in my archive, waiting to be published. It used a technique where the MCU writes its own debug registers... pretty crazy stuff. If only I had some free time to write a proper publication about it...
- userbinator 7y ago
  If only I had some free time to write a proper publication about it... You could just drop some hints on a hardware forum and let the community figure out the rest.
ajross 7y ago
tl;dr: The processor protects data accesses to the internal flash while the hardware debugger is connected so people with hardware access can't read out the code and config. But this protection only applies to the data side of the Harvard architecture buses. The instruction bus is used by the hardware to fetch the reset vector on a hardware reset. But the vector table is under software control. So by changing the reset vector to point to an arbitrary address in flash, then resetting the CPU under the debugger, you can get it to load your desired word from memory into the PC. Pretty clever.
ohazi 7y ago
To be fair, "restricting" flash readout while allowing hardware debug access always seemed like a minefield, and I would hope that anyone with a security sensitive application would have seen this from a mile away. You could have a completely bug-free, constant-time, constant-power cryptographic library running on one of these microcontrollers, and debug access would allow you to reliably extract encryption keys just by examining the execution path. The amount of processor and system state that you have access to with a hardware ARM debugger is crazy, but that isn't really the problem -- you can extract a ton of state with a minimal debugger too. Just a log of instruction pointer values would get you 90% of the way there. I think it's reasonable to assume that microcontrollers with exposed debug interfaces simply cannot be made secure, just as people generally assume that it's game over once someone has physical access to a computer.
- mrlambchop 7y ago
  Yup - this exactly. The JTAG fuses should be blown on all devices that need to secure their flash (or secrets). Working on these specific processors around 5 years ago, we implemented a serial port based "unlock" that would generate a challenge/response from the device that if correctly acknowledged, would unlock the JTAG whilst the chip has power (it locks again when it looses power). This worked great - we spent a lot of time on the UART driver to make sure it was super simple and robust during the period when it could listen to incoming bytes (no interrupts etc...).
- remcob 7y ago
  Modern cryptography libraries make sure that the execution path (and memory access patterns) do not depend on sensitive data. Usually this is what is meant with 'constant-time'. If a debugger can read out registers or memory you can just read out the sensitive material of course.
  - ohazi 7y ago
    Whoops... Yeah, you're right. You wouldn't expect to see instructions like bne, bge, etc. that depend on key material directly, so you wouldn't be able to rely the instruction pointer alone. Instead, you might see instructions like addlt, so you'd also need to inspect the value before and after, which, as you correctly state, the debugger will happily let you do.
userbinator 7y ago
IMHO unlike the tone of the article, this is cause for celebration, like every other time DRM is broken. Now all the proprietary firmware in those otherwise useless/insecure IoT devices etc. can be more easily reverse-engineered and replaced, possibly driving more hardware reuse and reducing e-waste. http://www.gnu.org/philosophy/right-to-read.en.html http://www.gnu.org/philosophy/right-to-read.en.html
- the_pwner224 7y ago
  DRM can be used for good as well as bad; it is about control. Most DRM is used for corporations to control you. But you can use things like this readout protection and Restricted ("Secure") Boot to get control over your own devices. If the BIOS lets you use your own keys (many do), Restricted Boot prevents attackers from booting unauthorized software on your computer. Similarly readout protection just hides the code on the device; this is useful for anyone who wants added security (security through obscurity is not perfect but it is always helpful). In that regard this news is bad since it means a security tool has been broken. But it is good in that the security tool was very often used by evildoers. Of course both of these examples rely on you trusting the bios & rdp implementation - ideally they would be open source.
  - saagarjha 7y ago
    > Similarly readout protection just hides the code on the device; this is useful for anyone who wants added security (security through obscurity is not perfect but it is always helpful). Trying to hide your code is a stupid thing to do. Trying to hide cryptographic keys is more useful (though still often only used for DRM applications) but preventing people from dumping your firmware is misguided.
    - bfrog 7y ago
      Where do you think keys are stored on occasion?
      - saagarjha 7y ago
rollulus 7y ago
I'm curious how they managed to get in contact with STM. I once discovered a silicon error in their STM32F0 but failed to get in touch at all.

103 points by bcantrill 7y ago

deleted 7y ago

[deleted]

I think you can thank this sort of hack for the widespread availability of cheap cloned "ST-Link" debuggers. They use STM32F103 or F102 chips inside, with firmware that was probably lifted from the debuggers on ST's evaluation boards. As recently as a few years ago, it was unusual to see standalone debugging hardware in the $2-20 range. Sometimes I wonder if ST bristled at the...reuse...of their IP, but it probably did more to promote STM32s as a learning platform than anything that ST did in that time period.

saagarjha 7y ago
> They use STM32F103 or F102 chips inside, with firmware that was probably lifted from the debuggers on ST's evaluation boards. I wonder if it was lifted using a ST-Link debugger…
osamagirl69 7y ago
I am not sure if it was always the case, but at least with ST and NXP/freescale you can download the firmware for their debugger from the website for free. I suspect that it was a strategic decision by ST to release their dev kits for cheap (<$10 for a stm32 dev board with programmer!) to drive developer/hobby/edu interest in hopes of people using their chips in production. Come to think of it, I think it was actually TI and the MSP430 that started the trend with the $4.30 kits with a socketed msp430 micro and onboard programmer. ST was the first to try it with an ARM as far as I know...
- nrp 7y ago
  Both were likely a response to Arduino presumably increasing the adoption of AVR without Atmel having to do anything. I recall the MSP430 kits being pitched that way in any case.
userbinator 7y ago
but it probably did more to promote STM32s as a learning platform than anything that ST did in that time period. ...and thus drive further product sales in the future. If you think about it, sales of development hardware are not going to be frequent nor recurring, while sales of the actual product dominate their profits. I'm personally glad that companies are starting to see the advantages of freely available documentation and cheap development hardware, and the days of 4/5-figure development boards with secret NDA documentation are slowing passing; ST was (and in some ways still is) one of the notoriously closed ones.
markrages 7y ago
There is an open-source firmware that is better in many ways. https://github.com/blacksphere/blackmagic https://github.com/blacksphere/blackmagic You can even debug on a $2 "blue pill" or wirelessly on a $1 esp8266 board. It has certainly not hindered STM32 popularity.
fest 7y ago
There's actually even more than this to low price. I have seen knock-off ST-Link dongles with STM32F103C8 MCUs that are not supposed to have enough flash memory for the stlink firmware, yet they functioned. How? Turns out they physically have more flash memory, but the accessible flash area is limited by programming tools and documentation to 64KiB (most likely price segmentation, but maybe there's a flash page remapping mechanism that would allow to bin devices based on manufacturing yield).

kosma 7y ago

I've talked to Johannes Obermaier in the past... very nice guy. It's not their first bypass, and hopefully not the last either. PS. I actually have yet another STM32F1 RDP bypass in my archive, waiting to be published. It used a technique where the MCU writes its own debug registers... pretty crazy stuff. If only I had some free time to write a proper publication about it...

userbinator 7y ago
If only I had some free time to write a proper publication about it... You could just drop some hints on a hardware forum and let the community figure out the rest.

ajross 7y ago

tl;dr: The processor protects data accesses to the internal flash while the hardware debugger is connected so people with hardware access can't read out the code and config. But this protection only applies to the data side of the Harvard architecture buses. The instruction bus is used by the hardware to fetch the reset vector on a hardware reset. But the vector table is under software control. So by changing the reset vector to point to an arbitrary address in flash, then resetting the CPU under the debugger, you can get it to load your desired word from memory into the PC. Pretty clever.

ohazi 7y ago

To be fair, "restricting" flash readout while allowing hardware debug access always seemed like a minefield, and I would hope that anyone with a security sensitive application would have seen this from a mile away. You could have a completely bug-free, constant-time, constant-power cryptographic library running on one of these microcontrollers, and debug access would allow you to reliably extract encryption keys just by examining the execution path. The amount of processor and system state that you have access to with a hardware ARM debugger is crazy, but that isn't really the problem -- you can extract a ton of state with a minimal debugger too. Just a log of instruction pointer values would get you 90% of the way there. I think it's reasonable to assume that microcontrollers with exposed debug interfaces simply cannot be made secure, just as people generally assume that it's game over once someone has physical access to a computer.

mrlambchop 7y ago
Yup - this exactly. The JTAG fuses should be blown on all devices that need to secure their flash (or secrets). Working on these specific processors around 5 years ago, we implemented a serial port based "unlock" that would generate a challenge/response from the device that if correctly acknowledged, would unlock the JTAG whilst the chip has power (it locks again when it looses power). This worked great - we spent a lot of time on the UART driver to make sure it was super simple and robust during the period when it could listen to incoming bytes (no interrupts etc...).
remcob 7y ago
Modern cryptography libraries make sure that the execution path (and memory access patterns) do not depend on sensitive data. Usually this is what is meant with 'constant-time'. If a debugger can read out registers or memory you can just read out the sensitive material of course.
- ohazi 7y ago
  Whoops... Yeah, you're right. You wouldn't expect to see instructions like bne, bge, etc. that depend on key material directly, so you wouldn't be able to rely the instruction pointer alone. Instead, you might see instructions like addlt, so you'd also need to inspect the value before and after, which, as you correctly state, the debugger will happily let you do.

userbinator 7y ago

IMHO unlike the tone of the article, this is cause for celebration, like every other time DRM is broken. Now all the proprietary firmware in those otherwise useless/insecure IoT devices etc. can be more easily reverse-engineered and replaced, possibly driving more hardware reuse and reducing e-waste. http://www.gnu.org/philosophy/right-to-read.en.html http://www.gnu.org/philosophy/right-to-read.en.html

the_pwner224 7y ago
DRM can be used for good as well as bad; it is about control. Most DRM is used for corporations to control you. But you can use things like this readout protection and Restricted ("Secure") Boot to get control over your own devices. If the BIOS lets you use your own keys (many do), Restricted Boot prevents attackers from booting unauthorized software on your computer. Similarly readout protection just hides the code on the device; this is useful for anyone who wants added security (security through obscurity is not perfect but it is always helpful). In that regard this news is bad since it means a security tool has been broken. But it is good in that the security tool was very often used by evildoers. Of course both of these examples rely on you trusting the bios & rdp implementation - ideally they would be open source.
- saagarjha 7y ago
  > Similarly readout protection just hides the code on the device; this is useful for anyone who wants added security (security through obscurity is not perfect but it is always helpful). Trying to hide your code is a stupid thing to do. Trying to hide cryptographic keys is more useful (though still often only used for DRM applications) but preventing people from dumping your firmware is misguided.
  - bfrog 7y ago
    Where do you think keys are stored on occasion?
    - saagarjha 7y ago

rollulus 7y ago

I'm curious how they managed to get in contact with STM. I once discovered a silicon error in their STM32F0 but failed to get in touch at all.