diff --git a/Hardware/Glitch_The_Wired/README.md b/Hardware/Glitch_The_Wired/README.md
index c4057e0..fa0e2b0 100644
--- a/Hardware/Glitch_The_Wired/README.md
+++ b/Hardware/Glitch_The_Wired/README.md
@@ -1,54 +1,131 @@
-# Glitch The Wired — Solution
+# Glitch The Wired
 
-## Overview
+| Field | Value |
+|-------|-------|
+| Category | Hardware |
+| Difficulty | Medium-Hard |
+| Points | 500 |
+| Author | Eun0us |
+| CTF | Espilon 2026 |
 
-Simulated voltage glitching attack on a WIRED-MED secure boot module. The goal is to inject a fault during the signature verification phase to bypass it and access the debug console.
+---
 
-## Steps
+## Description
 
-1. Connect to the glitch lab:
+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
 ```
 
-2. Observe the boot sequence:
+> 📸 `[screenshot: glitch lab banner and prompt]`
 
-```
+### Step 2 — Observe the boot sequence
+
+```text
 observe
 ```
 
-Note the cycle ranges — SIG_VERIFY runs at cycles 3200-3400.
-
-3. Configure glitch parameters:
+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.
+
+> 📸 `[screenshot: observe output showing all boot phases and cycle ranges]`
+
+### 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 delay targets the middle of the SIG_VERIFY window. Width of 10-30 cycles works.
+The width must be in the range 10–30 cycles:
+- Too short: transient recovery, CPU resumes normally
+- Too wide: brown-out, system crashes
 
-4. Arm and trigger:
+### Step 4 — Arm and trigger
 
-```
+```text
 arm
 trigger
 ```
 
-If successful, the boot log shows "SIG_VERIFY ....... SKIPPED" and a debug shell activates.
-
-5. Read the debug console:
+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]
+```
+
+> 📸 `[screenshot: boot log showing SIG_VERIFY SKIPPED and debug shell prompt]`
+
+### Step 5 — Read the maintenance token
+
+```text
 read_console
 ```
 
-The flag is in the maintenance token output.
+The debug console outputs the maintenance token containing the flag.
 
-## Key Concepts
+> 📸 `[screenshot: read_console output displaying the flag]`
 
-- **Voltage glitching**: Briefly disrupting power supply to cause CPU instruction skips
-- **Secure boot bypass**: Skipping signature verification allows unsigned code to run
-- **Timing precision**: The glitch must overlap with the target operation's execution window
-- **Width matters**: Too short = transient recovery, too wide = brown-out crash
+### 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}`