Security expectations for connected products are rising. With the EU Cyber Resilience Act (CRA), manufacturers must increasingly demonstrate that cybersecurity has been considered throughout product development, supported by appropriate security testing and documented evidence.

The CRA's vulnerability reporting obligations have applied since September 11, 2026, while its main cybersecurity and conformity requirements become applicable on December 11, 2027.

This creates a practical challenge for manufacturers, security teams and independent evaluators: how do you efficiently investigate firmware security, identify potential weaknesses and produce evidence that others can review?

And what happens when you do not have access to the source code?

In a recent internal project, we started with a raw boot ROM dump from a production SoC. Using an AI agent equipped with esFirmware and Epoch, our Time Travel Debugging tool, we went from binary-only analysis to identifying a single-fault bypass of its secure boot verification logic, supported by reproducible emulation evidence.

The analyst remained in charge. The agent handled much of the investigation, from bringing the firmware into emulation to navigating execution traces and running fault campaigns.

This post explains why dynamic firmware analysis matters, what has traditionally made it difficult, and how AI can now help overcome these barriers.

In a second post, we will explore the technical investigation in detail.

‍

From firmware binary to security evidence

Let's start with a common assessment scenario.

You need to evaluate the security of firmware, perhaps to investigate a vulnerability, assess a device, verify an implementation against security requirements, or support a certification process. But you do not have the source code. You have the compiled binary, extracted from a device, provided by a supplier, or recovered from a firmware image.

This changes how the investigation must be approached.

Static analysis is generally the starting point. It allows an analyst to disassemble the binary, reconstruct functions, identify interesting code sequences and formulate hypotheses about its behaviour.

But looking at the instructions alone does not necessarily tell us what happens when the firmware actually runs.

A security check may appear robust in the disassembly but behave differently depending on the values received at runtime. A branch that looks like an interesting attack target might never be reached in the execution scenario being investigated.

This is where dynamic analysis becomes particularly valuable.

‍

Why dynamic analysis matters for firmware

Dynamic analysis allows us to observe the binary as it executes, with a defined initial state and controlled inputs.

For firmware security investigations, this becomes especially useful when we need to understand:

• How the firmware progresses through its boot or initialization sequence.
• Which security mechanisms are actually executed, and in what order.
• How data moves between functions, registers and memory.
• How a security decision is calculated, stored and subsequently consumed.
• What happens when execution or data is deliberately altered, for example through a simulated fault injection.

Consider a secure boot implementation.

Finding the signature verification function in the binary is useful. But to evaluate the verification logic, we want to know what happens when an invalid bootloader is presented.

Which path is taken? Where is the rejection verdict produced? How is that verdict handled by the caller? Could an alteration to the execution flow change the outcome?

These are questions that dynamic analysis can investigate directly. The challenge is making the firmware executable in an environment where we can observe and control it.

‍

Three barriers that have traditionally made firmware dynamic analysis expensive

Running an ordinary application in a debugger is one thing. Running a firmware binary designed for a specific embedded platform is quite another.

Three challenges have historically made this type of investigation expensive and dependent on specialized expertise.

‍

1. Reproducing the execution environment

Firmware is tightly coupled to the hardware it was designed to run on.

Its execution may depend on a specific memory map, timers, cryptographic accelerators, fuses, peripherals and undocumented hardware behaviour.

Without the physical device, these dependencies need to be reproduced or appropriately modelled in emulation.

A missing peripheral response can stop execution. An incorrect register value can send the firmware down the wrong path. An incomplete hardware model may produce misleading results.

Getting a firmware binary to execute meaningfully is therefore often an iterative process of identifying and resolving these dependencies.

‍

2. Finding the relevant instructions among millions

Once the firmware runs, the next challenge is understanding what happened.

A single secure boot sequence can execute tens of millions of instructions. Yet the security decision we want to investigate may ultimately depend on a handful of instructions and runtime values.

Finding those instructions, understanding their dependencies and reconstructing the relevant execution path can require substantial effort.

‍

3. Producing reproducible evidence

Identifying a potential weakness is only part of a security assessment.

An internal security team, product manufacturer or evaluation laboratory also needs to understand how the finding was obtained and whether it can be reproduced.

What execution path was tested? Which input was used? What changed? Where did the normal and altered executions diverge?

Answering these questions with manually collected logs and screenshots is possible, but time-consuming.

All three challenges become even more significant when security testing needs to be repeated throughout product development or used to support broader security assurance activities.

‍

What changed: AI takes on the complexity of the investigation

The complexity of firmware analysis has not magically disappeared. Running an unfamiliar binary still requires reproducing its environment, understanding its behaviour and navigating potentially millions of instructions.

What has changed is who handles that complexity.

Until now, an analyst needed to be proficient not only in reverse engineering but also in operating and coordinating the different tools involved in the investigation. Configuring emulation, troubleshooting execution, navigating traces, scripting experiments and interpreting the results were largely manual tasks.

Today, an AI agent can take on much of that work.

The analyst describes what they want to investigate, defines the objectives and guides the analysis. The agent translates those instructions into actions, operates the tools, investigates execution issues and iterates towards the objective.

This is an important shift. It means that accessing meaningful dynamic firmware analysis no longer requires the analyst to personally orchestrate every technical step.

In our project, we combined two complementary technologies to make this possible:

• esFirmware provides the ability to emulate firmware execution, create execution snapshots and perform simulated fault injection campaigns.
• Epoch, our Time Travel Debugging platform, records execution and makes the resulting trace available for detailed investigation, including AI-assisted analysis.

Together, they provide a way for an agent to work with observed execution data rather than relying exclusively on interpretations of static code.

Here's how that changes the investigation.

‍

From trial-and-error emulation to an iterative workflow

When emulation encounters an unexpected execution path, unsupported hardware access or another blocking issue, the agent can investigate what happened.

With access to static analysis and Epoch execution traces, it can examine the relevant instructions and runtime state, identify a possible missing hardware dependency, adapt the model and try again.

The process becomes iterative: run the firmware. Investigate where execution stops. Understand the dependency. Adjust the emulation. Run again.

The analyst can supervise this process rather than manually handling every individual step.

‍

From millions of instructions to an explorable execution history

Once a meaningful execution is obtained, Epoch records it as a Time Travel Debugging trace.

In our case, the secure boot execution represented approximately 25 million instructions. 

Rather than navigating this execution sequentially, the agent could investigate it backward from the rejection verdict. Which instruction wrote the verdict? Which comparison produced it? What were the register values? Which function is called the verification routine?

Epoch makes the recorded execution available as a persistent dataset that the agent can query and revisit.

This is the principle we explored in our previous article, "Making dynamic analysis an AI problem".

The agent no longer needs to guess what happened. It can investigate what was recorded.

‍

A glimpse from the field: investigating a secure boot implementation

To demonstrate this approach, we investigated the boot ROM of a widely deployed ARM-based SoC. The investigation followed five main steps.

1. Bringing the firmware into emulation

The agent iteratively reconstructed the execution environment using esFirmware and Epoch, working with Unicorn and QEMU and modelling the necessary hardware dependencies as they appeared. We developed a tool for that: Retrace.

2. Recording and understanding execution

An Epoch trace captured approximately 25 million instructions, covering the execution from loading the bootloader through hashing and signature verification to the final verdict. Starting from the rejection, the agent navigated backward through the execution to identify the verification logic and understand how the verdict was generated and consumed.

3. Isolating the relevant execution

Using the runtime state captured in Epoch, we created an esFirmware snapshot at the entry of the verification routine. This allowed the investigation to focus on approximately 43,000 instructions rather than replaying the entire secure boot sequence.

4. Running the fault campaign

The analyst defined an instruction-skip fault model and a clear success criterion: changing the verification verdict to ACCEPT. esFirmware then executed thousands of faulted runs in minutes.

5. Verifying the result

Despite redundant encodings and other countermeasures present in the implementation, the campaign identified a 2-byte instruction which, when skipped in emulation, changed the verification verdict.

The execution trace confirmed that the caller subsequently trusted this verdict without performing a second check.

Two Epoch traces, one normal and one faulted, provided reproducible evidence of the observed behaviour and the point where execution diverged.

This demonstrates a weakness in the modelled verification logic. Establishing whether an equivalent fault can be induced and exploited on physical silicon requires additional testing.

The full investigation, including where the countermeasures held and what we could not prove end to end, will be covered in Part 2.

‍

Why the tools around AI matter more than AI alone

There is an important distinction between asking an AI to interpret a binary and giving it the means to investigate one.

An AI agent looking exclusively at disassembled code may propose convincing explanations that turn out to be incorrect.

This is why the combination of tools matters:

• Static analysis helps understand what the binary could do.
• Emulation shows what it does under defined execution conditions.
• Time Travel Debugging makes that execution explorable, down to instructions, registers and memory.
• Fault campaigns allow security hypotheses to be tested against controlled modifications of execution.

AI connects these capabilities and accelerates the investigation, while the analyst remains responsible for defining the questions, interpreting results and determining whether the available evidence supports a conclusion.

‍

Making firmware security assessment more accessible

Returning to the initial challenge, security teams increasingly need ways to test firmware, document their findings and support product security assurance.

The CRA makes this particularly relevant. Its requirements include cybersecurity risk assessment, security by design, vulnerability handling and technical documentation. Other security evaluation and certification frameworks also rely on the ability to substantiate security claims with appropriate testing evidence.

The approach presented here can contribute to those activities in several ways.

For manufacturers and firmware developers, emulation-based analysis can help identify weaknesses earlier in development, before finished hardware or a complete testing bench is available. This is especially valuable for mechanisms such as boot ROM security, where correcting a weakness after production may be difficult or impossible.

For security teams evaluating third-party firmware, binary-only analysis provides a path to investigate implementations even when source code is not available. It offers a way to go beyond a static review and observe the behaviour of security-critical functions under controlled conditions.

For evaluation laboratories, agent-assisted emulation and Time Travel Debugging can reduce the effort spent reconstructing execution environments and navigating traces, leaving more time for test design, interpretation and physical validation.

For compliance and security assurance activities, reproducible execution traces help document what was tested, under which conditions and with which results.

None of this means that emulated dynamic analysis alone demonstrates regulatory conformity or replaces testing on real hardware.

In particular, simulated instruction skips do not establish the physical feasibility of a fault injection attack. Real hardware behaviour, timing and fault effects still need to be assessed.

‍

Conclusion: the complexity no longer has to sit with the analyst

Firmware security analysis using dynamic capabilities has traditionally required a significant investment just to get started. Beyond understanding the security questions, analysts needed the technical expertise to configure, operate and coordinate a complex set of tools.

AI agents are changing that.

By giving an agent access to emulation, Time Travel Debugging and fault injection capabilities, much of the operational complexity can now be delegated. The analyst defines the objectives, instructs the agent and evaluates the evidence. The agent handles much of the work required to get there.

This does not eliminate the need for security expertise. It changes where that expertise is applied.

And for manufacturers and security teams facing increasing security assurance requirements, including those introduced by the CRA, it makes deeper firmware investigation more accessible, even when the only starting point is a binary.

In Part 2, we open our secure boot case study step by step, showing how the agent navigated the investigation, from raw binary to a reproducible fault injection finding.

‍