STM32 Zapping the JTAG-Interface

[harerod]

The STM32 family has been my premier choice for well over a decade. The STM32F407, STM32F051 and STM32F030 are among the favorites. Every now and then my customers express the wish that their devices shouldn't too easily copied by anybody getting their dirty paws on them. I never considered the STM32 series as secure, but with multiple tutorials available on how to extract the flash contents from locked devices, things have started to become ridiculous.

Having said that, I could easily do experiments of my own, but I don't believe in unnecessary cruelty against semiconductors. Therefore I would like to ask the following question:
Has anybody zapped a JTAG-pin only, leaving the rest of the device working? JTAG TDO would be a prime candidate. With burnt out driver transistors the JTAG core could wriggle along, being RP2->RP0 promoted, alas it would be a silent cry.
On the 407 the JTAG-pins are of the 5V-tolerant variety. Injected current characteristics etc. are documented in the datasheet. Since the 5V pins have a different protection concept, which doesn't permit voltages above Vsupply+4V. Permissible injected positive current is zero. (Absolute maximum ratings: Voltage characteristics / Current characteristics)

To define the actual zapping, I would use the approach from ESD-testing: Capacitance, charging voltage, discharge impedance.
I am looking forwards to your thoughts on this matter. Thanks you in advance.

[SiliconWizard]

Have you read the following app note?
https://www.st.com/content/ccc/resource/technical/document/application_note/89/12/c5/e2/0d/0e/45/7f/DM00186528.pdf/files/DM00186528.pdf/jcr:content/translations/en.DM00186528.pdf
That's for the F4 series. I don't know if something similar exists for the F0 series. Do you consider that not secure enough?

Voluntarily destroying the JTAG pads on the MCU? Yeah. I would never go that path. I'll be curious to read answers from people who think it's a good idea, and if so, how they'd do it safely (for the rest of the device) and in a repeatable way.

[magic]

Semiconductors tend to work as antifuses - they go short. If something goes open, it would be metal interconnects or bond wires, but I think such things usually happen when power still keeps flowing after the silicon is already shorted, since their voltage drop and power dissipation is lower than that of semiconductor devices.

This is probably not the effect you want.

BTW, I have seen a few micros "zapped" by a high voltage DC bus and they either had their pins permanently shorted high or everything shorted to everything.

[harerod]

@SiliconWizard: Yes. I have been with this product family for over a decade. I have been using F4s since they came out, finding erratas before they made it into the official doku. The problem is that others have demonstrated design shortcomings of the readout protection. I guess it started to become official here: https://www.aisec.fraunhofer.de/en/FirmwareProtection.html

@magic: Same here, I have seen all kinds of failure modes in silicon, an initial short being common. Since, unlike power electronics, this is a rather weak structure, I expect several possible failure modes. I explicitly mentioned a FT-pin in a STM32F407, the JTAG-TDO-pin, because the specific port design is important to the outcome.

Setting my initial motives aside, at this point I am curious if anybody has concrete experience in zapping single pins on a STM32 in a reproducible manner and is willing to share some information.

[SiliconWizard]

@SiliconWizard: Yes. I have been with this product family for over a decade. I have been using F4s since they came out, finding erratas before they made it into the official doku. The problem is that others have demonstrated design shortcomings of the readout protection. I guess it started to become official here: https://www.aisec.fraunhofer.de/en/FirmwareProtection.html

I haven't read this article yet, but from what I've heard, bypassing protection would involve expensive equipment, extracting the die from the packaging, and selectively remove the read protection option with laser. Frankly, unless your devices are particularly interesting or popular, I wouldn't even bother considering this possibility.

And that being said, people having access to such equipment and knowing how to use it would probably have little problem getting JTAG access even with a damaged JTAG pad. So I doubt risking to kill the chip is worth it to further protect it.

Now if there's actually a simpler way of bypassing the protection, not requiring the above, please let me know.

[abyrvalg]

@SiliconWizard, that article was just the beginning. Next published attacks were much easier, i.e. some older F0s allowed to read a single flash word at arbitrary address over SWD before actually engaging the protection, then F103 was attacked (over SWD again) via vector fetch, extracting most of the flash content. The next attack on F103 (SWD+partial power down glitch) allowed full extraction. So there are real reasons to be afraid.

Zapping debug pins - never tried it on STM, but had some experience on older PICs (grounding all pins except PGD, applying +-12V to PGD for few seconds): ~99% success on 16F627 (fried few pieces of thousands produced) and total failure on 16F877A (power rails getting short on every sample). Pethaps trying will be more productive than asking. I remember killing around 10pcs of 16F627 in the process of finding right voltage/timing.

