STM32F4xx Implementation

[SundaresanN]

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 uses esp8266 instead of Pico.

Guide me general direction on how to add the same function to your project. Thanks!

[CTXz]

Hey, this is pretty interesting!

I was naively not aware of the fact that this exploit also applies to later generations of the STM32F series.
I will buy a couple of F2, F3 and F4 devboards and test it out. I've only skimmed through the repo but by the looks of it the target exploit firmware code appears to be virtually identical to that of the F1, leading me to believe the current attack board firmware could work with little to no modification.

For a general direction I recommend starting out by running the current dump.py script and see how far you can already get with that.

[CTXz]

I've attempted to execute the exploit on a STM32F401 Blackpill with no success. The vulnerability does get to stage 1, however, after after the reset is applied, the F4 still refuses flash access. I suspect that the F4's readout protection triggered by SRAM execution can no longer simply be removed by a soft reset. Instead, it likely also requires a power cycle (which unfortunately would reset the FPB). With RDP=0, I did get it to work, indicating that my code is likely not the culprit.

I'm also not sure how the person in the mentioned repo achieved executing the vulnerability on their F4. The SRAM execution entry point of the F1 is still being used in their attack. That's rather odd, since the F4's SRAM execution no longer uses these quirky SRAM entry points. My F4 also throws a hard fault interrupt after the power glitch has been applied, which serves as my entry point for stage 1. Their code does not seem to take this into account at all.

Perhaps my F4 is a newer revision, or maybe its a clone?

I'm going to try removing all power caps from my blackpill board as a last desperate attempt at getting this to work. If that doesn't do it, I'll try it on a F4 discovery board. I'll also try to see if this works for an F2 I have lying around.

Any progress related to this can be found under the f4-testing branch

[Angelic47]

Hello, I recently discovered this project and conducted some further in-depth research on it. Here's what I tested on my stm32f412 development board:

1. I wrote a standard hello world firmware and enabled RDP level 1 protection.
2. I set boot1 to high and boot0 to high. At this point, the stm32 was set to start from SRAM.
3. Then, I connected boot0 to low. Pulling down the rst resets the CPU, and then the stm32 starts from the user flash.
4. I observed that the stm32 was completely unable to execute the original user code unless power was reapplied. Notably, even if boot0 is set to high and boot1 to low - entering the bootloader code, the stm32 is still unable to execute the internal bootloader properly.

This indicates that the stm32f4 has some level of defense against this vulnerability. Interestingly, if step 2 had not entered SRAM startup mode but system bootloader startup mode instead, then resetting the CPU via rst would allow normal execution from user code. It seems that the stm32f4 has specifically guarded against issues with SRAM startup shellcode. The same exploit does not apply to the stm32f4.

However, approaching from the bootloader might be a direction to consider. I haven't conducted further tests for now, but from the analysis of the bootloader code (0x1fff0000 - 0x1fff5fff), the bootloader is filled with numerous checks and defenses, making it extremely difficult to construct arbitrary code execution within the bootloader.

[CTXz]

I see, that's interesting.

So what you're saying is if we find a way to patch the FPB from within the bootloader, the reset would be able to jump into the shell code!

I know there have been a couple of projects that reverse engineered the bootloader code for vulnerabilities. Namely, for glitching attacks such as https://blog.kraken.com/product/security/kraken-identifies-critical-flaw-in-trezor-hardware-wallets, which glitch the flash read command of the USART bootloader to bypass the RDP check. Their hardware set-up to pull this off utilizes an pretty fancy FPGA, and even with that, the vulnerability needs to be brute forced for a pretty long time. I've considered attempting glitching attacks as such on the Pi Pico, but whether is is even possible is yet to be determined.

I'll also try to take a closer look at the the bootloader ROM once I have the time, and see If I can spot anything interesting.

Feel free to keep us updated with your progress!

[Angelic47]

