Fault Injection
Fault injection attacks force a microcontroller outside its intended operating conditions, causing incorrect computation or skipped code paths. The main physical mechanisms are voltage glitching (briefly shorting the supply rail), clock glitching (inserting an extra edge to shorten a pipeline stage), EMFI (a discharged coil inducing a transient current without electrical contact), and laser or light injection (exploiting the photoelectric effect on silicon). Voltage glitching is the cheapest and most accessible entry point.
Many automotive-targeted chips in the Renesas RH850, Infineon AURIX, NXP/Freescale MPC5xxx, and STMicroelectronics SPC5 families include ISO 26262 ASIL-D safety features such as CPU lockstep, memory ECC, and voltage monitoring. Those countermeasures target accidental hardware faults such as cosmic-ray upsets; they are not designed to detect a deliberately timed glitch whose amplitude and timing are controlled by an attacker.
Foundations
The Sorcerer's Apprentice Guide to Fault Attacks
Bar-El et al., IEEE Proceedings 2006 [1]
Circulated as ePrint 2004/100 and published in IEEE Proceedings 2006, this survey by Bar-El, Choukri, Naccache, Tunstall, and Whelan from Gemplus and academic partners remains the standard entry-point reference for the field. It catalogues injection mechanisms (voltage, clock, temperature, light, and particle beams) and distinguishes provisional faults (transient, device recovers on reset) from destructive ones (permanent silicon damage). The attack section covers the Boneh-DeMillo-Lipton RSA-CRT attack, DES fault attacks, and an EEPROM attack exploiting the gap between read and write threshold voltages. The countermeasures chapter concludes that proprietary countermeasures without systematic analysis are inadequate, a finding repeated by every subsequent decade of fault research.
Instruction and Data Glitch Attack oscilloscope traces showing how a supply-voltage transient diverges execution from the normal power trace. Figure from Bar-El et al., 2004/2006 (The Sorcerer's Apprentice Guide to Fault Attacks).
Safety != Security: On the Resilience of ASIL-D Certified Microcontrollers Against Fault Injection Attacks
Pareja, Wiersma, Witteman (Riscure), FDTC 2017 [2]
This paper demonstrates that ISO 26262 safety certification and resistance to deliberate fault injection are orthogonal properties. Testing three device classes (QM, ASIL-D1, ASIL-D2) against voltage glitching and EMFI, the QM device is bypassed at 100 percent; the ASIL-D variants, protected by lockstep, ECC, and voltage monitoring, reduce success rates to 37 and 16 percent, but a 16 percent rate remains exploitable within minutes. A power-analysis-guided voltage glitch bypasses the JTAG password-comparison routine at 0.34 to 3.2 percent per attempt on ASIL-D variants versus roughly 80 percent on QM. The paper recommends SAE J3101 hardware-protected security as the complementary framework.
False Injections: Tales of Physics, Misconceptions and Weird Machines
Timmers, Mune (Raelize), Dartmouth Security Seminar 2025 [3]
This paper challenges several widely held practitioner assumptions about voltage fault injection. Running 270,000 attempts against an isolated add instruction on an ESP32, successful faults appear with pulses up to 5,000 nanoseconds, roughly 400 times the clock period; glitch sharpness is not the relevant parameter. An energy-based model treats the glitch as discharging internal capacitance below the threshold for holding a logical one, with the success boundary following an exponential curve in voltage-versus-length space.
The second contribution is the "weird machines" attack: targeting a loop of 1024 add instructions reveals outputs only explainable as instruction-encoding corruption during fetch (register-field bits changed, not instructions skipped), enabling a glitch during memcpy or DMA to divert the program counter to attacker-supplied data without crossing any authentication check.
Distribution of glitch voltage versus glitch length outcomes on the ESP32, with green indicating no effect, yellow indicating a crash or reset, and red indicating a successful fault. Figure from Timmers, Mune, 2025 (False Injections, Dartmouth).
Shaping the Glitch: Optimizing Voltage Fault Injection Attacks
Bozzato, Focardi, Palmarini, IACR TCHES 2019 [4]
This TCHES paper is a general voltage fault-injection methodology paper rather than a TriCore or automotive-ECU case study. It introduces a low-cost arbitrary-waveform glitching setup and evaluates shaped glitches against conventional crowbar-style voltage fault injection. The case studies extract firmware from protected serial bootloaders on six microcontrollers from STMicroelectronics, Texas Instruments, and Renesas Electronics, including Renesas 78K devices whose suggested applications included automotive systems.
The key finding is that waveform shape can be as important as timing and voltage. Some attacks succeed with shaped pulses that avoid reset conditions while still disturbing the bootloader's security checks or creating checksum-leak side channels. The Renesas 78K case studies required complex, repeatable campaigns with hundreds of thousands to over one million glitches, making the paper useful background for later automotive work even though it does not target a production vehicle ECU directly.
Hardware setup for the arbitrary-waveform voltage fault injection rig, with two oscilloscope traces showing examples of shaped glitch waveforms. Figure from Bozzato, Focardi, Palmarini, 2019 (Shaping the Glitch, TCHES).
Fault Injection Attacks on Secure Automotive Bootloaders
Weiß, Pozzobon (Dissecto), ASRG 2023 [5]
This ASRG presentation targets NXP MPC5748G gateway ECUs, aiming to execute unsigned code through the UDS firmware-update channel. The UDS update sequence (see ECU Flashing chapter) requires a signature check before the bootloader marks a new image valid. PowerPC VLE encodes 0x0000 as an invalid instruction, so a PC-zero-overwrite causes an immediate exception; instead, EMFI corrupts the stack pointer so a function return pops a controlled value into the program counter.
The authors develop EFISSA, an evolutionary algorithm using exception-handler stack traces as a fitness signal to converge EMFI parameters toward controlled exceptions. On three different gateway ECU boards, EFISSA reduces parameter search from weeks to under one hour.
Attack diagram: fault injection diverts the program counter from the bootloader's signature-verification path into an unsigned exploit firmware image. Figure from Weiß, Pozzobon, 2023 (Fault Injection Attacks on Secure Automotive Bootloaders, ASRG).
Renesas (RH850 / V850)
The Renesas RH850 is a 32-bit V850-derived core used in electronic power steering, body control modules, and transmission controllers. Flash access is protected by a programmer-disable mode or a 16-byte IDCODE password. The VCL pin (core-voltage regulator output, intended for external decoupling capacitors) is an effective injection point: removing the capacitor and attaching a fast FET allows a timed crowbar to reach the CPU core directly.
Bypassing the Renesas RH850/P1M-E Read Protection Using Fault Injection
Melching, icanhack.nl 2022 [6]
The first public voltage glitch attack against the RH850 targeted an R7F701381 (RH850/P1M-E) from the Electronic Power Steering module of a 2021 Toyota RAV4 Prime, with programmer access fully disabled. The attack window is the roughly 100 microseconds between the last synchronize-command byte and the chip's reply; an N-channel FET on both VCL pins, driven by a Raspberry Pi Pico, pulls the rail to ground after a configurable delay. After about one day of parameter search, a successful glitch caused the chip to enter the command-waiting phase regardless of the access-check result, and the full firmware was extracted with standard read-memory commands.
The RH850/P1M-E ECU PCB from a Toyota EPS module, modified for voltage glitching: decoupling capacitors removed from both VCL pins, N-FETs attached, and the debug connector visible at lower left. Figure from Willem Melching, 2022 (icanhack.nl RH850 glitch).
Unlocking Renesas RH850/F1L Security with Voltage Glitching to Extract Firmware on Automotive ECUs
Sunny, Zari (FEV Secure Lab), 2024 [7]
Published in February 2024, this post applies the RH850 voltage glitch technique to an RH850/F1L BCM, which uses a 16-byte IDCODE check. The injection point is the ISOVCL pin. A ChipWhisperer Lite with a modified glitch output connects to ISOVCL; iterating offset, width, and voltage bypasses the ID code check. After a successful bypass, subsequent memory-read commands do not need re-authentication, though the target sometimes stops responding and full code flash and data flash extraction required repeated successful glitches. Reverse engineering revealed secret keys used for diagnostic security access.
Voltage-glitching hardware setup: the RH850/F1L BCM ECU, a ChipWhisperer Lite, and an oscilloscope, with the glitch output connected to the ISOVCL pin. Figure from Sunny, Zari, 2024 (RH850 Voltage Glitching, FEV Secure Lab).
Bypassing Debug Password Protection on the RH850 Family Using Fault Injection
Azalbert, Quarkslab 2026 [8]
Published in March 2026, this is the most thorough treatment of the RH850 IDCODE bypass to date. On an RH850/F1KM-S4 development board, the core problem is 80 microseconds of jitter per attempt on the UART interface, likely from a deliberate random delay in the firmware, making the password's last byte an unreliable injection trigger.
The ChipWhisperer Husky ADC input connects alongside the glitch output on ISOVCL, revealing a 4-microsecond power pattern about 80 microseconds after password receipt that corresponds to the comparison. Chaining a UART trigger with an ADC threshold trigger on that pattern collapses the window to a few microseconds; IDCODE protection is bypassed in under one minute and 88 attempts. A Pico Glitcher (roughly 40 euros) also succeeds in about 7,000 attempts over 80 minutes, and the attack transfers across multiple RH850-based ECUs.
ChipWhisperer Husky connected to an RH850 development board, with the ISOVCL SMA connector used both to inject glitches and to measure the power side channel. Figure from Azalbert, 2026 (Quarkslab RH850 debug password bypass).
Infineon (TriCore / AURIX)
Infineon's TriCore and AURIX families are widely used in powertrain and safety ECUs. The Simos18 ECU on Volkswagen group vehicles contains a TriCore TC1791S, and a lot of newer ECUs contain the TC2xx and TC3xx series. The entries below cover open tooling for AURIX debug access and a Black Hat 2025 demonstration that targets the AURIX lockstep countermeasure with voltage fault injection.
Reverse Engineering of the TriCore Aurix Debug Protocol
Pozzobon, HackInBo 2025 [9]
Presented at HackInBo Winter 2025 (15 November 2025), this talk describes the reverse engineering and open reimplementation of the Infineon DAP (Device Access Port) protocol used by AURIX TriCore chips. DAP is Infineon's proprietary debug interface, serving the same role as JTAG or SWD on Cortex-M parts, but using a two-pin bidirectional telegram-based protocol with CRC6 error detection. Prior to this work, DAP was only accessible through Infineon's Miniwiggler USB debugger or comparably priced vendor hardware, making independent experimentation with AURIX debug access difficult.
Pozzobon captured USB traffic between the Miniwiggler and target chips using USBPcap and Wireshark, then decoded the MPSSE (Multi-Protocol Synchronous Serial Engine) layer produced by the FTDI FT2232H inside the Miniwiggler. From the raw bit sequences he identified the DAP telegram framing: a start bit, a 6-bit command-type field, a 7-bit length field, a variable-length argument, and a 6-bit CRC6 trailer. The resulting Python reimplementation in epozzobon/tricore-things drives commodity FTDI boards such as the Tigard to act as DAP hosts, replacing the need for proprietary hardware. Slides link: HackInBo 2025 PDF; code at epozzobon/tricore-things.
For automotive security research, the practical value is tooling independence: once DAP access is legitimately available or separately unlocked, commodity FTDI hardware can read memory and control execution without Infineon's Miniwiggler.
DAP telegram message format showing color-coded bit fields: start bit, command type (yellow), length (pink), argument (blue), and CRC6 (red), as reverse-engineered from Miniwiggler USB captures. Figure from Pozzobon, 2025 (Reverse Engineering of the TriCore Aurix Debug Protocol, HackInBo).
Watch Your (Lock)Step: Glitching into Automotive Processors
Roth (hextree.io), Black Hat USA 2025 [10]
Thomas Roth (stacksmashing) presented this talk at Black Hat USA 2025. Roth demonstrates both voltage glitching and EMFI against a Tricore TC275. Reading between the lines in the talk it looks like the Debug password protection was bypassed, but this is not explicitly confirmed.
NXP / Freescale / ST (Power Architecture)
NXP/Freescale's MPC5xxx and SPC56xx families and ST's SPC5 line (including SPC58) share a common Power Architecture e200 core lineage from the joint Freescale/ST automotive development era, along with a closely related Boot Assist Module (BAM) ROM that handles flash censorship and programming access. O'Flynn's work targets the MPC55xx/MPC56xx BAM directly; Van den Herrewegen and Adam target the SPC5606B chip-lockout configuration that O'Flynn specifically noted he could not break; the GoGoByte team attack the JTAG password authentication on the ST-branded SPC5 series, with SPC58 explicitly named.
BAM BAM!! On Reliability of EMFI for in-situ Automotive ECU Attacks
O'Flynn, ESCAR Europe 2020 [11]
The canonical reference demonstrating that EMFI attacks transfer from a laboratory to a real, unmodified automotive ECU. The target family is the NXP/Freescale MPC55xx and MPC56xx Power Architecture series.
The Boot Assist Module (BAM) is ROM-based code that listens for an 8-byte password over UART or CAN; if the password matches a private flash password set, BAM loads a secondary bootloader with flash uncensored. The attack sends an incorrect password and fires an EMFI pulse timed to hit the comparison code, causing BAM to accept it. Four configurations are tested: a CW308T-MPC5676R evaluation board, an MPC5676R development kit, an MPC5566 DK, and a GM E41 ECU (part 12691652, 2019 Chevrolet Silverado 2500 HD).
Success rates run 1 to 2 percent per attempt on development boards; on the E41, the CCW tip produced no successes while the CW tip did, with a working glitch typically found within 1 to 5 minutes. A noted false-positive trap: EMFI fired too early switches BAM to the public password without uncensoring flash, misleading any attacker who checks password acceptance rather than actual flash access.
Hardware targets used to characterise the EMFI attack: (a) NAE-CW308T-MPC5676R evaluation board, (b) MPC5676R development kit, (c) GM E41 ECU in-situ target, (d) MPC5566 development kit. Figure from O'Flynn, 2020 (BAM BAM!!, ESCAR Europe / ePrint 2020/937).
Overall success rate table across four target boards and two password strategies (private and public), with 1-2% success rates achieved consistently across development boards and the real-world E41 ECU. Figure from O'Flynn, 2020 (BAM BAM!!, ESCAR Europe / ePrint 2020/937).
Disabling Censorship on SPC5606B Chips
Van den Herrewegen, Adam, 2025 [12]
This paper attacks the SPC5606B in chip lockout: the censorship control word uses the public password, so BAM loads a secondary bootloader but the System Status and Configuration Module (SSCM) leaves flash censored, returning the same 16-byte block from address zero on every read. O'Flynn's private-password glitch does not apply and his BAM-level attempts on this configuration produced no successes. NXP PSIRT was notified in October 2024.
A GIAnT voltage-control tool forces a Power-On Reset by dropping Vdd below 2 V (RESET triggers only a soft reset, which does not reload shadow flash). A roughly 4-microsecond activity burst visible at about 500 microseconds after POR corresponds to the SSCM loading censorship configuration; a Teensy 4.0 ADC module triggers EMFI at that point. Initial scans reveal a chunk-leakage anomaly: faults at 618 to 620 microseconds cause censored flash to return a different 16-byte block, confirming the SSCM is selecting an arbitrary flash offset. Narrowing to a 1 mm clockwise coil just before that window fully disables censorship. The attack is confirmed on a bare SPC5606B and on a Nissan Hands-Free Module ECU.
The Nissan Hands-Free Module ECU with the SPC5606B chip in chip-lockout configuration, used as the real-world target for the censorship-disable EMFI attack. Figure from Van den Herrewegen, Adam (Disabling Censorship on SPC5606B Chips).
Ops! It Is JTAG's Fault: Journey to Unlocking Automotive Grade IC
Li, Shi, Yang, Wu (GoGoByte), Black Hat USA 2024 [15]
This Black Hat USA 2024 talk targets the JTAG password protection on ST's SPC5 family, with SPC58 named as the demonstration target. The SPC5 JTAG-controller authentication compares a 64-bit password sent over the debug interface against a value stored in flash; a single comparison success would normally be a viable glitch target, but the SPC5 implementation runs a redundant check after the primary comparison, so a one-shot voltage glitch on the password compare cannot enable JTAG on its own.
The GoGoByte team reverse-engineered the authentication state machine and identified the internal flag values that indicate "password accepted" inside the JTAG controller. They then built a small custom hardware adapter that suppresses or reshapes the redundant-check phase so that the chip evaluates the authentication exactly once per attempt, turning the protection into a single, stable trigger window. With that gadget in place, voltage fault injection on the first comparison passes the authentication and exposes the full JTAG interface, giving code execution and firmware access on the gateway-class ECU built around an SPC58. The authors report the issue to STMicroelectronics and expect the same flow to apply across the rest of the SPC5 series and likely related Power Architecture parts from other vendors.
Tesla
The two entries below target Tesla's in-vehicle compute hardware rather than a single chip family. Together they cover three Autopilot generations: Tegra X2 in Autopilot 2 and 2.5, and Tesla's own FSD chip with its surrounding AMD SoC in HW3 and HW4. Both works combine fault injection with software bugs, and both leverage that the chips involved are also shipped in other vehicles and devices.
Three Glitches to Rule One Car: Fault Injection Attacks on a Connected EV
Kühnapfel, Werling, Jacob, Seifert (TU Berlin SecT), ASIA CCS 2025 [13]
This ASIA CCS '25 paper enumerates the security assets exposed by hardware access to a Tesla Car Computer, then attacks each of the three subsystems on both Hardware Revision 3 and Hardware Revision 4. The main compute SoC is an AMD x86 part; alongside it sits Tesla's custom FSD chip running the autopilot stack; a separate Gateway ECU based on an NXP MCU (replaced on later vehicles by a nearly identical ST Microelectronics part) bridges to CAN.
Two of the three subsystems fall to plain voltage glitching with low-cost hardware. The AMD SoC is glitched by interfering with the digital control line between the SoC and its external voltage regulator. The FSD chip is attacked with a crowbar setup directly on its core rail. The Gateway is the hardest target: voltage glitching produced only resets, and only electromagnetic fault injection yielded semantic faults usable for control-flow disruption. The vulnerable parts are either advertised for automotive use or certified to automotive safety standards, so the attacks generalise to other manufacturers using the same silicon.
Making the Magic Leap past NVIDIA's Secure Bootchain
Katze, 39C3 2025 [14]
Presented at 39C3, this work chains three exploits against the Nvidia Tegra X2 (Parker) used in Magic Leap 1 headsets, Tesla Autopilot 2 and 2.5 boards, the Nvidia Drive PX2, and the Skydio X2 drone. Sparsehax is a stack overflow in the sparseFS image unpacker reachable from the Fastboot USB interface, giving code execution inside the bootloader. Dtbhax is a buffer overflow in CBoot's device-tree loader that lets an oversized DTB overwrite CBoot itself, providing persistence without device-specific firmware. RCMhax targets the Tegra X2 BootROM's USB recovery mode through USB-controller design flaws and Transfer Request Block manipulation, writing arbitrary data into SysRAM and ultimately executing code at BootROM privilege. The BootROM bug is unpatchable; fixes appear only in Tegra X1+ and Orin.