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]
Bar-El, Choukri, Naccache, Tunstall, and Whelan wrote this survey at Gemplus and with academic partners; it circulated as ePrint 2004/100 and appeared in IEEE Proceedings in 2006, and it is still the usual entry point into the field. It catalogues injection mechanisms (voltage, clock, temperature, light, and particle beams) and separates 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 that exploits the gap between read and write threshold voltages. The countermeasures chapter concludes that proprietary countermeasures adopted without systematic analysis are inadequate, a conclusion that later fault research has kept confirming.
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]
Pareja, Wiersma, and Witteman set out to show that ISO 26262 safety certification says nothing about resistance to deliberate fault injection; the two are independent properties. They tested three device classes (QM, ASIL-D1, ASIL-D2) against voltage glitching and EMFI. The QM device fell 100 percent of the time. The ASIL-D variants, protected by lockstep, ECC, and voltage monitoring, dropped the success rate to 37 and 16 percent, but even 16 percent is exploitable within minutes. Using power analysis to place the glitch, they bypassed the JTAG password-comparison routine at 0.34 to 3.2 percent per attempt on the ASIL-D variants, against roughly 80 percent on QM. Their recommendation is to treat 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]
Timmers and Mune take aim at several assumptions practitioners hold about voltage fault injection. Across 270,000 attempts against an isolated add instruction on an ESP32, successful faults show up with pulses as long as 5,000 nanoseconds, roughly 400 times the clock period, so glitch sharpness turns out not to be the parameter that matters. They propose an energy-based model in which the glitch discharges internal capacitance below the threshold needed to hold a logical one, and the boundary between success and failure follows an exponential curve in voltage-versus-length space.
Their second result is the "weird machines" attack. Glitching a loop of 1024 add instructions produces outputs that only make sense as instruction-encoding corruption during fetch: register-field bits change rather than instructions being skipped. That opens the door to glitching during a memcpy or DMA transfer to steer the program counter onto attacker-supplied data without ever passing an 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]
Bozzato, Focardi, and Palmarini wrote a general methodology paper on voltage fault injection, not a TriCore or automotive-ECU case study. They build a low-cost arbitrary-waveform glitching setup and compare shaped glitches with conventional crowbar-style voltage fault injection. Their case studies pull firmware from protected serial bootloaders on six microcontrollers, from STMicroelectronics, Texas Instruments, and Renesas Electronics, among them Renesas 78K devices whose suggested applications included automotive systems.
Waveform shape, they find, can matter as much as timing and voltage. Some attacks work with shaped pulses that stay clear of reset conditions while still disturbing the bootloader's security checks or opening checksum-leak side channels. The Renesas 78K case studies needed repeatable campaigns of hundreds of thousands to over one million glitches. That makes the paper useful background for later automotive work even though it never targets 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]
Weiß and Pozzobon go after NXP MPC5748G gateway ECUs, with the goal of running unsigned code through the UDS firmware-update channel. That update sequence (see ECU Flashing chapter) requires a signature check before the bootloader will mark a new image valid. PowerPC VLE encodes 0x0000 as an invalid instruction, so overwriting the PC with zero just triggers an immediate exception; the authors instead corrupt the stack pointer with EMFI so that a function return pops a controlled value into the program counter.
To find the right EMFI parameters they built EFISSA, an evolutionary algorithm that uses exception-handler stack traces as its fitness signal and converges toward controlled exceptions. On three different gateway ECU boards, EFISSA cut the 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]
Melching ran the first public voltage glitch attack against the RH850. The target was an R7F701381 (RH850/P1M-E) taken 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. About a day of parameter search later, a successful glitch pushed the chip into the command-waiting phase regardless of the access-check result, and the full firmware came out over 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]
In February 2024, Sunny and Zari applied the RH850 voltage glitch technique to an RH850/F1L BCM, which uses a 16-byte IDCODE check. Here the injection point is the ISOVCL pin. A ChipWhisperer Lite with a modified glitch output drives ISOVCL, and iterating offset, width, and voltage bypasses the ID code check. Once past it, later memory-read commands need no re-authentication, though the target sometimes stops responding, and extracting the full code flash and data flash took repeated successful glitches. Reverse engineering the firmware turned up 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]
Azalbert published the most thorough treatment of the RH850 IDCODE bypass so far in March 2026. On an RH850/F1KM-S4 development board, the main obstacle is 80 microseconds of jitter per attempt on the UART interface, probably a deliberate random delay in the firmware, which makes the password's last byte an unreliable injection trigger.
Wiring the ChipWhisperer Husky ADC input alongside the glitch output on ISOVCL exposes a 4-microsecond power pattern about 80 microseconds after the password is received, which lines up with the comparison. Chaining a UART trigger to an ADC threshold trigger on that pattern shrinks the window to a few microseconds, and IDCODE protection falls in under one minute and 88 attempts. A Pico Glitcher (roughly 40 euros) manages it too, in about 7,000 attempts over 80 minutes, and the attack carries over to 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 talk that attacks the AURIX lockstep countermeasure with voltage fault injection.
Reverse Engineering of the TriCore Aurix Debug Protocol
Pozzobon, HackInBo 2025 [9]
At HackInBo Winter 2025 (15 November 2025), Pozzobon walked through 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. It plays the same role as JTAG or SWD on Cortex-M parts but runs a two-pin bidirectional telegram-based protocol with CRC6 error detection. Until this work, reaching DAP meant using Infineon's Miniwiggler USB debugger or comparably priced vendor hardware, which put independent experimentation with AURIX debug access out of easy reach.
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) gave this talk at Black Hat USA 2025, running both voltage glitching and EMFI against a Tricore TC275. Reading between the lines, it looks like the debug password protection was bypassed, though the talk does not say so outright.
NXP / Freescale / ST (Power Architecture)
NXP/Freescale's MPC5xxx and SPC56xx families and ST's SPC5 line (including SPC58) share a Power Architecture e200 core lineage from the joint Freescale/ST automotive development era, and with it a closely related Boot Assist Module (BAM) ROM that handles flash censorship and programming access. The three entries here hit different parts of that shared design. O'Flynn goes straight at the MPC55xx/MPC56xx BAM. Van den Herrewegen and Adam take on the SPC5606B chip-lockout configuration, the one O'Flynn had said he could not break. The GoGoByte team attack the JTAG password authentication on the ST-branded SPC5 series, naming SPC58 as the target.
BAM BAM!! On Reliability of EMFI for in-situ Automotive ECU Attacks
O'Flynn, ESCAR Europe 2020 [11]
O'Flynn's work is the reference usually cited for showing that EMFI attacks carry over from the lab 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. When the password matches a private flash password set, BAM loads a secondary bootloader with flash uncensored. The attack sends a wrong password and fires an EMFI pulse timed to land on the comparison code, so BAM accepts it anyway. Four configurations were 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 the development boards. On the E41, the CCW tip produced no successes while the CW tip did, and a working glitch usually turned up within 1 to 5 minutes. There is a false-positive trap worth noting: an EMFI pulse fired too early switches BAM to the public password without uncensoring flash, which misleads anyone who checks for 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]
Van den Herrewegen and Adam attack the SPC5606B in chip lockout. Here the censorship control word uses the public password, so BAM loads a secondary bootloader, but the System Status and Configuration Module (SSCM) keeps flash censored and returns 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 against this configuration had 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 (asserting RESET only triggers a soft reset, which does not reload shadow flash). About 500 microseconds after POR, a roughly 4-microsecond activity burst marks the SSCM loading its censorship configuration, and a Teensy 4.0 ADC module fires EMFI at that point. Early scans turn up a chunk-leakage anomaly: faults at 618 to 620 microseconds make censored flash return a different 16-byte block, which shows the SSCM is picking an arbitrary flash offset. Narrowing to a 1 mm clockwise coil just before that window disables censorship entirely. 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]
At Black Hat USA 2024, the GoGoByte team went after the JTAG password protection on ST's SPC5 family, using SPC58 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 ordinarily make a fine glitch target, but the SPC5 implementation repeats the check after the primary comparison, so a one-shot voltage glitch on the password compare cannot enable JTAG by itself.
They reverse-engineered the authentication state machine and found the internal flag values that mean "password accepted" inside the JTAG controller. Then they built a small custom hardware adapter that suppresses or reshapes the redundant-check phase, so the chip evaluates the authentication exactly once per attempt and the protection becomes a single, stable trigger window. With that gadget in place, voltage fault injection on the first comparison passes authentication and exposes the full JTAG interface, giving code execution and firmware access on the gateway-class ECU built around an SPC58. The team reported the issue to STMicroelectronics and expects the same approach to work across the rest of the SPC5 series, and probably 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 take advantage of the chips involved also shipping 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]
Kühnapfel, Werling, Jacob, and Seifert first enumerate the security assets that hardware access to a Tesla Car Computer exposes, then attack each of the three subsystems on both Hardware Revision 3 and Hardware Revision 4. The main compute SoC is an AMD x86 part. Next to it sits Tesla's custom FSD chip running the autopilot stack. A separate Gateway ECU, built around an NXP MCU (swapped on later vehicles for 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 gives way when the digital control line between it and its external voltage regulator is interfered with. The FSD chip is attacked with a crowbar setup directly on its core rail. The Gateway is the hard one: voltage glitching produced only resets, and only electromagnetic fault injection gave 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 carry over to other manufacturers using the same silicon.
Making the Magic Leap past NVIDIA's Secure Bootchain
Katze, 39C3 2025 [14]
At 39C3, Katze chained three exploits against the Nvidia Tegra X2 (Parker), a chip that shows up 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, that yields code execution inside the bootloader. Dtbhax is a buffer overflow in CBoot's device-tree loader: an oversized DTB overwrites CBoot itself, giving persistence without device-specific firmware. RCMhax goes after the Tegra X2 BootROM's USB recovery mode through USB-controller design flaws and Transfer Request Block manipulation, writing arbitrary data into SysRAM and eventually running code at BootROM privilege. The BootROM bug cannot be patched; fixes show up only in Tegra X1+ and Orin.