Sometimes, security mechanisms can be bypassed if you just do things slightly out of the ordinary. For instance, readout protection on microcontrollers is a given nowadays, to the point where it’s intentionally enabled and relied upon as a major technical measure to protect intellectual property. The gist is — when you connect to a microcontroller over its debug interface and then ask to read its flash memory, it will politely refuse. However, [Racerxdl] shows us that in practice, it’s not flawless protection – for certain chips, you just need to be a little quicker than usual.
Usually, flashing and debugging software will chat with the microcontroller for a bit, and probe parameters before going for any direct requests. However, if you skip the courtesy and bluntly get to the point immediately right after power is applied to the microcontroller, you can intimidate them just enough to give you one byte of its memory before it refuses to cooperate further. Since that can be any byte you wish, you can read the entire flash — one byte at a time.
You need to power cycle the chip before you can progress, so the hardware does involve a bit more than just an SWD interface, and it will take a fair bit more time than reading out a non-protected chip the usual way; plus, of course, the debugging interface needs to be active for this in the first place, which isn’t always the case. However, it still beats paying a few thousand dollars for a factory in China to decap your chip and read it out using a fancy machine.
[Racerxdl] didn’t just write a proof-of-concept for this attack – they implemented it for one of our favourite chips, the RP2040. As such, you no longer need an unobtainium STM32 to dump an unobtainium STM32.
To be clear, [Racerxdl] didn’t design this attack — it’s been around for some time now. Credit for that goes to Johanes Obermaier. All in all, this is a wonderful reminder that seemingly reliable security mechanisms can be foiled by the simplest tricks. For instance, if your chip erases the flash when you unlock its protection, you can just tell it not to.
Umm… why?
Right to repair, for instance. Here, just downstairs, you can see [CJay] talking about repairing their 3D printer that the company won’t provide controller chip images for. You just know the printer’s running slightly modded open-source software, possibly even under GPL – but that won’t stop the company from not providing you with sources! Extra points because in [CJay]’s situation, the fault is caused by the manufacturer’s bad design decisions, too.
It would be great if something similar worked for Chipcon/TI 8051 micros.Unfortunately, it does not.
Yes, there is an exploit against TI 8051 micros like the CC2510 ;) I’ll write a blog post about it in about a week, I’ll post a link here then.
Here’s the link of how to do this against TI 8051 microcontrollers: https://zeus.ugent.be/blog/22-23/reverse_engineering_epaper/
Used the same way on 6805s in the good Ole days
There actually is an exploit against those chips (for the CC2510 at least), I’m writing a blog post about this, please remind me in about a week if I forget to post here.
Please learn with us. It’s not “your pico”, it’s “your pipico” (“little dick” in Portuguese).
100% Agree – Sorry for not putting that in the title of the project :'(
Glitch Attack works on RP2040 captured STM32F0x – Cool!
DEADBEEF, the hexadecimal representation of the 32-bit number 3735928559, used in Hexspeak and as a magic debug value.
I checked recently and stm32’s are getting back in stock at farnell… at three times the price of before, but still in stock.
No clue how they sell these when there is the RP2040 and the stuff from Padauk among others.
Trivially – the reason they’ve been out of stock is because demand has far outstripped supply. Making a new design? Sure, stick a different chip in it. But reworking an existing design often costs far more than just paying the premium.
Because it’s not quite as easy as ‘just use an alternative’ when you have an existing codebase, hard earned knowledge, significant investment in toolchain, range of products etc. which use one particular processor line.
Sure, it’s possible but it’s not a fast process and what’s to say the PADAUK or Pi chips won’t dry up in the exact same way?
Plus, PADAUK chips, RP2040 etc. don’t have anywhere near the performance of some of the STM32 chips, nor do they have the IO capability so it’s not a trivial drop in replacement, it’s a considerable investment in engineering and re-design for, potentially, much lower performance which all costs a *lot* of money.
We’ve got numerous designs that would take a TON of work to port to the RP chip, and several that it just doesn’t have the IO/peripherals for.
I spent far too long wondering when ST had introduced FOX chips and how I’d missed the announcements before I realised the headline should probably say F0x.
Nice collection of hacks though, I have a use for one of them to recover firmware for a bricked, closed source 3d printer where the careless replacement of a hot end has cooked a GD32F103 chip and the manufacturer’s solution is ‘buy a new board’.
I’d consider just replacing it with an open source alternative but it’s not my machine.
GD32F103 is a decent replacement.
It’s actually a GD from the factory but not the usual F103C8T6, it’s a slightly larger variant with 64 pins, I’ve already got a replacement part (tacked it onto a larger LCSC order) but obviously need the code which I’m going to try and extract from a working printer.
oh that’s wonderful! if you manage to pull this off, take a few pictures&screenshoits, write some text, post it somewhere and then submit it to us, we’d gladly cover it!
RE FOX: hehe yeah it’s just our font – the actual headline I used is F0x, and you can see the f0x in the URL too.
Deadbeef. . . . Cotdc, BO2k good times. Long love the internet.
anyone knows if this works with an stm32f105?