Hardware Power Glitch Attack (Fault Injection) - rhme2 Fiesta (FI 100)May 05, 2020
I was walking through the financial district when I came across this strange device. Anyone know what it is? It has no recognizable logos or branding, just the letters "V1" written on one side and a USB connector on the other. Here is a photo. It's probably some kind of memory, but it's an unusual design. I'll check it when I get home. I finally got home. I connected the USB device to my computer, but it seems to be permanently locked. Now I am curious about the device and its content. Would I be able to unlock it using Fault Injection?
Hey guys, this was a recreation of the story in the Riscure Embedded Hardware CTF Fiesta challenge description. I am very excited about this one. So check it out. The device is permanently locked, we can imagine the code could look like this: a loop with a condition that will always be true, so it's an endless loop. And it just prints "Lock", which sucks, because we want to get to the code after the loop, where it prints the secret. “Clearly there is no way to get to that code. Sometime." - that's what a software developer would say. But bear with me.
We will perform a
attacks from college and also watched some conference talks about it. Which is only theoretical knowledge, but at least I had something of a plan. So the challenge is a
attackand fail to get out of this loop. I am so excited about this challenge that it was my favorite experience and the perfect ending to the Riscure embedded
hardwareCTF for me. Prepare to have your mind blown.
injectionchallenge, which means you fuck with the hardware to make it do something wrong. And there are multiple ways to perform a
For example, you know from the movies how an EMP can jam the electronics, so trigger a small electromagnetic pulse in the chip and it could do something weird.Or the chip runs off a clock at a certain speed and weird things happen once in a while. ez you let it run faster than intended or much slower. But what I'm going to do is a
powerproblem. Which means I want to cut the
powersupply for a really short amount of time, so the device doesn't reboot, but does something weird. And to do this I need to build something.
I choose to do it with an FPGA developer board that I still have lying around. An FPGA is for now like any other electronic board, something that you can program to do whatever you want. In my case I want to use the switches to control the duration of the power drop and a button as a trigger. And I want to use a single wire as the output of the FPGA to control an electronic switch that turns the power supply on or off, i.e. a transistor. So let's focus on the first part, programming the FPGA to do what we want.
If you're a software developer, the code you write for FPGAs may sound very foreign to you. At least for me it took quite a while until it clicked. Because you're not writing sequential programs, you're really just writing a definition, a description of a digital circuit. The same description languages are basically used in the design of real chips like CPUs. So what you're looking at here is a very simple chip that I've designed. This is just a first try to rewrite the verilog code, but let me try to explain it. Like I said, I'm describing the behavior of the chip here.
And at the beginning I say that this chip has some inputs, for example, a switch, a button and the clock. So the FPGA board also has a clock signal. Which is just 0,1,0,1,0,1,0,1... And I define some outputs: two LEDs and a normal output pin on the board. Then I define some internal registers, so a small memory cell that remembers some values. I've already defined a 32-bit counter register, but ignore it for now. And a glitch_register, which will be the output of the glitch, so 1 is on or 0 is off. Now I connect these internal registers with an actual output from the chip.
Really imagine the wires going from the
faultregister to the output. So the LED and pin output are directly connected to the register value. And I also connect the input of the button to the other output of the led, so obviously when the button is pressed, the LED will turn on. You see, really just describing how the chip is connected. Then I set some initial values, these values are set when the device is turned on. So the counter for now is set to start at 0, but the
faultpower output is 1, so it turns on from the start.
And then comes a block that simply describes what happens at each clock cycle. Every time the clock signal has a positive edge, that is, a rising edge, it will do the following. It will take the value in the fault register and invert it. And you know that the fault register is directly connected to this output pin, so that pin will simply move 1,0,1,0,1,0 with each clock cycle. Then it just compiles the hardware definition and programs the FPGA. And by programming the FPGA I don't mean that you write some kind of sequential assembly code in some memory. This is not a processor.
You can build a processor with it, so it's kind of a deeper layer. But basically it contains a lot of digital building blocks that will connect together in a way that does what you described. So yeah, it's a lot of magic. But it's quite fascinating how it works, so you should look it up. And then we can look at the oscilloscope and see that it works. You see the output pin here is constantly going 0,1,0,1,0,1. Cool huh? Now I just have to write a little more verilog code to get the behavior I want. So, for example, I want to use the switches on the board to set how long to turn off the power, so I have to include them in another definition file.
Developing this hardware is really frustrating at first, but I learned it on my own a few years ago, because I heard that FPGAs are amazing, I think that was just about the time when bitcoin people started to implement mining on FPGAs. The verilog code is still very short, because it's not a really complicated circuit. But let's see. So first of all, everything here happens when the FPGA sees a rising edge of the clock. And then things here don't happen sequentially, it just defines what happens when the rising edge is seen. It's all simultaneously, it's wires connected in a circuit of digits, not a program.
So if the current state was idle, which is when the device turns on, check if the button is pressed. If the button is pressed, the status will be set to fail. So with the next clock cycle, now the FPGA is in a fault state where it will generate a 0, to indicate that it will turn off the power and start incrementing the counter. So with each clock cycle it will now keep incrementing this counter. At some future clock cycle, the counter will have the exact binary value of the switches. So with switches you can obviously set a binary value with 0 and 1.
So if that is reached the state will change to wait. By that I mean I don't want to accidentally miss multiple times, because a miss is very short, and when I don't release the fire button fast enough, I could miss again. So Holdoff will output a 1 again, so the power turns back on, but it will also use a counter to wait for a moment. And when enough clock cycles happen, it will go back to the idle state where we wait for the button to be pressed again to perform another fault. So now we can take a look at that with the oscilloscope, you can see that the power is high, and when we press the trigger button, the power will go down to 0 for a very short amount of time.
You can see here the scale of the oscilloscope in nanoseconds. And with switches we can set a counter value to indicate how long a fault should last. Oh this looks great. I think we're ready to go. So now we just have to connect our target to control power. This is actually a bit tricky, because the board gets its power through the USB cable, which also carries the serial communication so we can interact with the board. But let's go step by step, first of all let's take care of the power. The FPGA board doesn't work with 5V, so we have to use a small circuit to convert the 3.3V to 5V, which we already did for the power side channel analysis a few videos ago.
So I just reused the one way level converter. It looks complicated but it does nothing more than being able to switch 5V with a 3V signal. And now we can connect that 5V to VCC, the power input of the board. You will see that you don't have to go through the USB cable, you can simply connect directly to the power source. Now we just need to be able to somehow interact with the board through the serial. As you know, those arduino boards have an extra chip in there, a USB to UART converter, thus serial. Which is great, because we already have the USB drivers for that installed on my laptop.
Now I just take an arduino UNO that I have and remove the atmega microchip from it. Basically now only the USB to UART chip is left and I can directly connect the RX and TX to the target board. When I now make a serial connection to this arduino UNO board, what I'm actually doing is talking directly to the serial on the challenge board. And here is the complete setup. We have the FPGA that performs a power failure that can be configured with the switches. And pressing the button will really do it. The FPGA's 3V fault output is converted to 5V via the one-way level converter and then connected to VCC, the target board's power input.
So when the FPGA's fault output drops, the power supply to the challenge board is cut off for a brief moment. And to interface with the serial board, we've connected the USB-to-serial converter chip from another Arduino. Awesome. Now all we have to do is connect to the serial so we can watch the "BLOCKED" message and then play with the duration of the glitch. You can also see that the power doesn't drop completely like before without a target. I think maybe it has something to do with the capacitors on the target board releasing charge when power drops. But it's actually not that bad, so the power isn't completely cut off, but drops a bit below the recommended voltage threshold.
I think that's better for a glitch. So when you play with it, sometimes you miss the board so much that it resets. Which is not what we want. And sometimes he even loses the show you showed him. You can see here that after the crash, it started flashing red, which means the program is lost and the bootloader is waiting for it to show up. I have no idea why it happens, but you can see that failures are somewhat dangerous, and in theory you could crash the board if a critical code path in the bootloader fails. But when you get the right time, the right time you want to fail, and the voltage drop is the right length, then magically the loop breaks and the flag appears.
How crazy is that! Resolved! Let's recap quickly. The board had an endless loop that never stopped, and the flag would print after the loop. So in theory you could never get to that part. It's dead code. But we know that microchips can behave strangely and miscalculate things, for example, when power is below minimum voltage for a short period of time. Typically the chip is not operational at those voltage levels, but since we are only doing so for a very short period of time, it will not only stop working, but could miscalculate some loop condition, or perhaps bypass instructions completely.
We really don't know. I'm also assuming riscure made it very easy, so you don't have to fail an exact compare statement, but maybe they did a lot of calculations and if just ONE fails, it will break, so we have a high chance of failing something important. But nevertheless, I think this is just amazing. I've always felt that these types of glitch
injections are very theoretical and unrealistic, but to have done a simple one myself and not even a professional, it was amazing. I hope you can appreciate how crazy that is too. I wish the side channel power analysis challenge had been on the same level.
If you have any copyright issue, please Contact