Yes, that's exactly what I'm getting at - aside from booting from SRAM, there might be another path to success. At least, that's how the hardware seems to behave.

I'm actually trying to see if it's possible to cause a fault in the bootloader's RDP (Read-out Protection) check through voltage glitching.

In fact, I have successfully induced a fault and bypassed the RDP check for a single command. However, because the bootloader checks the RDP with every command execution and has strict memory address restrictions (only reading/writing/executing from flash 0x08000000 to flash end, SRAM 0x20003000 - 0x20040000, the bootloader's own code range 0x1fff0000-0x1fffffff, and option bytes), constructing a reliable and stable Arbitrary Code Execution (ACE) is challenging.
From my observations, it would take at least two successful glitch injections to bypass the RDP check and construct an ACE.

Worse, when RDP1 is enabled, the bootloader has a few lines of code that clear everything from 0x20003000 - 0x20040000 to 0 on every reset. In other words, even with glitch injection, we have no chance of persisting in memory - any attempt must succeed in one go, without allowing the bootloader code to be executed again.

I'm trying my best to pursue this approach. As crazy as it sounds, on my xilinx zynq7000 FPGA platform implemention, inducing STM32 faults through precise timing has about a 2% - 3% success rate, which means it might be possible to achieve a pwn within a reasonable time frame.
Of course, we might still end up with nothing - who knows if ST will introduce any other obstacles along the way.

[Angelic47]

Regarding voltage fault injection, from what I know: It's not strictly necessary to use an FPGA, even though it is a very suitable solution.

Picofly managed to carry out an attack on the Switch's Tegra X1 chip using just a Raspberry Pi Pico; ESP32_nRF52_SWD even went as far as to pwn the nRF52's SWD disable protection using only an ESP32.

While FPGAs offer higher trigger precision and jitter reliability, these conditions are often "sufficient but not necessary." In fact, a fast enough MCU can achieve the same effect.

[Angelic47]

Ultimately, my attempt was unsuccessful.
Here is the story that unfolded over these past few weeks:

As mentioned before, I discovered that the STM32F412 I'm working with completely locks access to the entire flash when started in RAM mode, a measure as drastic as when a debugger is attached — it's impossible to unlock flash access without performing a power cycle.
However, I found that starting in system bootloader mode does not enforce a complete lock on the flash.

According to my analysis of the bootloader,
it is indeed possible to construct arbitrary code execution, but this is highly challenging.

Firstly, the bootloader contains a go address command that allows jumping to any address.
Its restriction is that this command can only jump to 0x08000000 (flash) or between 0x20003000-0x20040000.
Any other address will be rejected.
Additionally, the go command isn't a true jump & go: it loads the estack pointer located at address + 0x0 and jumps to the reset handler pointer at +0x4 for execution.

To make the go address usable, we must also find a way to place a valid attack payload at 0x20003000.
This isn't difficult, as the bootloader also has a write memory command that can write data to 0x20003000 in RAM.
(Writing to 0x20000000-0x20002FFF is not allowed because this is the memory used by bootloader, and ST has specific checks for this.)

Notably, when the options byte is set to level 1,
a piece of code in the bootloader's initialization section zeroes out the entire range from 0x20003000 to 0x20040000. Well done, ST.
Therefore, to construct this attack, we must glitch out a combo twice after reset, or it's a no-go.

The write memory command can write a maximum of 256 bytes at a time.
In this scenario, we definitely don't want to glitch the write memory multiple times,
as it would significantly lower the success rate of the combo.
Thus, we must complete all attacks within 256 bytes. A highly potent assembly wizardry is necessary.

Hence, we can immediately come up with the following attack plan:

1. Set the boot0 pin of the STM32F412 to system bootloader and power on;
2. Send the write memory command;
3. Glitch the target to bypass the options byte check of the write memory command;
4. Write the payload into RAM. We only have one chance, and can only write a maximum of 256 bytes;
5. Send the go address command;
6. Glitch the target to bypass the options byte check of the go address command;
7. Jump to the payload, then set the boot0 pin to flash boot and reset the device.
8. The reset vector hijacked by FPB will cause the CPU to jump to the payload stage 2 located in RAM, completing the attack.

Indeed, this plan seemed effective, and in fact, I was successful in executing the combo and running the payload in RAM. However, this was futile—I was met with a massive surprise; the data in the flash was directly destroyed.

The data returned by the payload showed that only 0x08000000 - 0x0800000f was correct;
all other addresses just repeated the contents here.
Furthermore, after powering on the STM32F412 normally again, it was no longer able to run the program in the flash.

I have absolutely no idea why this happened.
I tried many times, but the result was always the same.
After about 50~300 continuous glitches, the flash data would be found corrupted.
So, I conducted the following test:

1. Flash a regular hello world program into the STM32F412 using USB DFU, keeping RDP level 0;
2. Set the boot0 pin of the STM32F412 to system bootloader and power on;
3. Do nothing and randomly glitch the target;
4. After a certain number of attempts, observe that the STM32F412 can no longer run the program in the flash;
5. Re-enter USB DFU to be informed that the device is in RDP level 1 status, requiring a mass erase to unlock.

This means that the flash of the STM32F412 was indeed destroyed,
even corrupting the option byte (!= 0xAA or != 0xCC), making it believe that it's RDP level 1 status.

To ensure my reasoning was correct, I also conducted the following test:

1. Write a code that checks if there is a certain magic at 0x20003000, if so, jump to execute at 0x20003000;
2. Otherwise, write the payload with magic to 0x20003000;
3. Write this test code into the flash at 0x08000000, and set RDP level 1;
4. Reset, observe the STM32F412 running the program in flash normally, and that the payload was written to 0x20003000;
5. Reset again, observe the STM32F412 running the payload at 0x20003000;
6. Reset once more, discover that the STM32F412's reset vector has been hijacked by FPB, and the stage 2 located at 0x20003000 completely printed out the entire flash content.

This test result proves that my idea was correct.
However, regarding the destruction of the flash, I currently have no solution.
Perhaps the glitching process damaged the logic of the flash controller? I'm really at a loss...

If the flash controller was damaged, perhaps using EMFI (Electromagnetic Fault Injection) or laser fault injection could circumvent this issue.
However, this would no longer be feasible with just an RP2040; the cost would significantly increase, perhaps even to an unacceptable level.

Also, I don't know if other STM32F4 series devices would have the same issue; I haven't tested them yet.

This is all the results I have up to this point, for your reference.

[CTXz]

This is pretty amazing and tragic at the same time but may just provide a foundation for a successful exploit. Thanks for the update! I may join the effort once I can find some spare time :)

