Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Interesting Find: STM32 RDP1 Decryptor

carlossless.io

Post reply on HN
Print view View original

11–20 of 25 posts

Re: An Interesting Find: STM32 RDP1 Decryptor

#11

Post by seplox »

MrBuddyCasino wrote: post #2

Some context: "STM32 Read-Out Protection (RDP) secures flash memory through three levels (0, 1, 2) configured via option bytes. Level 0 allows full access (default). Level 1 restricts debugging and flash access, allowing regression to Level 0 by erasing flash. Level 2 permanently locks the device, disabling debug features, and cannot be reverted." I actually have a half-defective device with an STM32 MCU that I would…

> Has Level 2 been cracked?

It's tricky because you have to chain multiple exploits, but yes. You can temporarily downgrade from RDP2 to RDP1 via glitching. At that point, you have to move directly into RDP1 techniques without causing a reset.

The protection levels are set in the RDP register. [listed out of order...] Level 0 = 0xAA, Level 2 = 0xCC, Level 1 = anything else. Flip just a single bit and you get out of RDP2.

Edit:

https://sec-consult.com/blog/detail/secglitcher-part-1-repro...

https://www.usenix.org/system/files/conference/woot17/woot17...

Re: An Interesting Find: STM32 RDP1 Decryptor

#12

Post by brohee »

Barbing wrote: post #6

What specifically might happen in the real world because of this? Which industries have to worry? >Finally, other than glancing at the PCB, which has an SOP-16 IC with the label scraped off (presumably the microcontroller), I haven't tried analyzing how this device works yet. Scraped off for obscurity, not export/customs, right?

It makes devices using those (extremely popular) chips easy to clone as you can dump the firmware (firmware that sometimes also contain secrets, like cryptographic keys or API keys).

Not world shattering, but damn annoying (I myself handle a few millions of those in a connected object deployment and at the very least it warrants a revision of the risk analysis, as the attacker level got lowered some scenarios became more likely).

Re: An Interesting Find: STM32 RDP1 Decryptor

#13

Post by duskwuff »

mschuster91 wrote: post #9
ndiddy wrote: post #4

> One quirk: the software would always overshoot when reading. A STM32F205RB has 128KB of flash, but the tool would happily read past that boundary, padding everything beyond it with 0xFF. The actual flash contents within the valid 128KB region were correct though, so it's easy enough to just trim the output to the right size. This is likely because in many cases, ST will sell microcontrollers with more flash than ad…

> the STM32F103C8 > the STM32F103CB Damn I have a hard time visually telling these two apart and I'm on a computer...

The markings on the part are even more ambiguous. I don't have any great comparison photos, but you can probably find some online.

Re: An Interesting Find: STM32 RDP1 Decryptor

#14

Post by efesak »

Barbing wrote: post #6

What specifically might happen in the real world because of this? Which industries have to worry? >Finally, other than glancing at the PCB, which has an SOP-16 IC with the label scraped off (presumably the microcontroller), I haven't tried analyzing how this device works yet. Scraped off for obscurity, not export/customs, right?

This thing just makes it easier to dump the firmware, but it's not a revolution or anything. The STM issues have been known about for a while, and with a bit of effort, you can dump it yourself without this or any expensive tools, as I once did: https://analogic.cz/rs41-rpm411/

Re: An Interesting Find: STM32 RDP1 Decryptor

#16

Post by rts_cts »

MrBuddyCasino wrote: post #2

Some context: "STM32 Read-Out Protection (RDP) secures flash memory through three levels (0, 1, 2) configured via option bytes. Level 0 allows full access (default). Level 1 restricts debugging and flash access, allowing regression to Level 0 by erasing flash. Level 2 permanently locks the device, disabling debug features, and cannot be reverted." I actually have a half-defective device with an STM32 MCU that I would…

What sort of sound machine is it? Not sure how this would help with an encrypted flash drive.

Re: An Interesting Find: STM32 RDP1 Decryptor

#17

Post by rustyhancock »

some_random wrote: post #3

Huh, very interesting. As mentioned, I assume it's probably making use of the existing exploits against STM32 RDP1 but I'd really like to see some analysis of the device to see for sure.

Yes and why cooling to freezing might help! Slowing the clock presumably?

Re: An Interesting Find: STM32 RDP1 Decryptor

#18

Post by technothrasher »

rustyhancock wrote: post #17
some_random wrote: post #3

Huh, very interesting. As mentioned, I assume it's probably making use of the existing exploits against STM32 RDP1 but I'd really like to see some analysis of the device to see for sure.

Yes and why cooling to freezing might help! Slowing the clock presumably?

Speaking of cooling STM chips, I noticed a while ago, much to my annoyance, that the STM32C0 chips started to do really strange things below -20C even though they're rated to -40C. Luckily the pin compatible STM32G0 chips worked correctly down to -40C, so I could finish the project and ship the product.

Re: An Interesting Find: STM32 RDP1 Decryptor

#19

Post by hobs »

MrBuddyCasino wrote: post #2

Some context: "STM32 Read-Out Protection (RDP) secures flash memory through three levels (0, 1, 2) configured via option bytes. Level 0 allows full access (default). Level 1 restricts debugging and flash access, allowing regression to Level 0 by erasing flash. Level 2 permanently locks the device, disabling debug features, and cannot be reverted." I actually have a half-defective device with an STM32 MCU that I would…

Could you just record the sounds by using the speaker out as a mic in somewhere else?

Re: An Interesting Find: STM32 RDP1 Decryptor

#20

Post by XMPPwocky »

rts_cts wrote: post #16
MrBuddyCasino wrote: post #2

Some context: "STM32 Read-Out Protection (RDP) secures flash memory through three levels (0, 1, 2) configured via option bytes. Level 0 allows full access (default). Level 1 restricts debugging and flash access, allowing regression to Level 0 by erasing flash. Level 2 permanently locks the device, disabling debug features, and cannot be reverted." I actually have a half-defective device with an STM32 MCU that I would…

What sort of sound machine is it? Not sure how this would help with an encrypted flash drive.

Presumably the decryption key is in the firmware.
Post reply on HN