STM 32F4xx - what hacks are known around Level 2 security?

[peter-h]

It seems perfectly possible, under Level 2, to have a "boot block" which accepts a firmware block,  say via USB MSC or via HTTP, encrypted with a key stored in the boot block, and you have a product whose firmware can be upgraded but can't be extracted. You can even publish the firmware block but with say AES256 "nobody" can decipher it. And obviously there would also be a CRC or a hash inside the encrypted block. Superficially there does not appear to be a vulnerability in this basic scheme. The CPU can write CPU FLASH even with L2 set.

That's if Level 2 doesn't have a back door.

Googling yields various success stories but only for the 32F0 e.g.

https://www.usenix.org/system/files/conference/woot17/woot17-paper-obermaier.pdf (STM32F051R8T6)
https://www.aisec.fraunhofer.de/en/FirmwareProtection.html (32F0 general)
https://community.st.com/t5/stm32-mcus-security/readout-protection-cracked-on-stm32/td-p/387997 (ambiguous but 32F0 again AFAICT)
https://community.st.com/t5/stm32-mcus-security/stm32f4xx-firmware-protection/td-p/133047 (someone asking about 32F4; no useful replies)

Does anyone know any more? The setup described for the 32F0 extraction is a fairly easy hobby job. I am not talking about de-packaging and etching off the passivation layer; that's pretty esoteric.

[wek]

Does anyone know any more?

Those who do are unlikely to go public (i.e. black hats).

JW

[peter-h]

Sure, but the guy in the 32F0 attack did publish it. Actually the first two URLs in my post above are the same paper, from roughly 2017.

How old is the 32F0? In particular the STM32F051R8T6 ? The DS is 2017 but that's just the last revision.

The errata for this chip
https://www.st.com/resource/en/errata_sheet/es0202-stm32f051x4x6x8-device-errata-stmicroelectronics.pdf
under 2.2.2 shows ST addressed the specific race condition referenced in the attack paper. So perhaps that attack - quoted all over the place - is no longer viable. ST fixed it in 2016. Interesting they think L2 remains secure:



Now for the 32F417VGT6
https://www.st.com/resource/en/errata_sheet/es0182-stm32f405407xx-and-stm32f415417xx-device-errata-stmicroelectronics.pdf



My reading of the above is that L2 is defective in that it can be (in effect) downgraded but only by internal software, which is hardly a problem because if somebody can run own code in there, they can read out the whole device anyway. Is that right?

[dietert1]

If you have a choice, you can superimpose a private security scheme on top of the proposed one or the legal standard. If you don't trust STM you could add another device of different make to improve security. Thus one can block a chip maker backdoor. Security is a moving target.

I am currently studying the STM32H7 true random number generator. They publish very little info on that peripheral. Like there is no clock frequency spec in the datasheet. They do have an application note AN4230 about using NIST procedures to check the quality of random number generation. I already noticed that the more recent checks "can't" be used with my STM32H743 prototype. What this really means is the older parts won't pass those tests. Only more recent MCUs have a configuration switch to turn off "moderation". On top of that they write: "A special device must be used for certification." I understand that MCUs available from distributors won't certify!
In my own tests i saw that the quality of generated random numbers depends somewhat on clock setup. With HSI48 it worked better than with PLL1Q crystal derived clock. Also i saw a 8x 32-bit fifo instead of the 4x 32-bit fifo described in manuals. Currently i am running a large test searching for "unexpected" correlations. Needs roughly a day or so. Even if i find nothing, i will probably use some extra linear transform for those random numbers, just in case.

Regards, Dieter

[peter-h]

you can superimpose a private security scheme on top of the proposed one

Can you give an example? People talk about using a smartcard chip for "secure processing" but you still have a wire connection between that and the main CPU. The smartcard chip could do some authentication, maybe, but at extra cost and hassle.

What I find interesting is that ST apparently fixed that 32F0 back door very fast - a year before that paper about it was published. I think that's pretty good.

[dietert1]

