Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

141 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

GRIT: Glitch Research & Injection Testbed

License: CC BY-NC 4.0

Embedded authentication controller firmware for fault-injection practice. Primary target: ATmega328P (Arduino Uno / Nano / Pro Mini) via ChipWhisperer Husky Plus. Also supported: ATmega2560 (Arduino MEGA 2560); build with BOARD=mega2560.

The GRIT bench — an Arduino Uno target wired to a ChipWhisperer Husky Plus (voltage glitch, clock glitch, and synchronous SCA capture), with the power-analysis shunt on a breadboard.

Twenty-nine vulnerability modules across five attack families:

  • M01–M14 (VFI / Crowbar): loop integrity, auth bypass, lockout defeat, CRC skip, boot verify, memory dump, privilege chain, hardened double-check, XOR-obfuscated credential bypass, attempt-counter defeat, triple-redundant AND-gate fault, permutation-table bypass, CBC-chain bypass, and checksum-gate bypass.
  • M15–M18 (Clock Glitch): branch skip (CLK_BYPASS), nonce-response bypass (CLK_NONCE), fault-counter defeat via STS instruction skip (CLK_FAULT_CTR), and two-stage escalation chain (CLK_ESCALATE).
  • M19–M22 (Advanced VFI): persistent SRAM gate fault (two-command chain), EEPROM-backed gate fault, timer-based glitch-detection evasion, and LFSR-jitter countermeasure bypass.
  • M23, M28 (SCA): recover secrets from power traces; no fault needed or possible. M23 leaks a 4-byte secret from a byte-compare (H(key⊕secret)); M28 (SBOX_LEAK) recovers a 4-byte AES-128 subkey via CPA on the S-box output (H(Sbox[pt⊕key])) — the canonical real-world power-analysis attack, where the S-box nonlinearity makes only the correct key correlate.
  • M24–M27 (EMFI): precision branch corruption via electromagnetic pulse (FaultyCat v3 coil). TOCTOU single-stage bypass, warmup, two-stage chain, and LFSR-jitter two-stage chain. CW Husky TRIG MCX triggers the FaultyCat for precision timing; FC-only D4-direct wiring also supported (no Husky needed for EMFI).
  • M29 (Fault on crypto / DFA): the modern fault attack on a cipher. Firmware runs full AES-128 with the trigger around round 9; a single-byte fault there plus a handful of correct/faulty ciphertext pairs recovers the whole key by Differential Fault Analysis (Piret-Quisquater, CHES 2003) — no key guessing, no power traces. See scripts/tutorial_09_dfa.py.

Each module has an access code, reachable by fault injection or, for many modules, binary analysis of the firmware ELF.

New here? GRIT is a playground, not a hardware-gated CTF. You can flash the HEX onto any Arduino and start attacking over plain USB serial — no Husky, no FaultyCat, no soldering required to begin. Bring the fault-injection gear only when you want to land the hardest glitches, or build your own rig against the D4 trigger. See PLAYGROUND.md and scripts/grit_console.py.

For educational purposes only. Fault injection involves high-speed electrical transients that can permanently damage microcontrollers, development boards, and connected equipment. The author takes no responsibility for any damage to hardware, property, or systems resulting from use of this project. Always work in a safe environment with appropriate precautions.

Attack modes supported:

  • SCA (Power Analysis): Husky ADC captures power trace via shunt; identifies where comparisons happen in time so fault injection can be targeted precisely. No glitch fired. Tutorial: tutorial_01_sca.py. Start here. SCA reveals the ext_offset, then VFI exploits it.
  • VFI (Voltage Fault Injection): LP+HP MOSFET crowbar, Husky glitch SMA → ATmega DIP pin 7 (Vcc). Tutorial: tutorial_02_vfi.py. Targets M01's wide loop; no SCA pre-calibration required.
  • CLK (Clock Glitch): Husky HS2 replaces Arduino crystal; bad clock pulse inserted mid-loop. Requires crystal removal + fuse change via python scripts/set_fuses_clk.py (Husky ISP). Tutorial: tutorial_03_clk.py.
  • EMFI (Electromagnetic Fault Injection): FaultyCat v3 EM coil above ATmega DIP package corrupts flash instruction fetch (BREQ→BRNE). Two wiring options: Phase 2 (CW Husky TRIG MCX → FaultyCat ext-trigger, precision timing) or FC-only (Arduino D4 → FaultyCat TRIG via 1kΩ+2kΩ divider, no Husky). Targets M24–M27.

