REA: Evidence-Centered Reverse Engineering

Overview

REA shows how an AI agent can move from a concrete software feature question to a defensible reconstruction or comparison. Across native binaries, JavaScript and Electron graphs, managed assemblies, packages, firmware, browser targets, and process runs, the series connects target identity, provider choice, bounded observations, and Evidence. Its core boundary is explicit: static structure, inference, and runtime behavior remain distinct, so unresolved paths, partial coverage, and operational limits stay visible.

Learning outcomes

REA links feature questions to target-bound Evidence instead of treating a tool output as a conclusion.
Provider identity, analysis profile, coverage, and authority determine what a result can support.
Static graphs and decompiled representations guide reconstruction but do not prove runtime execution or original source.
Unknowns, ambiguity, partial coverage, and cleanup limits should remain visible and drive the next check.

Keywords

REAEvidenceprovenanceprovidersdecompilationapplication graphruntime observationreconstructionreproducibilityProcess Capture

Chapters

REA: Evidence, Not Guesswork

From feature clues to defensible relationships

9m · From feature clues to defensible relationships

REA Evidence Model: Facts and Limits

Separate facts, inference, and unknowns

9m · Separate facts, inference, and unknowns

REA: From Question to Investigation

Narrow uncertainty with evidence-bearing actions

10m · Narrow uncertainty with evidence-bearing actions

10m

REA Architecture: One Interface, Many Engines

Keep ownership and provider boundaries visible

10m · Keep ownership and provider boundaries visible

10m

REA: Every Result Has a Producer

Read claims through target, profile, and Evidence

9m · Read claims through target, profile, and Evidence

REA: Deterministic Provider Choice

Bind one engine and profile without silent fallback

9m · Bind one engine and profile without silent fallback

REA: Native Behavior Tracing

Connect clues to typed code relationships

9m · Connect clues to typed code relationships

REA: Application Graphs and Runtime Boundaries

Trace modules, IPC, and routes without execution

9m · Trace modules, IPC, and routes without execution

REA: Static Artifacts to Behavioral Experiments

Keep identity and authority across provider handoffs

9m · Keep identity and authority across provider handoffs

REA: A Trustworthy Reverse-Engineering Workflow

Choose authority, verify claims, preserve unknowns

13m · Choose authority, verify claims, preserve unknowns

13m

Preview every chapter · Unlock full text, audio, and video from chapter 4

Plans

Ch.1-3 FreeCh.4-10 Premium

FAQ

What is REA used for?

REA is used to investigate software features and behavior when source is unavailable or insufficient. It connects native, application-graph, artifact, browser, managed, and process observations so an agent can build or compare a bounded reconstruction.

How does REA keep reverse-engineering evidence trustworthy?

REA keeps evidence trustworthy by attaching target identity, producer, authority, coverage, confidence, and limitations to results. It separates direct observations from derived relationships, runtime events, and reconstruction.

Does REA prove that a statically found code path executed?

No. REA treats static routes, decompiled output, and application-graph relations as evidence about structure; runtime reachability requires a separately authorized observation under a defined window or scenario.

How does REA choose among multiple analysis providers?

REA binds one usable deep provider and analysis profile for a target; if several are usable, automatic selection reports ambiguity instead of choosing by order, speed, or silent fallback.