6a0877384d
- Remove undeployed challenges: Phantom_Byte, Cr4cK_w1f1, Lain_Br34kC0r3 V1, Lain_VS_Knights, Lets_All_Love_UART, AETHER_NET, Last_Train_451, Web3/ - Sync 24 solve/ files from main CTF-Espilon repo - Update all READMEs with real CTFd final scores at freeze - Add git-header.png banner - Rewrite README: scoreboard top 10, edition stats (1410 users, 264 boards, 1344 solves), correct freeze date March 26 2026
132 lines
3.3 KiB
Markdown
132 lines
3.3 KiB
Markdown
# Glitch The Wired
|
||
|
||
| Field | Value |
|
||
|-------|-------|
|
||
| Category | Hardware |
|
||
| Difficulty | Medium-Hard |
|
||
| Points | 100 |
|
||
| 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
|
||
```
|
||
|
||
|
||
|
||
### 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.
|
||
|
||
|
||
|
||
### 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]
|
||
```
|
||
|
||
|
||
|
||
### Step 5 — Read the maintenance token
|
||
|
||
```text
|
||
read_console
|
||
```
|
||
|
||
The debug console outputs the maintenance token containing the flag.
|
||
|
||
|
||
|
||
### 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}`
|