[BD4XIA]

This article may be helpful: https://jerinsunny.github.io/stm32_vglitch/

[manizzle]

Just to confirm, the STM32F205RET6 (i am guessing the T6 is a new revision here) will also wipe SRAM via bootloader when RDP1 is set.

[Angelic47]

So far, I've roughly confirmed that the STM32F412 has a firmware self-destruction feature. At least, the chips I have on hand behave this way.

In the past, besides attempting voltage fault injection, I even used SiliconToaster for EMFI fault injection.

The results were consistent: I could trigger the STM32 bootloader to fail twice, thereby unexpectedly executing the attack payload. However, the firmware was destroyed, and the dumped flash content was only correct for the first 16 bytes, every things followed by are same things as this 16 bytes, with an infinite loop.

Additionally, here are my further findings:

1. This attack approach is indeed feasible, and I have succeeded a few times.

   By precisely timing immediately after the glitch, once the STM32 responds with a timeout (no level changes on UART, 500 cycles at a 250 MHz FPGA clock), I immediately pull the RST low to reset the STM32. This method prevents the STM32's self-destruction process but further increases the difficulty of achieving the two faults. If successful, the attack can be completed, and the entire flash can be dumped.

   However, testing shows that this attack consumes time measured in days, with a high time cost. There is still no guarantee of completely avoiding the self-destruction function; safety and stability remain unassured. The smaller the RST window, the more likely it is to miss a potentially successful fault; the larger the RST window, the more likely it is to directly cause firmware self-destruction.

