An Interesting Find: STM32 RDP1 Decryptor • Hacker News Board

Re: An Interesting Find: STM32 RDP1 Decryptor

#21

Post by Graziano_M » Tue, Mar 03, 2026, 2:53 AM UTC

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?

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)

Re: An Interesting Find: STM32 RDP1 Decryptor

#22

Post by gquere » Tue, Mar 03, 2026, 7:27 AM UTC

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.

Re: An Interesting Find: STM32 RDP1 Decryptor

#23

Post by gquere » Tue, Mar 03, 2026, 7:29 AM UTC

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…

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.

Re: An Interesting Find: STM32 RDP1 Decryptor

#24

Post by rustyhancock » Tue, Mar 03, 2026, 9:59 AM UTC

Graziano_M wrote: post #21

rustyhancock wrote: post #17

Earlier quoted context omitted.

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 vec…

Very neat!

Re: An Interesting Find: STM32 RDP1 Decryptor

#25

Post by pseudohadamard » Wed, Mar 04, 2026, 3:05 PM UTC

Graziano_M wrote: post #21

rustyhancock wrote: post #17

Earlier quoted context omitted.

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 vec…

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.