I remember a solution with a 1wire peripheral chip that included some onetime programmable EPROM. If you mirror there an encrypted version of the unique STM32 id, it can provide additional protection against cloning. Another cheap solution may be some CPLD or so that implements a challenge-response scheme similar to a dongle for a PC application or a cell phone for bank account access.
A firmware-only solution could be based on a small component hidden inside a large package that makes the whole thing crash once per hour if missing. This works like those tax avoidance schemes involving chains of bank accounts. With a little effort one can make it very tedious to re-engineer.

Regards, Dieter

[wek]

Sure, but the guy in the 32F0 attack did publish it.

Motivation of white hats (prospect of employment, fame?, altruism?) is way weaker than of the black hats (money). Read, most successful attacks are unlikely to be published.

How old is the 32F0? In particular the STM32F051R8T6 ? The DS is 2017 but that's just the last revision.

Around 2012 and the 'F051 was the first in the line.

JW

[darkspr1te]

I have not tried on the F4x yet but i have had success with 103's via a vector attack, STM32F3xx via a vcc glitch and sram attack and I am guessing but the STM32F4x should also fall to this.


A chip whisperer glitch attack is by far the easiest and every device I have tried has fallen to it. i've managed to repair quite a few devices that have had broken bootloaders due to firmware flash issues or worse when the OEM provides the wrong file and kills you machine then shrugs and goes "sorry, nothing more i can do" , Looking you ANSEL and your dodgy support team.


there are some other attacks out there i have not tried that may work on stm's ,
reading found here -> https://offzone.moscow/upload/iblock/0a5/nad1d86e3ah3ayx38ue56vxbh2j07kd4.pdf


the clock pulse glitch has worked on one stm i tried but no others which lead me to believe it's a re-marked clone and indeed to does fail the bluepill test code.




darkspr1te

[peter-h]

Very interesting, darkspr1te.

Is the SRAM attack just SRAM readout?

One interesting bit is that ST document the vulnerability on the F0 and say (in the errata) that they fixed it. But there is no mention on the F4, which may suggest that it doesn't have that particular vulnerability.

Which STM32F3xx did you succeed with and did you read the FLASH or just the RAM? The errata for the 303 does not say anything
https://www.st.com/resource/en/errata_sheet/es0204-stm32f303xbc-device-errata-stmicroelectronics.pdf

A google on chip whisperer glitch attack finds a ton of stuff...

[darkspr1te]

The SRAM attack with vcc glitch is you load code into sram then reset the device and then a timed glitch of power and sudden change to BOOT1 pin will cause the device to run SRAM code but ignore RDP2 status , another user mentioned he had also done the same but instead his SRAM code used code already on the flash to read out but i have not personally tried this method as it requires cold boot stepping and a lot of guessing to figure out the UART code on flash (if it even has it). i cannot actually remember the exact model of the F3x i did as it was a long time back, some OBD device that emulated SLCAN belonging to a client.


Also any device that used STM DFU code be it in hardware support or added via software will fall to the USB request buffer over flow as the way the code works is it read flash first then checks to see if RDP if greater than zero which means that data is in RAM and can be read via a debugger, if you patch libusb then you can in fact read the entire flash via DFU_DUMP which uses the first valid read option and request a large amount of data which causes DFU to just keep reading and dumping to uart
the DFU has been fixed in newer chips but too many companies using the software DFU option are still using old buggy stm code and this goes for GD & CS devices too, any of their chips with soft DFU support can be dumped this way.


for a really good video on it too is this

[peter-h]

Great video, but surely it is easy to design a CPU which is immune to this particular attack.

Anyway, back to the 32F4... nothing found yet on hacking that one.

[Rudolph Riedel]

Found this: https://jerinsunny.github.io/stm32_vglitch/

Well, RDP1, but I found that to be interesting.

[peter-h]

This attack is pretty easy. But as you say L1, not L2, was set. I reckon they failed with L2 otherwise they would have reported it.

I can't see the point in L1. Is there any?

It sounds like they used this boot loader feature



