ccc talk - bypassing code protection on multiple MCU types

[mikeselectricstuff]

https://media.ccc.de/v/camp2023-57401-unlock_the_door_to_my_secrets_but_don_t_forget_to_glitch#t=213

TL;DR -
Most MCUs have a way to erase a secured part so it can be reprogrammed.
The erase operation happens in multiple stages - erase memory, erase config bits, re-enable access.
Glitching during the first phase prevents the flash erase bit not the later stages.
They only show on ST but sufggest other mfrs parts have similar vulnerabilities.
 

[DavidAlfa]

Love those hacking videos!
I guess you first buy few virgin MCUS and do the work on them, when it works consistently then try on the final device.
Still, how many devices will you break before being successful?
The device manufacturer might suspect if you suddenly want to buy 50 mainboards replacements for the machine

[mikeselectricstuff]

Love those hacking videos!
I guess you first buy few virgin MCUS and do the work on them, when it works consistently then try on the final device.
Still, how many devices will you break before being successful?
The device manufacturer might suspect if you suddenly want to buy 50 mainboards replacements for the machine

In one of the questions at the end, he says that once the timings have been established it always works, though not clear if this would apply to different chips of the same type, but seems pretty likely

[DavidAlfa]

But there're also device revisions, which might be a nightmware to deal with.
You want to attack a device made in 2013, containing STM32F103 rev. A.
You might only get rev. X , Y, or Z now. Perhabs the revision can't be extracted from the marking, and it's a "Scratch and win" thing.
So a different revision might have a totally different timing, or increased security, whatever, that ensures this can't be done.
But for sure anyone with enough resources will end getting the same chip rev. in their hands .
Very enjoyable talk!

[AMDFX8150]

Need this done for a few Ryobi 40v units

[peter-h]

Watched a bit of the video in post #1

This attack vector leverages that many microcontrollers allow to deactivate their debug interface protection under the condition that the entire flash memory is erased first.


I don't think the 32F4 series has this option, does it? Once you set Level 2, that's it. No way to erase it.

[DavidAlfa]

Not sure if you booted using BOOT0=1

[peter-h]

Sorry I don't understand how BOOT0 pin affects the ability to erase (and thus re-use) a Level 2 secured 32F4xx. Did some digging around and can't find anything obviously relevant.

I am booting with BOOT0 = BOOT1 = 0.

[amyk]

This is the easier approach, but for a few k$ some companies in the East will extract the code for you physically.

[peter-h]

If somebody is going to de-capsulate a chip and read out the FLASH, all the "fuse" protection is dud.

Smartcard chips have special measures (buried layers) and stuff like Icc obfuscation to make this supposedly impossible. But AFAIK this works only for keys and such, not for a large area of FLASH ?

[mikeselectricstuff]

If somebody is going to de-capsulate a chip and read out the FLASH, all the "fuse" protection is dud.

Smartcard chips have special measures (buried layers) and stuff like Icc obfuscation to make this supposedly impossible. But AFAIK this works only for keys and such, not for a large area of FLASH ?

If a system is properly designed, you can disclose everything but the keys and it's still secure.
Of course in practice bad design, e.g. security by obscurity, means in practice this may not be the case, and access to code makes it easier to find vulnerabilitues