Prerequisites

Hardware — the firmware is hardware-agnostic: it exposes a D4 trigger (see PLAYGROUND.md), so any voltage glitcher, external clock source, or EM pulser that honours it will work. The list below is our reference rig — the equipment these write-ups and confirmed parameters come from. Bring your own gear; your setup, and your mileage, may vary.

Required

  • Arduino Uno / Nano / Pro Mini (ATmega328P) or MEGA 2560 (ATmega2560) — the target
  • A way to fault it: a voltage glitcher (crowbar on Vcc), an external clock source (CLK modules), and/or an EM pulser (EMFI modules). See PLAYGROUND.md for build-your-own options.

Our reference rig (what these write-ups were confirmed on — swap in your own equivalents)

  • ChipWhisperer Husky Plus — VFI crowbar, clock glitch, SCA capture, EMFI Phase-2 triggering. (Our scripts use the ChipWhisperer API; adapt them for other gear.)
  • FaultyCat v3 — EMFI pulser for M24–M27 (a ChipShouter or any equivalent EM pulser works too)
    • 3× AA batteries for the HV section (USB alone only charges the cap to ~5V — no real pulse)
    • USB to laptop for logic power + Python API
    • EMFI coil (screw onto SMA jack)
  • Breadboard, jumper wires
  • 2× 2.2kΩ + 2× 3.3kΩ resistors, voltage dividers (5V→3.3V) for serial + trigger lines
  • 1× 4.7Ω resistor, power-analysis shunt (needed from tutorial_01_sca.py onward)
  • Do not add capacitors to the 5V rail for VFI — they act as Vcc reservoirs and prevent droop-tail faults from reaching the ATmega

Software

# ChipWhisperer Python environment (activate before running VFI/CLK/SCA scripts)
source /path/to/chipwhisperer-husky/cwenv/bin/activate

# FaultyCat Python environment (activate before running EMFI scripts)
source /path/to/fcvenv/bin/activate
# Verify FaultyCat is detected:
faultycmd info

Quick Start

# 0. Activate ChipWhisperer venv (once per terminal session)
source /path/to/chipwhisperer-husky/cwenv/bin/activate

# 1. Flash the firmware
python scripts/flash.py

# 2. Open a serial monitor
python scripts/grit_console.py --monitor

# 3. Run the tutorials in order
python scripts/tutorial_01_sca.py   # SCA on M09 → prints an ext_offset hint for your M09 crowbar sweep
python scripts/tutorial_02_vfi.py   # VFI on M01 (wide window, no SCA hint needed)
python scripts/tutorial_03_clk.py   # clock glitch (crystal removal + set_fuses_clk.py)
python scripts/tutorial_04_emfi.py  # EMFI on M25 (FaultyCat coil; coil positioning by crash rate)

Flashing

Don't want to build? Grab a prebuilt hex from the latest release — Uno/Nano (ATmega328P) and MEGA 2560 (ATmega2560) builds are attached, with SHA256SUMS.txt to verify. Flash it (below), open a serial monitor at 38400 baud, and you're playing. (Prefer to build it yourself? See Building from Source.)

The in-repo firmware/grit.hex is the same Uno (ATmega328P) build. Flash it however you prefer.

Port varies by OS: /dev/ttyACM0 or /dev/ttyUSB0 on Linux, /dev/cu.usbmodem* on macOS, COM3 on Windows.

Convenience script: handles nRST timing and frees the port if a serial monitor is holding it:

python scripts/flash.py                   # auto-detect board
python scripts/flash.py --board uno       # force Uno / Nano (ttyACM0)
python scripts/flash.py --board mega2560  # force Mega 2560 (ttyACM1)

Direct avrdude:

avrdude -c arduino -p m328p  -P <port> -b 115200 -U flash:w:firmware/grit.hex   # Uno / Nano / Pro Mini (ATmega328P)
# MEGA 2560: firmware/grit.hex is the 328P build — flash the MEGA release hex, or `make BOARD=mega2560` first:
avrdude -c wiring  -p m2560  -P <port> -b 115200 -D -U flash:w:grit-fw-4.3.0-mega2560-atmega2560.hex  # Mega 2560

Building from Source

Requires avr-gcc 5.4+ and avrdude 7+.

