Can We Break the Fault Injection Mitigation Bob?

Can We Break the Fault Injection Mitigation Bob?

Speakers: Arun Magesh, Principal Security Consultant, Aon

Conference: Hacktivity

YouTube: https://www.youtube.com/watch?v=70BlpvPXEWc

Overview

In this compelling Hacktivity talk, "Can We Break the Fault Injection Mitigation Bob?", Arun Magesh, a Principal Security Consultant at Aon (an automated firmware analysis company), delves into the often-underestimated world of hardware fault injection attacks. While software vulnerabilities like buffer overflows and cross-site scripting dominate security discourse, Magesh argues that attackers can bypass even the most robust software security by directly manipulating the underlying hardware. This talk serves as a critical wake-up call, demonstrating that many common software-based mitigations designed to counter such attacks are, in practice, largely ineffective and easily circumvented.

Magesh meticulously unpacks the mechanics of various fault injection techniques, including voltage glitching, electromagnetic fault injection (EMFI), and laser fault injection. He illustrates how precisely timed disruptions can corrupt or skip critical instructions, leading to security bypasses that are impossible to achieve through software alone. The presentation is highly technical, featuring detailed explanations of experimental setups, characterization processes, and fault modeling – a methodology for systematically identifying and exploiting vulnerabilities at the assembly level.

The core message of the talk is clear: hardware fault injection is not a niche, sophisticated attack reserved for nation-states. With increasingly accessible tools and methodologies (even Arduino-based setups), it poses a tangible and growing threat to embedded systems, IoT devices, and even high-security processors. Magesh's work underscores the urgent need for developers and security architects to move beyond purely software-centric security paradigms and adopt a holistic approach that considers the physical security of the underlying hardware.

Background

▶ Watch: Different hardware fault injection methods explained (0:40)

Fault injection is a broad term, encompassing anything that disrupts the normal operation of a system to induce an error or change its behavior. In the software realm, this can involve fuzzing inputs, exploiting buffer overflows, or leveraging cross-site scripting (XSS) to alter program flow. However, Arun Magesh's talk pivots sharply to the hardware domain, where the implications are often more severe and less understood by conventional software developers. The fundamental premise is that even if software is perfectly written and free of logical flaws, an attacker can still compromise a device by directly manipulating the hardware on which that software runs.

The talk details several methods for injecting faults into hardware:

• Voltage Glitching: This involves temporarily manipulating the power supply to a microcontroller or integrated circuit (IC). By dropping the voltage to a very low point for a few nanoseconds, the CPU may not receive enough power to execute an instruction correctly. This can cause the instruction to be skipped entirely, or its execution can be corrupted, leading to unexpected behavior.
• Electromagnetic Fault Injection (EMFI): Leveraging principles of electromagnetism, EMFI involves placing a magnet or coil near the silicon. By injecting a strong current, an electromagnetic field is generated that can induce current in the tiny metal layers connecting transistors within the chip, thereby injecting faults directly into the silicon itself.
• Laser Fault Injection: This highly precise method requires decapsulating the chip to expose the raw silicon. A focused laser beam is then shone onto a specific transistor or region, generating charges that can flip bits or alter the state of the circuit.
• Other Methods: Magesh also mentions temperature manipulation, physical shock, and even rare cases of gamma radiation from outer space (citing a US election incident where a bit flip occurred).

While a casual user might experience a glitch as a temporary system crash requiring a reboot, for a security professional, these transient faults represent a critical attack vector. A prime example is bypassing secure boot mechanisms. Secure boot typically relies on cryptographic hash comparisons (e.g., SHA-256) to ensure the integrity of firmware. If the calculated hash matches an expected value, the boot chain proceeds; otherwise, the device fails to boot. An attacker employing fault injection could, for instance, corrupt the comparison instruction, forcing the system to return 'true' even if the hash values don't match, thereby allowing tampered firmware to load.

Fault injection has historically been a topic of academic research for 15-20 years. However, Magesh highlights that in the last five years, it has moved into the mainstream, enabling real-world exploits. Notable examples include the Nintendo Switch jailbreak, which famously leveraged fault injection, and the bypass of AMD SMM (System Management Mode) secure boot mechanisms. These instances demonstrate that the threat is not theoretical but has tangible consequences for widely deployed commercial products. The increasing accessibility of tools and knowledge lowers the barrier to entry, making it a critical area of concern for hardware and embedded system security.

