FPGA-Driven Glitching (Regular and Crowbar) with Phase-Locked Loop

I spent the majority of this weekend working on improving my knowledge of hardware security, focussing on my experiments with glitching. In my previous posts on the topic, I had investigated how one could use two Arduinos to generate glitches against each other, by cutting the power supply.

In this post, I will cover how to do the same with an FPGA, and how to use a crowbar circuit to generate an alternative style of glitch, which is advantageous for attacking production devices where we cannot (or do not want to) modify the target hardware.

iCE40 HX8K

In these experiments, I will be using the iCE40 HX8K breakout board to drive my glitches:

This board can be purchased for just under $65 each from Digikey at the time of writing – it comes with an inbuilt programmer, and can be programmed with the lightweight, vim-friendly Project IceStorm toolchain. In the above photo, this device is configured to be programmed into volatile memory only (J6 jumpers horizontal, no jumper on J7).

Crowbar Circuit Glitching

We will first create a crowbar circuit to generate glitches against an Arduino board (Arduino Uno-compatible target). Compared to previous glitches where we simply broke the power circuit on a glitch trigger, this circuit will short out VCC to GND. In diagram form:

I couldn’t find the transsitor symbol on draw.io, the little triangles are transistors.

In practice, we can implement this by removing the microcontroller from the Arduino board and inserting it into a breadboard, connecting a minimal set of pins back to the board, and then using a transistor across the VCC and GND lines, as per the following diagram:

All the blue pins should be wired up to their corresponding sockets on the host, and use a transistor (I used a 2N7000 I found on the floor) to create a short circuit when a a trigger signal is high. If all goes well, you should be able to switch on the board and have it work as normal (mostly). Our test code is a simple counting loop:

int x;
int y;
double i = 0;
while(1)
{
  for(x = 0;x < 500;x++)
  {
    for(y = 0;y < 500;y++)
    {
      i += 1;
    }
  }
  Serial.println(i,DEC);
}

The final result should resemble something like this:

Here, the purple and blue wires are VCC, and the orange and grey wires are GND. The red wire is the glitch trigger (and black is common ground for the FPGA): when it’s raised past the transistor’s threshold voltage, the transistor will begin conducting, shorting out VCC and GND. In it’s default state (with the transistor off), the Arduino board should function as normal.

Increasing Clock Speed with PLLs

The next step is to build the control code for this. The control code is simple – to generate continuous glitches, we perform an infinite counting loop – once we reach a sufficiently large number, we pull an IO pin high (to switch on the transistor) for a number of clock cycles, and then we pull the pin low and reset the counting loop until the next glitch.

This code is well suited for an FPGA, but the onboard clock of our board only runs at 12Mhz. We can increase the clock speed dramatically by using a Phase Locked Loop (PLL). In a nutshell, a PLL is a way to generate a signal at a fixed ratio to the input clock. The IceStorm compiler toolkit provides a macro (SB_PLL40_CORE) to configure a PLL in the FPGA, and documentation for the iCE40 FPGA itself describes the parameters (from Page 7 of “iCE40 sysCLOCK PLL Design and Usage Guide”).

We can then construct our PLL initialization macro (by  “construct”, I mean “copy from the Internet and adjust as necessary”):