cd firmware
make                  # ATmega328P (Uno / Nano / Pro Mini)
make BOARD=mega2560   # ATmega2560 (MEGA 2560)
make CLK=cw           # Clock-glitch firmware (Husky HS2 as clock source)

From a clean clone, build with make obscure. Plain make produces Training firmware, which needs the descriptive-flag header grit_flags.h — kept out of the public repo so the answers aren't sitting in source. Either flash the prebuilt firmware/grit.hex (already a Training build) or run make obscure for a spoiler-free build from source. BOARD= / CLK= combine with any mode (e.g. make obscure CLK=cw). See Build Modes below.

Fuse targets (ATmega328P):

python scripts/set_fuses_clk.py  # Switch to external clock (Husky ISP — use instead of make fuses-clk)
make fuses-bod-off    # Disable BOD (optional — see § BOD)
make fuses-reset      # Restore factory fuses

Firmware version: fw-4.3.0


Build Modes: Training vs Obscure

GRIT builds in two flavours. The attack methods are identical in both — only the answers change.

⚠️ The Training flags are deliberate spoilers — they exist for education, not for scoring. Each descriptive flag (e.g. GRIT{c09_xor_mask_…}) names the very mechanism you're meant to discover, and every module secret is recoverable straight from the binary by design — that's the point: the answers are in the firmware for you to learn from. If you want a genuine, spoiler-free challenge, build Obscure Mode (random flags) or simply don't peek. We trust you to play your own game. (The prebuilt grit.hex is a Training build; make train / plain make from source need the private flag header, so from a clean clone use the prebuilt hex or make obscure.)

Training Mode Obscure Mode
Build make train / plain make (needs private flag header) make obscure (works from a clean clone)
Flags fixed, descriptive (GRIT{...} name the mechanism) per-device random (GRIT{cNN_…}, no hint)
Recoverable secrets fixed per-device random
Purpose learn the platform; self-documenting each unit unique — a shared flag never transfers
Reproducible yes: make obscure SEED=<32-hex> rebuilds the same device
cd firmware
make train                 # descriptive flags — learn how each module works
make obscure               # unique build from a fresh random seed
make obscure SEED=<32hex>  # reproduce a specific unit from its seed

Obscure Mode derives every flag and secret from a 16-byte seed (scripts/gen_device.py) and writes a private answer key to device_builds/device_<id>.txt (gitignored). To harden a unit so its firmware can't simply be dumped, after flashing set the readout lock:

make flash        # program the chip
make lock         # LOCK bits 0xFC — disable flash/EEPROM readback (needs an ISP programmer)
make unlock       # chip-erase to clear the lock before reflashing

None of this is destructive or permanent. Lock bits and every fuse target are fully reversible by a chip erase (make unlock) — GRIT never touches RSTDISBL/SPIEN, so the chip always stays ISP-programmable. See § BOD and the fuse notes above.


BOD

BOD does not affect any GRIT module. ATmega328P BOD blanks for ~2000 ns; all VFI modules use crowbar durations well below that (heaviest: M12 at rep=10 → 1356 ns). No fuse changes needed to solve any challenge. If you want a vanilla baseline anyway, make fuses-bod-off disables BOD (optional, non-destructive, reversible with make fuses-reset).


Modules

GRIT ships 29 modules across five attack families. Each is a small, self-contained "authentication" routine with a deliberate weakness you defeat with a specific technique.

Attack families: VFI — voltage fault injection (crowbar on Vcc) · CLK — clock glitch (external clock replaces the crystal) · SCA — side-channel power analysis (no fault) · EMFI — electromagnetic fault injection (EM pulse) · DFA — fault on crypto (fault an AES round).

Difficulty runs ★☆☆☆ (tutorial) → ★★★★★ (expert). Solved = whether the attack has been landed on real hardware here: ✅ confirmed on the bench · ⬜ implemented and offline-validated but not yet landed. 26 / 29 solved — only the three multi-stage EMFI chains (M25–M27) remain, and they're offline-validated and bench-ready.

