readout protection cracked on STM32

[dieter 123]

Posted on January 08, 2018 at 10:21

Am I correct that readout protection has a major issue and is not working at all? Are all STM32s affected? Any comments on this from ST?

See here:

https://www.aisec.fraunhofer.de/en/FirmwareProtection.html

#stm32-rdp-read-protection Note: this post was migrated and contained many threaded conversations, some content may be missing.

[henry.dick]

Posted on April 23, 2018 at 17:06

Given the production processes, we are likely see bugs discovered today in chips to be introduced a couple years out, from vendors who are really diligent at working out bugs in its chips.

Just the nature of the beast.

[AvaTar]

Posted on April 23, 2018 at 19:38

... but they are going to make a very bad impression ...

Only if the customers care, and read up ...

And there are projects that do not require secrecy, albeit they tend to sell hardware in small numbers.

[re.wolff9]

Posted on April 23, 2018 at 20:33

I'm atypical that I forget to lock the code in the processors that I sell. Most managers will think their programmers are very special to be able to build whatever they built.

And especially in the larger companies, where the number of chips sold is also large, someone will think of this 'incident' and inquire from ST what 'fixed' chips to buy....

[iumez]

Posted on May 15, 2018 at 23:55

The SWD attack does not result in a successful read every time as they're taking advantage of a race condition. It seems unlikely you'd improve much on the 45 bytes per second.

[iumez]

Posted on May 15, 2018 at 23:59

Since when do you accept 'everything person X can think of' as the limit of what's possible?

[AVI-crak]

Posted on May 16, 2018 at 04:24

Steal someone else's program code is possible, but very difficult. It is much cheaper to find a solution in a global network, and write your own version. This is much faster and cheaper than hacking.

How to protect your own program: for this there are 100500 ways, and some are not too honest. For example, the prohibition of executing program code from RAM. Forced memory cleaning. Checking for serial number in parts - in many small blocks - through intermediate data. The one who can pull out your firmware will shoot voluntarily.

Dirty tricks: using the data space of the periphery - to check for hacking. Your program code will have a self-destruct when run in the stimulator, or when using a debugger. At the same time, an insignificant at first glance error will remain, which does not lead to the state of system crash, but makes the final algorithm of the device completely useless.

Soot is more - you can keep your own right to the project even with its public publication. To do this, you have to confuse the program code to the state of the bloody shroud before your eyes. A special glamor is the use of abbreviations for variable names, the removal of spaces, and the use of macros on a huge scale. With filling in one very long line of a mash of single characters and signs of operations Ci.

Yes, the program code will work, but how it works will only be known to you.

[Philipp Krause]

Posted on June 06, 2018 at 21:56

As I just found out from the Gnupg-users mailing list, there are also companies offering readout from protected STM32F103 devices:

http://www.pcbcopy.com/2016/ic_1128/1928.html

It looks like the service has been offered since 2016, so much earlier than the research we learned about here.

Philipp

[ranran]

If I understand correctly, this vulnerability is only when RDP level 1 is used.

Yet, Level 2 is not affected. Right ?

Thx,

ran

[re.wolff9]

If I understand and remember correctly, the problem can be triggered in RDP level 1.

However, they also showed that they can almost target a single bit erase. But that "almost" is enough to ALWAYs cause a level 2 -> level 1 downgrade.

As a user a level 2 protected device is "almost bricked". If you find a software bug, the device is bricked and can no longer be used. To prevent this from happening accidentally, a very specific bit pattern is used to enable level 2. So any single bit change in IIRC 16 bits of configuration flash bits will downgrade the level 2 to level 1.

All this depends on quite some effort of the attacker. Level 1 or level 2 will keep most hobbyist "lets read the code and see what it is doing" away. But bigger players, can spend the "a week to reproduce the findings in the article" or "$500 to have it done commercially", What the commercial "read protected chips" guys can do beyond what the article describes is unknown.

[A.rubley]

Looks like the F1 series is somehow (?) affected as well... https://blog.zapb.de/stm32f1-announcement/

Has somebody more information?