Reverse Engineer Anything: reconstruct one behavior, then prove it matches

What the documentation establishes

The project exposes inspection workflows through MCP and a CLI; an agent uses the resulting evidence to produce and test an implementation. Source ↗

The October 7 DX-Ball checkpoint describes an analysis library and inspection utilities, with playable-game work still in progress. Source ↗

The setup flow registers the MCP server and matching instructions; the client must be restarted afterward. Source ↗

Local inspection does not imply that an agent’s tool results stay outside its model provider. Source ↗

Maurice Heumann’s October 9 report describes a separate game-decompilation effort using IDA MCP and a byte-comparison harness. It is not evidence that the REA DX-Ball project is complete. Source ↗

The walkthrough below is an original worked exercise. We have not independently tested this product’s performance.

Read the game demonstration precisely

The official DX-Ball case study describes recovery of individual functions from a Windows executable. Its October 7, 2026 checkpoint says the current builds are inspection utilities and an analysis library; playable-game work remains in progress. The sound-panning example combines instructions, callers, constants, and comparisons with original code. These are the project authors’ results, not tests performed by Current.

For your own project, make a three-column evidence note: observed behavior, explanation, and remaining uncertainty. A sprite moving correctly in one recording belongs in the first column. A general collision rule requires evidence across positions, velocities, and boundaries. If an explanation only works for the showcase scene, keep it provisional.

A second viral story: keep the projects separate

Maurice Heumann’s October 9 field report describes a separate first-person-shooter reconstruction. The author says early, readable output concealed incorrect behavior, and later work used machine comparisons. The report names IDA MCP. Current has not reproduced its results; reposts of it are one source, not several independent tests.

The useful question for the exercise here is whether your checks can reject a plausible wrong result. Do not import a claimed completion percentage from that story into the REA showcase. Keep the target, tool, author, date, and verification method attached to each claim.

Prepare the target and the analysis environment

The setup guide currently requires a supported Node.js release: 22.19 or later in the 22 series, 24.11 or later in the 24 series, or 26+. Run the documented setup command below, review its proposed configuration changes, and restart your agent. Installing only an instruction skill does not register the MCP tools. Static JavaScript inspection does not need a native decompiler; deep native analysis needs a supported provider.

Create a fresh investigation directory with separate evidence, observations, implementation, and comparisons folders. Record the artifact filename, version, platform, and SHA-256. This identity record matters when a later update changes the behavior. Keep your original read-only and work on a copy. Put unrelated application data outside the investigation directory. This directory structure is our suggested exercise organization, not a required REA configuration.

npx rea-agents@latest setup

Target: <absolute path to my authorized local artifact>
Question: How does one ball reflect from the left and right walls?
Scope: horizontal motion only; no paddle, score, art, or audio.
First record artifact identity and available analysis capabilities.
Inspect without executing the target until a runtime experiment is agreed.
For each conclusion, cite the file/function/address or observed frame.
Separate directly observed facts, inferred rules, and unresolved cases.
Do not invent missing constants. Propose the smallest discriminating test.
Deliver a behavior table and specification before implementation.

Turn observations into a specification

Choose a starting position well away from either wall, then repeat close to each boundary. Keep the same timestep and initial velocity. Record the next position and velocity, including whether the original clamps position, reflects excess distance, or lets a correction occur on the next frame. Those alternatives can look identical at ordinary speed and diverge after a large timestep.

Ask the agent to trace where each input enters the calculation and where the output is consumed. Require evidence for units: pixels versus world units, per-frame movement versus movement per second, and signed versus unsigned values. A plausible function name is not enough. If the decompiler and a runtime observation disagree, preserve both and investigate the caller or conversion. Do not silently average incompatible explanations.

Write a small specification before generating code: accepted input range, coordinate system, boundary behavior, rounding, state changes, and unsupported cases. Have the agent propose an example that would falsify each uncertain assumption. This is more useful than asking it whether its own reconstruction looks correct.

Use a comparison harness with real observations

