reading operation works perfect, write operation does not work for me

[hmeijdam]

The h3 option worked fine for reading the flash contents. I used the shellcode.bin binary. Write operation however does not work for me. When issuing Write I get the Exception error as per example below.

w 08001000 ffffffff
Write [08001000]: FFFFFFFF!!! EXCEPTION !!!
ID: 03
Restart required!

[nhancaheo]

The h3 option worked fine for reading the flash contents. I used the shellcode.bin binary. Write operation however does not work for me. When issuing Write I get the Exception error as per example below.

w 08001000 ffffffff
Write [08001000]: FFFFFFFF!!! EXCEPTION !!!
ID: 03
Restart required!

Hi hmeijdam, I tried to follow same tutorial but unsuccessful to read out flash content. Did you use external UART reader? Cause JP4 doesn't work when I flash attachboard binary file. Thanks!

[JohannesObermaier]

Hi all, the read/write functionality accesses memory directly but has no flash-writer implemented. Let me explain some details on how this works:

The read/write in the PoC is implemented as a simple load/store from/to an address. Reading and writing RAM and peripherals can be done directly. Also READING flash memory is possible. But the chip requires additional steps to WRITE into the flash memory, i.e., enabling memory programming in the flash memory interface peripheral, triggering (and waiting) for the page erase, and then writing data. This is beyond the scope of this PoC.

I am sure that the PoC can be extended to support your use case. There is documentation available, e.g., the PM0075 has further information on how to write to flash memory.

I am leaving this open as I am willing to accept pull requests for such features.

[nhancaheo]

Hi all, the read/write functionality accesses memory directly but has no flash-writer implemented. Let me explain some details on how this works:

The read/write in the PoC is implemented as a simple load/store from/to an address. Reading and writing RAM and peripherals can be done directly. Also READING flash memory is possible. But the chip requires additional steps to WRITE into the flash memory, i.e., enabling memory programming in the flash memory interface peripheral, triggering (and waiting) for the page erase, and then writing data. This is beyond the scope of this PoC.

I am sure that the PoC can be extended to support your use case. There is documentation available, e.g., the PM0075 has further information on how to write to flash memory.

I am leaving this open as I am willing to accept pull requests for such features.

Thanks for your explanation! I failed to replicate H3 exploit method. After glitching, STM32F103 seems booting to FLASH instead of SRAM even BOOT1=1. Steps which I already tried. 1/ Flash STM32F103 with blinking PC13 led and output signal on serial. Code works for sure! 2/ Set RDP via STM32CodeProgrammer, re-connect -> DATA READ FAILED 3/ Wiring as instructed. Voltage supplied to DUT is around 2.8-2.9V which is okay for openocd to connect 4/ Load shellcode.bin to SRAM at 0x20000000, terminated openocd 5/ Press Blue button on STM32F3 Discovery board, LD8->LD9->LD10, shellcode doesn't appears on serial and PC13 of DUT blinks.

Can you please give me hints what went wrong? I tried more than 10 times already. I noticed that "h3-attack.bin" from "bin" folder is different from compiled file using STM32CubeIDE. Thanks!

[JohannesObermaier]

hard to tell what goes wrong... you could verify step by step how far you get in the PoC code. e.g., if the SRAM code "survives" the glitch, if the Flash Patch Unit was configured correctly and so on.

[nhancaheo]

hard to tell what goes wrong... you could verify step by step how far you get in the PoC code. e.g., if the SRAM code "survives" the glitch, if the Flash Patch Unit was configured correctly and so on.

Thanks for your hints! It works for me by removing capacitor C2 capacitor on RESET pin which prevents voltage glitching from working. I confirmed that h3 works flawlessly for me. Thanks again!

[JohannesObermaier]

Great! I also added your feedback to the README.

[darren-Dreams]

Hi all, the read/write functionality accesses memory directly but has no flash-writer implemented. Let me explain some details on how this works: The read/write in the PoC is implemented as a simple load/store from/to an address. Reading and writing RAM and peripherals can be done directly. Also READING flash memory is possible. But the chip requires additional steps to WRITE into the flash memory, i.e., enabling memory programming in the flash memory interface peripheral, triggering (and waiting) for the page erase, and then writing data. This is beyond the scope of this PoC. I am sure that the PoC can be extended to support your use case. There is documentation available, e.g., the PM0075 has further information on how to write to flash memory. I am leaving this open as I am willing to accept pull requests for such features.

