> 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 advertised. For example, the STM32F103C8 on the popular "bluepill" dev board is advertised as having 64 KB of flash. It actually has 128 KB of flash because it's the same chip as the STM32F103CB (this simplifies manufacturing because they can use the same die for both), it's just that ST never tested the second half of flash. In most cases you can use the second half of flash and it'll work just fine, but obviously it's not something you'd want to rely on for a commercial product.
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/
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).
As I understand it this bypasses a "please do not read" level of protection on cheap microcontrollers, not an actual secure element, so only those secrets are impacted that were not properly protected to begin with.
Scraping is almost always for obscurity to try and impede cloning. I don't really know why folks bother; it's not effective. Especially with LLMs, it's never been easier to vaguely describe a chip's connections and get plausible part numbers back. Add in traditional decapping / xray / other microscopy and it's really just not that hard to know what you're holding.
"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 like to dump. Its a noise machine with a flash card containing the sounds, but the content is encrypted. I'd like to get at the decryption key to salvage it.
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.
RDP2 has been cracked by glitching. You first need to downgrade RDP2 to RDP1 then do the RDP1 bootloader glitch. It's not exactly easy but it's well documented and can be done given enough time. Though the STM32F4 targets do have a high chance of bricking during this attack.
First I'd like to point out that "Decryptor" is an ill-chosen term: there's no encryption mechanism here, RDP is a software lock based on an internal flash state.
This dongle is very likely to be this original attack https://github.com/JohannesObermaier/f103-analysis/tree/mast... but now packaged. If you want to read more this repo has the best doc: https://github.com/CTXz/stm32f1-picopwner. It's a multi-step attack where a payload is executed from persisted SRAM (RDP1 means you can read/write to it) after a quick reset. The fact that they mention freezing the chip heavily weighs in that direction since it's needed for higher clock chips.
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.
It's probably to keep the payload in SRAM for longer.
If it's the attack I believe it to be, basically it:
1. Acts as a debugger (core blocks touching flash) and writes a 2-part payload to SRAM.
2. Detaches the debugger, straps the boot pins to boot from SRAM (payload 1)
3. Resets the board via reset pin (keeping SRAM)
4. SRAM payload 1 runs (core blocks touching flash), configuring the FPB to 'overlay' the reset vector on flash with a pointer to payload 2
5. Flicks off the power just long enough for the hardware to reset, but not long enough for the SRAM to clear (this is where I think being cold helps).
6. Device boots 'unlocked' into 'flash', but the FPB hijacked the vector table and so the CPU immediately jumps to payload 2.
7. Payload 2 can now do whatever with flash (e.g. dump it out over UART or SPI)
Freezing RAM keeps its contents intact for remarkable amounts of time. For DRAM it's long enough to unplug the DIMM from the target device and move it across to the analysis device for recovery of the data on it. It's one of those things that's hard to believe until you actually do it, that you can have the RAM totally disconnected and unpowered while it retains its contents.
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.
Anyone knows why this is called “decryption”? I thought that the mechanism was simply a fuse that would deny reading/debugging operations, is there actual crypto involved?
> 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 advertised. For example, the STM32F103C8 on the popular "bluepill" dev board is advertised as having 64 KB of flash. It actually has 128 KB of flash because it's the same chip as the STM32F103CB (this simplifies manufacturing because they can use the same die for both), it's just that ST never tested the second half of flash. In most cases you can use the second half of flash and it'll work just fine, but obviously it's not something you'd want to rely on for a commercial product.
I'd guess they also bin the 128KB flash so that when a defect occurs, they just use the other half so they can improve yields.
> 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.
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/
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).
As I understand it this bypasses a "please do not read" level of protection on cheap microcontrollers, not an actual secure element, so only those secrets are impacted that were not properly protected to begin with.
Scraping is almost always for obscurity to try and impede cloning. I don't really know why folks bother; it's not effective. Especially with LLMs, it's never been easier to vaguely describe a chip's connections and get plausible part numbers back. Add in traditional decapping / xray / other microscopy and it's really just not that hard to know what you're holding.
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 like to dump. Its a noise machine with a flash card containing the sounds, but the content is encrypted. I'd like to get at the decryption key to salvage it.
Has Level 2 been cracked?
> 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...
RDP2 has been cracked by glitching. You first need to downgrade RDP2 to RDP1 then do the RDP1 bootloader glitch. It's not exactly easy but it's well documented and can be done given enough time. Though the STM32F4 targets do have a high chance of bricking during this attack.
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.
Could you just record the sounds by using the speaker out as a mic in somewhere else?
First I'd like to point out that "Decryptor" is an ill-chosen term: there's no encryption mechanism here, RDP is a software lock based on an internal flash state.
This dongle is very likely to be this original attack https://github.com/JohannesObermaier/f103-analysis/tree/mast... but now packaged. If you want to read more this repo has the best doc: https://github.com/CTXz/stm32f1-picopwner. It's a multi-step attack where a payload is executed from persisted SRAM (RDP1 means you can read/write to it) after a quick reset. The fact that they mention freezing the chip heavily weighs in that direction since it's needed for higher clock chips.
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?
It's probably to keep the payload in SRAM for longer.
If it's the attack I believe it to be, basically it:
1. Acts as a debugger (core blocks touching flash) and writes a 2-part payload to SRAM.
2. Detaches the debugger, straps the boot pins to boot from SRAM (payload 1)
3. Resets the board via reset pin (keeping SRAM)
4. SRAM payload 1 runs (core blocks touching flash), configuring the FPB to 'overlay' the reset vector on flash with a pointer to payload 2
5. Flicks off the power just long enough for the hardware to reset, but not long enough for the SRAM to clear (this is where I think being cold helps).
6. Device boots 'unlocked' into 'flash', but the FPB hijacked the vector table and so the CPU immediately jumps to payload 2.
7. Payload 2 can now do whatever with flash (e.g. dump it out over UART or SPI)
Freezing RAM keeps its contents intact for remarkable amounts of time. For DRAM it's long enough to unplug the DIMM from the target device and move it across to the analysis device for recovery of the data on it. It's one of those things that's hard to believe until you actually do it, that you can have the RAM totally disconnected and unpowered while it retains its contents.
Very neat!
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.
Anyone knows why this is called “decryption”? I thought that the mechanism was simply a fuse that would deny reading/debugging operations, is there actual crypto involved?