# Module Family Diff. Solved What it is — and how you break it
M01 INTEGRITY_CHECK VFI ★☆☆☆ Big 50×50 integrity loop — the tutorial target. Glitch Vcc anywhere in its ~1.3 ms window to corrupt the counter and pass.
M02 AUTH_VERIFY VFI ★★☆☆ 8-byte password compare. One Vcc glitch on the compare branch skips the mismatch and authenticates.
M03 LOCKOUT_GUARD VFI ★★★★ Lockout counter built as an AND-accumulate; fault one iteration of its ~193 µs window to defeat it.
M04 LICENSE_VALIDATE VFI ★★★☆ CRC-checked "license" compare. Glitch the compare branch to accept an invalid license.
M05 BOOT_VERIFY VFI ★★★☆ 8-iteration boot signature check. Glitch one iteration to pass secure-boot verification.
M06 MEMDUMP_GUARD VFI ★★★★ AND-accumulate guard protecting a memory dump; fault it to unlock the dump.
M07 PRIV_ESCALATE VFI ★★★★ Two-stage privilege chain: glitch stage-1 auth, then the privilege guard, to escalate.
M08 HARDENED_VERIFY VFI ★★★☆ A "hardened" double-check AND gate; land the glitch in the narrow two-loop window to bypass both checks.
M09 XOR_MASK VFI ★★☆☆ Same compare, XOR-obfuscated. The mask doesn't help — glitch the compare all the same.
M10 ATTEMPT_GUARD VFI ★★☆☆ 3-try lockout + compare. Fault the compare before the counter locks you out.
M11 TRIPLE_GATE VFI ★★★★ Triple-redundant AND gate (defence in depth); one well-timed glitch still collapses all three.
M12 BYTE_PERM VFI ★★☆☆ Password bytes checked in a permuted order; glitch the permuted compare — order doesn't save it.
M13 CHAIN_LOCK VFI ★★★☆ CBC-style XOR-chained compare; fault the chained comparison to pass.
M14 CHECKSUM_GATE VFI ★★★★ Pre-flight checksum then compare; glitch the compare inside the checksum-guarded window.
M15 CLK_BYPASS CLK ★☆☆☆ Clock-glitch tutorial: a bad clock edge makes a CPSE skip fail, jumping straight to the flag.
M16 CLK_NONCE CLK ★★☆☆ Nonce/response check; clock-glitch the EOR so the expected value reads 0 and the branch is taken. (Also solvable by binary analysis.)
M17 CLK_FAULT_CTR CLK ★★★☆ 5-try fault counter; clock-glitch to skip the STS that writes the counter, so it never increments.
M18 CLK_ESCALATE CLK ★★★★ Two-stage clock-glitch escalation: skip two CPSE checks (stage-1 g, stage-2 d) to reach the flag.
M19 PERSIST_GATE VFI ★★★★ Fault sets a persistent access gate in SRAM; a second command (d) then reads the flag through the open gate.
M20 EEPROM_PERSIST VFI ★★★★ Like M19 but the gate loads from EEPROM; fault the eeprom_read_byte() result — the gate survives resets.
M21 GLITCH_DETECT VFI ★★★★ Has a Timer1 glitch-detector, but the ~675 ns crowbar is far shorter than its 1 ms tick, so the AND-loop attack slips past.
M22 JITTER_GUARD VFI ★★★★ An LFSR randomises the pre-delay (0–63 iters) to dodge fixed offsets; sweep a wide window to cover the jitter.
M23 SCA_ONLY SCA ★★★☆ No fault is possible — a byte-by-byte compare leaks H(key⊕secret). Recover the 4-byte secret with CPA on power traces (the linear-leak warm-up for M28).
M24 TOCTOU_RACE EMFI ★★★★★ Single EM pulse corrupts a BREQ→BRNE at the time-of-check/time-of-use gate and the flag prints. VFI can't hit the 125 ns window — EMFI only.
M25 EMFI_WARMUP EMFI ★★★★☆ EMFI calibration target — same single-stage bypass as M24 but a smaller 4× LDI buffer. Start EMFI here. (Bench-ready, not yet landed.)
M26 EMFI_NARROW EMFI ★★★★★ Two-stage EM chain: pulse one BREQ to set the auth flag (g), then a second BREQ for the flag (d). (Bench-ready, not yet landed.)
M27 EMFI_CHAIN EMFI ★★★★★ Two-stage chain with LFSR jitter on stage-2 (0–7 NOPs); sweep ext=12–24 to cover every jitter value. (Bench-ready, not yet landed.)
M28 SBOX_LEAK SCA ★★★★ The canonical power-analysis attack: recover a 4-byte AES-128 subkey via CPA on the S-box output H(Sbox[pt⊕key]) — the S-box non-linearity makes only the right key correlate.
M29 AES_DFA DFA ★★★★★ Fault-on-crypto: full AES-128 with the trigger around round 9. One faulty byte + a few correct/faulty ciphertext pairs recovers the whole key by Differential Fault Analysis (Piret–Quisquater). Solver: tutorial_09_dfa.py.

