## Summary This 2025 arXiv SoK sets out to be the single document you hand a strong security generalist who has never touched fault injection. It does three things: (1) a beginner-friendly taxonomy of FI techniques rooted in *one* unifying physical mechanism, the **timing-constraint violation**; (2) a cost/performance ranking of the major techniques (clock/voltage glitching cheapest, laser most precise, EMFI the versatile middle); and (3) a replication study of a software FIA-detection tool (Lazart) that surfaces a real research gap: existing detectors flag *almost every line* of a binary as vulnerable because their fault models do not connect what is feasible in hardware to what is exploitable in software. For our project the value is not novelty but **framing**: it is the clearest published statement that FI breaks "the assumption that hardware will guarantee proper execution of software," and a tidy six-stage anatomy of an attack that maps cleanly onto our own reasoning spine. ## Technique & setup This is a systematization, so the "bench reality" is the cross-cutting structure it imposes: - **One mechanism under the families.** Combinatorial logic sits between two D flip-flops; correctness depends on the data path settling before the clock latches. Voltage glitches, clock glitches, and (by one theory) EMFI all work by **violating that timing constraint** so a wrong value latches. The paper lumps clock and voltage glitching together on the evidence that the faults they produce are identical, and gives the supply-voltage-to-propagation-delay relation in an appendix. Laser FI is the odd one out: it flips bits directly via ionizing charge rather than (only) timing. - **Technique cards, each with a "Considerations" trade-off.** Underpowering (cheap, imprecise, hits the whole IC), negative/positive power-supply glitch (more precise, needs deeper target knowledge), precisely-timed vs. fuzzy clock glitch (100% reproducible-but-laborious vs. ~75% brute-force), Rowhammer (the only fully-software, no-physical-access fault; deterministic vs. probabilistic memory massaging), laser FI (decap required, single-bit precise, expensive but getting cheaper), and EMFI (no decap, local, cheap-ish, precise but not single-transistor). - **Cost / performance tables (their estimates).** Cost low→high: clock/voltage (~$30-50 floor, up to ~$600) < EMFI (~$500-$10k+) < laser (~$4k-$50k+); Rowhammer ~free. Reported success rates are *not* the same as feasibility: laser ~100%, EMFI ~1-2%, glitching low single-digit %, but the paper insists feasibility = *average time to success* (a fast 0.1% attack beats a slow 1% one). - **Six-stage anatomy ("the cyber kill chain of a FIA").** Fault Modeling → Injection → Manifestation (circuit-logic error) → Propagation (software-logic error) → Observation → Exploitation. Countermeasures aim to detect/prevent/mitigate at any stage. Abstraction ladder: physics → gates/registers → ISA → machine code → assembly → source, with fault models defined at each level (set/reset/bit-flip at the bottom; NOP/instruction-skip and data/control-flow corruption higher up). - **The detection gap (replication).** Re-running Lazart on a PIN-verify snippet, the authors show it both false-positives (flags a return value that is hardened by a large Hamming distance, infeasible for a 1-bit fault) and false-negatives (misses a feasible fault on the FAILURE block) because it reasons at LLVM-IR without machine-code awareness. Their proposed fix is a synthesis model carrying source-level detection *with* instruction- and bit/byte-level feasibility, so "is this physically reachable with 1 bit/byte?" prunes the noise. ## Relevance to our work This is an **orientation and teaching anchor**, treated as a single synthesis input rather than a reproduce target. Its payoffs for the project: - **Framework corroboration.** Its threat-model sentence, FI "breaks the assumption that hardware will guarantee proper execution of software," is independent, citable support for the project's framework (The Assumption Lens): a decision rests on an assumption, and the assumption is physical and disruptable. Its six-stage anatomy is an external scaffold that sits neatly beside our observe / influence / disrupt triad (Injection/Manifestation are *influence/disrupt*; Observation closes the loop). - **Defender's misconceptions list.** Section 9 is gold for threat modeling and directly feeds [[bsi-aisec-study-hardware-attacks-microcontrollers]] and our defenses digest: physical access is *not* required (Rowhammer, software-exposed energy management for remote voltage glitching à la CLKscrew); high clock frequency *raises* glitch/EMFI success rather than helping; multi-core mutual checking helps but does not fully prevent; and success rate ≠ feasibility. - **"Start with voltage glitching" is the consensus, not just ours.** Their explicit recommendation, begin with clock/voltage glitching, consider laser for precision, EMFI as the versatile balance, confirms the choice of voltage glitching as the project's first concrete loop and the sub-$100 rig in the project's hardware shopping list. - **A real open problem for the synthesis/experiments track.** The hardware↔software fault-model gap (detectors that flag everything) is a concrete, defensible research focus and a caution when we read any "this binary is FIA-vulnerable" tool output. Pairs with [[fissc-fault-injection-simulation-secure-collection]] and [[breier-hou-how-practical-are-fault-injection-attacks]] (its practicality twin). Actionability is **high** as framing/teaching material; it is a survey, so there is nothing to reproduce directly. The CLKscrew, ESP32-v3 PC-control, and clock-frequency references it cites are already in or adjacent to our corpus. ## Provenance arXiv preprint 2509.18341 v1 (22 Sep 2025), supplied by the owner into `incoming/` and ingested locally; raw PDF kept as link-rot insurance. Text extracted with pdfminer. ## Key references - Original: <https://arxiv.org/abs/2509.18341> - Citation: C. S. Liu, F. Wang, P. Gould, C. Yagemann, "SoK: A Beginner-Friendly Introduction to Fault Injection Attacks," arXiv:2509.18341 [cs.CR], 2025. </content> </invoke>