# Glitch The Wired

| Field | Value |
|-------|-------|
| Category | Hardware |
| Difficulty | Medium-Hard |
| Points | 500 |
| Author | Eun0us |
| CTF | Espilon 2026 |

---

## Description

A WIRED-MED secure boot module is exposed on the lab bench.
You have access to the power rail and can inject voltage glitches to disrupt the boot process.

Find the right timing window to bypass signature verification and access the hidden debug console.

- Glitch Lab: `tcp/<host>:3700`

Format: **ESPILON{...}**

---

## TL;DR

Simulate a voltage glitching attack against a secure boot module. Observe the boot sequence
to identify the SIG_VERIFY timing window (cycles 3200–3400), configure glitch delay and width,
arm and trigger, then read the maintenance token from the unlocked debug console.

---

## Tools

| Tool | Purpose |
|------|---------|
| `nc` | Connect to the glitch lab interface |
| Python 3 | Automation and parameter sweep |

---

## Solution

### Step 1 — Connect

```bash
nc <host> 3700
```

![glitch lab banner and prompt](https://git.espilon.net/Eun0us/ESPILON-CTF-2026-Writeups/raw/branch/main/screens/glitch_banner.png)

### Step 2 — Observe the boot sequence

```text
observe
```

The output lists boot phases with their cycle ranges:

```
ROM_INIT      [0      – 1000]
BOOTLOADER    [1000   – 2000]
LOAD_FIRMWARE [2000   – 3200]
SIG_VERIFY    [3200   – 3400]   <-- target
LAUNCH_KERNEL [3400   – 5000]
```

The signature verification phase runs between cycles 3200 and 3400.

![observe output showing all boot phases and cycle ranges](https://git.espilon.net/Eun0us/ESPILON-CTF-2026-Writeups/raw/branch/main/screens/glitch_observe.png)

### Step 3 — Configure glitch parameters

Target the middle of the SIG_VERIFY window with a width of 20 cycles:

```text
set_delay 3300
set_width 20
```

The width must be in the range 10–30 cycles:
- Too short: transient recovery, CPU resumes normally
- Too wide: brown-out, system crashes

### Step 4 — Arm and trigger

```text
arm
trigger
```

If the timing is correct, the boot log shows:

```
ROM_INIT      ......... OK
BOOTLOADER    ......... OK
LOAD_FIRMWARE ......... OK
SIG_VERIFY    ......... SKIPPED  <-- glitch worked
LAUNCH_KERNEL ......... OK
[DEBUG SHELL ACTIVATED]
```

![boot log showing SIG_VERIFY SKIPPED and debug shell prompt](https://git.espilon.net/Eun0us/ESPILON-CTF-2026-Writeups/raw/branch/main/screens/glitch_unlock.png)

### Step 5 — Read the maintenance token

```text
read_console
```

The debug console outputs the maintenance token containing the flag.

![read_console output displaying the flag](https://git.espilon.net/Eun0us/ESPILON-CTF-2026-Writeups/raw/branch/main/screens/glitch_flag.png)

### Key concepts

- **Voltage glitching**: Briefly disrupting the power supply causes the CPU to skip one or
  more instructions, potentially jumping over security checks
- **Secure boot bypass**: The signature verification function is skipped entirely when the
  glitch lands in its execution window
- **Timing precision**: The glitch must overlap with the target operation. Too early or too
  late misses the window. The SIG_VERIFY window is only 200 cycles wide.
- **Width matters**: The fault pulse must be long enough to corrupt execution but short enough
  that the regulator does not detect a brown-out and reset the chip

---

## Flag

`ESPILON{gl1tch_byp4ss_s3cur3_b00t}`