Upd: forgot completely, recently I witnessed a “suitable” single pin failure on STM32F103VET6 as a result of occasional +15V application (the MCU was powered normally, single GPIO pin have been exposed to VBATT via failed motor driver IC). The chip worked normally after that, but that single pin stuck at 0.

[amyk]

For a few k$ there are many companies in China who will extract the code... even from a chip that has no pins left! You will never win.

[abyrvalg]

In theory - sure, there are more advanced approaches like “editing” the silicon with FIB to bypass the damage or scanning charges in flash cells. But for a few k$? - I doubt. It’s more likely that for a few k$ they will try something like ChipWisperer, then will ask you to add another 0 to the price and so on. Do you know any success stories?

[harerod]

@amyk: I heard that prices for those kinds of services start around 1k€. They might require more than one sample, though. The product I am thinking about costs about 100k€ per unit and only ships a few hundred per annum. So the expensive part for an attacker would be procurement of samples. On top of that, the sample would be destroyed after an unsuccessful reading attempt of that kind.

According to recent publications, an AES-protected bootloader for STM32F407 is about as useful as the "Ligne Maginot" was. The embarrassing part about the attack pattern we are concerned about here, is that the hardware required is usually readily available at any electronics developer's lab. And the attack, succesfull or not, will most likely leave no traces on the sample. That last part we can mitigate, though.

[harerod]

@abyrvalg: Thanks for picking up the actual topic. Your findings show that it can be and has been done - thanks for sharing. Would you mind telling which pin that was, that got fried? It would be interesting to know, whether this was an FT pin or not. Then we could make a more educated guess what caused that pin to be "stuck at 0".
Should we decide to go that route, I see no problem in sacrificing a dozen devices or so. The device concerned comes in the LQFP100-package, so no challenge to a Yamaichi-socket on a test board. The tip about grounding all the other pins is great, I see how that would help sharing the stress for the other pins.

[abyrvalg]

It was either PA8 or PC8 (this pair controls the motor driver and I don’t remember which one of them died), both are FT. The pin stuck at "active" 0 (overcoming an external 4k7 pullup).
Btw, for a 100k/piece product I would do something like fitting a Java smart card executing some small, but essential part of the product’s code. That isn’t so complicated as it may look, and it’s fun.

[magic]

Overcoming a pullup is fine, but what happens when the core tries to drive such a pin high?

If the chip goes down in smoke or at least crashes, then fine. But if it continues to work and the broken pin shifts from 0,000V to 0,001V or the supply current increases by 20mA then it isn't going to help much.

[harerod]

Abyrvalg, thanks for the feedback regarding PA8/9.

As with all security features, it is about raising the bar. That way we keep the script kiddies away and see the amount of criminal energy the competition is willing to invest. I know from experience that it is most likely easier to recreate the firmware's function, than decompiling and understanding half a megabyte of optimized compiler generated ARM code. That approach might even be legal.


Would there be anybody else with concrete experiences in zapping pins on STM32?

[harerod]

Here is the basic structure of a FT-Pin, taken from RM0090 and AN4899. For reference, I attached the TC structure as well.AN4899 even reminds us that FT-pins are very vulnerable when the device is not powered, but grounded (Chapter: Voltage protection when no V DD is supplied) - which once more fits nicely with abyrvalg's report.

Comparing this to abyrvalg's input, we might postulate that the output N-MOS failed as a short. That would be an excellent outcome for our current endeavour.

[bson]

I wish they'd stop with the silly boot ROM stuff.  Also, the POR mode needs to be antifused; during development it comes up with the SWD fully accessible, and the core halted - execution then requires explicitly resuming it.  With the fuse blown, it comes up with the debug interface disabled and the core executing; enabling the debug interface would then have to be done through firmware.  What's in the boot ROM can be moved into a source code library that can then be reviewed, stripped down to those portions actually used (basically, don't ship unused functionality as that can only increase the attack surface or cause unexpected problems, while it's effectively untestable), and actually tested.  If some portion of their customer base needs a helper, give them a binary monitor they can install, built around their assist library.  And they shouldn't include undocumented hardware features or mechanisms, that's just more untestable, unused functionality and a potential source of problems.

[rhodges]

I wish they'd stop with the silly boot ROM stuff.

When I was starting with STM32, I used the boot ROM to load my binaries. It was a hassle, but it got me started. And some might be using it for loading firmware over serial, SPI, ethernet, or whatever. I infer that you would like some easy way to disable it when you want.

