Making the Intervention Survive Execution

FIRMENSTEIN’s semantic diagnosis is useful only if the resulting intervention can participate safely in native firmware execution. This chapter focuses on that boundary: how the Interleaved Invocation Bridge lets an intervention call native functions, trigger other hooks, and return to the original service without losing execution context. It also follows the larger lifecycle from extracted firmware artifacts to runtime feedback, so readers can see where an apparently correct repair can still fail.

The challenge is easy to underestimate. A hook is often described as though it were a small replacement function: intercept a call, compute an answer, and continue. In a user-mode emulator, however, the native binary and the intervention code may use different execution layers. The intervention may need to reuse a native helper, and that helper may itself reach another intercepted API. Registers, stack frames, return addresses, and control ownership then cross the boundary more than once. If those transitions are not managed deliberately, a semantically correct answer can still corrupt the program that receives it.

The emulator has two execution layers

Execution Interventions are meant to alter the behavior of a firmware service while it runs, not to replace the entire native program. FIRMENSTEIN therefore has to coordinate two layers. One is the native firmware instruction layer, where the service’s ordinary code and any retained native functions execute. The other is the intervention layer, where synthesized logic can inspect or change arguments, memory, and return values. The Interleaved Invocation Bridge, or IIB, connects them.

A simple hook has one direction: native code reaches a call site, the emulator intercepts it, and control moves to the intervention handler. IIB is needed for the cases in which that picture is incomplete. The handler may need to call a native function because the original implementation still contains useful logic. That native function may reach another call site with its own intervention. The second handler may need to return to the native layer, after which control must come back to the first handler and eventually resume the original caller. The system is interleaved because execution alternates between native instructions and intervention code while the logical operation is still in progress.

sequenceDiagram participant N as Native firmware participant H as Hook detector participant I as Intervention handler participant C as CPU and stack context participant F as Native function participant T as Trap return N->>H: Reach native call site H->>C: Save registers and execution context H->>I: Transfer control to intervention I->>C: Use isolated intervention stack I->>F: Redirect to native function F->>H: Reach chained hook call H->>I: Enter chained intervention I-->>F: Return to native layer F-->>T: Return through designated trap address T-->>I: Make native result available I->>C: Restore saved context C-->>N: Resume original execution

The bridge’s first responsibility is context preservation. Before an intervention invokes native code, it captures the relevant CPU state, including general-purpose registers, the stack pointer, program counter, and status flags. When the native call returns, that state is restored so the intervention can continue with the caller’s execution context intact. This does not mean that every native side effect is erased. The point is to prevent the mechanics of crossing layers from overwriting the context that the surrounding firmware expects to remain stable.

The second responsibility is stack isolation. The native function needs a stack on which to create its own frames and temporaries, but the intervention handler may already be using its stack for local state. IIB reserves a separate stack region before entering native code.