Thanks for your explanation! I failed to replicate H3 exploit method. After glitching, STM32F103 seems booting to FLASH instead of SRAM even BOOT1=1. Steps which I already tried. 1/ Flash STM32F103 with blinking PC13 led and output signal on serial. Code works for sure! 2/ Set RDP via STM32CodeProgrammer, re-connect -> DATA READ FAILED 3/ Wiring as instructed. Voltage supplied to DUT is around 2.8-2.9V which is okay for openocd to connect 4/ Load shellcode.bin to SRAM at 0x20000000, terminated openocd 5/ Press Blue button on STM32F3 Discovery board, LD8->LD9->LD10, shellcode doesn't appears on serial and PC13 of DUT blinks.

Can you please give me hints what went wrong? I tried more than 10 times already. I noticed that "h3-attack.bin" from "bin" folder is different from compiled file using STM32CubeIDE. Thanks!

Hi nhancaheo, I tried to follow H3, but failed to read Flash. I only receive 0xFE, 0xFE when I use CuteCom? 1) "Power up both boards" 2) "Open the serial interface connected to the DuT (9600, n, 8, 1)" 3) "Startup the debugger for the DuT "openocd -f ... 4) "Upload the shellcode into the DuT's SRAM", before that, use "reset halt"? 5) "Disconnect the debugger", how did you operate it, can you describe the operation in detail, disconnect SWD ~ CN4-Pin1, CN4-Pin3?

[nhancaheo]

Hi all, the read/write functionality accesses memory directly but has no flash-writer implemented. Let me explain some details on how this works: The read/write in the PoC is implemented as a simple load/store from/to an address. Reading and writing RAM and peripherals can be done directly. Also READING flash memory is possible. But the chip requires additional steps to WRITE into the flash memory, i.e., enabling memory programming in the flash memory interface peripheral, triggering (and waiting) for the page erase, and then writing data. This is beyond the scope of this PoC. I am sure that the PoC can be extended to support your use case. There is documentation available, e.g., the PM0075 has further information on how to write to flash memory. I am leaving this open as I am willing to accept pull requests for such features.

Thanks for your explanation! I failed to replicate H3 exploit method. After glitching, STM32F103 seems booting to FLASH instead of SRAM even BOOT1=1. Steps which I already tried. 1/ Flash STM32F103 with blinking PC13 led and output signal on serial. Code works for sure! 2/ Set RDP via STM32CodeProgrammer, re-connect -> DATA READ FAILED 3/ Wiring as instructed. Voltage supplied to DUT is around 2.8-2.9V which is okay for openocd to connect 4/ Load shellcode.bin to SRAM at 0x20000000, terminated openocd 5/ Press Blue button on STM32F3 Discovery board, LD8->LD9->LD10, shellcode doesn't appears on serial and PC13 of DUT blinks. Can you please give me hints what went wrong? I tried more than 10 times already. I noticed that "h3-attack.bin" from "bin" folder is different from compiled file using STM32CubeIDE. Thanks!

Hi nhancaheo, I tried to follow H3, but failed to read Flash. I only receive 0xFE, 0xFE when I use CuteCom?

1. "Power up both boards"
2. "Open the serial interface connected to the DuT (9600, n, 8, 1)"
3. "Startup the debugger for the DuT "openocd -f ...
4. "Upload the shellcode into the DuT's SRAM", before that, use "reset halt"?
5. "Disconnect the debugger", how did you operate it, can you describe the operation in detail, disconnect SWD ~ CN4-Pin1, CN4-Pin3?

Make sure all wirings are correct, check voltage supply from PD0,PD1 (~around 2.9V is okay), you may need to remove capacitors on 3.3V and RESET lines. You can try to use this openocd command "openocd -f interface/stlink-v2-1.cfg -f target/stm32f1x.cfg -c "init;load_image shellcode.bin 0x20000000;exit;", remember to replace stlink-v2-1.cfg with your actual interface. It should display "1832 bytes written" and then press BLUE button.

