STM32F read-out protection basically useless?

[yakabmarci]

I know this was cracked before, but required high skills and expensive equipment, but now

this method makes it really easy, basically anyone can do it.

Any official statement concerning this from ST?

Like the list of devices which are affected, possible mitigation solutions.

This seems to be a pretty big oops, basically makes stm32 unusable for other than hobby projects

See page for details:

https://blog.zapb.de/stm32f1-exceptional-failure/

[berendi]

> basically makes stm32 unusable for other than hobby projects

What, should I be afraid now that someone breaks into our basement with a Segger probe, and uploads some malicious firmware into the washing machine that ruins my socks?

[TDK]

I think you’re overestimating how much getting 90-95% of a file will help you. Good luck reconstructing the last 5-10% in assembly code.

[waclawek.jan]

Also, it's probably dealing with the ancient 'F1 family only because that's probably the only one not implementing RDP Level 2.

The authors conveniently omitted this fact.

 They do mention it, sort of ("For example, the debug interface of the STM32F0 series can be entirely switched off. In contrast, the STM32F1 series does not directly support this, but relies on another approach.")

The trick is clever though, probably works on every Cortex-M3/M4 (M7?) with protection schemes which don't disable the debugger interface, and there are firmwares where leaked portions might be detrimental.

JW

[Tesla DeLorean]

>>I know this was cracked before, but required high skills and expensive equipment, but now this method makes it really easy, basically anyone can do it.

I think the thresholds are massively overstated, a janitor has "access" to expensive equipment, and "skills" can be mastered by a singular teenager.

[Tesla DeLorean]

It substantially changes the attack surface, and might yield enough information to completely breach the device through secondary means, or enough to expose the secret sauce..

[yakabmarci]

maybe your washing machine has a secret algorithm specially developed for socks, and the evil hacker breaks into your basement, messes with the socks calibrations, then your socks will be forever ruined, have you thought about that?

[yakabmarci]

so what are you saying? ... meh.. it was broken anyway...

If before was not that hard now it is certainly easier, a drunk janitor could do it, blindfolded with his hands tied behind his back...

[waclawek.jan]

No, Clive's remark was more generic than just related to this particular issue - namely, that you should *never* rely on the mcu protection scheme as the sole barrier to some adversary to ruin your business, as this approach has been proven wrong in the past too many times, and often done publicly so by "tinkerers". The "unlock services" provided by some "outlets" at relatively low cost is the very proof of this - whether they in reality fulfill all their promises or not.

Ultimately, this all boils down to money, representing the barrier; and the effectivity of the barrier is a multi-factor issue (depending also on the application (e.g. in this particular case, is there a few-bytes easily identifiable magic sauce in the binary?)), thus it can't be simply "good" or "bad". We've just learned that in this regard, 'F1 (and other STM32 using RDP Level 1, and other Cortex-M3/4-based mcus using protection schemes which don't lock out the debug interface) may be somewhat cheaper than we previously thought, that's all.

JW

[Pavel A.]

RDP level 2 is scary. Why ST won't implement password lock on debug interface, like some others do?

-- pa