Andy

Okay, STM32. RDP1 protected, means I have access to the BootROM in a limited fashion and I could potentially glitch the flash content out of it as usual by triggering a flash memory read in the boot ROM via UART, CAN or whatever other interface I want to use and glitch the RDP check.

The problem is, you only get 256 bytes per glitch back from the ROM, so you need to land a lot of glitches to extract the whole flash.
The STM32s have the nasty tendency to flip even more protection bits or trigger a full chip erase when you don't land a glitch perfectly which turns hitting a lot of glitches until you extracted the flash into a pretty exciting process.

I just dumped a ROM from an F7 and threw it into IDA. While reverse engineering, I got another idea: There is a write memory command. This not only allows writing to flash, but also to SRAM in case the chip is unlocked.
There is also a Go command which sets SP and jumps to code you point it at. Also only if you are unprotected.

Why did nobody glitch these two commands yet? First try to get some payload into SRAM using the memory write cmd, then once this succeeded, glitch the Go command until your payload is executed. Your payload then just dumps the flash to UART. I can squeeze that into 256 bytes, so there are only TWO glitches I need to land.

Am I missing something why this wouldn't work? Code running from SRAM can access flash even when RDP1 is set, right? RDP1 just causes the flash to be locked after a JTAG probe attach. So that should work.

I also have multiple tries when doing this. I would glitch it continuously without resetting it (as long as it survives the glitches) when hitting the read command, so that is not a problem eiter: Just get the payload into the chip, then hammer the Go command with glitches until it jumps.

Why did nobody document this approach yet?

/cc @stacksmashing any thoughts?

Nov 6 at 8:17pmWeb
Show threadAndyNov 7

It still feels like I am missing something. The idea is so simple, I can't be the first to come up with it. There has to be some hidden issue why this won't work.

I just wrote some simple code that lives in flash which attempts to print the first 64 bytes of flash and prints it on UART. It does this by jumping into a small read-function that I deliberately placed into SRAM.

Then I locked the chip to RDP1 and it still works. You can read flash from code executing from SRAM even if RDP1 is set.

Why did nobody try this yet?

Here is a lengthy discussion about another exploit for the F2, F3 and F4: https://github.com/CTXz/stm32f1-picopwner/issues/13
This isn't applicable to the F7 because it doesn't have the remapping feature of the flash patching unit.

This exploit requires you to get code into SRAM and then trick the chip into thinking it boots from flash which doesn't lock the flash but in reality it boots from SRAM. Between writing the code into SRAM via JTAG and executing the exploit, you need to briefly glitch the power to release the flash lock that was set by attaching a JTAG probe to load the code. That doesn't seem to work properly on the F4 according to people. However xobs made it work in the end on a chip from 2023.

Now because they failed loading code via JTAG, they thought about loading the exploit code into the SRAM by glitching the boot ROM and then execute it with another glitch.

But why so complicated? Why not glitch the write and go commands like I proposed to just execute dumping code directly? Then just dump stuff via UART using your loaded payload. I don't get it.

Also people are talking about hardware security features that seem to lock the flash. That might actually be something different. I think the option bytes are easily getting corrupted which sets PCROP config bits. That is the "Proprietary Code Read Out Protection" which marks code as execute-only and you can't read it anymore. The CPU crashes because normal ARM code uses literal pools to load constants PC-relative from the end of the function. Data fetches are also prevented when PCROP is enabled which causes these loads to fail as well and crash the CPU. I haven't verified that yet though.

Here are two blog posts that describe the PCROP issue and its effect during glitching as well:
https://jerinsunny.github.io/stm32_vglitch/
https://www.anvilsecure.com/blog/glitching-stm32-read-out-protection-with-voltage-fault-injection.html

Both of them again glitch the read memory command. Again: Why?

Time to order some test chips and build a glitch target board!

STM32F4xx Implementation · Issue #13 · CTXz/stm32f1-picopwner

Nice work, I'm interested in adding changes to script and do dumping on F4, please check this https://github.com/lolwheel/stm32f4-rdp-workaround.git implementation for F4, same as your work but use...

GitHub