You can't delete the ST boot loader or replace with a custom one, so the attacker just needs to set the BOOT0/BOOT1 pins to jump to this boot loader.

The simplest way to piss him off is to use a BGA package and make the BOOT0/BOOT1 connections on inner layers. That will waste, what, a day? But then you have made a rod for your own back if you need to troubleshoot something.

Actually there is a whole "tamper-proof" industry out there, with stuff encapsulated in resin or even glass, with embedded wire wound around it, and breaking the wire wipes the data inside. Every ATM contains such a module, AIUI. It is done because fundamentally you cannot trust even the most modern smartcard chips, with some things. But that's a big hassle.

[rbe]

This topic is quite relevant to me as well, and I have some concerns regarding the potential risks of not read/write protecting the flash memory on MCUs like the STM32F0 or STM32G0 series. Specifically, if another user were to connect a debugger and download the flash contents using STM32CubeProgrammer, what could realistically be deciphered from the extracted .bin file, especially if the firmware is relatively complex?

My bigger concern is whether this person could generate a usable HEX file that could be later uploaded to another MCU by accessing all the option and other registers through STM32CubeProgrammer. While downloading the flash contents provides access to some data, it doesn't include RAM information or dynamic execution context, so the extracted flash content alone shouldn't offer a complete understanding of the code's behavior. Is that correct?

[peter-h]

Extracted FLASH is the product's entire code, normally, but any factory-input data held on another chip (e.g. serial numbers) obviously won't be obtained that way.

As regards disassembly, it's a long time since I did that, but clearly lots of people do it today, otherwise you would not get cracked versions of high value retail software which was presumably written in MS VC++ and whose executables are a few MB. But then one doesn't disassemble the whole program - only the license checking code.

It depends on who the enemy is. If it is just copying your product then you can do strategy 1, if it is reverse engineering a complex function, strategy 2, if it is crypto key extraction, strategy 3.

[uer166]

doesn't include RAM information or dynamic execution context, so the extracted flash content alone shouldn't offer a complete understanding of the code's behavior. Is that correct?

Unless you're loading stuff into RAM from another data source that is not flash (e.g. from internet), then dumping flash and running code on another MCU will provide all info needed to reverse engineer the application. To be frank: if you're using a STM32G0 or similar chip, you're not making a nuclear reactor, worry about your thing working and not about someone dumping the flash, it's never as valuable as you might think.

[rbe]

You're not wrong folks, the application itself might not be significant on a large scale. However, there are specific control algorithms in this power supply unit (PSU) firmware that I would be concerned about if they fell into other people hands.

I sincerely apologize if my concerns seem off-topic, but I thought it would be a great opportunity to bring them up here.

In fact, I would appreciate some advice on a related issue I'm currently dealing with. The company I work for is planning a business model that involves using a third-party gang programmer to limit and track the number of firmware flashes that our customers perform. This would allow to charge our customers based on the amount of flashes were performed. Additionally, customers would have the option to flash a specific memory section with a .bin file containing firmware parameters. The simplest approach would be to allow the customer to connect to the MCU via SWD and use STM32CubeProgrammer to upload these contents. However, without flash protection, they could easily download the entire flash contents to their local drive. Not only that, but they would also have access to all option bytes and other critical settings. This is a scenario I'm not comfortable with, so I'm seeking insights from industry experts on potential solutions or alternative approaches.

I’m aware of the level 1 and level 2 RDP. However, I noticed that with RDP Level 1 enabled, I couldn't write to flash memory. I only tested this briefly and plan to investigate further.

Just so I understand this correctly, is it possible for the other party, if no flash protection is in place, to download the entire flash memory content and generate a HEX file that essentially reconstructs the entire program? This could potentially allow customers to bypass the flash counter and abuse the system.

Much appreciated in advance!

[dietert1]

The RTC persistent memory may be useful to implement a protection scheme involving the device unique id. There are so many ways to confuse an attacker, like taking advantage of otherwise unused peripherals, e.g. some timer that "traps" while debugging. Nobody distributes a software product without any protection. Of course the effort depends. Invent something of your own and get it checked by people you can trust. A little obscurity doesn't hurt.