See CHALLENGES.md for deeper per-module attack descriptions, real-world analogies, and a glossary of AVR instructions, CW Husky API terms, and fault-injection concepts. VFI window sizes are quoted in ext_offset units = clkgen cycles (≈135.6 ns/cycle at the 7.3728 MHz default). Many modules are also solvable by binary analysis of the firmware ELF — no hardware required. (Confirmed offsets and per-device answer keys are kept private by design.)

Serial commands

s01 … s29    select module
g            run glitch loop / show hint (M01, M02, M07–M13, M19–M22, M24–M27 stage-1; M15, M18 stage-1; M23/M28 baseline trace; M29 hint)
p<hex16>     8-byte credential (M02, M07 stage-1, M08–M14)
p<hex8>      4-byte plaintext (M28 — feeds one CPA trace)
c<hex32>     16-byte plaintext → AES-128 ciphertext (M29 — trigger around round 9)
n<hex2>      PIN byte (M03)
l<hex16>     8-byte license key (M04)
b<hex8>      4-byte signature (M05)
d            stage-2 check (M06, M07 stage-2, M18 stage-2, M19 stage-2, M26 stage-2, M27 stage-2)
k<hex2>      1-byte key response (M16, M17)
k<hex8>      4-byte secret submission (M23 SCA secret, M28 AES subkey)
k<hex32>     16-byte AES key submission (M29 — recovered by DFA)
f<flag>      submit a flag to mark progress (e.g. fGRIT{...})
r            reset module state (resets SRAM; M20 EEPROM gate NOT reset)
? / h        help

Prompt: grit:01> through grit:29> (updates on module select).


Scripts

Script Purpose
scripts/grit_console.py Hardware-free starter kit. Interactive serial console, passive --monitor mode, and an importable GritSession client — the base to build your own attack tools on (no Husky/FaultyCat). See PLAYGROUND.md
scripts/gen_device.py Obscure Mode generator: per-device random flags/secrets from a seed (make obscure)
scripts/tutorial_01_sca.py Start here: Power analysis. Capture M09 power trace, locate comparison loop, compute VFI ext_offset hint; no glitch fired
scripts/tutorial_02_vfi.py VFI: guided M01 measurement — maps trigger window, lands first hit
scripts/tutorial_03_clk.py Clock glitch: M01 via HS2 clock replacement, 2D width×offset sweep
scripts/tutorial_04_emfi.py EMFI: M25 via FaultyCat coil (D4→FC TRIG, no Husky); teaches coil positioning by crash-rate feedback
scripts/tutorial_05_serial.py Hardware-free: build/exercise your attack harness (GritSession) with no FI gear — enumerate, oracle loop, timing, PRNG modelling
scripts/tutorial_06_multiglitch.py Multi-point VFI: Husky num_glitches (up to 32/trigger) — spray an AND-loop window in one shot; needs Husky + crowbar
scripts/tutorial_07_cpa.py CPA: recover M28's 4-byte AES subkey via correlation power analysis with adc_mul=4 synchronous sampling; needs Husky + shunt
scripts/tutorial_08_diy_glitcher.py + .ino DIY glitcher: a second Arduino as a crowbar triggered on D4 — glitch M01 with no ChipWhisperer
scripts/tutorial_09_dfa.py DFA: recover M29's full AES-128 key by Differential Fault Analysis (Piret-Quisquater). --selftest verifies the solver offline (no hardware)
scripts/flash.py Flash helper: frees the port, handles nRST timing
scripts/diag_uart.py Quick UART diagnostic — confirms firmware banner and EMFI module visibility

For guided first attacks in each class — including EMFI on the FaultyCat with no Husky — use the tutorial_0*.py scripts above and build on grit_console.py. See PLAYGROUND.md.


Wiring

See WIRING.md for full pin tables, Saleae Logic2 probe points, divider calculations, and SCA / VFI / CLK mode diagrams.

