From 25 million instructions to one faulty skip: AI-driven fault analysis of a secure boot

In part 1, we argued that the walls around firmware analysis are coming down when an AI agent drives the right instruments: esFirmware to run, trace and fault firmware, and Epoch to turn an execution into a time-travel trace.

We gave it a tampered BL2, which it correctly rejected.

The question: can a single, well-placed fault turn that rejection into an acceptance?The short answer is yes. One 2-byte instruction, skipped once, flips the verdict, despite several countermeasures in the code. The rest of this post shows how we got there, step by step, and what we could and could not prove.The setup: an AI agent did the workEvery step below was carried out by an AI agent, Claude Opus 4.8, driving our tools directly. The analyst set the goals, chose the fault model and the success criterion, and reviewed the evidence. The bring-up, the reversing, the campaign set-up and the trace analysis were done by the agent.A frontier model is not a requirement. On other projects, we saw open-weight models do the same kind of work. They are less capable, but they run entirely on our own infrastructure. For firmware that must not leave the organisation, that trade-off matters: the binaries, the traces and the findings stay in house.At a glanceEach stage narrows the problem: the full trace locates the verdict, the snapshot cuts each run by a factor of about 600, the campaign finds the one vector, and two short traces prove it.The target and the fault modelWe started from two raw dumps and no documentation: Input What it is Boot ROM 128 KB of 32-bit ARM code, the first code the SoC runs Flash image SPI-NAND dump containing the BL2, its header and its signature The boot ROM embeds many protections against the fault injection.

These are classic countermeasures against fault injection.To create a meaningful test, we modified a few bytes of the BL2. The signature no longer matches, so a correct boot ROM must reject it. That rejection is our baseline.The fault model is instruction skip: a single instruction is not executed, as if a glitch had made the CPU jump over it. It is the most common effect of clock and voltage glitches, and a good first model for a campaign. The success criterion is simple: the verdict word becomes 0xAAAAAAAA for an image that should have been rejected.Step 1: bringing the boot ROM up in emulationA boot ROM talks to hardware from its first instructions: timers, clock and power controllers, the flash controller, a hardware hash engine. None of it exists in a generic emulator, and none of it is documented. This is where emulation projects usually stall.To get past this wall, we built a dedicated tool whose only aim is rehosting a binary: making it run outside its original hardware, on an emulator, with enough fidelity to execute its real code paths. It combines two sources of insight. Our TTD capabilities let the agent record each emulated run and walk back from a stall to the exact instruction and register access that caused it. Open-source static analysis tools give it the surrounding code, the cross-references and the functions that touch the same peripheral.With this tool, the agent worked through the bring-up as a loop:Run the boot ROM in emulation and record the run until it stalls, typically spinning on a peripheral register that never changes.Walk back in the trace to the access that blocks execution, then read the code around it with static analysis to understand what the ROM expects from that register.Add a hook or a stub that answers what the ROM expects, then run again.Each iteration moved execution further. In the end, a small library of hooks was enough: a ticking general-purpose timer, stubs for the hardware blocks the ROM only polls, and a software implementation of the hash the ROM normally offloads to a hardware engine. With these, the ROM runs its real secure boot path, on unmodified code.The agent also located the BL2 in the flash dump by parsing its header and checked it was bit-for-bit identical to the image the ROM loads at runtime.The workflow spans two emulators, by necessity rather than by choice: QEMU for fast, many-shot fault campaigns, Unicorn for recording time-travel traces. Hooks and stubs had to behave the same on both. The analyst never had to handle that plumbing directly.

Everything was managed through the AI agent.Step 2: recording the whole secure boot with EpochWith the boot ROM running, we recorded one complete execution with the tampered BL2 as an Epoch time-travel trace: about 25 million instructions.