Could GD32F103 support be possible ?

[cxgth]

Hey, thanks for your work and implementation.

I'm facing the same problem as described in #27.
I tried to dump the firmware of an STM32 clone (GD32F103).
Due to multiple failed attempts, I ordered a genuine STM32 blue pill and built a rig to be able to quickly swap microcrontrollers for testing.

The first attempt with a STM32F103 worked flawlessly.
So my guess is, right now it will not work with a GD32F103, but:

I found the CVE and original paper, the conference presentation @ WOOT '20 and another repository with an exploit for CKS and GD32 clones.

• CVE-2020-13465
• CVE-2020-13472
• paper from CVE
• WOOT'20 conference
• sraptor_exploit

The attack between STM32F103 and GD32F103 seems to be similar.
Do you think it could be implemented ?

[yangzs001]

I also want to know how to extract the firmware of GD32F103

[CTXz]

Thanks for the CVE references.

I'll take a look when I find the time. If they seem doable with an RP2040, I might get my hands on a GD32!

[curcius]

I would be very happy if it were possible to dump the GD32f103 and thank you very much for your effort in making it work @CTXz

[chupalt]

GD32F103 doesn't require glitching
https://github.com/JohannesObermaier/f103-analysis.git

[curcius]

GD32F103 doesn't require glitching https://github.com/JohannesObermaier/f103-analysis.git

Do you have any tutorials?

[curcius]

😭

[dolphin22]

FPB doesn't work on GD32F103. D2 method from Johannes's research doesn't work for me as well.

[Kiprus]

I tried using method D2 on the GD32F103, but only zeros were written to the RAM. The PC register has a value of 0, which suggests that there is no code execution, meaning the memory bus might be locked. I think the issue could be with the programmer or OpenOCD, as they might be accessing the core during initialization, which is causing us to get Debug_En.

[dolphin22]

I tried using method D2 on the GD32F103, but only zeros were written to the RAM. The PC register has a value of 0, which suggests that there is no code execution, meaning the memory bus might be locked. I think the issue could be with the programmer or OpenOCD, as they might be accessing the core during initialization, which is causing us to get Debug_En.

I can load image to SRAM with BOOT0 and BOOT1 HIGH. I also facing the same issue with openocd 12-dev to load_image to flash, both with stlink and jlink. But it works with st-flash not sure why.

[Kiprus]

I tried using method D2 on the GD32F103, but only zeros were written to the RAM. The PC register has a value of 0, which suggests that there is no code execution, meaning the memory bus might be locked. I think the issue could be with the programmer or OpenOCD, as they might be accessing the core during initialization, which is causing us to get Debug_En.

I can load image to SRAM with BOOT0 and BOOT1 HIGH. I also facing the same issue with openocd 12-dev to load_image to flash, both with stlink and jlink. But it works with st-flash not sure why.

Do you mean that you were able to read the firmware with RDP in this way? Can you describe how you did this?

[dolphin22]

I tried using method D2 on the GD32F103, but only zeros were written to the RAM. The PC register has a value of 0, which suggests that there is no code execution, meaning the memory bus might be locked. I think the issue could be with the programmer or OpenOCD, as they might be accessing the core during initialization, which is causing us to get Debug_En.

I can load image to SRAM with BOOT0 and BOOT1 HIGH. I also facing the same issue with openocd 12-dev to load_image to flash, both with stlink and jlink. But it works with st-flash not sure why.

Do you mean that you were able to read the firmware with RDP in this way? Can you describe how you did this?

I am unable to dump flash firmware using this method because FPB doesn't work on GD32 families. I can load firmware to SRAM (BOOT0=BOOT1=HIGH) when security protection is enabled, see photo

[curcius]

News about gd32? 🥹