ccc talk - bypassing code protection on multiple MCU types - Page 1
Forum section: electronics / general

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 11, 2023, 12:51:37 pm
content: https://media.ccc.de/v/camp2023-57401-unlock_the_door_to_my_secrets_but_don_t_forget_to_glitch#t=213TL;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.

author: DavidAlfa
author_rank: Super Contributor
timestamp: September 11, 2023, 02:39:31 pm
content: 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

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 11, 2023, 02:42:07 pm
content: Quote from: DavidAlfa on September 11, 2023, 02:39:31 pmIn 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

author: DavidAlfa
author_rank: Super Contributor
timestamp: September 11, 2023, 02:51:57 pm
content: 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!

author: AMDFX8150
author_rank: Newbie
timestamp: September 14, 2023, 04:36:08 pm
content: Need this done for a few Ryobi 40v units

author: peter-h
author_rank: Super Contributor
timestamp: September 17, 2023, 04:01:33 pm
content: Watched a bit of the video in post #1This 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.

author: DavidAlfa
author_rank: Super Contributor
timestamp: September 17, 2023, 04:17:40 pm
content: Not sure if you booted using BOOT0=1

author: peter-h
author_rank: Super Contributor
timestamp: September 17, 2023, 05:18:47 pm
content: 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.

author: amyk
author_rank: Super Contributor
timestamp: September 18, 2023, 12:29:37 am
content: This is the easier approach, but for a few k$ some companies in the East will extract the code for you physically.

author: peter-h
author_rank: Super Contributor
timestamp: September 18, 2023, 06:41:07 pm
content: 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 ?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 20, 2023, 07:02:21 pm
content: Quote from: peter-h on September 18, 2023, 06:41:07 pmIf 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