readout protection cracked on STM32

dieter 123 · ‎2018-01-08

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.

re.wolff9 · ‎2018-01-16

Posted on January 16, 2018 at 11:04

I did not realize that MANI works for ST.

I get the impression that they marked this thread as 'for logged-in users only' I get the unexpected error (which for me is now expected... 🙂 ) when not logged in. At first I thought the thread was completely 'hidden/deleted' due to the 'ST in a bad light' nature....

@ST:

Let me tell you that I value a manufacturer highly that owns up to the mistakes with a statement like: 'Oops we messed up. We're looking into it, we'll fix the bugs, but as you may know, re-taping chips is quite expensive and has a very long lead time, so it may take a while before fixed chips are readily available'.

And just waving the problems away with a baseless: 'They only tested F0, so all other families are probably fine' is quite damaging to your reputation. You PROVE to me that you don't understand the issues.

Now even IF MANI was semi-officially talking for the company you can still recover by saying: 'oops, MANI didn't understand the full issue, the official statement reads: ... '.

Amel NASRI · ‎2018-01-16

Posted on January 16, 2018 at 11:39

Regarding the 'unexpected error', refer to

.

So there is no censorship intention there.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

AvaTar · ‎2018-01-16

Posted on January 16, 2018 at 14:10

Let me tell you that I value a manufacturer highly that owns up to the mistakes with a statement like: 'Oops we messed up. We're looking into it, ...

I strongly suspect they (ST) said something along this lines to their larg-time F0 customers.

And Mani's statement is for casual user/hobbyist consumption. And is not quite 'fully official', I guess ...

AvaTar · ‎2018-01-16

Posted on January 16, 2018 at 14:14

@Amel,

Regarding the 'unexpected error', refer to

.

Even clicking on this link (logged in, of course), I get 'an unexpected error occured'.

I can't do anything here except replying to threads in my message list - for a few days now.

So there is no censorship intention there.

I did not suppose censorship in this case.

Emphasis on 'this case' ... 😉

MANI Christophe · ‎2018-01-16

Posted on January 16, 2018 at 23:31

As the issue we are talking about here is limited to the publication mentioned above, be assured that we have validated that this affect only the STM32F0 and, as specified into the document, it is not successful in all other series.

We are working on a corrective plan but as you mentioned 're-taping chips is quite expensive and has a very long lead time, so it may take a while before fixed chips are readily available'

Further communication will be shared when the new platforms will be ready.

Today, it is important to remember that it is possible to workaround the current limitation of the STM32F0 readout protection level 1 by activating the level 2. It is anyhow the only real way to keep code protected into the memory.

dieter 123 · ‎2018-01-17

Posted on January 17, 2018 at 09:26

Hi

mani.christophe

‌

Regarding possible work around: what about declaring the SWD pins as output pins within firmware? That would work as well, no?

Thx

re.wolff9 · ‎2018-01-17

Posted on January 17, 2018 at 09:38

That prevents attaching the debugger after your startup code has run. This does not prevent anything in the current situation, as the debugger can and must connect under reset.

re.wolff9 · ‎2018-01-17

Posted on January 17, 2018 at 09:48

So can you explain to me how the cold boot let it run for a few microseconds, reset and read RAM fails on other families?

Just for kicks, I took the STM32F4 reference manual and looked it up.

Level 1 read protection enabled

....

no access ... to Flash memory or backup SRAM.

Please note that 'SRAM' is not mentioned. So... according to the manual the CBS method will still work.

Martin Velek · ‎2018-01-18

Posted on January 18, 2018 at 12:59

Cool article but I don't understand why reading of FLASH content is so complicated in RDP 1. As far as I know, the SRAM, Perihperal Read/Write is not protected. If it is possible to change CPU registers, there is nothing more easier than to fill SRAM with executable instructions to read FLASH memory, change PC(reg15) detach the debugger and attach again in a moment and read the filled SRAM area.

Martin

re.wolff9 · ‎2018-01-18

Posted on January 18, 2018 at 13:54

As far as I know, stuff like that is not possible. Although, from a security point-of-view, this mode is 'risky': You have to get a bunch of things right before it is safe. ST have put some thought into this and managed to thwart a few lines-of-attack before they happen.

As far as I know the chip 'locks up' when you do something it doesn't like. Quite possibly the 'change PC' is included in the list of things that makes it lock up.

I spent ten minutes this morning trying to navigate from ST.com to the 'community'. Not able to find it. Probably me. I googled for the community link and from there tried to find this discussion. Not able to find it. Probably just me.