2. The self-destruction function is limited to Bootloader Boot mode.

   Testing shows that triggering faults in Bootloader Boot Mode can cause the STM32 to self-destruct. In flash boot mode, the same scenario could not be replicated by any means. Through reverse engineering of the bootloader, I did not find any relevant implementations or suspicious self-destruction function switches in the bootloader ROM code. This suggests it might be achieved through a hardware structure.

   Another interesting fact is: In Bootloader mode under RDP0, performing such fault injections can also trigger self-destruction, causing the chip to be unable to correctly read the Option Bytes and incorrectly assume that the chip is in RDP1 mode. This manifests as RDP0 suddenly appearing as RDP1.

3. The self-destruction function does not seem to be flash erasure.

   The self-destruction happens so quickly, even within 50-100 FPGA clock cycles at 250 MHz. Intuitively, this does not seem like erasing the flash, as the entire flash could not be erased so fast.

   It seems more like some method locks access to the entire flash bus (code bus). Another piece of evidence supporting this is that dumping the flash does not require switching back to flash boot mode. Once the above attack succeeds, the flash can be dumped directly in bootloader mode. I successfully performed this dump once under RDP1. Whether in flash boot mode or bootloader mode, the dump data content remains unaffected.

   Once self-destruction is triggered, the bootloader mode yields the first 16 bytes as the reset vector code of the bootloader ROM, with subsequent content looping. In flash boot mode, the first 16 bytes are the correct reset vector code from the flash, with the rest looping similarly.

   This indicates that the STM32 has a method to quickly lock down the flash bus, preventing normal flash bus operation, even preventing normal reset of the flash bus, rather than erasing the entire flash for self-destruction.

   However, despite the flash not being truly erased, there's no way to read the entire flash anymore; the flash becomes completely inaccessible.

4. Unlocking the bus lock can only be done by performing a full chip flash erase.

   Executing a full flash erase can unlock this lock, making the flash accessible again. Otherwise, the STM32 becomes a brick — its original firmware is lost. Even if it starts in flash mode again, the bus lock from the self-destruction function prevents it from normally reading and executing the original firmware.

   If it's RDP Level 2, it gets even more interesting. The chip is almost completely bricked because you can't even enter the bootloader, making full flash erase impossible.

   I haven't found any software methods to unlock this flash lock. It appears to be entirely a hardware-implemented self-destruction feature.

   However, if a full flash erase is performed, it's equivalent to reverting RDP Level 1 to RDP Level 0. This aligns with ST's official design: all is lost, mission failed.

I must say, well done, ST. This self-destruction feature may have already been extensively deployed and implemented on newer batches of STM32. I can't be sure, but according to my experiments, the STM32F412 already has such a design. The STM32F40x, F10x, and F01x I have on hand do not.

These are all my research results for your reference. It seems ST's MCU solution is more secure than we initially thought. If anyone has better ideas, feel free to discuss them here; I'm also very curious if there are any other interesting approaches or results coming up.

[yangzs001]

干得好，我有兴趣向脚本添加更改并在 F4 上进行转储，请检查 F4 的 https://github.com/lolwheel/stm32f4-rdp-workaround.git 实现，与您的工作相同，但使用 esp8266 而不是 Pico。

指导我如何将相同的函数添加到您的项目中。谢谢！

I have tested it and the power failure program will not disappear after cooling down the chip. Only a few times have the firmware been successfully read out, and most of the time the program does not run after a power failure. I think it should be a problem with the program entry point?