Ok, I think I am ready to close the firmware readout topic.
My 2nd STM32F051 board arrived, and as expected, I can simply reproduce the frauenhofer result, and readout a RDP-1 protected board.
(see images)
It also means my setup is correct, and so the same method cannot be used on a F1 board.
Not unexpected, but at least I now also actually hacked a F051 board, so give my failed F103 attempts some credibility.
tl;dr; some more insight why F0 != F1
Busting open the STM32 has been tried for this version, you should look 1-2 pages back, due to the fact that the JTAG interface shares the pins with the SWI interface we're using too much time switching the interfaces and lose the race, ......
Well, to go into detail: That is not *the* reason, it is merely *one* of the many possible reasons. It could really be any of these:
- F0 vs F1 have different protection implementation, F0 has 2 levels, F1 has 1 level - (die difference)
- F0 vs F1 have different debug implementations. F0 has only SWD, F1 has JTAG and SWD - (die difference)
- F0 vs F1 have different debug implementations. F0 has only SWD, F1 has JTAG and SWD - (switching to SWD may already trigger the lockdown)
- F0 vs F1 have different core bus matrix design. F0 with M0 core reads flash over shared bus. F1 with M3 code has dedicated ICODE bus (hack is based on bus conflict race)
All 4 of the items above mean that there is a key difference on the section specifically relevant to this attack, so a relevant part of the chip die was redesigned between the two chip families, and so any bug could or could not be there.
So, does that mean the F1 is uncrackable? I do not know. But it does mean that it was rather naive of me to think/hope the F0 debug attack would simply map to the F1.
We may think the chips are similar because we use them similar. But they are really different though and through.
If F1 is hackable, it would need all new top-level base reseach
There is still a chance to replace the STM32 quarz with external very slow clock source, but the prognosis is not so good.
So far, if there is no hidden external command over the serial line to overwrite the STM32 firmware than the only solution is to write a new one.
Alas no. I lol'ed because when this was mentioned, I literally was looking at the clock diagram on my other monitor.
But (apart from the arguments above) the flash controller has its own fixed build in RC clock. To win the race (if one exists on the F1) we would have to make the flash controller slower, and the debug access (APB bus and AHB bus) faster.
And that is the opposite of what we can do. Officially, we can make APB/AHB slower. I guess we could try overclocking. But we do not even know if there is a race condition at all, the F1 is just too different. So I repeat, it would need all new research from the bare basics, not buiding on top of Frauenhofer. Where do we stop, I was not planning on promoting on this.
So, not to be negative, but I am calling it quits.