The output is an evidence graph, not “the source code”
Reverse Engineer Anything, or REA, became one of October's loudest developer projects. The focused October 20 scan recorded 337,758 GitHub stars, 1,278 open issues, an 810-point Hacker News launch discussion, and thousands of votes across reverse-engineering and AI communities. Those numbers prove attention. They do not prove that a recovered explanation is complete, that a reconstruction is lawful, or that generated code matches the behavior users depend on.
REA's useful contribution is narrower and more defensible. It gives an agent one interface to established inspection tools, runtime observation, target inventories, and structured Evidence records. Instead of copying snippets among a decompiler, debugger, browser inspector, and chat window, the agent can ask a sequence of bounded questions and retain how each answer was reached. The official project explicitly says it does not recover original source code or automatically clone an application.
That distinction should define the operating model. A decompiler produces a representation. A runtime trace observes one executed path. A string search finds a clue. An agent connects those artifacts into a claim. None of those stages alone establishes semantic equivalence. The claim becomes useful only when a reviewer can identify the exact target, inspect the cited observations, understand what was inferred, replay the procedure, and see what remains unknown.
The unit of trust is not the agent's explanation. It is a claim bound to an authorized artifact, cited observations, a replay path, and an explicit uncertainty state.
This is also why “reverse engineer anything” is a dangerous acceptance criterion. Reverse engineering an owned Electron app to recover a lost export path is different from analyzing untrusted firmware, a proprietary competitor, a mobile service, or a cryptographic protocol. Tool capability, authorization, isolation, evidence standard, and release authority change with the target. A good platform forces those differences into the contract before the first tool call.
REA is an orchestration and evidence layer over different observation planes
REA currently spans several distinct planes. Native analysis can use Hopper or a configured Ghidra installation. Managed and JavaScript targets expose different inspection primitives. Browser and Electron workflows can combine source maps, accessibility data, console events, payload summaries, and runtime observation. The CLI and MCP interface let an agent route among these tools while returning structured results.
authorized target + immutable digest
|
inventory and safe triage
|
static | runtime | interface
|
evidence envelopes
|
claim graph + gaps
|
independent replay
|
reconstruction release gateStatic evidence includes file format, sections, strings, symbols, references, disassembly, pseudocode, control flow, imports, and data layouts. It can show that a branch or call exists. It may not show that the branch executes under the relevant configuration, that a server enables it, or that the recovered types are correct.
Dynamic evidence includes process events, network exchanges, UI transitions, inspector output, and controlled traces. It can show what happened in one environment and input path. It may miss dormant behavior, alternate accounts, feature flags, timing races, error handling, or anti-analysis behavior. Observing one success cannot prove universal behavior.
Interface evidence records externally visible behavior: inputs, outputs, timing, error states, accessibility structure, file changes, or protocol messages. It is often the safest basis for compatibility work because a clean-room implementation can target an observed contract without copying an internal representation. It still needs representative tests and an authorization decision.
The official Ghidra adapter illustrates why provider boundaries matter. REA pins a supported Ghidra and JDK combination, runs headless analysis, checks imported-byte digests, separates read-only operations, authenticates transport, and publishes verification commands. Windows support is explicitly narrower than Linux and macOS. These are valuable controls, but they are provider-specific. They do not automatically secure every plugin, target, debugger, or agent process attached to the workflow.
| Plane | Strong evidence | Typical blind spot | Required check |
|---|
| Static binary | Instruction, reference, string, import, layout | Runtime reachability and environment | Digest, tool version, address, replay |
| Dynamic process | Executed path and observed state change | Unobserved branches and timing | Controlled fixture, input, trace, isolation |
| Browser or Electron | UI event, payload, console, source-map relation | Server behavior and hidden flags | Account, build, network, and session scope |
| Agent synthesis | Cross-artifact hypothesis and next test | Unsupported causal story | Claim citations, counterevidence, reviewer |
| Reconstruction | New code passing independent behavior tests | License, security, and maintainability | Clean handoff, provenance, release gate |
Make every investigation declare its authority, artifact, method, and uncertainty
An investigation contract should be signed off before analysis. It names the target, approved purpose, forbidden actions, environment, data restrictions, tool versions, and retention rules. The agent may propose a plan, but it must not expand the target or enable active behavior because a clue looks interesting.
version: 1
investigation_id: RE-2026-104
authorization:
owner: product-security
basis: owned-device-firmware-recovery
target_scope: [firmware.bin]
forbidden: [credential-access, third-party-services, persistence]
target:
sha256: 4b6e...d91a
acquired_at: 2026-10-20T01:20:00Z
environment:
isolation: offline-vm-snapshot
network: denied
tools: [rea-agents@6.5.0, ghidra@12.1.4, jdk@21]
evidence: {require_replay: true, preserve_counterevidence: true}
release: {reconstruction_separate_team: true, human_approver: security-lead}Artifact identity is the root. Hash the original input, any unpacked child, analysis database, capture, source map, generated report, and reconstructed output. If the target updates, start a linked investigation rather than silently continuing. Otherwise a reviewer cannot know whether an address, string, or observed message belongs to the same build.
Claims need states. Observed means the record directly contains the fact. Derived means a deterministic transformation produced it. Inferred means an analyst or model connected evidence into a hypothesis. Contradicted means credible evidence conflicts. Unresolved means the evidence is insufficient. The model must not upgrade an inferred claim to observed because several clues agree.
{
"claim_id": "CL-17",
"claim": "the export command writes an SQLite backup",
"state": "inferred",
"target_sha256": "4b6e...d91a",
"evidence": ["EV-91:string_xref@0x14008af20", "EV-104:runtime_file_event"],
"counterevidence": ["encrypted export path not exercised"],
"replay": "rea evidence replay EV-91 EV-104 --json",
"reviewer": null,
"disposition": "needs negative-path fixture"
}Citations must point below the report level. “Ghidra found this” is not enough. Record the binary digest, image base, procedure or address, operation, tool build, configuration, output digest, and surrounding limitations. Runtime observations need exact inputs, account state, environment, timestamps, event order, and capture identity. A screenshot without state and sequence is a picture, not a reproducible observation.
Counterevidence is first-class. If static analysis suggests a local permission check while runtime traces show a server rejection, retain both. If two decompilers recover different types, preserve the disagreement. The fastest way to make an agentic investigation unsafe is to optimize the report for a coherent story.
Replay is the acceptance test. Another operator should be able to create the supported environment, supply the pinned target, run the bounded procedure, and obtain equivalent evidence. Equivalence does not mean byte-identical model prose. It means the same underlying observations, claim state, and unresolved gaps.
Choose tasks by evidence accessibility, not by the drama of the target
Current community examples show real value: developers report investigating earbuds firmware, AirPods calibration, smart-glasses protocols, and an LG webOS media stack. They also show the hype boundary. In the focused scan, a suggestion to reverse engineer CUDA drew the most-upvoted objection: even with AI assistance, that is a multi-year systems effort. The right question is not whether an agent can open the file. It is whether the team can define a bounded claim and verify it.
| Task | Fit | Why | Acceptance evidence |
|---|
| Recover behavior in your own legacy app | Good | Clear authority and testable outputs | Owned artifact, traces, regression fixtures |
| Document a file format for migration | Good | Bounded inputs and deterministic cases | Corpus, parser tests, malformed fixtures |
| Malware triage | Conditional | High value but hostile execution risk | Offline sandbox, no active callbacks, analyst review |
| Compatibility implementation | Conditional | Can use observed interface behavior | Legal approval, clean-room split, independent tests |
| Copy a competitor's feature | Poor | Authorization, contract, and contamination risk | Stop unless qualified review approves a bounded path |
| “Rebuild CUDA” | Poor | Vast hardware, compiler, and ecosystem surface | Decompose into a narrow compatibility claim first |
Start with one claim. “Find where version 4.2 stores the export preference” can succeed. “Explain the whole application” invites an attractive but untestable narrative. Require a maximum tool budget, maximum artifact scope, explicit stop conditions, and a human checkpoint before active instrumentation or target mutation.
Use negative fixtures. If the claim is that a flag enables encryption, test the disabled state, malformed state, different account, older build, and unsupported input. If the claim concerns a protocol, replay invalid order, missing field, duplicate request, timeout, and version skew. A happy-path reconstruction is a demo; negative behavior is part of the contract.
Separate investigation from reconstruction and reconstruction from release
REA handles investigation; the coding agent may then use normal file-editing and test tools to build something informed by the findings. That handoff is where evidence can turn into contamination. The reconstruction workspace should receive an approved interface brief, behavioral fixtures, and permitted facts, not an unrestricted dump of proprietary pseudocode and internal names.
A clean-room arrangement is not automatically required or sufficient. It is a control pattern that counsel and the rights holder may choose. When used, the investigation team records observable behavior and an approved specification. A separate implementation team builds from that specification. Access logs, provenance, review, and independent tests show what crossed the boundary. Do not claim the label “clean room” simply because two folders exist.
investigation workspace
target + tools + raw evidence
|
approved facts only
v
interface specification + fixtures
|
v
reconstruction workspace
new source + dependency provenance
|
security / license / behavior tests
v
named human release decisionRelease tests should come from a source independent of the generated implementation. Otherwise the same mistaken interpretation writes both code and assertions. Cover stable behavior, error states, security boundaries, performance limits, accessibility, data migration, telemetry, and rollback. Record where parity is deliberate, where behavior changed, and where equivalence is unknown.
Security review must assume hostile targets and hostile evidence. Static files can exploit parsers. Runtime targets can detect instrumentation, spawn children, access networks, or persist. Source maps, logs, and captures can contain secrets or personal data. Pin tools, minimize privileges, use disposable environments, restrict network and filesystem access, scan outputs, and clean up every process and project.
Legal review must be target-specific. Copyright exemptions, interoperability provisions, license terms, anti-circumvention rules, contracts, patents, trade secrets, and local law can point in different directions. The U.S. Copyright Office's Section 1201 rulemaking is an official starting point, not a blanket permission. Record the actual authorization basis and jurisdiction. If the basis is unclear, stop.
Failure modes are usually evidence failures before they are model failures
| Failure | How it appears | Control |
|---|
| Target drift | Addresses and behavior no longer match | Digest every artifact; open a new versioned run |
| Inference laundering | Report states a hypothesis as observed fact | Claim states and cited records |
| Happy-path certainty | One successful trace becomes a universal rule | Negative fixtures and branch inventory |
| Provider overreach | Agent invokes mutating operations unexpectedly | Allowlist tools; human gate active steps |
| Hostile target escape | Parser or process affects the analysis host | Disposable isolation, no network, least privilege |
| Contaminated rebuild | Generated code copies protected expression or secrets | Approved handoff, provenance, review, scanning |
| Self-confirming tests | Agent writes implementation and matching weak tests | Independent oracle and reviewer-owned fixtures |
| Popularity substitution | Stars and demos replace local validation | Representative benchmark and acceptance report |
Open-issue count is another ambiguous signal. It can indicate adoption, duplicate requests, automated reports, missing triage, or maintenance pressure. Review issue classes and release cadence before using it in procurement. The same applies to community cases: a compelling post can establish possibility, but not general accuracy.
Track evidence coverage, not just conclusion count. What share of high-impact claims are observed versus inferred? How many have successful independent replay? Which target regions or paths remain untouched? How many claims changed after reviewer challenge? A report with fewer conclusions and visible gaps is safer than a comprehensive-looking map built from shallow scans.
Adopt agent-assisted reverse engineering with a fixture-first rollout
- Select an owned, non-sensitive program with source available to the evaluator but hidden from the agent.
- Define five narrow claims covering static, dynamic, negative, and error behavior.
- Freeze the binary, environment, REA/provider versions, model, prompts, permissions, and budgets.
- Require claim-level records, target digests, evidence citations, counterevidence, and replay.
- Have an expert compare claims with source and ground truth without fixing the agent's report.
- Score unsupported certainty, missed behavior, replay success, time, tool calls, and reviewer effort.
- Repeat on a changed build to test target/version handling.
- Run a reconstruction exercise through an approved specification handoff and independent tests.
- Exercise cancellation, malformed input, hostile file, provider crash, and cleanup paths.
- Approve target classes and operations separately; default new classes to denied.
Do not start with the most valuable proprietary target. Start where failure is cheap and truth is available. The first acceptance report should show precision by claim state, recall over the fixture set, replay rate, unsafe operation attempts, evidence completeness, and reviewer minutes. It should also list what the benchmark does not represent.
Production monitoring should log target identity, authorization reference, agent and model version, tool calls, provider results, claims, evidence links, reviewer changes, and final disposition. Alert when a tool or model upgrade changes claim states on frozen fixtures. Revoke a provider if cleanup, authentication, digest verification, or permission behavior regresses.
Finally, drill the stop path. Cancel during analysis, remove authorization, revoke a provider, rotate a credential, and archive an investigation. Confirm that processes terminate, temporary artifacts are removed or retained according to policy, evidence remains readable, and no reconstruction can continue on a revoked target.
The strategic payoff is not automatic cloning. It is reducing the cost of forming and testing precise hypotheses about software while keeping truth, authority, and release decisions inspectable. That is a smaller promise than the project name, and a much more useful engineering contract.
FAQ
Does REA automatically recover original source code?
No. It coordinates analysis tools and evidence. Decompiled pseudocode, recovered names, traces, and an agent's explanation are representations and hypotheses, not the original source.
What belongs in an evidence record?
Authorization, immutable target digest, tool and version, method, observation, claim state, citations, counterevidence, uncertainty, replay command, reviewer, and disposition.
Can reconstructed code ship automatically?
No. Separate investigation from implementation, use an approved handoff, generate provenance, run independent behavior and security tests, complete license and legal review where required, and require named human approval.
Are stars evidence that REA is correct?
No. The focused scan recorded extraordinary attention, but correctness must be measured on representative fixtures against expert-reviewed ground truth.
What is the best first task?
Use an owned application with a narrow behavior question, a frozen target, available ground truth, low sensitivity, and a safe isolated environment.
Sources and further reading
