How REA Makes Reverse Engineering an Evidence Trail

Windows Calculator can feel mischievous. Enter 200 + 10%, press equals, and the result is 220—not 200.1, which a literal percentage conversion might suggest. That tiny surprise is a perfect reverse-engineering problem: what rule is the program actually following?

How do you reverse engineer software when source code is unavailable? Traditionally, you reach for a disassembler, debugger, or decompiler and reconstruct the answer from fragments. REA, short for Reverse Engineer Anything, changes the starting point. It connects a coding agent to analysis tools, so you can ask about one behavior in plain English and receive the instructions, source relationships, constants, and runtime evidence needed to explain it. The agent is not guessing from the screen; it is following a trail through the program. (rea.tools)

Reverse engineering is detective work

Reverse engineering means learning how a program behaves by examining the program itself rather than relying on its original source code, the human-readable instructions written by its developers. A compiled program is the machine-ready form of an application; a native binary is a file containing that compiled code for a processor. When REA inspects one, it can return assembly, the low-level instructions executed by the CPU, and pseudocode, a readable approximation produced by a decompiler.

Neither view tells the whole story. A single instruction may load a value, but you still need to know where that value came from, which branch is taken, and what the called function does. A caller is the function that invokes another function; a reference is a location that points to code or data. The useful answer appears when those pieces line up with a test we can run. REA’s native-analysis workflow is built around that combination of instructions, callers, references, and constants.

That is where an agent helps. Instead of opening hundreds of screens and hoping the right address looks familiar, you give it a narrow question: “Which function handles the percent key, and what changes when the operator is plus rather than multiply?” Narrow questions produce better evidence than asking an agent to explain an entire executable in one pass.

What REA adds to the workflow

REA connects an agent through the Model Context Protocol, or MCP, a standard way for an AI application to call external tools. Its setup registers the connection and installs matching investigation instructions for a supported coding agent. The documented setup command is:

npx rea-agents@latest setup

The current guide lists Node.js 22.19+, 24.11+, or 26+ as supported lines. For native programs, REA can work with an analysis provider such as Ghidra, Hopper, or IDA. JavaScript and Electron applications—desktop apps built with web technologies—can be analyzed statically without one of those native engines, while browser investigations can observe a selected action through a local debugging connection. (rea.tools)

These routes matter because software hides behavior in different places. Static analysis means examining files without running the application; runtime observation means watching the application while it runs.

• A native binary exposes instructions, data, strings, and call relationships.
• A JavaScript or Electron app exposes modules, source locations, and IPC, or inter-process communication, which is how separate processes exchange messages.
• A browser session exposes loaded scripts, network requests, and activity triggered by a real click.

The shape changes, but the investigation stays familiar: find an entry point, follow the data, and test the conclusion.

Example: why 200 + 10% becomes 220

The percentage button is context-sensitive. In this calculation, previous is 200 and current is 10. The recovered rule can be written like this:

if operation is multiply or divide:
 percent = current / 100
else:
 percent = current * previous / 100

For addition, 10% means 10 percent of the first number:

10% of 200 = 20
200 + 20 = 220

For multiplication, the same button acts like a decimal conversion:

10 / 100 = 0.1
200 × 0.1 = 20

The interesting part is not the arithmetic. It is the path to the arithmetic. At the binary level, the handler checks operator identifiers, loads the constant 100, and calls helper routines whose original names may no longer exist in the compiled file. A decompiler can make the broad structure readable, while instructions and references supply the missing details. Microsoft also maintains a public Calculator repository, which makes it possible to cross-check the behavior without assuming every installed build is identical to the public source. (github.com)

Example: recovering a game’s speed curve

The browser case feels different because the behavior lives inside an update loop. The Chromium-derived T-Rex Runner keeps a speed value, increases it during a successful update, and stops at a maximum. Its configuration defines a starting speed of 6, acceleration of 0.001, and maximum speed of 13:

if (!collision) {
 this.distanceRan += this.currentSpeed * deltaTime / this.msPerFrame;
 if (this.currentSpeed < this.config.MAX_SPEED) {
 this.currentSpeed += this.config.ACCELERATION;
 }
}

That produces a rule more useful than “the dinosaur gradually speeds up.” Each collision-free update adds 0.001 until the cap. The number of updates matters, so this is not exactly the same as adding 0.001 per wall-clock second. A reconstruction can expose those settings as a slider while preserving the original update logic. (raw.githubusercontent.com)

REA’s browser workflow is valuable here because it can inspect the script actually loaded by a page and observe activity through a local debugging connection. Static source tells you what the author wrote; runtime evidence tells you which page, request, or branch was active during the action. Using both avoids a common trap: rebuilding a plausible rule that the running application never uses. (rea.tools)

Separate evidence from interpretation

A coding agent can produce a confident explanation even when the evidence is thin. Reverse engineering works better when every conclusion has a visible anchor:

1. Name one behavior, such as a button, file parser, or calculation.
2. Collect the relevant instructions, source locations, calls, constants, or runtime events.
3. Mark unresolved functions and assumptions instead of hiding them.
4. Rebuild the smallest version of the behavior.
5. Compare the original and reconstruction with the same inputs.

That last step is differential testing: running two implementations with identical inputs and comparing their outputs. It turns a persuasive explanation into a checked one. REA’s own case studies emphasize this evidence trail, including the unknowns that remain when analysis cannot resolve a path.

What REA does not remove

REA does not turn a stripped or obfuscated binary into perfect source code. A decompiler guesses types and structure; dynamic code can evade static analysis; an observation window records only what happens during that window. The agent may also confuse a plausible interpretation with a proven one. Good investigations preserve the original artifact, record addresses or source locations, and test edge cases.

There is also a boundary around authorization. Inspect software you own, have permission to analyze, or are studying under rules that allow it. Reverse engineering can support preservation, interoperability, debugging, education, and security work, but a tool does not grant permission to inspect or redistribute someone else’s software.

A better starting question

The promise of “reverse engineer anything” sounds enormous, but the practical method is small. Choose one button, one file format, one calculation, or one request. Ask the agent to show the path from entry point to result, keep unresolved calls visible, and validate the reconstruction against the original.

That is the real shift REA introduces. Reverse engineering remains careful technical work; dense instructions are still dense, and tricky binaries are still tricky. But instead of treating the program as a silent black box, you get an evidence trail that you and the agent can read together. A mystery like 200 + 10% becomes a branch, a constant, a formula, and finally a behavior you can reproduce.