Any tutorial about glitching

mbrugman · December 4, 2024, 4:17pm

(sorry, this may be a long post )
I’ve been working on a presentation for a hacking conference. I was going to talk about glitching/fault injection attacks, but not demo one. After reading this thread I decided it would be fun to do that!

First, a few photos of the setup:

The PCB under test is mounted in a 3D printed base. The Bus Pirate is connected to the UART pins of the PCB and to a ChipShouter PicoEMP

A close-up of the business end of the EMP tool up against the microcontroller

Next, here’s a quick tutorial/explanation of what I’m doing:

Background

The device being “hacked” is the PCB from a cheap webcam. In this case, we’ve found the UART pins and have connected the Bus Pirate to them and interrupted the bootloader (U-Boot).

U-Boot is prompting for a password we don’t know, so we’ll try sending a carriage return (\r) character and then firing an EMP blaster at the microcontroller during the “check” of the password.

If the password was not correct, U-Boot will send the text ### Please input uboot password ### back over the serial line. The glitch code will parse the response looking for a specified letter. If that letter is not present, then the password check was bypassed.

Code

First, I added a new command in the UART mode: glitch. You can see the code here in my fork of the main repo.

The code uses two of the IO points:
I00 - this is the output to the glitching hardware/device
I01 - an input to let the code know the hardware is ready

The basic code flow (once configured):

Check to make sure hardware is ready (with timeout)
Send a carriage return
After user-specified delay, fire the output to the glitcher tool
Start receiving from the device under test (DUT)
Get up to 19 characters or timeout
Parse response, looking for a certain letter (In this case, a capital ‘P’)
If that char was not found, end
Wait a short delay
Count attempts, if not at limit, jump back and try again

At any time, pressing the BP button will stop the process.

Determining timing

I used a logic analyzer. I wanted to use the FALA, but I couldn’t get the libraries to load for it under Linux.

Here’s a capture of the full sequence:

The top input is the BP sending the return to the DUT
The second input is the response from the DUT to the BP
The third input shows the output I00 from the BP

Zoomed in a bit with some timing markers:

The first input shows the end of the TX from the BP
Second input shows the DUT starting to send the “bad password” response
Third input shows where the glitch device was triggered.

Timing pair one shows the BP output went high 5.625us from the end of the BP TX. The second just shows that there’s a time of 8.25us from the send of the BP to the DUT telling us the password was bad

This was an iterative process - I changed the glitch config a few times to get the timing where the PicoEMP was firing about where I guessed the U-Boot code was checking the password.

Operation

First, I used the bridge command of the UART command to get the DUT into a condition where it was accepting password attempts. I pressed the button on the BP to stop the bridge, but not exit UART mode.

Next, issue the the glitch command. This is from the serial terminal:

UART> glitch


Use previous settings?
 Glitch trigger character: 13 (ASCII)
 Glitch trigger delay: 83 us
 Glitch cycle delay: 50 ms
 Normal response character: 80 ASCII
 Number of glitch attempts: 10 

y/n, x to exit (Y) > 

Hardware setup!

UART Glitcher.  Press Bus Pirate button to exit.
Attemp 1 RX: ### Please input ub
Attemp 2 RX: ### Please input ub
Attemp 3 RX: ### Please input ub
Attemp 4 RX: ### Please input ub
Attemp 5 RX: ### Please input ub
Attemp 6 RX: ### Please input ub
Attemp 7 RX: ### Please input ub
Attemp 8 RX: ### Please input ub
Attemp 9 RX: ### Please input ub
Attemp 10 RX: ### Please input ub
Target glitch count exceeded, no glitch :/

UART>

As for the settings:
trigger character was going to be configurable, but I figured most times it will trigger on hitting return, so it’s actually hardcoded right now.
triger delay is a time in microseconds from when the character is sent to the BP UART until the I00 output goes on. It’s 83 us here - the time begins shortly after the character is sent, not when the send is done. It took some trial and error with the logic analyzer to get that time
cycle delay is just a time between attempts
normal response character is a character that you’d expect to see if the password code on the DUT ran. In this case, it’s ASCII 80 for a capital P. The DUT responds with ### Pleas… The assumption is that if we don’t see that, we glitched past the check code
attempts how many times to try before giving up.

That’s the basics. I’ve gotten to the point where everything works, but haven’t successfully glitched it yet. I just wanted to share what I’ve been doing.

Next, I need to modify the firmware of the PicoEMP. If you connect to the serial port, you can arm a “Fast Trigger” mode. In that mode, there’s a PIO running (yes, it’s 2040 based); that PIO watches an input and quick-fires the EMP pulse. But you need to arm that mode each time. I will modify the firmware to just start up in that mode and stay there.

Let me know if anyone has any questions or comments. I’ll follow up if I get it to bypass the password entry.