Regards, Dieter

[peter-h]

Yes if you allow customers to upload executable code then you have no security - except through obscurity.

You could have an interface whereby you have a USB MSC (removable storage device) profile and people can drop files into that. Then your code can validate those files in some way. My product does exactly that. It also has an HTTP server which presents a view of the filesystem and that is another way but USB is a lot less work (FatFS and the ST USB MSC code). Other ways would be a PC app which interacts with your box over a serial port and uploads the modules but that is more work and you have to maintain a windows application on top! And laptops don't have serial ports anymore, etc, etc.

Even if you have set RDP2, your code can still program the CPU FLASH. This is how you can do secure firmware upgrades. The upgrade is encrypted and/or has a hash on the end, and the decryption key is stored in the CPU FLASH which in theory cannot be read under RDP2.

The problem is that, as the above cracking examples show, probably not a single industrial-level uC is secure from the VCC pulsing attack. And every box you sell will contain the key, the attacker needs to just get hold of one, and then the entire installed base is vulnerable. Just like DVDs all became wide open once the mpeg keys were extracted from a copy of PowerDVD...

However, depends on who the customers are. If they are big firms they are very unlikely to do hacking, in case somebody on the inside spills the beans on them. Big firms today also almost never touch bootleg software. But smaller users may well have a go. That is my experience across 40+ years. I used to sell to banks, utilities, etc and they would not touch it, but small businesses, especially ones run by people from, shall we say, the Indian subcontinent, frequently had a go at disassembly, sometimes complaining to me that I made it hard Today, the chinese will attack anything that is worth attacking, and copy it.

Yes timers have been used since the 1970s to break single-stepping but the ST chips have an option to pause timers when single stepping.

All the modern uCs have a unique CPU ID and it would be normal to duplicate that in another EEPROM type device on the board. Disassembly will find it but you can bury it deep.

There is an endless list of obscurity methods. In the 1970s and 80s, Z80 days, people used to execute the copyright message. ASCII letters were mostly reg-reg moves and you could rig it that if the copyright message was edited out, it would crash, etc. But asm was also very easy to unravel. C is much harder.

If you have a very high value algorithm then you can run it on a modern smartcard chip, which is supposedly immune to these attacks. They have a serial port and you can interface it to a uC easily. I did such a design many years ago. The smartcard chip contained fast RSA hardware, secure key storage, and it had an 8051 for housekeeping. I don't know the state of the art now.

People also use Xilinx RAM-based FPGAs for protecting designs.

[Siwastaja]

Remember that whenever someone publishes an attack, at least 10 others discovered it months or years earlier.

Given the track record of large part of STM32 microcontrollers having published attack vectors against their flash protections within short time (often less than a year), it's a good initial assumption to consider any locking to have no effect whatsoever, i.e., any firmware you write will be readable by anyone who really wants to do it, investing some possibly trivial amount of money and time (some thousands of $, some weeks) into the process. So no FBI/NSA scale stuff.

Locking is therefore only useful to slow down total hobbyists from looking at the project. Not that they would probably be interested in disassembling some machine code anyway.

Nobody distributes a software product without any protection.

I do. Our products do not use any flash locking, obfuscation, or self-invented encryption (which would be then decrypted into RAM/FLASH for running anyway) because I consider it fully false sense of security. We do our best to develop safe firmware using well known good data security practices, and we also believe that security by obscurity (what you are kinda implicitly suggesting) is such colossally useless tactic that it's not worth any time.

But I do realize that some manager type people prefer to use proven-useless techniques, even if they understand they are such, as a proof of intent (in a non-technical sense). I understand the rationale, but the problem is the opinionated nature of this: for some others (e.g. myself), proven-useless techniques show the wrong type of intent, intention to believe in false sense of security and cargo cult engineering, both very negative aspects. I do realize however that some people see it in the opposite way, and think that superficial cargo cult engineering is pretty neutral and wastes only a small amount of time and does not prevent proper engineering from happening.

