Old-School Glitching
Voltage glitching might seem like the latest security threat, where attackers are using complicated FPGA and digital logic designs to perform the fault injection. But at its core the idea is simple. In this article, Colin demonstrates how you can build a classic project, using only through-hole ICs and zero programmable logic.
In past articles, I’ve talked about my ChipWhisperer project (for side-channel power analysis and certain types of fault injection), as well as ChipSHOUTER (for electromagnetic fault injection). Another ongoing project is something called ChipJabber—which performs voltage fault injection. But, for a bit of fun, I’ve also built a simplified version of the tool that anyone can make.
This month I’m taking you on a bit of a throwback to more classic magazine articles—when you had home-etched PCB art alongside something you could build with discrete parts. It might be just what you need to complete a project on your own with things you’ve already got on hand. In fact, you can easily build this circuit in a breadboard or on prefboard—it has no surface-mount device (SMD) parts at all.
While many of my articles reference the most recent devices and the latest security threats, I wanted to see how “old-school” I could go and still build a useful fault injection circuit. So, we’re going to reproduce the attack from my article “Recreating Code Protection Bypass“ in the September 2018 (Circuit Cellar 338) [1]. In that article I used my ChipWhisperer device, which has an FPGA to generate pulses with specific time offsets and widths. Instead of using an FPGA, we’re going to generate those pulses the old-fashioned way with RC delay circuits and discrete logic chips. Instead of a programmable computer interface, you’ll have to twiddle a variable resistor knob to adjust the delay values.
I’m going to cheat a little in this article and will use two recent devices—a Microchip Technology MCP1825 LDO adjustable voltage regulator (introduced in 2008) and a Maxim Integrated MAX4619 multiplexor (introduced in 1999). Neither are critical for building a working circuit—for example the LDO has a smaller (less than 0.5V) drop-out than a classic Texas Instruments LM317 (greater than 2V) drop-out. This makes the design more practical since it can be powered from three AA cells, and avoids needing more expensive 9V batteries. For the multiplexor, it’s possible to use older devices, or even use a single MOSFET as part of the output driver. Figure 1 shows the final result—the ChipJabber-Unplugged in all its glory. This PCB has a minimum number of vias to make it possible to build in a home-etch tank, or in my example, it’s been milled out with a Bantam Tools PCB Mill.
But I will still be presenting you with a circuit that uses all through-hole circuits, and has a minimum number of vias (perfect if you need to etch or mill your own boards). Most of my logic is going to be using newer technology (working at 2V-6V range). The chips are all available in older technology versions, in case you want to build the true vintage version of this design. We’ll discuss those changes later, let’s first remember what we need to do.
BEGIN AT THE END
I can’t include all the details of the background of the attack in this one article. But luckily, it’s something I covered in my previous article from September 2018. If you don’t have that handy, I can refer you to the tutorial posted as part of ChipWhisperer [2], or a more detailed walk-through will be linked as part of the ChipJabber-Unplugged material [3]. This attack is also detailed in my upcoming book “The Hardware Hacking Handbook” (published by No Starch Press), but unless you have a time machine you are better sticking with the already published sources.
— ADVERTISMENT—
—Advertise Here—
The quick summary is that the LPC1114 device from NXP Semiconductors (along with several related parts) use a special “magic value” programmed into flash location 0x2FC to indicate that read-protect is active. If that value is corrupted, the device thinks that no code protection is enabled, and the device will respond to read requests.
To do this attack, we will reset the device, and insert a fault during the boot-up process. Once the device boots, we force the device to go into the built-in bootloader. From this bootloader, we’ll check to see if a read of flash memory is allowed. If the read-protect worked as expected, it will block the read. But if we managed to corrupt the code read protection (CRP), we’ll instead read the corrupted value.
To inject the glitch, we will drop the core voltage of the device slightly during the boot process at a specific instance in time. This causes a perturbation on the power supply rail, which is enough to somehow corrupt the checking of the read protect value. In this case we don’t know the specific effect we cause. For example, we could be causing instructions to be skipped, or we could be causing only the value to become garbled. Both will have the same effect.
MAKING PULSES AND TAKING NAMES
The core of the logic is a pulse generator built using the SN74AHC123A from Texas Instruments (introduced July 1997—the original 74123 introduced in 1983) monostable multivibrator. This device allows us to trigger on rising and falling edge pulses, and generate a specific output width pulse as set with an RC circuit. Using two such blocks in series allows us to generate first a pulse with a specific delay from the initial trigger edge, and then with a certain width. As you can see in Figure 2, this means we can generate a width and delay dependent on the individual pulse generator settings. By using adjustable RC values to adjust each pulse width, we now have an adjustable width and delay from the trigger event.
Our goal here is to insert faults on specific cycles of the target device. This means we actually would like an ability to shift the pulse around on a very small time-scale to target specific operations—meaning adjustments in the range of hundreds of nanoseconds. But at the same point, we may need to offset where the fault occurs from the trigger on a larger time-scale, because the device may perform many operations before we reach our specific operation of interest, which could mean waiting tens or hundreds of microseconds. For this reason, the architecture has both a fine and a coarse adjustment method for the pulse delay and pulse width.
An easy solution would have been to use a variable capacitor for the fine adjust, but this would add significantly to the cost. And for me (and I assume most people) they are less likely to have a variable capacitor around of the correct value.
Instead, we use one monostable multivibrator to trigger the second. The first delay is used for the fine adjust, and after the fine adjust delay is over it triggers the long adjust delay. We combine the two outputs to form a single large pulse. Because the SN74AHC123A contains two monostable multivibrators, we can implement the two delays using one chip. The schematic diagram for a single delay block (with both fine and coast adjust) is shown in Figure 3. Note a limitation of this design is the trigger input must be held high long enough for the second multivibrator to trigger—very narrow triggers won’t work. In our use case that won’t be a problem, but a later iteration of this design features an additional single-shot pulse stretcher on the input.
Our design has a total of two SN74AHC123A chips. The first implements the “offset delay” (Pulse Generator #1 from Figure 2), and the second implements the “pulse width” (Pulse Generator #2 from Figure 2). Both the offset and width have coarse and fine adjusts. To provide further flexibility, the coarse adjust uses a switch to select between several “ranges” on the coarse adjust. On the lowest range the coarse adjust is bypassed fully, allowing you to generate a pulse down to about 100ns width.
SWITCHING VOLTAGES
We now have the question of the output driver. We could simply implement the MOSFET crowbar I used in the ChipWhisperer-Lite, as discussed in my September 2018 article. This would actually be the easiest solution. But while we are building a discrete version, why not extend this a little further? The final version offers the MOSFET output still, but also has a selectable output driver that allows more complex waveforms. Here we use the MAX4619 multiplexor, which was demonstrated by Chris Gerlinsky in his seminal presentation “Breaking Code Read Protection on the NXP LPC-family MCUs” [4] on which this entire project is based.
— ADVERTISMENT—
—Advertise Here—
This simply switches the output between two voltage levels. I’ve chosen to use two linear regulators to select those voltages. While you might use the classic LM317, it has a relatively high drop-out voltage and can only go down to 1.2V. Instead, I’m using the more recent MCP1825, which has a lower drop-out voltage and can go down to 0.4V (it’s only specified to 0.8V, but in practice it goes lower). Watch the input voltage with the MCP1825. It’s rated only to a 6V input. For this reason, we use only three AA batteries as a power source which, when brand new, should generate about 1.6V each, for an input of 4.8V. If you use four AA batteries when they are new, it could blow up the MCP1825.
PUTTING IT TOGETHER
Some final touches on the circuit include an option to choose rising or falling edge trigger modes, a push-button manual trigger, and an LED that indicates when a glitch was inserted. The LED has a simple pulse-stretcher in front of it that makes it easier to visibly see the very narrow glitches. I won’t include the full schematic here, but instead will direct you to the project website [3].
We need a few more things for this to work. We need our target board with a LPC1114 microcontroller (MCU), we need a way to program the MCU and we need to understand a little more about the MCU itself. Let’s start with the development board preparation required. The development board we will use is made by Olimex, and is the LPC-P1114 development board for the LPC1114 MCU. You could use any development board (or even the raw chip), because we don’t need any features beyond being able to access the serial port pins and an ability to force the bootloader to run.
Forcing the bootloader to run means setting pin PIO0_1 and PIO0_3 to 0. The former is done with the BLD_E jumper, the latter will require you to add an extra jumper wire. The other modifications are to remove capacitor C4 and C1, open up the two jumpers 3.3V_CORE, add a jumper to route the two core voltage pins together and out to a header and to route the reset pin to 2 or 3 header pins. The reset pin is routed to multiple header pins as we’ll use it both as a driven signal (from the computer), and we’ll also trigger the ChipJabber-Unplugged. The end result is shown in Figure 4. Compared to the modifications from September 2018, there is one difference: before we added a shunt resistor since we’re only shorting the 3.3V_CORE to ground, now we are actively driving 3.3V_CORE. So, we simply cut open the jumper, and don’t add a resistor as before.
You’ll also need a serial adapter here to talk to the 3.3V logic levels of the LPC1114 device. Few people have access to a real RS-232 serial port on their computer anymore, so I’ll avoid trying to recommend using a MAX232 as would be standard for the articles of Circuit Cellar past. But, in keeping with the theme of using through-hole electronics, I’ll recommend the Microchip MCP2221A. This 14-pin DIP package IC provides a USB to UART conversion, with the bonus of a few extra GPIO pins. We’ll use these GPIO pins to toggle the device reset line.
SETTING UP THE ATTACK
In order to bypass the fuse bytes, we need to first configure them. If this was a “real-life” attack of course the device would already be locked. But first we need to actually program our test device to set it up like in real life. Luckily, we can do this through the provided on-device bootloader. We simply need to program a hex-file which has the value 0x12345678 at 0x2FC to trigger the code read protection. A suitable file is present on the project website (ChipJabber-Unplugged.com [3]).
Our setup is then as shown in Figure 5. Here the ChipJabber-Unplugged is set to have a “normal” core voltage of 2.00V. This is routed to the LPC1114 core voltage. The VCC and GND are routed to the USB serial dongle (here implemented with the MCP2221A as mentioned). Finally, the nRST pin for the LPC1114 is routed to both the MCP2221A GPIO2 pin, and also to the trigger input to the ChipJabber-Unplugged. This allows us to toggle the reset pin of the LPC1114. On the rising edge of the reset, we’ll adjust the delay of the fault to try and find where the actual loading or check of the read protection value happens.
To test our fault, we can implement some very minimal parts of the bootloader program. I’ve shown you in Listing 1 the basic Python 3 code. This uses an open-source PyMCP2221A library to toggle the GPIO2 pin, and then a standard serial driver (PySerial) to talk to the LPC1114. The most important command is the “R 0 4\r\n”— this is asking to read 4 bytes from address 0 (flash). The device will respond with code “19” if the device is locked. If the device response with any other code, it might indicate a successful glitch.
import time
import serial
from PyMCP2221A import PyMCP2221A
gpio = PyMCP2221A.PyMCP2221A()
gpio.GPIO_Init()
gpio.GPIO_2_OutputMode()
with serial.Serial('COM57', 38400, timeout=1) as ser:
while(True):
gpio.GPIO_2_Output(0)
gpio.GPIO_2_Output(1)
time.sleep(0.05)
ser.flush()
ser.write(b"?")
line = ser.readline()
print(line)
if line != b'Synchronized\r\n':
continue #Error on Sync - skip this run
ser.write(b'Synchronized\r\n')
print(ser.readline())
ser.write(b'12000\r\n')
print(ser.readline())
#Sync'd up - issue read, see if we got different response
ser.write(b'R 0 4\r\n')
resp = str(ser.read(10), 'UTF-8').lstrip()
if resp.startswith('R 0 4\r19') is False:
print(resp)
print("Possibly OK - run dump script now")
raise ValueError("Done?")
LISTING 1 – This simple script toggles the reset pin, and tries to read flash that should return the status code “19” indicating the device is locked. Any different status code indicates the device may now be unlocked.
A more complete version of this code uses a library that is capable of doing the complete code read. That code is available in the ChipWhisperer tutorial [2], so I haven’t recreated it here. The important part is just detecting if we have gotten an odd read value.
TUNING THE GLITCH SETTINGS
The most critical aspect is to tune the glitch settings. Too powerful a glitch means we’ll be resetting the device—not a useful effect. To do this, I use the same trick I talked about before, which is to perform power analysis at the same time. Instead of using my ChipWhisperer hardware as normal, I’ve attached an oscilloscope to the power pin. Setting the oscilloscope to AC-coupled and with a small input scale lets me see the power of the device during boot.
To start with, I set turned the “Normal” voltage that is driving 3.3V_CORE down until near where the device stopped running normally (stopped responding to the bootloader commands). I found around 2.00V worked OK here. I then turned the “glitch” voltage to minimum to start (which is about 0.41V).
— ADVERTISMENT—
—Advertise Here—
The next step is to tune the glitch width. To do this I triggered my oscilloscope off the rising edge of the reset pin (same trigger used by ChipJabber-Unplugged). I then monitored two outputs. The first was the output of the ChipJabber-Unplugged, measured using a DC-coupled measurement. This measurement lets me see the size of the pulse inserted. The second measurement is the same output but measured nearer to the device, and measured using an AC-coupled input that won’t be able to capture the full glitch waveform, because I’m zooming in on a small (50mV) scale. This second measurement is trying to observe the boot sequence of the device.
Starting with the narrowest glitch setting, I observed the device during boot. As you widen the glitch out, you will see different effects. You can see in Figure 6 an example where the glitch width has been increased too far, and the device has “flat-lined.” You are actually seeing me trip some sort of reset circuitry here and the device will reboot.
If I reduce the glitch width slightly, the oscilloscope trace now looks like Figure 7. Here the device has booted without interruption. Sweeping the location of this glitch around eventually finds a successful glitch. In my case, I ended up inserting a glitch at 52.2µs from the rising edge of reset, a glitch width of 142ns, a normal operating voltage of 2.00V, and a glitch voltage of 0.41V.
The actual successful glitch will require some experimentation on your part. Because I haven’t gone into as much detail about the search strategy, there are a number of references and resources provided for you, available in the RESOURCES section at the end of this article. I’ve already mentioned a few of these earlier, such as my September 2018 article [1], Chris Gerlinsky’s original presentation [4] and the ChipWhisperer tutorial [2]. Beyond that, you can see a series of blog posts by Dmitry Nedospasov on Toothless.co [5], which later evolved into a more complete presentation by Thomas Roth, Josh Datko, and Dmitry Nedospasov called Chip.Fail [6]. Finally, another glitch circuit I’ll direct you to is Samy Kamkar’s GlitchSink [7]. It implements another variation of the voltage glitch hardware. Of course, you can also use your trusty ChipWhisperer hardware with the more advanced ChipJabber (not “unplugged” edition) if you want complete control.
BUILDING YOUR OWN
Now that you’ve seen all the fun you can have, you must want to build your own, right? While you might have noticed there is no full schematic and PCB artwork in these pages. I’ll direct you instead to the project website at ChipJabber-Unplugged.com [3]. Here you can find the full schematic and Gerber files, including ones I used in these photos, which are optimized for homemade PCBs. If you’re interested in a ready-made parts kit or PCBs, you can find more information on that website as well. Hopefully you’ll enjoy this chance to prove that even “old tech” can still create many of the attacks that people have only recently started paying attention to. 
RESOURCES
References:
[1] Colin O’Flynn – “Recreating Code Protection Bypass: An LPC MCU Attack” (Circuit Cellar 338, September 2018)
[2] ChipWhisperer Tutorial – Bypassing LPC1114 Read Protect
http://wiki.newae.com/Tutorial_A9_Bypassing_LPC1114_Read_Protect
[3] ChipJabber-Unplugged Reference: www.chipjabber-unplugged.com
[4] Chris Gerlinsky – “Breaking Code Read Protection on the NXP LPC-family Microcontrollers”. Recon Brussels 2017. https://recon.cx/2017/brussels/resources/slides/RECON-BRX-2017-Breaking_CRP_on_NXP_LPC_Microcontrollers_slides.pdf
[5] Dmitry Nedospasov – “NXP LPC1343 Bootloader Bypass” – https://toothless.co/blog/bootloader-bypass-part1
[6] Thomas Roth, Josh Datko, and Dmitry Nedospasov – “Chip.Fail: Glitching the silicon of the Internet-of-Things.” – https://chip.fail
[7] Samy Kamkar – GlitchSink – https://github.com/samyk/glitchsink
Maxim Integrated | www.maximintegrated.com
Microchip Technology | www.microchip.com
NXP Semiconductors | www.nxp.com
Olimex | www.olimex.com
Texas Instruments | www.ti.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JULY 2020 #360 – Get a PDF of the issue
Sponsor this Article
Colin O’Flynn has been building and breaking electronic devices for many years. He is an assistant professor at Dalhousie University, and also CTO of NewAE Technology both based in Halifax, NS, Canada. Some of his work is posted on his website (see link above).
