Hardware Power Glitch Attack (Fault Injection) - rhme2 Fiesta (FI 100)

I was walking through the financial district when I came across this strange device. Anyone know what it is? There are no recognizable logos or brands, 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 souvenir, but it has 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'm curious about the device and its contents. Could you unlock it via

fault

injection

? Hey guys, this was a recreation of the story in the Fiesta challenge description of the sophisticated CTF embedded

hardware

.

I'm 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, i.e. 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. Ever." - that's what a software developer would say. But bear with me. We'll do a

hardware

attack

and get out of this loop. I'm so excited about this challenge, it was my favorite thing to experience and the perfect ending to the sophisticated embedded hardware CTF for me.

Prepare to have your jaw dropped. attacks from university and also saw some talks at conferences about it. Which is just theoretical knowledge, but at least I had some of plan. So the challenge is a

fault

injection

challenge, which means you screw the hardware into doing something wrong. And there are several ways to perform a fault attack. For example, you know from movies how an EMP can damage electronic devices, so activate a small electromagnetic pulse in the chip and it might do something strange. Or the chip runs on a clock at a certain speed and strange things happen once you let it run faster than intended or much slower.

But what I will do is a

power

problem. Which means I want to cut off the

power

supply for a really short period of time, so that the device doesn't reboot, but it does something weird. And to do this I need to build something. I choose to do it with an FPGA development board that I still have lying around. An FPGA is for now like any other electronic board, something 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 are a software developer, you may find the code you write for FPGAs very strange. At least it took me a long time until I understood. Because you're not writing sequential programs, you're actually 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.

And what you're seeing here is a very, very simple chip that I designed. This is just a first try at rewriting Verilog code, but let me try to explain it. As I said, here I am describing the behavior of the chip. 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, i.e. a small memory cell that remembers some values.

I already defined a 32-bit counter register, but I'm ignoring it for now. And a

glitch

_register, which will be the output for the

glitch

, so 1 is on or 0 is off. Now I connect these internal registers with a real output from the chip. Really imagine cables running from the fault register to the output. This way, both the LED and the output of the pin are connected directly to the register value. And I also connect the button input to the other LED output, so obviously when the button is pressed, the LED will light up. You see, we're 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 fault power output is 1, so it turns on at first. And then comes a block that simply describes what happens in each clock cycle. Whenever the clock signal has a positive edge, that is, a rising edge, it will do the following. It will take the value in the crash register and invert it. And you know that the fault register is connected directly to this output pin, so that pin will simply move 1,0,1,0,1,0 with each clock cycle.

Then you simply compile the hardware definition and program the FPGA. And by programming the FPGA I don't mean writing some kind of sequential assembly code into some memory. This is not a processor. You can build a processor with it, so it's 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 pretty fascinating how it works, so you should look it up. And then we can look at the oscilloscope and see that it works.

You'll see that the output pin here constantly goes to 0,1,0,1,0,1. Great 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 the power should be off, so I have to include them in another definition file. Developing this hardware stuff 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 it was right around the time when bitcoin people started implementing mining on FPGAs.

The verilog code is still very short because it is not a really complicated circuit. But let's see. First of all, everything here happens when the FPGA sees a rising edge of the clock. And then things here don't happen sequentially, they just define what happens when you see the rising edge. Everything is simultaneously, they are 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 to see if the button is pressed. If the button is pressed, the status will be set to fault.

So, with the next clock cycle, the FPGA is now in the fault state where it will generate a 0, to indicate that the power will be turned off and start incrementing the counter. So with each clock cycle, this counter will continue to increment. At some clock cycle in the future, 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 level is reached the state will change to sleep. By this I mean that I don't want to accidentally miss several times in succession, because a miss is very short, and when I don't release the trigger button fast enough, I could miss again.

So wait will generate a 1 again, so the power comes back on, but it will also use a counter to wait a moment. And when enough clock cycles occur, it will return to the idle state where we wait for the button to be pressed again to perform another error. Now we can take a look at it with the oscilloscope, we can see that the power is high, and when we press the shutter button, the power will drop to 0 for a very short period of time. You can see the scale of the oscilloscope in nanoseconds here. And with switches we can set a counter value to indicate how long a failure should last.

Oh, this looks very good. I think we're ready to go. So now we just have to connect our target to control the power. This is actually a bit complicated, because the board receives power through the USB cable, which also carries 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 does not 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.

Then I simply reuse the one-way level converter. It seems complicated but it does nothing more than being able to change 5V with a 3V signal. And now we can connect that 5V to VCC, the power input of the board. You will find 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 via serial. As you know, those arduino boards have an extra chip, a USB to serial UART converter. Which is great, because we already have the USB drivers installed on my laptop.

Now I just take an Arduino UNO that I have and remove the Atmega microchip. Basically now it's just the USB to UART chip left and I can directly connect RX and TX to the target board. When I now establish a serial connection with this arduino UNO board, what I actually do is talk directly to the serial on the challenge board. And here is the complete configuration. We have the FPGA that performs a power failure that can be configured with the switches. And pressing the button will actually do it. The 3V fault output of the FPGA is converted to 5V through the unidirectional level converter and then connected to the VCC, the power input of the target board.

So when the FPGA's fault output drops, the power supply to the challenge board is cut off for a brief moment. And to interact with the board via serial, we have connected the USB to serial converter chip from another Arduino. Awesome. Now all we have to do is connect to the series so we can observe the "BLOCKED" message and then play with the duration of the error. 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 the power drops.

But it's actually not that bad, so the power is not completely cut off, but simply drops a little below the recommended voltage threshold. I think it's better for a technical problem. So when you play with him, sometimes you miss the board so much that it resets. Which is not what we want. And sometimes it even loses the program you installed. 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 update. I have no idea why it happens, but you can see that failures are somewhat dangerous and in theory you could brick the board if you fail a critical code path in the bootloader.

But when you get the timing right, i.e. at 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 quickly recap. The board had an endless loop that would never stop and the flag was printed 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 the power is below the minimum voltage for a short period of time. Typically the chip doesn't work at those voltage levels, but because we do it for a very short period of time, it won't just stop working, it could miscalculate some loop condition or perhaps skip instructions altogether. .

We really don't know. I'm also assuming that riscure made it very easy so you don't have to fail on an exact comparison 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 on something important. However, I think this is just amazing. I always felt that these types of fault injections are very theoretical and unrealistic, but having done a simple one myself and not even a professional, was amazing. I hope you can appreciate how crazy that is too. I just wish the challenge of side channel power analysis had been at the same level.