How AI Agents Reverse Engineer Software With REA

REA lets AI agents investigate binaries and undocumented interfaces through inspectable evidence — a reconstruction earns trust only within the scope of its comparisons with the original.

Data & Attribution — The examples come from REA's published DX-Ball and Notion investigations and their linked artifacts. Comparison results are reported by those projects. We reviewed public source and test definitions; we did not independently rerun the native comparisons.

You have a program that works, but the implementation you need is hidden in an executable, a bundled application or a captured request. The task is to recover one behavior and check it against a reference. This guide follows that process from a game function to internal interfaces and HTTP APIs.

Give the agent access to the evidence

REA supplies the tools an agent uses to investigate. It exposes analysis operations through the Model Context Protocol, or MCP, and a command-line interface. For native binaries, it connects to engines such as Ghidra, Hopper and IDA. Other workflows inspect packaged JavaScript, Electron applications and recorded network traffic. The coding agent interprets the results, asks follow-up questions and can write a candidate implementation. REA project overview.

This gives the agent an investigation loop: locate the relevant code, inspect a result, identify what remains unexplained, and request the evidence needed to resolve it. A missing argument in pseudocode can lead to an instruction-level check. An address used in arithmetic can lead to a byte read. A function call can lead to its caller or callee.

The drawback: native analysis still depends on a compatible engine and target format. Decompiler output can omit or misrepresent details. REA's Ghidra documentation identifies assembly and pseudocode as analysis outputs and preserves limitations such as strings that the engine has not defined. Ghidra provider semantics.

Follow the DX-Ball calculation

The first decompiler result was insufficient to recover the behavior. In REA's DX-Ball investigation, the sound-panning helper initially appeared to take no arguments and perform a floating-point-to-integer conversion. The instruction listing exposed a stack argument and arithmetic that the pseudocode had omitted.

The investigation followed the caller to establish that the input represented a brick's horizontal screen position. It then read the referenced data to recover the multiplication constant, subtraction constant and stored scale. Each step answered a specific question left open by the previous result. DX-Ball investigation.

The maintained source expresses the recovered calculation as:

pan = truncate((1.5625 × x − 500.0) × scale)

At a scale of 1, a position of 0 produces −500, 320 produces 0, and 640 produces 500. Truncation converts the floating-point result to an integer. The source keeps the scale as a separate global value. Reconstructed sound-pan function.

Those details make the explanation reviewable. The input has a meaning established by its caller; the constants come from the executable; and the expression has outputs that can be compared with the reference.

The drawback: recognizing the calculation does not establish its behavior across every input or its integration with the game's audio system. A candidate implementation needs a separate comparison, with its input domain stated.

Verify behavior and compiled bytes separately

The sound-pan test defines 3,205 comparisons. It covers every integer position from 0 through 640 at five scales: 0, 0.5, 1, 20 and −1. That is 641 positions multiplied by five scales. The test compares the maintained C function's return value with execution of the target function; its documented scope includes the original floating-point arithmetic and conversion helper. Differential test source.

This comparison asks whether the two implementations produce the same results for the tested inputs. It is stronger evidence than a successful build or a few plausible examples because the original supplies the expected behavior.

Compiler replay answers a different question. The project also reports matching all 63 bytes of the compiled function, using its pinned historical compiler and explicitly reviewed relocations. Relocations identify references that must be mapped to their target destinations before comparing emitted code. The project's replay checks complete function extents rather than accepting a matching prefix. Compiler matching methodology.

The reconstruction's oracle matrix separates tested behavior, matching function bytes, rendering effects and a playable game. That distinction prevents a successful function check from becoming a claim about the entire executable. Verification scope.

The drawback: behavior comparisons cover their stated input domain, while byte comparisons depend on the compiler, flags and reviewed references. Neither check establishes complete application equivalence. The comparison method must match the claim being made.

Trace an interface across processes

An undocumented interface may be spread across several parts of an application. REA's Notion example follows a clipboard operation through four stages:

1. The API exposed to the page.
2. The preload wrapper that sends an IPC request.
3. The main-process handler that receives it.
4. Electron's system-clipboard writer.

The shared channel name connects the sender and receiver. Reading the wrappers reveals how the arguments travel, and the main-process handler includes a sender check before passing data to the clipboard writer.

The case study supplies locations in Notion Desktop 7.6.1's packaged JavaScript. It separately identifies cached web-module probes used to investigate structured clipboard data. Notion clipboard investigation.

For this kind of investigation, follow one operation across its boundaries and retain the source location for each handoff. That produces a trace a reviewer can inspect: which API is called, what message it sends, who receives it and what happens next.

The drawback: static code relationships establish possible paths. Extracted-module probes establish behavior under their harness. Neither establishes every live desktop interaction, and this internal clipboard trace does not establish Notion's remote HTTP API contract.

Investigate an undocumented HTTP API

Start with the interaction that produces the request. A search, filter change or next-page action gives a request a purpose. Its caller can explain how parameters are constructed and how the response is consumed.

REA's JavaScript workflows can trace endpoint candidates, request construction and response consumers. Its documentation distinguishes static relationships from runtime observations and preserves unresolved dynamic behavior. That matters when a bundle contains routes that are never exercised in the interaction under investigation. JavaScript feature tracing.

Captured traffic supplies another kind of evidence. REA can inspect a saved HAR file or a supported native mitmproxy capture without contacting the recorded URLs. The result preserves recorded requests, responses and exposed payloads, together with their locations and limitations. Missing capture content remains a gap in the evidence. Historical network captures.

An existing browser session can also provide observations through Chrome's debugging protocol. Capture options matter: JSON and WebSocket shapes describe paths, types and counts rather than supplying actual values. A shape suitable for comparing structures may be insufficient for reproducing a particular response. Browser observation.

A practical first contract can have three expectations: the request carries the selected filter, the response exposes the fields the client consumes, and advancing the page changes the returned results in the expected way. These are proposed checks for a bounded investigation, not a claim that three checks establish complete compatibility.

The drawback: one successful interaction does not establish expired-session behavior, empty results, error responses, write semantics or future stability. An inferred client needs further permitted comparisons for the behaviors it will depend on.

Keep observations and interpretations distinct

An explanation should carry enough context to be checked. REA's evidence schema records the target digest, provider, operation, parameters, results, locations and limitations. It also distinguishes observed, derived and inferred findings. Evidence schema.

These distinctions help a reader assess a conclusion. A byte read establishes the bytes returned from an address. Interpreting those bytes as a constant adds meaning. Calling that constant an audio scale requires the surrounding arithmetic, callers or behavior to support the interpretation.

When reviewing an agent's explanation, ask for the artifact location supporting each important claim and identify the comparison that would resolve each consequential unknown. This makes the next investigation step specific.

The drawback: provenance identifies the evidence being discussed; it does not make an interpretation correct. A digest cannot substitute for a behavior comparison, and an evidence identifier cannot establish facts outside the referenced result.

Watch a REA walkthrough

This independent REA walkthrough by Rob Shocks is useful companion viewing for the investigation workflow.

The drawback: a video follows a particular setup and version. Check REA's current provider documentation for your target and platform; the article's comparison claims come from the linked source and test artifacts.

Start with one question you can test

Choose a behavior with an accessible reference. Suitable first questions include a numeric conversion inside a binary, an internal message handoff or one read-only HTTP interaction. Define what input is supplied and what output or state change should be observed.

The human contribution is to select the target, provide domain context, decide which observations matter and judge whether the comparison covers the intended use. The agent can then investigate a bounded question and produce an explanation or candidate implementation that can be reviewed against those expectations.

The drawback: when the original behavior cannot be observed, the result may remain an explanation or hypothesis. Increasing the amount of generated code does not supply the missing reference.

Pick one function or endpoint, write three observable expectations, and identify the original result that can check each one. Record a comparison result for all three expectations before expanding to a second function or endpoint.