[hmeijdam]

Hi all, the read/write functionality accesses memory directly but has no flash-writer implemented. Let me explain some details on how this works:

The read/write in the PoC is implemented as a simple load/store from/to an address. Reading and writing RAM and peripherals can be done directly. Also READING flash memory is possible. But the chip requires additional steps to WRITE into the flash memory, i.e., enabling memory programming in the flash memory interface peripheral, triggering (and waiting) for the page erase, and then writing data. This is beyond the scope of this PoC.

I am sure that the PoC can be extended to support your use case. There is documentation available, e.g., the PM0075 has further information on how to write to flash memory.

I am leaving this open as I am willing to accept pull requests for such features.

Ok, that makes sense. It was just my misinterpretation of the feature. It helped me already a lot in being able to repair a device that had a blown-up microprocessor.

[darren-Dreams]

Hi all, the read/write functionality accesses memory directly but has no flash-writer implemented. Let me explain some details on how this works: The read/write in the PoC is implemented as a simple load/store from/to an address. Reading and writing RAM and peripherals can be done directly. Also READING flash memory is possible. But the chip requires additional steps to WRITE into the flash memory, i.e., enabling memory programming in the flash memory interface peripheral, triggering (and waiting) for the page erase, and then writing data. This is beyond the scope of this PoC. I am sure that the PoC can be extended to support your use case. There is documentation available, e.g., the PM0075 has further information on how to write to flash memory. I am leaving this open as I am willing to accept pull requests for such features.

Thanks for your explanation! I failed to replicate H3 exploit method. After glitching, STM32F103 seems booting to FLASH instead of SRAM even BOOT1=1. Steps which I already tried. 1/ Flash STM32F103 with blinking PC13 led and output signal on serial. Code works for sure! 2/ Set RDP via STM32CodeProgrammer, re-connect -> DATA READ FAILED 3/ Wiring as instructed. Voltage supplied to DUT is around 2.8-2.9V which is okay for openocd to connect 4/ Load shellcode.bin to SRAM at 0x20000000, terminated openocd 5/ Press Blue button on STM32F3 Discovery board, LD8->LD9->LD10, shellcode doesn't appears on serial and PC13 of DUT blinks. Can you please give me hints what went wrong? I tried more than 10 times already. I noticed that "h3-attack.bin" from "bin" folder is different from compiled file using STM32CubeIDE. Thanks!

Hi nhancaheo, I tried to follow H3, but failed to read Flash. I only receive 0xFE, 0xFE when I use CuteCom?

1. "Power up both boards"
2. "Open the serial interface connected to the DuT (9600, n, 8, 1)"
3. "Startup the debugger for the DuT "openocd -f ...
4. "Upload the shellcode into the DuT's SRAM", before that, use "reset halt"?
5. "Disconnect the debugger", how did you operate it, can you describe the operation in detail, disconnect SWD ~ CN4-Pin1, CN4-Pin3?

Make sure all wirings are correct, check voltage supply from PD0,PD1 (~around 2.9V is okay), you may need to remove capacitors on 3.3V and RESET lines. You can try to use this openocd command "openocd -f interface/stlink-v2-1.cfg -f target/stm32f1x.cfg -c "init;load_image shellcode.bin 0x20000000;exit;", remember to replace stlink-v2-1.cfg with your actual interface. It should display "1832 bytes written" and then press BLUE button.

Hi nhancaheo, I tried successfully on the chips STM32F103C8 and STM32F103R8, but failed on STM32F103VC. Have you tested successfully, in other series of STM32F1

[hmeijdam]

hard to tell what goes wrong... you could verify step by step how far you get in the PoC code. e.g., if the SRAM code "survives" the glitch, if the Flash Patch Unit was configured correctly and so on.

Thanks for your hints! It works for me by removing capacitor C2 capacitor on RESET pin which prevents voltage glitching from working. I confirmed that h3 works flawlessly for me. Thanks again!

I'm glad you found this. Yesterday I got very confused that I could not repeat h3 on another STM32F103C6 that I needed to extract for a repair, but in the end removing C2 made it work right away.