SB_PLL40_CORE #(.FEEDBACK_PATH("SIMPLE"),
 .PLLOUT_SELECT("GENCLK"),
 .DIVR(4'b0000),
 //.DIVF(7'b0001000), //25Mhz
 .DIVF(7'b0111111), // 48/96MHz
 //.DIVQ(3'b001), //25Mhz
 // .DIVQ(3'b100), //48Mhz
 .DIVQ(3'b011), //96Mhz

.FILTER_RANGE(3'b001), // wfm without PLL is broken
 ) uut (
 .REFERENCECLK(clk),
 .PLLOUTCORE(clk_25),
 // .LOCK(P16),
 .RESETB(1'b1),
 .BYPASS(1'b0)
 );

The actual glitching loop is a trivial counting loop with adjustable glitch width and toggling LED patterns to indicate when glitches occur, as follows:

always @(posedge clk_25) begin
 if (rst) begin
 glitch_reg <= 0;
 ctr_p <= 0;
 ctr_q <= 0;
 end else begin
 ctr_p <= ctr_p + 1;
 if (ctr_p == 32'h00800000) begin
 ctr_q <= 32'h00000fff; // target at 12mhz: how long does this need to be?
 if (blinkptn == 8'b10101010) begin
 blinkptn <= 8'b11110000;
 end else begin
 blinkptn <= 8'b10101010;
 end
 ctr_p <= 0;
 end
 if (ctr_q > 0) begin
 glitch_reg <= 1;
 ctr_q <= ctr_q - 1;
 end else begin
 glitch_reg <= 0;
 end
 end
end

We then program the FPGA, power on the contraption, and if all goes well, you should see glitches appear reliably (you’ll need to adjust to find the correct glitch width, and change the frequency to taste).

(My attempts in) Glitching the ESP8266…

In our previous experiments, I had used an ESP8266 device (a LoLin NodeMCU from the BSides Canberra badge – thanks Silvio!) to drive glitches against an Arduino target. I wanted to see if I could use a crowbar circuit to glitch this target. I first identified the VCC and GND rails, and tried the same circuit as above:

I also tried glitching the voltage regulator, shorting out the output to the ground pin, to little success. My next step was to remove the metal casing: 

Underneath, we can see an ESP8266EX MCU, as well as a NAND Flash, an oscillator crystal (26MHz) and a bunch of decoupling ~things~. At this point, I figured if I removed all the decoupling components, I’d be able to impact the power supply more meaningfully, but this met without success.

Note that one of these is not a decoupling component, and actually connects to the reset pin – I’ll leave identifying which one as an exercise for the reader.

After a little bit of scratching my head, I went back and re-read Colin O’Flynn’s excellent paper on crowbar circuits (https://eprint.iacr.org/2016/810.pdf), and my eye was drawn to an interesting comment:

 This particular MOSFET has a RDS(ON) of 0.035Ω, meaning it would
 be less effective against low-impedance power rails likely to be
 found on high-speed processor boards.

Going back to the datasheet of the 2N7000 transistor, I noticed a potentially fatal flaw:

It is my conjecture that this high of a resistance prevents a crowbar glitch from being effective against the ESP8266, as there is a much lower resistance (well, impedance) path through the MCU – therefore, even when VCC is shorted with GND, enough current flows through the MCU to make this not matter.

Furthermore, I made no attempt to solder directly to the pins of the MCU, as an error-isolating measure, primarily due to laziness. I will try this in future.

When all else fails!

At this point, I wanted to experiment with regular MITM-style glitching against the ESP8266, partly to confirm my own suspicion. The new setup was much simpler:

Here, I used an Arduino board to supply 3.3V directly to a 3.3V input on the target, and used a transistor to intercept the ground rail. With some slight modifications to the glitching code, I could reliably produce glitches here as well:

Strangely, this experiment produced far less arithmetic errors than a similar experiment against an Arduino. I’m not sure why this might be (my glitching is not precise enough? I need shorter glitch pulses?), but I will expeirment with this further when time permits.

Summary

In this article, we covered the basic theory of a crowbar circuit for glitching, and demonstrated it practically against two targets: one successful (Arduino / Atmega328p) and one unsuccessful (BSides Badge / ESP8266EX). This has left us with several points for further investigation, which I am most excited to continue working on.

You can download the control code (as well as board configuration file, and makefile) here.

Bonus!

Next week, I am running a hardware workshop, in conjunction with our friends from Sectalks – it is bitterly sobering that there is so little activity in this area in the local security community about this topic that I, of all people, feel comfortable standing up in front of a crowd and talking about this.

Nevertheless, building community and capability starts somewhere, and here, it starts with a slide pack of destiny:

 

About Norman

Sometimes, I write code. Occasionally, it even works.
This entry was posted in Bards, Computers, Jesting and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s