AI
Why Automotive ECUs Face Extreme Fault Tolerance Requirements
Modern cars contain dozens of ECUs controlling brakes, steering, and the engine.
“they can kill you. If your ECU decides” — Thomas Roth
A bit flip in the brake-by-wire controller can mean the brake pedal stops working. ASIL D, the top automotive safety category, requires any computation fault to be detected within roughly one millisecond. The car’s engine bay makes this hard: an alternator load dump can put 120 volts on the main power line, spark plugs fire at 25,000 volts roughly 100 times per second in a V6, and starter motors add further electrical noise. These are not edge cases. They are the normal operating environment for ECU silicon.
Lockstep: A Safety Mechanism Sold as a Security One
Lockstep runs two CPU cores on the same inputs, with the second core delayed by two clock cycles. After both execute, a hardware comparator checks that register contents and outputs match. A fault that hits one core at a given moment won’t hit the other at the same offset, so divergence triggers an error handler.
The catch: this is a safety feature. It protects against cosmic rays and alternator spikes. It was not designed to stop an attacker who can replay the same glitch thousands of times with microsecond precision.
“feature, it’s not a security feature.” — Thomas Roth
Glitching the Tricore: Setup, Method, and First Results
The TC275 dev board exposes a dedicated core voltage rail behind a large regulator. Roth removed the decoupling capacitors, soldered on a wire, and connected a Pico-based fault injector. A Jupyter notebook then brute-forced delay and pulse parameters. With lockstep and ECC both enabled, the chip still produced successful glitches, shown in the live on-stage glitch of a lockstep debug password (17:44).
The TI Hercules resisted voltage fault injection, but the same characterization firmware broke when Roth switched to electromagnetic fault injection, confirmed in the TI Hercules EMFI scan result (18:55). Three more chips from NXP, ST, and Renesas followed.
“is vulnerable to fault injection.” — Thomas Roth
Reversing the Debug Protocol to Build a Fast Attack Loop
The official TriCore tooling takes 2-3 seconds per connection attempt and runs only on Windows. For a campaign needing millions of glitch attempts, that is unusable. Roth sniffed the USB traffic from the onboard FTDI FT2232 debugger using Wireshark’s built-in MPSSE dissector, then built a script that replays only the minimal commands needed to check whether the debug port is unlocked.
The result: 50 unlock checks per second, cross-platform, with a reset and fault injection trigger included. He also reverse-engineered the undocumented two-wire DAP protocol and released what he believes is the first open-source TriCore DAP implementation.
Two of Five Debug Protections Fall
After weeks of blind glitching across 5 processors, 2 debug password protections failed. Roth declined to name the two vendors. The other three didn’t fall, but he was direct about what that means: more time would likely break them too. With debug access unlocked, firmware can be read and modified on any device using those chips.
The closing observation: the Nintendo Switch 2 reportedly uses lockstep in its boot ROM. The assumption that lockstep stops fault injection has not been tested by most of the people making it.
Notable Quotes
they can kill you. If your ECU decides Thomas Roth · ▶ 1:58
is vulnerable to fault injection. Thomas Roth · ▶ 16:15
feature, it’s not a security feature. Thomas Roth · ▶ 28:55
Key Takeaways
- Lockstep duplicates CPU cores for safety, not security, and does not reliably block fault injection attacks.
- Roth glitched 5 automotive lockstep processors from Infineon, TI, NXP, ST, and Renesas; 2 debug protections fell entirely.
- Open-source DAP tooling now enables 50 TriCore unlock checks per second, making brute-force glitch campaigns practical.