Glitching is a technique to interfere with processor electrical input. One way to achieve this is briefly lowering the voltage a CPU gets in hopes that it results in skipped instructions, incorrect fetches, decodes or bad writebacks.

Voltage Fault Injection 1

Description:

Challenge 7: "Power Trip"

You’ve discovered a device that appears locked down tight, every known interface rejects your commands. But somehow you find a code block that’s never supposed to execute, likely due to built-in protection checks.

By carefully injecting a voltage glitch at the right moment, you might be able to bypass those checks and force the device into revealing its hidden path. The SDA pin serves as your glitch trigger, and if successful, the device will spill the flag over UART @ 9600 baudrate.

Your mission is clear:

    Identify the timing window during which to trigger the voltage glitch.
    Inject a glitch using the SDA pin as your trigger source.
    Access the dead code block and retrieve the flag via UART at 9600 baudrate.

I have started the challenge by building a simple fault injector using pi pico and a project from MKesenheimer https://github.com/MKesenheimer/PicoGlitcher

Parts needed:

• Pi Pico
• 2 Resistors (1K and 10-50Ohm)
• jumper cables
• NPN transitor, I used BC546
• breadboard

using those parts I have built the following circuit

When the transistor is not switched on (no glitch signal is being send from pico) then 5V are being supplied to the PwnPad via pico VBUS or VSYS lines, but as soon as we switch the transistor on the voltage on those lines drops for a very short period of time below typical operating voltage resulting (if we did it correctly) in the fault being injected and hopefully returning the flag.

This is the glitcher connected to the PwnPad with the capacitor desoldered, as they might interfere with the glitch.

Connecting to UART we see a message

when enabling the glitch we can see that cnt got corrupted and appear to have been set to higher than possible value

Voltage Fault Injection 2

Description:

Challenge 8: "Glitch Storm"

Building on the success of the Power Trip challenge, you are once again faced with the same challenge. The goal remains the same, trigger a voltage glitch to enter a hidden code path and retrieve the flag.

However, the catch this time is that the glitch trigger is no longer the obvious SDA pin. You must discover the new trigger pin and timing to successfully glitch the device.

Your mission is clear:

    Analyze the device to identify the new glitch trigger.
    Precisely time and inject the voltage glitch at the discovered trigger.
    Access the hidden code block and extract the flag over UART.

For this challenge I have decided to use a MOSFET for glitching, which I felt gave more reliable results. I used the same 33R resistor and IRLZ44N as the mosfet

Here it is on a breadboard

In this case the glitch works a little bit different, when the mosfet is switched on as we can see from the schematic the input voltage from pico will be pulled to ground for a short period of time. We can observe this using our logic analyzer.

This is the controller input I used to glitch the PwnPad and the resulting flag, you can also notice it did not work the first time and the device actually turned off a couple of times.

I2C (Inter-Integrated Circuit) is a two-wire serial communication protocol designed for efficient communication between integrated circuits. It uses just two lines: one for serial data (SDA) and one for serial clock (SCL), allowing multiple devices (masters and slaves) to communicate on the same bus. The protocol is synchronous, all devices share a common clock signal managed by the master.

I2C challenge 1

Description:

Challenge 3: "Bus Whisperer"

Deep inside an abandoned research lab, you’ve discovered a prototype security device. It appears to be communicating with hidden components over an I2C bus. The traffic is silent to the untrained eye, but with the right tools, you can eavesdrop on the device's conversations and uncover what it's hiding.

Your mission is clear:

    Identify the I2C communication lines used by the device.
    Identify all connected I2C devices the system is interacting with.
    Retrieve the hidden message embedded in the communication.

I started of by identifying the I2C pins on the board, as with the UART they were labelled, easy to spot. Then I connected my login analyzer, to see if any data was being send.

I saw that some data is being transmitted.

I setup a i2c analyzer in logic and saw that the master tries to write to i2c devices from different addresses When viewing it as ASCII text we can see that it is in fact the flag being written. (NOTE I have changed the connections on my logic analyzer as it was behaving weirdly on channel 1)

I2C challenge 2

Description:

Challenge 4: "Invisible Wires"

You’ve infiltrated a secure facility to extract a prototype device believed to hold critical secrets. After ripping the main board from its casing and making your escape, a sudden realization hits (you left a secondary board behind), still wired in and powered.

Unexpectedly, the stolen board is trying to communicate with its twin over I2C, as if expecting a response. It’s time to turn the tables: tap into the bus, reverse the dialogue, and extract what it’s trying to say.

Your mission is clear:

    Identify the I2C lines used for board-to-board communication.
    Reverse engineer the protocol or expected responses from the second board.
    Emulate or spoof the missing board to trigger a flag or secret message.

On the logic analyzer we see thats its trying to setup a write to device under 0x12 address, but it is not getting acknowledged so it keeps waiting for a device on the bus.