I had not thought much about the boot ROM, but if it is based on Flash, like the main program memory, is it possible to reprogram it also? Or at least write it with zeroes? One could argue that the boot ROM should always be there as a last resort to unbrick a processor, but maybe that should be the choice of the developer?

[bson]

Here's an example.  Consider the F40x bootloader selection attached.  (Sorry, but I can't figure out how to inline images on this forum anymore.  I used to be able to just upload them to a web server and add an img tag, but that no longer works.)

Look at how it selects the bootloader; it connects USARTx to specific pins during hw init (regardless of what you might use those pins for).  You might want to use the USB DFU bootloader, but if a USARTx just happens to receive a 0x7f, which is not exactly an exotic bit sequence, it will branch off to the USART bootloader and your USB firmware updater connecting to it will never see a response.  Totally randomly.  Which is utterly unnecessary if you don't ever intend to update firmware using a serial port, at all.  Ever.  Any half decent engineer would just remove the USART bootloader altogether.  In fact, if you only ever update using USB you would keep only the USB one.  Why have the others?  They can only ever trip you up!

And this is only from a 30k foot view using a trivially simplified flowchart.  If you were to actually review the boot ROM you'd find a million and one technical decisions that are simply wrong in your product.

[harerod]

The STM32 family requires lots of study. Having come from 8051, PIC, AVR, it took me a year to get comfortable with this family. Knowing the documented stuff is a must, alas we have to cope with heaps of undocumented features as well. That is one reason why I stick to certain chips, which I have run through lots of tests, in house and in test labs (medical and MIL, among others). Another option would be to move to a newer member of the family, which comes with a different bootloader and security scheme.

Having said that - the topic of this thread is quite narrow - how to zap a certain pin on an STM32, for example the JTAG-TDO on STM32F407. I would most likely join you on another thread discussing the quirks of the STM32-bootloaders.

[julian1]

I managed to accidently zap a *single* pin of an stm32f407. I believe the scenario was - mcu powered, pin configured gpio / not af, and likely exposed to + or -15V (maybe +-12V) due to careless probing. All surrounding pins (same port, doing spi and gpio) were fine.

 

[newbrain]

I managed to accidently zap a *single* pin of an stm32f407. I believe the scenario was - mcu powered, pin configured gpio / not af, and likely exposed to + or -15V (maybe +-12V) due to careless probing. All surrounding pins (same port, doing spi and gpio) were fine.

Same here, with about  20V and an STM32F411. The core, all the other pins, and peripherals still work, but the chip now draws something like 300 mA...not recommended.

[julian1]

I will note, that I don't remember any excessive current draw, and I continued to use the mcu (disabling that gpio pin in software), with a bodge to a different gpio. But, obviously, it is easy to imagine that in most scenarios, a guarantee of future behavior and stability is more important criteria for a product.

[harerod]

Don't beat yourself up. If you are in this business long enough, you are bound to make the occasional slip. In my book, the part that matters most, is not to hurt people.

Thanks for the feedback!

[bson]

How about zapping only the clock input?

The problem is zapping might only fuse the ESD TVS diode, and any output driver might then fight to pull down rail.

Maybe the VDD_IO for a block including the zapped pin can be disconnected, effectively powering off a bunch of pin drivers.  Of course, that probably needs to be accounted for during board design to make sure nothing uses any of those pins.  An attacker can reconnect it of course, but all they're going to see is a short that fries the chip in short order.

[harerod]

bson, thanks for your input.
The procedure would be as follows: the device is programmed with custom firmware, including custom bootloader, before soldering. During programming RP2 is set. Then the TDO-pin is zapped. Any further activation of the JTAG interface would already be caused by an attack. So, well, not of primary concern.

[SiliconWizard]

I managed to accidently zap a *single* pin of an stm32f407. I believe the scenario was - mcu powered, pin configured gpio / not af, and likely exposed to + or -15V (maybe +-12V) due to careless probing. All surrounding pins (same port, doing spi and gpio) were fine.

Same here, with about  20V and an STM32F411. The core, all the other pins, and peripherals still work, but the chip now draws something like 300 mA...not recommended.

Yes. As I previously said, how can you ever make sure such a destructive attempt won't have any harmful consequence? And even if you manage to do it in lab on a couple devices in specific conditions, how can you make sure it will be repeatable in production on hundreds or thousands of devices?

I would personally never attempt such a thing outside of lab experiments.
Oh well.