The code below is an original toy exercise, not DX-Ball code and not a recovered REA function. It tests a deliberately simple clamp-and-reverse rule. Running it demonstrates the mechanics of a comparison harness; passing these invented examples says nothing about another game. Replace the fixture rows with measurements or an executable reference from your authorized target before claiming a reconstruction matches.

Save this as wall-check.mjs and run node wall-check.mjs. It should print three passing fixture checks. Next try a large timestep, zero velocity at a boundary, an object wider than the available playfield, and repeated contacts. Decide which inputs your specification supports. Compare sequences as well as isolated frames: a one-pixel error may accumulate into a different collision several seconds later.

import assert from 'node:assert/strict';

function step(x, vx, dt, left, right) {
  const next = x + vx * dt;
  if (next < left) return [left, Math.abs(vx)];
  if (next > right) return [right, -Math.abs(vx)];
  return [next, vx];
}

// Invented fixture expectations, NOT measurements from DX-Ball.
const fixtures = [
  { input: [5, 2, 1, 0, 10], expected: [7, 2] },
  { input: [1, -3, 1, 0, 10], expected: [0, 3] },
  { input: [9, 3, 1, 0, 10], expected: [10, -3] },
];
for (const row of fixtures) {
  assert.deepEqual(step(...row.input), row.expected);
}
console.log('3 toy fixture checks passed');

Make the result reviewable and repeatable

Your handoff should include the artifact identity, a concise specification, evidence locations, comparison inputs, expected outputs, observed mismatches, and a command that repeats the tests. Keep an unknowns section even when the first version passes. List which environment you used and which parts depend on a native provider. A future contributor should be able to tell whether a failure comes from a different artifact or a changed reconstruction.

If tools are missing, check MCP registration and restart the client. If a native investigation cannot start, inspect provider setup rather than repeatedly asking the model to guess. If only pseudocode is available, label the result a static inference. The FAQ also distinguishes local analysis from the agent’s model processing: tool results reach the agent and its provider’s data policy applies.

Reassess after either the target or REA changes. Re-run the same comparisons first, then investigate new mismatches. Keep old evidence attached to the version it describes. Expand to a second mechanic only after the first has a stable specification and independently checkable results; a full game adds assets, timing, input, persistence, audio, and platform integration that one recovered function cannot validate.

Check that your verifier can fail

Before giving an agent repeated repair attempts, make one deliberately incorrect implementation in a disposable copy of your own exercise. In the toy wall harness above, replace the right-wall result with the unchanged positive velocity. The right-wall fixture must fail. If it still passes, inspect the fixture, the loaded file, and the command before accepting any more generated code.

Then restore the implementation and deliberately alter a known expected value. The suite should fail again. These two small controls answer different questions: can the test see a behavioral error, and is it actually reading the expectation you think it is reading? They do not prove that the invented fixtures represent a real game.

Keep reference observations and the acceptance definition separate from candidate edits. In a team repository, arrange review so a worker cannot quietly redefine success in the same change it asks you to accept. If the specification genuinely needs to change, review that as an explicit decision with new evidence. A checksum stored beside a writable test file is a useful change detector, but not an independent protection if the same process can replace both.

For a real artifact, add a held-out comparison that was not used to tune the implementation. Include at least one boundary condition and one multi-step sequence. Keep input provenance and original output values. A matching binary fragment, a passing behavior test, and a convincing screen recording answer different questions; report each separately instead of calling them all a complete reconstruction.

Reference artifact and version: <fill in>
Candidate source revision: <fill in>
Acceptance definition reviewed by: <fill in>
Wrong-implementation control: <failed as expected / investigate>
Wrong-expectation control: <failed as expected / investigate>
Held-out inputs and provenance: <fill in>
Comparison result: <pass / mismatch / not run>
Remaining uncertainty: <fill in>

Guide history

Revisions preserve the original instructions. A source recheck alone does not create a new revision.

Revision 2 · Added a separate October 9 game-decompilation report and a practical check-the-checker exercise. Keeps author claims distinct from REA and preserves the original comparison tutorial.

Revision 1 · New source-linked investigation with a scoped agent brief, original comparison harness, failure analysis, and honest case-study limits.

Continue learning