We can get the flag by emulating a device under the address 0x12. I have used esp32 bus pirate for this purpose, but it can also be done with an arduino https://github.com/geo-tp/ESP32-Bus-Pirate

UART or Universal Asynchronous Receiver-Transmitter is one of the most used protocols for serial communications between devices. It only uses two wires between transmitter and receiver to communicate and one wire for the shared ground. The data formats and transimission speed that it should used are configurable. Data in UART is transmitted as frames.

Uart challenge 1

Description:

Challenge 1: "Serial Snitch"

As a skilled hardware hacker, you've intercepted a mysterious device recovered from a rogue tech syndicate. The device, dubbed "Specter-1", controls access to a secret underground server, but its interface remains locked behind an unknown UART configuration.

Your mission is clear:

    Identify the UART pins you've uncovered during your investigation.
    Determine the correct baud rate to establish a stable connection.
    Access the device’s command interface and unlock control over the system’s lighting grid.

First I identified the UART pins on the PCB, they are labeled so its easy to find. After that I have connected my Logic analyzer to TX, RX pins and GND to the GND on my logic analyzer.

Then I have connected my Logic Analyzer to my PC and started Logic software from Saleae. After starting the capture in Logic and turning on the PwnPad we can see that some frames were captured for the 1st channel.

In this case the default setting for decoding the uart transmission worked well and I didn’t have to change anything to get the flag. You can also turn the LED ON/OFF if you have a device (USB-UART TTL FT232) to trasnmit data to the PWNPAD.

Uart challenge 2

Description:

Challenge 2: "Echo Chamber"

Following the success of your first infiltration, you've intercepted another device from the same syndicate. This one seems almost identical — same pinout, same behavior — but something’s off. Your usual tools can’t make sense of the UART output. It looks like the engineers behind this one were clever enough to obfuscate communication by using a non-standard baud rate.

The challenge is a test of patience and precision. You'll need to analyze the signal itself to get in.

Your mission is clear:

    Identify the UART pins using your probing tools.
    Determine the correct (non-standard) baud rate via signal analysis.
    Establish a reliable terminal connection and extract the flag from the interface.

In this case from the description we can see that the baud rate is not gonna be standard, we can follow the same steps as with the previous challenge, but we need to get the right baud rate, so that the decoding is sucessful. Baud rate just tells us how many bits are send each second, so we can take the time of one bit width to get the approximate baudrate for our challenge

baudrate = 1 \ width_of_bit

We can see that we are receiving something, but with baudrate of 9600 the data in unreadable

We zoom in on Logic and check the width of 1 bit and the input that into our calculation

32us = 32 * 10^-6

inputting that into our formula we get:

1 / (32 * 10^-6) = 31250

We can change the uart configuration in Logic and get our flag

PwnPad is a cheap, easily to assemble, fun introduction to hardware hacking. You can find more about the project on its github repo https://github.com/twelvesec/PwnPad/tree/main

Arduino as ISP programmer

I encountered a lot of problems when trying to upload a bootloader to my atmega 328p, so hopefully this helps some people.

First off you might read that it will work with minimal setup and you don’t really need an external 16Mhz clock, decoupling capacitor or other stuff, well in my case it did not work with the minimal setup and I just “bricked” my atmega with a wrong fuse setting when trying to burn the bootloader.

In any case I would recommend the following components if you want to use an Arduino:

• 2 22pF capacitors
• 2 100nF capacitors
• 1 10K resistor
• 16Mhz crystal
• Breadboard
• Some wires

When you have all the components all thats left is to connect the arduino to the atmega for programming

Programming Arduino             Target atmega 328p

D10 (SS)                        Pin 1
D11 (MOSI)                      Pin 17
D12 (MISO)                      Pin 18
D13 (SCK)                       Pin 19

After connecting you can run Arduino IDE select File -> Examples -> Arduino as ISP and upload it to your arduino I recommend also setting the verbose output in File -> Preferences during upload and compilation as it help debug any issues you might encounter.

Double check the connection from the arduino to the breadboard and if you are ready go into Tools setup it as shown on the screen and you can burn your bootloader.

if successfull you will get a similar output to this:

Now your atmega 328p is ready to work as a replacement for you arduino chip or as the processor for PwnPad (After you upload the PwnPad sketch to it).

Some common issues I encountered (Mostly with bad connections):

1. bad connection to the breadboard, results in device signature being 0x000000, check your connection try again

2. 16Mhz crystal faulty connection first you will get the fuses being written normally: But after they are saved and the atmega clock changes to 16mhz external you will get an error and your atmega will show up with some kind of Invalid device signature In this case your device is probably “bricked” and you will have to use a high voltage programmer to restore the default fuse settings and try again, I use avr fusebit doctor.