And maybe enabling the lock bits is just that. Nobody got fired by setting the lock bits. Not that it prevents copying, examining or reverse-engineering the firmware in any way at all, but hey, you did set the lock bits. And setting them takes only seconds.

[peter-h]

Locking is therefore only useful to slow down total hobbyists from looking at the project

But, often, that is all that's needed. I know (circumstantially) that grinding off some chip markings pisses off most casual ripoff artists. Not on a CPU but on smaller chips. Copying is a huge vast business so a lot of copying is not done by really smart people. Just look at my other thread about fake H8/323 chips; they invested ~5 digits in a chip packaging and marking line but even got the markings wrong!

Setting RDP2 will piss off a lot of people.

We do our best to develop safe firmware using well known good data security practices

What are those? I've never heard of such a thing, if the CPU FLASH is wide open.

And at the upper end, say banking comms security products (used to do a bit of that too) people use physical tamper-proofing. They don't trust any smartcard chip.

[dietert1]

Yes, a photo sensor can be a pretty innocent looking anti-tampering device. I mean if you have a board with some 200 or more components. Once more a hurdle that can be overcome, e.g. by analyzing more than one device, yet that's what people use. Multiple hurdles can make an attacker go somewhere else.

Regards, Dieter

[peter-h]

Widely used in banking comms, way back. A funny case where one box kept getting wiped overnight; a security guard shone a torch at the LCD They had keys in battery backed CMOS SRAMs and wiped these upon various tamper triggers.

IIRC, an LED can be used to measure light too.

[jnk0le]

encrypted with a key stored in the boot block, and you have a product whose firmware can be upgraded but can't be extracted. You can even publish the firmware block but with say AES256 "nobody" can decipher it. And obviously there would also be a CRC or a hash inside the encrypted block. Superficially there does not appear to be a vulnerability in this basic scheme. The CPU can write CPU FLASH even with L2 set.

This can be targeted by DPA/CPA attacks. Complexity varies on the used crypto implementation, which is easy to deduce (HWcrypto from part numbers, execution times from SPA etc.)
e.g. tiny-aes-c can be broken in like 50CPA traces by chipwhisperer.

Not even talking about timming attacks as many of those libraries really like to put T tables in flash memory (8x128b cached lines on F4), or somewhere else behind cache 

[peter-h]

This can be targeted by DPA/CPA attacks. Complexity varies on the used crypto implementation, which is easy to deduce (HWcrypto from part numbers, execution times from SPA etc.)
e.g. tiny-aes-c can be broken in like 50CPA traces by chipwhisperer.

Can you supply more detail?

AES is AES. TinyAES is merely a slow version which generates the tables on the fly, so it is 900 bytes in size and does 100kbytes/sec (AES256) compared with a more usual AES256 (like you get in e.g. MbedTLS, which AFAIK is a commonly used bit of code) which is 4026 bytes in size and does 800kbytes/sec (my measurements, 168MHz 32F417).

Are you saying there is key leakage via exec time varying with the key or data? There might be but you need to be able to inject known data to do the measurement, which is slow because the spoof firmware will be rejected each time, but only after some seconds. For the paranoid, it would make sense to do some random delay before rejecting each candidate block after the decrypted version fails the hash...

HWcrypto from part numbers

The hardware AES you get on some chips (like the 32F417) may have key leakage too but again you need to be able to inject small bits of data and run it. FWIW for the purpose discussed, tinyAES is fine and the low speed doesn't matter. Software AES is better anyway because you can then use the chinese copies of the 32F407. I am using hw aes in MbedTLS though because that runs over 100mbps ETH so can be doing 1MB/sec (a poorly optimised but reliable ETH implementation).

tiny-aes-c can be broken in like 50CPA traces by chipwhisperer.

How would chipwhisperer crack AES, if you are not inside the device? The purpose of chipwhisperer is to break RDP2 and extract the entire FLASH and then you don't need to crack AES-anything because the key is right there somewhere.