Stm32f105rbt6 usart1

[luistmw]

I succesfully tested out a bluepill (works great) but ive been trying the Stm32f105rbt6 to no success. Tried thru usart1 and usart2 but get no response.

[CTXz]

Hmm, interesting

It'd be a shame if the attack doesn't work on F105's. Truth be told, I've only tested the attack on F102's (RxT6) and F103's (RxT6 & C8T6). Is the target device a simple breakout board or is it a more complex board? Sometimes caps on the reset and power lines can have an effect on the power glitching.

[luistmw]

I did remove every cap and after i put on breakout board.When i tried the original exploit i was having same issue. And tried this but didnt work either. Apparently the startup address might be different on rbt6. https://github.com/JohannesObermaier/f103-analysis/issues/1

[CTXz]

I wasn't quite aware of these differences. I'll try to get my hands on a RBT6 and see how far I can get with it. I suppose you've attempted to change the start-up address to 0x1CC as guessed by the user, right?

[CTXz]

Alright, I've done a bit of research regarding the whole start address thing. This stack overflow post turned out to be rather helpful. By the looks of it, the difference in entry points is a result of STM's quirky implementation of booting from SRAM. Because the size of the vector table apparently differs between some models, so must the value of the entry point, which is located after the vector table. STM F1's seem to deal with this by aliasing the memory block at 0x00000000 to a 16 Byte ROM which holds a minimal Interrupt Vector Table (which from my understanding is harcoded into the chip?). The second entry of this IVT is the reset vector which is set to jump to the entry point. In the case of the F1C8T6 found on the blue pill, the reset vector will jump to 0x20000108, that's the Start of the RAM + an offset of 0x108. I guess once the entry address has been jumped to, the IVT loaded in RAM is used.

Knowing this means the entry point can be easily figured out by simply booting the STM32F1 into SRAM (no flashing required) and the executing a reset halt. The value of the PC should be then set to the entry point provided to the reset vector in the ROM.

So, to figure out the entry vector for your model, simply:

1. Set BOOT0 and BOOT1 to high.
2. Connect your debugger
3. Open openocd and run reset halt
4. Check what value the PC contains (Will be shown after executing reset halt)

The last digits will provide the entry point offset that you'll need to fix in the linker file. Let me know what the offset is and whether it worked!

[luistmw]

Alright, I've done a bit of research regarding the whole start address thing. This stack overflow post turned out to be rather helpful. By the looks of it, the difference in entry points is a result of STM's quirky implementation of booting from SRAM. Because the size of the vector table apparently differs between some models, so must the value of the entry point, which is located after the vector table. STM F1's seem to deal with this by aliasing the memory block at 0x00000000 to a 16 Byte ROM which holds a minimal Interrupt Vector Table (which from my understanding is harcoded into the chip?). The second entry of this IVT is the reset vector which is set to jump to the entry point. In the case of the F1C8T6 found on the blue pill, the reset vector will jump to 0x20000108, that's the Start of the RAM + an offset of 0x108. I guess once the entry address has been jumped to, the IVT loaded in RAM is used.

Knowing this means the entry point can be easily figured out by simply booting the STM32F1 into SRAM (no flashing required) and the executing a reset halt. The value of the PC should be then set to the entry point provided to the reset vector in the ROM.

So, to figure out the entry vector for your model, simply:

1. Set BOOT0 and BOOT1 to high.
2. Connect your debugger
3. Open openocd and run reset halt
4. Check what value the PC contains (Will be shown after executing reset halt)

The last digits will provide the entry point offset that you'll need to fix in the linker file. Let me know what the offset is and whether it worked!

That worked 100% !!!!!

[luistmw]

You can probably integrate this into the script easily

[luistmw]

0x1e0 was the address

[CTXz]

Neat! Glad that worked!

Yes i was thinking about how to potentially integrate this into the scrip, ideally without requiring the target firmware to be built from scratch. Until that's done, I'll keep the issue open.

[luistmw]

Now that i think about it this can probably work way beyond the f1 chipset

[CTXz]

Hi, I've worked on a new release which should be able to automatically detect the entry point offset. I've attached it below. The target binaries have already been built, so all you need to do is to run the dump script. If you could try it out and confirm whether it works on your STM32F105, that'd be amazing!

~[stm32f1-picopwner.zip]()~

EDIT: Fixed filename case related issue. Please use this release:

stm32f1-picopwner.zip

[luistmw]

Ill test out in about an hour ill let you know on results

[luistmw]

Hi, I've worked on a new release which should be able to automatically detect the entry point offset. I've attached it below. The target binaries have already been built, so all you need to do is to run the dump script. If you could try it out and confirm whether it works on your STM32F105, that'd be amazing!

~[stm32f1-picopwner.zip]()~

EDIT: Fixed filename case related issue. Please use this release:

stm32f1-picopwner.zip

Can confirm that it is working correctly on f105rbt6

[CTXz]

Amazing, thanks for the help. The changes have been merged into main and the issue can be closed now. :tada: