A Trustworthy Reverse-Engineering Workflow

REA’s central promise is not that an agent can recover every application or replace every specialist analysis tool. It is that an agent can move from a concrete feature question to an evidence-backed understanding without losing the identity, authority, and limits of the observations along the way. The practical judgment at the end of this series is therefore simple: choose the workflow that can answer the missing question, state the claim that workflow can support, and keep the next unknown visible when the evidence stops.

The question-to-claim path

A trustworthy REA investigation starts with a question that names both a subject and a decision. “How does this application search offline?” can lead to a useful explanation, but “Which local data path turns a query into matches, and which parts must a new implementation reproduce?” is more operational. It tells the agent what behavior matters and what kind of reconstruction may follow.

The first commitment is the target. It may be a native binary, an application directory or ASAR, a managed assembly, an Android package, a firmware image, a browser page, or a declared process scenario. The target is not just an input path. It is the subject whose identity must remain attached to every later observation. A package component, extracted firmware child, managed module, and process run each have their own identity and boundary. If that identity is not clear, a later comparison or handoff can connect results that merely look related.

The second commitment is authority. Static analysis is appropriate when the question concerns admitted bytes, metadata, relationships, or candidate paths. A native provider can follow strings, references, procedures, instructions, and value relationships. A JavaScript provider can construct an application graph without executing recovered modules. A managed provider can read PE/CLI metadata and CIL without loading the assembly. An artifact provider can inventory a package or extract selected firmware contents. Each route gives the agent a different kind of fact.

A live behavior question requires a different authority. Passive browser observation can report what a selected page exposed after attachment during a bounded window. An Inspector observation can record script locations and execution-context events. A native UI scenario or Process Capture can observe a declared interaction or run under its own lifecycle. Those observations do not retroactively make static inferences into runtime facts, and a passive attachment does not authorize navigation or evaluation.

The third commitment is the provider and, for overlapping deep engines, the analysis profile. A common operation name does not mean that all providers produce equivalent results. REA’s selection policy chooses one explainable deep producer for a target, binds the semantic settings that can affect the analysis, and refuses silent fallback. Auxiliary providers retain their own identities. This is what lets a later result answer not only “what was found?” but also “who found it, under which conditions, and what could that producer not resolve?”

The fourth step is progressive investigation. Search and inventory find candidates. References, callers, callees, graph edges, and package relationships connect them. Function dossiers, decompilation, managed members, browser captures, or process observations examine the relevant region or run. Each step should reduce a named uncertainty. If it does not, it may be an attractive detour rather than useful analysis.

The final step is not necessarily a definitive explanation. It may be a reconstruction decision, a comparison, a request for another observation, or an explicit stop. REA’s Evidence model makes those outcomes compatible. An agent can implement a stable data shape while marking an unobserved error path as an assumption. It can compare two graph versions while leaving one-sided absence unknown under partial coverage. It can use a static native route to design a test without claiming that the route always executes.

flowchart LR Q["Question"] --> T["Target identity"] T --> H["Authority and provider"] H --> P["Profile or declared scenario"] P --> O["Bounded observations"] O --> E["Evidence and unknowns"] E --> D{"What decision remains?"} D -->|"Reconstruct or compare"| V["Verify the resulting claim"] D -->|"Missing material evidence"| N["Choose the next authority"] V --> C["Cleanup and preserve provenance"] N --> H

The loop is the important part. A new authority is chosen because the current Evidence leaves a material question open, not because the agent has run out of familiar commands.