HACKING PROJECT · crypto · Advanced

Fault-Injection Rig (EMFI / Voltage Glitching)

Achieve and reproducibly characterize a fault-induced control-flow bypass on a real embedded target using automated glitch-parameter search.

**The problem**
Secure boot, readback protection, and cryptographic checks on embedded systems assume the CPU executes instructions faithfully, but this assumption breaks when an attacker corrupts timing at the silicon level. Electromagnetic fault injection (EMFI) and voltage/clock glitching can skip a single instruction — a signature-check branch, a lifecycle-state comparison, a debug-lock fuse read — and defeat protections that are cryptographically sound in software. Most product security teams never test their hardware against these physical faults, leaving root-of-trust, secure-boot, and JTAG-lock defenses unvalidated.

**What you'll build**
Build an instrumented fault-injection bench combining a controllable glitch source (crowbar MOSFET for Vcc glitching, XY EMFI probe, or ChipWhisperer-Husky), precise trigger synchronization, and a scripted parameter-sweep harness that automates the search over glitch offset, width, and intensity. Characterize a target MCU/SoC, correlate glitch parameters to observable outcomes (crash / mute / success), and demonstrate a concrete bypass such as secure-boot signature skip or readout-protection defeat, then document countermeasures (redundant checks, random delays, fault detectors, shielding).

**Objective** — Achieve and reproducibly characterize a fault-induced control-flow bypass on a real embedded target using automated glitch-parameter search.

**Expected outcome** — A documented fault-injection rig, an automated parameter-sweep tool with success-rate heatmaps, and a technical report demonstrating one exploited protection plus recommended silicon/firmware countermeasures.

**Difficulty** — Expert — requires oscilloscope-level signal timing, silicon fault physics, custom triggering, and destructive-testing discipline on real hardware.

**Primary category** — Hardware/Embedded Security; Secondary = Penetration Testing, Reverse Engineering, Cryptographic Attack

**Security domains** — Primary = Security Research; Secondary = Red Team, Hardware/Embedded Security, Malware Analysis (firmware), DevSecOps (product security testing)

**Technical focus** — Voltage/clock glitching, EMFI, side-channel-adjacent analysis, secure-boot bypass, readout-protection (RDP/CRP) defeat, JTAG/SWD unlock, trigger synchronization, fault characterization, hardware countermeasure design

**Core technologies** — Languages: Python, C, some Verilog/HDL awareness; Frameworks/Libraries: ChipWhisperer (chipwhisperer Python API), NumPy/Pandas, Matplotlib; Security Tools: ChipWhisperer-Husky/Lite, PicoScope/oscilloscope, EMFI probe (e.g. NewAE ChipSHOUTER), logic analyzer, JTAGulator, OpenOCD; Cloud/Infra: local lab bench, bench PSU, soldering/rework station; AI/Data: parameter-sweep datasets, optional ML classifier for glitch-outcome labeling; Databases: SQLite/CSV for sweep result logging

**Where it's valued** — Semiconductor and IoT device manufacturers, automotive (ECU/immobilizer), payment/HSM and smartcard vendors, medical devices, defense, hardware security consultancies

**Careers it builds toward** — Hardware Security Researcher, Embedded/Product Security Engineer, Silicon Security Validation Engineer, Red Team Hardware Specialist, Fault-Injection/Side-Channel Analyst

**Framework alignment**
• MITRE ATT&CK: Operates below most ATT&CK abstraction; closest tactics — Initial Access via Hardware Additions (T1200), Defense Evasion / Pre-OS Boot: System Firmware (T1542.001) as the bypass outcome; ICS ATT&CK Module Firmware (T0839) and System Firmware (T0857) where the target is an OT device.
• NIST CSF 2.0: Identify (hardware attack-surface/asset), Protect (validating tamper/fault resistance of root-of-trust). Primarily a Protect-assurance and Identify activity.
• OWASP: OWASP IoT Top 10 (maps to insecure hardware / lack of physical hardening); ISVS/MASVS-RESILIENCE analog for anti-tamper — otherwise N/A for web/API.
• CIS Controls v8: Largely N/A (physical/silicon layer); tangential to Control 4 (Secure Configuration) for disabling debug interfaces and Control 1 (hardware asset inventory).

**Innovation** — Research-Level Project — fault injection is an established discipline, but an automated, reproducible, well-characterized rig with outcome classification is genuinely research-grade and rare in student portfolios. Scores: Innovation 8/10, Startup 6/10, Enterprise-Readiness 7/10, Patent = Possible.

Browse all projects →