Mode summary:

  • SCA: Husky VOUT (3.3V) → 4.7Ω shunt → ATmega Vcc (DIP pin 7); Husky MEASURE POS SMA (single-ended, keep the shorting cap on NEG) on the Vcc side captures the drop; no crowbar connected.
  • VFI: Husky glitch SMA → ATmega DIP pin 7 (Vcc); TIO2/TIO4 voltage dividers (5V→3.3V) for serial RX + trigger; TIO1 direct (3.3V→5V OK).
  • CLK: crystal removed; Husky HS2 → Arduino XTAL1; same divider wiring as VFI.
  • EMFI (Phase 2, precision): Start from VFI wiring; disconnect glitch SMA; wire CW TRIG MCX → FaultyCat TRIG (3.3V direct); FaultyCat SMA → EMFI coil above ATmega DIP. 3× AA batteries required in FC HV section.
  • EMFI (FC-only, no Husky): Arduino D4 → 1kΩ → FC TRIG, 2kΩ to GND; Arduino USB to laptop; FC USB to laptop. Use scripts/tutorial_04_emfi.py. No CW Husky needed.

Tip — keep two boards. The clock-glitch modules (M15–M18) need the 16 MHz crystal physically removed and an external clock wired to XTAL1 (DIP pin 9) — a semi-permanent modification. Rather than de-solder and refit the crystal every time you switch attacks, it's worth dedicating one Arduino as the crystal-removed / external-clock board (jumper from your clock source → pin 9) and keeping a second stock board for everything else: VFI (crowbar on Vcc, DIP pin 7), SCA, and EMFI, all of which run on the board's own crystal. Bonus: the crystal-removed board doubles as the synchronous-sampling target for CPA (M28), where driving the ATmega from the Husky's own clock is what makes the power traces line up sample-for-sample.


References & Further Reading

GRIT's attacks are grounded in the fault-injection and side-channel literature. These are the primary sources behind each technique — read them to understand why the modules behave as they do, and where the field is heading.

Fault injection — the techniques GRIT uses:

  • C. O'Flynn, Fault Injection using Crowbars on Embedded Systems, IACR ePrint 2016/810 (2016) — the crowbar VFI method GRIT's LP+HP MOSFET rig is built on (M01–M14, M19–M22). https://eprint.iacr.org/2016/810
  • ChipWhisperer documentation — clock/voltage glitching, synchronous SCA, the Husky API. https://chipwhisperer.readthedocs.io
  • J. Balasch, B. Gierlichs, I. Verbauwhede, An In-depth and Black-box Characterization of the Effects of Clock Glitches on 8-bit MCUs, FDTC 2011 — the instruction-skip / branch-corruption clock-glitch fault model on 8-bit AVR behind M15–M18 (CLK). https://www.esat.kuleuven.be/cosic/publications/article-2059.pdf · doi:10.1109/FDTC.2011.9
  • A. Moro, A. Dehbaoui, K. Heydemann, B. Robisson, E. Encrenaz, Electromagnetic Fault Injection: Towards a Fault Model on a 32-bit Microcontroller, FDTC 2013 — the EM branch-corruption fault model behind M24–M27 (EMFI). https://arxiv.org/abs/1402.6421

Side-channel analysis — GRIT's SCA modules:

Modern fault attacks on cryptography — the frontier (see also research directions):

  • G. Piret, J.-J. Quisquater, A Differential Fault Attack Technique against SPN Structures, with Application to the AES and Khazad, CHES 2003 — DFA: recover an AES key from a handful of correct/faulty ciphertext pairs (the attack behind M29). doi:10.1007/978-3-540-45238-6_7
  • C. Dobraunig et al., SIFA: Exploiting Ineffective Fault Inductions on Symmetric Cryptography, CHES 2018 / ePrint 2018/071 — statistical ineffective fault attacks, which defeat detection/infection and masking countermeasures. https://eprint.iacr.org/2018/071
  • F. Zhang et al., Persistent Fault Analysis on Block Ciphers, TCHES 2018(3) — PFA: a single persistent S-box fault plus many ciphertexts recovers the key (demonstrated on an ATmega). https://tches.iacr.org/index.php/TCHES/article/view/7272

Hands-on & real-world glitching — practical study material:

These crypto-fault techniques (DFA/PFA/SIFA) are a natural next tier for GRIT — it already ships an AES S-box (M28) but only attacks it with power analysis, not faults. Contributions welcome.

About

Glitch Research & Injection Testbed — 29 intentionally-vulnerable AVR modules for practising fault injection (VFI/CLK/EMFI) and side-channel analysis (SCA/CPA/DFA) on a plain Arduino.

Topics

Resources

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages