Glitching. A Fault Injection Primer

After three years of doing trainings via AS.T we have a bunch of great video material on lots of different topics. Just this week I found myself explaining glitching for the third or fourth time to someone and generally it involved send them some highlights from our recent classes. I decided I'd throw this up on the blog and refer people there going forward. If you're interested in this, check out our Fourth of July Sale. As part of this bundle you'll get access to our Hardware Hacking with FPGAs class, as well as our Intro to Fault Injection and Glitching. You can opt to access the recording or join one of our upcoming live sessions - it's your choice.

The Basics

What's happening when you "glitch" something is you're actually causing read errors on internal buses. As a result certain values get red incorrectly and this can result in things like skipping instructions, for example if an instruction gets decoded incorrectly, or simply reading the wrong values. Typical examples are changing the executed application control flow or as often is the case with bootroms (the first immutable code that gets executed) misconfigured debugging that is on when it really has been set to off.

The simplest and easiest form of glitch, albeit less common in the wild, is clock glitching. Here we simply run the clock faster, we overclock the target, and voila, values get misread. How's that happening? Well, the increased clock frequency doesn't take into account the actual physical propagation delay at a transistor level of those same signals. The clock determines how data gets sampled, and the data didn't arrive in time, we in effect sample the previous clock cycles data. By the way we cover these kinds of circuits in detail in Hardware Hacking with FPGAs. This might not be true for all the bits, but it's enough to bypass a strcmp checking a password for example, as can be seen here:

The Setup

There's things other than bootrom glitches that can be achieved with glitching, as shown with the previous password check example, however, let's be real ... you're reading this for the bootrom glitches. So to give you the idea as a rule of thumb with glitching you're attacking the bootrom bootloader of the manufacturer. Often these will have some vendor specific name, especially in larger chips where this is actually a customizable "low level bootloader" that you can load into non-volatile-memory and lock it. I just call it the bootrom for short, meaning it's immutable and it's the executed before the application code. Usually this is literally a mask ROM on the chip.

The question is can you get back in? The answer is yes with some finesse. The first step is to actually determine which PINs have to be bootstrapped to get back into the bootrom, as these will usually have to be configured correctly to get back in. You can see an example of that here:

First things first, you'll want to write a check if the chip is locked or unlocked. We need to do this on a working chip, before we actually glitch. We'll want to make sure it's running predictably and stable and that all of our communications are working. In our Hardware Hacking with FPGAs and Intro to Fault Injection and Glitching we generally use Python for this, although you can use whatever:

Next, at least for voltage glitching, you'll also need to determine where you can access the core voltage. If you have a socket - you're all set (pro tip: search AliExpress, checkout out our AliExpress Webinar) Some assembly (soldering) may be required. In the case of the NXP LPC, you can solder a couple of connections and do it all insitu. Here's how we do it in our Intro to Fault Injection and Glitching class:

We're trying to get errors from running the chip beyond it's limits, for this we should start by running it at it's absolute limit. For example, you may want to run the target at as low a voltage as possible. You can usually find this pretty easily by empirically lowering the voltage until things get weird. Again, we do this in our Intro to Fault Injection and Glitching class:

Putting it All Together

Now with the script and everything else working, we let the script do it's thing. We sit back and relax, eventually it will work. Here we have it for the NXP LPC.

Here's an example for the ST STM32, here we're checking whether or not JTAG is enabled. When we see that JTAG is enabled, we're in.

And for all of you demanding a real-world example, here's all of this applied against a Trezor One wallet. We're able to dump the wallet seed over JTAG using this exact attack insitu on the Trezor One.

Like what you see?

Check out our Fourth of July Bundle. As part of this bundle you'll get access to both of the relevant classes I outlined above, Hardware Hacking with FPGAs and Intro to Fault Injection and Glitching. You can opt to access the recording or join one of our upcoming live sessions - it's up to you. We hope to see you soon!