Key Findings

▶ Watch: Fault modeling: manipulating assembly with single bit flips (12:55)

Arun Magesh’s talk meticulously deconstructs the efficacy of hardware fault injection and reveals several critical findings regarding its power and the fragility of common software-based mitigations:

• Fault Injection is Potent and Accessible: Contrary to the perception of fault injection as a highly sophisticated, nation-state-level attack, Magesh demonstrates that it can be achieved with relatively accessible equipment (like an Arduino-based setup). It's "dumber than a software attack" in some ways, relying more on electronics and statistical attempts than complex logical reasoning.
• Common Software Mitigations are Largely Ineffective: The core of the talk showcases how widely adopted software-based defenses against fault injection (such as using complex numbers, double checks, random delays, and state machines) can be systematically bypassed. These mitigations often fail because they operate at a higher level of abstraction than where the fault injection attack occurs.
• Fault Modeling is Crucial for Understanding and Exploitation: The process of characterization (identifying specific glitch parameters like delay and width) and fault modeling (mapping glitches to specific assembly instructions) allows attackers to move beyond random "hit-and-hope" attempts. This targeted approach significantly increases the efficiency and success rate of attacks, enabling precise manipulation of program flow.
• Compiler Optimizations Undermine Mitigations: A significant finding is that even if a developer meticulously implements software mitigations in C code, aggressive compiler optimizations can inadvertently remove or alter these protections. For example, a compiler might optimize away a "double check" if it deems it redundant, unknowingly reintroducing a vulnerability. This highlights the necessity of assembly-level code review for security-critical sections.
• No "Fully Secure" Against Fault Injection; It's a Game of Effort: Magesh stresses that there is no absolute "fully secure" state against fault injection. Instead, security becomes a matter of increasing the attacker's effort, time, and cost. While a mitigation might increase the number of attempts needed from a few thousand to millions, for a determined attacker targeting high-value assets (like a smart card's cryptographic key), even 100 million attempts is a feasible undertaking.
• Multiple Glitches Can Enhance Attack Success: For scenarios involving non-deterministic code (e.g., with random delays), injecting multiple glitches within a specific window can significantly increase the probability of hitting the target instruction. However, there's a sweet spot; too many glitches will simply crash the system.
• "Magic" Faults Exist: Some fault injection results are difficult to model directly. A glitch might corrupt a hidden state or register, manifesting its effect in a subsequent, seemingly unrelated operation. This adds a layer of unpredictability and complexity to both attacking and defending.

In essence, Magesh's findings paint a stark picture: hardware fault injection is a formidable and increasingly accessible threat that demands a fundamental shift in how embedded system security is approached, moving beyond superficial software fixes to deeply analyze the interaction between code, compiler, and the physical hardware.

Technical Deep Dive

▶ Watch: Bypassing double check software mitigation (18:00)

Arun Magesh's technical deep dive into fault injection began with a clear demonstration of the experimental setup and the methodology for characterization and fault modeling.

Experimental Setup:

Magesh used a common, accessible microcontroller as his target: the STM32 F103, specifically the "Blue Pill" development board, which features an ARM Cortex M3 processor. This choice underscores the accessibility of fault injection to commercial off-the-shelf devices.

• Target Device: STM32 F103 (Blue Pill).
• Glitching Device: A custom-built device, also based on a microcontroller, designed to generate precise voltage glitches. It incorporates a MOSFET to momentarily short the 3.3V power line of the target to ground.
• Control Software: A PC running Python scripts orchestrated the entire attack, controlling the glitching device and analyzing the target's output.
• Trigger Mechanism: A General Purpose Input/Output (GPIO) pin (specifically PB5) on the target was set to go high at the start of the critical code section and low at its end. This provided a precise, time-correlated window for injecting faults.

Characterization: Finding the Sweet Spot:

The first step in any fault injection attack is characterization – identifying the optimal parameters for glitching a specific chip. This process is unique to each setup, chip, and even configuration. Magesh demonstrated this using a simple loop that counts 50 twice, expecting an output of 2500.

• Parameters: Two key parameters are tuned:
• Glitch Delay: The time offset from the trigger (GPIO high) to when the glitch is injected.
• Glitch Width: The duration of the voltage drop (e.g., in nanoseconds). Too short (e.g., 10ns) and the CPU ignores it; too long (e.g., 1 second) and the CPU crashes.
• Process: The system runs the target code thousands of times, systematically varying glitch delay and width. The results are plotted, revealing a "sweet spot" (often colored red in Magesh's plots) where the CPU executes but instructions are corrupted (e.g., 2500 becomes 2100 or 4500). Green areas indicate no effect, while purple areas signify system crashes.

Types of Faults:

Magesh categorized the types of faults that can be induced:

• Instruction Skipping: The CPU entirely bypasses an instruction, such as a string compare or a branch.
• Instruction Corruption: More dangerous, this involves flipping bits within an instruction's opcode. For example, a Branch to function_A instruction could be corrupted to become a Branch to function_B, or a register move could be altered (e.g., move r0 to R2 becomes move r0 to R3).
• Cross-Domain Glitches: Faults are not limited to the CPU. Glitching the voltage can affect other components like RAM or hardware cryptographic cores, leading to data corruption or key leakage.

Fault Modeling: Targeting Specific Instructions:

The talk highlighted the crucial difference between attacking C code and attacking its underlying assembly. For a if (hash_value == expected_hash) check, the C code appears robust. However, at the assembly level, this translates into several distinct operations:

1. Loading string values into registers (e.g., R0, R1).
2. Executing the string compare function.
3. Storing the return value (e.g., into R0, then R3).
4. Comparing the result with zero (e.g., CMP R3, #0).
5. Conditional branching based on the comparison (e.g., BNE - Branch Not Equal).

Magesh demonstrated how a single-bit flip could bypass this check:

• Register Corruption: Changing move r0, R2 to move r0, R3 (if R2 and R3 hold different values) can trick the comparison into always returning true. This requires only a one-bit flip in the instruction.
• Branch Corruption: Flipping a bit in the BNE instruction to change it to BEQ (Branch Equal) effectively inverts the if/else logic, forcing a "pass" condition.

The focus on one-bit flips is strategic; while multi-bit flips are possible, controlling multiple, independent bit flips simultaneously is exceedingly difficult, making single-bit flips a higher-probability attack.

Mitigations and Their Bypass:

Magesh systematically dismantled common software-based mitigations:

1. Complex Numbers / Hamming Distance: Using values with high Hamming distance (e.g., 0x55 and 0xAA) instead of 0 and 1 for pass/fail flags. While seemingly robust, the underlying move, compare, and branch instructions remain vulnerable to the same one-bit flips. The mitigation doesn't change the attack surface at the assembly level.
2. Double Checks: Performing the same security check twice (e.g., string compare twice). Magesh argued against if/else structures, as they introduce branch instructions that are easily glitched. Even with two separate checks, an attacker can simply glitch the second check, which is typically the final deciding factor. The linear nature of the code means the second check occurs at a predictable time, making it a viable target.
3. Random Delays: Introducing random delays before or after critical code sections to make timing-based attacks harder to reproduce. While this shifts the instruction execution window, the core critical operation still exists. Attackers can counter this by increasing the number of glitch attempts across a wider time window, relying on statistical probability to eventually hit the moving target. This makes modeling harder but doesn't prevent bypass.
4. State Checks: Implementing a multi-stage state machine (e.g., State1 -> State2 -> State3) where each state transition is validated. Magesh demonstrated a 98% success rate in bypassing this over 10,000 attempts. For critical applications like smart cards, attackers are willing to expend far more effort (millions or hundreds of millions of attempts) to achieve a bypass.

Multiple Glitches:

To overcome challenges like random delays, Magesh explored the utility of injecting multiple glitches. Injecting two or three glitches within a specific time window can significantly increase the probability of success (e.g., from 0.7% for a single glitch to 1.49% for two, and up to 31% for three in one experiment). However, there's a limit; too many glitches will simply cause the CPU to halt or reboot. The optimal number of glitches is target-specific and requires experimentation.

The deep dive reinforced that hardware fault injection targets the very execution of instructions, making many software-level defenses akin to building a secure vault with a compromised foundation.

Demo / Proof of Concept

▶ Watch: Using multiple glitches to increase attack success (24:00)

While Arun Magesh's presentation did not feature a live, interactive demonstration in the traditional sense, he extensively showcased the results of his experiments through detailed graphs, plots, and code snippets, which effectively served as a proof of concept for the discussed fault injection techniques and their ability to bypass mitigations.

The "demo" was presented as follows:

1. Characterization Plots: Magesh displayed graphs illustrating the process of characterization. These plots mapped glitch delay against glitch width, with different colors (green for no effect, purple for CPU crash, red for successful glitch/corruption) indicating the outcome. This visually demonstrated how the "sweet spot" for effective fault injection is identified, showing specific regions where instructions could be corrupted without crashing the entire system. For example, a plot showed that glitch widths less than 200 nanoseconds had no effect, while those over 200 nanoseconds caused system failure, leaving a narrow "red" band in the middle for successful instruction corruption.

1. Bypassing a Simple string compare: He presented a basic if (hash_value == expected_hash) scenario. The accompanying plot showed clear "red" zones around specific glitch delays and widths, indicating successful bypasses where the system reported a "pass" despite an incorrect hash value. This visually confirmed that fault injection could alter the logical flow of a program.

1. Mitigation Bypass Demonstrations: For each mitigation strategy discussed (complex numbers, double checks, random delays, state checks), Magesh provided visual evidence of their bypass:

• Complex Numbers: He showed a plot where, even with Hamming distance-based values (like 0x55 and 0xAA), the bypasses (red markers) still appeared around 1800 nanoseconds, demonstrating that the underlying assembly instructions were still vulnerable.
• Double Checks: The plots for double checks revealed two distinct clusters of "red" bypass points, corresponding to the timing of the two separate checks. This illustrated that an attacker could target either the first or, more strategically, the second check to achieve a bypass.
• Random Delays: For code with random delays, the plots showed a broader, less defined "red" region in the middle of the operation. While the exact timing of the instruction shifted, the overall window for the critical operation remained, allowing for successful (though less reproducible) fault injection by scanning a wider range of delays.
• State Checks: Magesh presented statistics for state checks, reporting a 98% success rate over 10,000 attempts, demonstrating that even multi-stage state machines are not immune to repeated fault injection.

1. Impact of Multiple Glitches: The "demo" included numerical results showing how injecting multiple glitches (e.g., two or three) within a single attempt significantly increased the success rate, from 0.7% to 1.49% and then to 31%. This validated the strategy for improving attack probability, especially against randomized targets.

Crucially, Magesh mentioned that all the code and the framework used for these experiments, based on Arduino, are publicly available. This allows others to reproduce his findings and delve into fault injection themselves, transforming his "demo" into a reproducible and verifiable proof of concept for the wider security community. The speaker's emphasis on making these tools accessible through an Arduino platform further underscores his point that fault injection is no longer an esoteric, high-barrier attack.

Defensive Implications

▶ Watch: Real-life Android MDM bypass with a gas lighter (35:50)

The insights from Arun Magesh's talk carry significant implications for anyone involved in securing hardware and embedded systems. The core message is that traditional software-centric security approaches are insufficient against hardware fault injection.

1. Acknowledge the Inevitability, Focus on Effort:

The most critical takeaway for defenders is that absolute "full security" against fault injection is a myth. Instead, the goal shifts to making attacks exponentially harder, more expensive, and time-consuming for an adversary. Implementing mitigations, even if ultimately bypassable, can increase the number of attempts required from thousands to millions or even hundreds of millions. This extended effort can deter less-resourced attackers or make the attack economically unviable for certain targets.

2. Deep Dive into Assembly for Security-Critical Code:

Relying solely on high-level C code for security mitigations is dangerous. Magesh's examples clearly show that compiler optimizations can strip away intended protections (e.g., removing a "double check" as redundant). Defenders must perform assembly-level code reviews for security-critical functions (like bootloaders, cryptographic operations, and authentication routines) to ensure that compiler output aligns with security intent and does not introduce new vulnerabilities. Any changes to the C code or compiler settings require a fresh assembly review.

3. Layered Hardware and Software Defenses:

While software mitigations alone are weak, they can be part of a layered defense. True resilience requires integrating hardware-level security features:

• Internal Voltage Monitors: More expensive chips can incorporate internal voltage monitors that detect abnormal voltage drops and trigger a system reset or secure shutdown, preventing voltage glitching attacks.
• Light Sensors: For laser fault injection, some chips include internal light sensors that detect decapsulation or laser exposure, again leading to a secure state.
• Physical Tamper Detection: Beyond voltage and light, other physical tamper detection mechanisms can be employed, though these add to complexity and cost.

However, Magesh notes that these hardware protections significantly increase chip cost, making them unviable for many commercial or low-cost IoT devices.

4. Design for Non-Linearity and Redundancy (with Caution):

While random delays can be bypassed, they do increase the difficulty of precise fault modeling. When implementing redundancy (like double checks), consider non-linear execution paths or redundant checks across different clock cycles or processing units, if possible, to make it harder to hit both checks with a single, precise glitch. However, be wary of introducing new branch instructions that become single points of failure.

5. Understand Cross-Domain Glitching:

Defenders should consider that fault injection might not just target the CPU. Attacks can affect other components like RAM, flash memory, or dedicated cryptographic hardware. Protecting these interfaces and ensuring data integrity across different hardware domains is crucial.

6. Threat Model Fault Injection:

Organizations developing embedded systems must formally include hardware fault injection in their threat modeling process. This means identifying critical assets (keys, sensitive data, secure boot states), understanding potential attack surfaces (power lines, external interfaces), and evaluating the feasibility of various fault injection techniques against their specific hardware.

7. Leverage Available Tools for Internal Testing:

Magesh made his Arduino-based fault injection framework publicly available. This provides an invaluable resource for security teams to proactively test their own devices against fault injection attacks, characterize vulnerabilities, and validate the effectiveness of their mitigations before products are deployed.

In conclusion, the defensive strategy against fault injection demands a shift from reactive software patching to a proactive, hardware-aware security engineering approach. It's about designing for robustness at every layer, acknowledging the physical reality of the silicon, and continuously raising the bar for attackers.

Key Takeaways

• Hardware Fault Injection is a Potent and Accessible Threat: Attackers can bypass robust software security by directly manipulating hardware, using techniques like voltage glitching, EMFI, and laser fault injection. Tools and methodologies are increasingly accessible, lowering the barrier to entry.
• Common Software Mitigations are Largely Ineffective: Defenses like complex number checks, double code checks, random delays, and state machine validations often fail because fault injection operates at the assembly level, bypassing high-level software logic.
• Assembly-Level Understanding and Fault Modeling are Crucial: To defend effectively, it's essential to analyze security-critical code at the assembly level, understand compiler optimizations, and perform fault modeling to identify vulnerable instructions and predict attack outcomes.
• Compiler Optimizations Can Undermine Security: Developers must be aware that aggressive compiler optimizations can inadvertently remove or weaken intended software mitigations, necessitating meticulous assembly-level review of security-critical code.
• Absolute Security is Elusive; Focus on Increasing Attacker Effort: There is no "fully secure" solution against fault injection. The goal is to implement layered hardware and software defenses that significantly increase the time, cost, and expertise required for an attacker to succeed, making the attack economically unviable for most targets.
• Comprehensive Threat Modeling is Essential: Organizations must incorporate hardware fault injection into their threat modeling, considering physical attack vectors and the interplay between hardware, firmware, and software to design truly resilient systems.

About the Speaker(s)

Arun Magesh is a Principal Security Consultant at Aon, a company specializing in automated firmware analysis (not the hardware wallet company, as he clarified). His primary expertise lies in chip security, IoT reverse engineering, and embedded pentesting. Magesh also has experience in compliance, highlighting his broad understanding of security challenges across various domains, from deep technical exploits to regulatory requirements. His work focuses on uncovering and understanding hardware-level vulnerabilities to enhance the security of embedded devices.