Build a reverse-engineering studio: REA, oracles, and clean-room loops

This page is an operator / tooling guide for assembling a reverse-engineering studio: one MCP analysis core (morluto/rea), a ring of open-source engines and bridges, three oracle types that decide what is true, and a two-room clean-room loop (Room A writes SPEC.md; Room B builds from the wall only). It is not a crack tutorial, not an exploit PoC, and not permission to analyze software you do not own or lack written authorization for (/compliance/, /faq/legal-boundary/).

Chinese twin: /zh/blog/rea-reverse-engineering-studio/. New to REA? Start with /blog/rea-beginner-guide/, the install demo /docs/install-demo/, then the visual workbench path /blog/eleven-rea-workbench/. Teaching pin on this site: [email protected] (/blog/rea-agents-6-5-0/) — do not default teaching labs to floating latest.

Why a “studio” instead of a single tool

Real RE jobs span formats (PE/ELF/Mach-O, APK/DEX, .NET, JS/Electron), surfaces (static, dynamic, network), and verification (rebuild + oracle). One GUI never covers every lane. A studio is a deliberate stack:

Stars are popularity snapshots, not doctor-green proofs and not legal cover (/blog/evaluating-rea-claims/).

Category tables (GitHub API snapshot 2026-10-18)

Star counts below were re-fetched with gh api repos/OWNER/REPO --jq .stargazers_count on 2026-10-18 (Asia/Shanghai / UTC+8). Re-fetch before you quote; numbers drift.

01 — Analysis core

REA does not ship Ghidra or IDA. Setup registers MCP and may offer Hopper with approval; Ghidra/IDA stay bring-your-own (/faq/setup-vs-providers/). Upstream quick start: npx rea-agents setup (morluto/rea README). On rea.run we pin the teaching equivalent: npx -y [email protected] setup.

02 — Mobile & apps

03 — Binary & low-level

04 — Network & runtime

05 — Rebuild & verify (maps + loop)

Three oracle types

An oracle is any check that compares your reconstruction to a reference you trust. The model proposes; the oracle decides. Studio teaching uses three kinds:

Pick the strongest oracle you can automate. Byte oracles catch instruction-level drift; behaviour oracles catch API contracts; runtime oracles catch integration gaps. Many studio jobs combine two or more.

Also test the oracle (TH08 lesson)

A weak compare can pass instruction bytes while float constants are wrong. Public reconstruction write-ups on the TH08 line describe a helper that already passed exact instruction-byte compare, then failed downstream: the rebuild checked player power against 0.0 while the original used 128.0 (maximum-power threshold). The comparator remapped addresses before comparing instructions (rebuilds may place constants elsewhere) but never checked the floating-point value at that address. Instruction bytes matched; meaning did not. Auditing floating-literal references after fixing the compare surfaced more wrong constants that a weaker oracle had already “accepted.”

Habit: before you trust a green run, plant three must-fail variants. If any planted failure passes, the oracle is broken — and every prior green result is suspect.

Planted-failure checklist

• [ ] Change one constant (e.g. threshold 128.0 → 0.0, or scale 100 → 10).
• [ ] Swap one branch (true/false arms, ×÷ vs +− percent rule, early-return polarity).
• [ ] Off-by-one boundary (inclusive/exclusive edge, length−1, loop limit).
• [ ] Run the oracle on each planted variant → all three must fail.
• [ ] If any planted variant passes → fix the oracle first, then re-audit prior accepts.
• [ ] Record the three variants + oracle command in NOTES.md / CI so the check is repeatable.

No exploit or cracking steps belong in this checklist — only self-tests of your verification harness on authorized fixtures.

Two-room clean room (SPEC.md is the wall)

Classic clean room, run by agents:

binary (authorized) → Room A (REA + Evidence) → SPEC.md (wall) → Room B (rebuild) → oracle (+ planted failures) → retry

Copy-pasteable prompt templates (pin 6.5.0)

Setup (teaching pin — not floating latest):

Install REA and connect it to this coding agent using npx -y [email protected] setup.
Show me the setup plan for approval, then verify with:
npx -y [email protected] doctor --json

Room A — reader:

Use REA to investigate how [feature] works in [authorized app].
Tag every claim as observation, inference, or unknown, and cite Evidence.
Then write SPEC.md: behaviour, inputs, outputs, edge cases, and open unknowns.
Describe what it does. No code, no addresses, no names or assets from the original.

Room B — builder:

Build [feature] from SPEC.md in ./my-version.
Write tests from the behaviour in the spec and run them.
Do not open the original binary, decompile, or Room A notes.

Goal-shaped stop condition (adapt to your agent’s goal tool):

/goal every case in SPEC.md passes in ./my-version, the oracle rejects all 3 planted failures,
and no file outside ./my-version was changed. or stop after 25 turns.

Planted failures:

Add three deliberately wrong variants under ./oracle-tests: change one constant,
swap one branch, shift one boundary by one. Run the oracle on each and confirm
all three are rejected. If any passes, fix the oracle first.

NOTES.md wrap-up (factory memory):

Before ending this session, update NOTES.md with what was confirmed, what is still
unknown, which checks exist, and the next experiment to run. Commit it.

Clean-room loop checklist

• [ ] Scope gate: own / written authorization / open source / clean-room fixture (/compliance/, /faq/legal-boundary/).
• [ ] Isolate: disposable copy; never overwrite the only production artifact.
• [ ] REA pass: pin npx -y [email protected]; doctor --json; Evidence — not vibes.
• [ ] SPEC.md wall: observable behaviour + IO + edges + explicit unknowns; no code/addresses/original-name assets.
• [ ] Room B rebuild: clean tree; SPEC only.
• [ ] Oracle + planted failures: measurable pass/fail; three must-fail variants rejected.
• [ ] Retry: feed diffs back into Room A / SPEC; do not invent unknowns.
• [ ] Stop rule: document gaps — no CVE chains, keys, or DRM bypasses.

Worked teaching examples: /showcase/dx-ball/ · /blog/rea-beginner-guide/.

Clean room vs the “decompiled some package” myth

A common story claims popular clean-room apps were built by “decompiling the vendor suite.” The useful rule is the opposite: observe behaviour + public specs; forbid reading vendor app packages. Understanding ≠ taking.

Public example of the rule set: FilmCraft AGENTS.md (§2 Clean-room code: never read/disassemble/copy Adobe application bundles; observe behaviour by using the app; codecs from public specs). Related ArtCraft-family apps follow the same spirit — behaviour and public formats, not vendor package guts. Link those AGENTS/READMEs when you teach; do not treat social claims as evidence of package theft.

Boundaries (REA disclaimer ↔ models)

REA’s own disclaimer frames allowed research / education / interop / preservation / auditing of software you own or may examine — and forbids DRM / anti-cheat circumvention, copying proprietary protected code and assets, and similar abuse. Models may refuse or re-route out-of-bounds tasks; that is expected, not a broken install.

Site pages: /compliance/ · /faq/legal-boundary/. An agent output is not a license to the original program, its data, or its name.

Minimum start path + doctor deepen

Upstream Quick start documents npx rea-agents setup. rea.run teaching equivalent — always pin 6.5.0 unless a release note forces otherwise:

# Node.js 22.x (>=22.19), 24.x (>=24.11), or 26+ per upstream README
npx -y [email protected] setup
npx -y [email protected] doctor --json
# Restart your agent after approving MCP registration

# Optional: client-scoped doctor (example client id — use yours)
npx -y [email protected] doctor --client claude_code --json

# Optional: native lane — BYO Ghidra 12.x + 64-bit JDK 21+
export GHIDRA_INSTALL_DIR=/absolute/path/to/ghidra_12.1.4_PUBLIC
export JAVA_HOME=/absolute/path/to/jdk-21
npx -y [email protected] doctor --provider ghidra --json

Install UI walkthrough: /docs/install-demo/. Version notes: /blog/rea-agents-6-5-0/. Ghidra/IDA remain BYO (/faq/setup-vs-providers/).

Suggested studio layouts (pick one to start)

GUI companion (optional): /blog/eleven-rea-workbench/ — visual IDE around engines; still authorized targets only.

Common pitfalls

How this fits the rea.run teaching path

1. Vocabulary + Evidence: /blog/rea-beginner-guide/
2. Pin 6.5.0: /blog/rea-agents-6-5-0/
3. Install demo: /docs/install-demo/
4. Optional GUI: /blog/eleven-rea-workbench/
5. This page: studio ring + oracles + two-room clean-room
6. Practice: /lab/ · /showcase/dx-ball/

Compliance

• Analyze only software you own, have written authorization for, open-source you may study, or clean-room teaching fixtures.
• No crack, keygen, DRM-bypass, or exploit PoC content on this page.
• Commercial engines (IDA, Hopper, JEB, …) remain BYO under vendor licenses; REA grants no license keys.
• Stars and awesome-list placement ≠ permission.
• Clean-room = behaviour + public specs; not reading vendor app packages.
• rea.run is a community operator guide; the existing footer disclaimer stays — no extra prominent banner.
• Media under /media/blog/rea-reverse-engineering-studio/ are hosted for this article (studio walkthrough video + cover still).

Sources

• REA: morluto/rea (README Quick start; site pin [email protected]; DISCLAIMER)
• REA author’s public awesome list: morluto/awesome-reverse-engineering (765★, 2026-10-18)
• Graded AI×RE map: zhuyansen/awesome-ai-reverse-engineering (8★; README 119 graded repos on fetch day)
• Clean-room AGENTS example: storytold/filmcraft AGENTS.md
• Engine / bridge repos in the tables (GitHub API stars 2026-10-18)
• On-site: /blog/rea-beginner-guide/ · /blog/eleven-rea-workbench/ · /docs/install-demo/ · /showcase/dx-ball/ · /compliance/ · /faq/legal-boundary/ · /zh/blog/rea-reverse-engineering-studio/

FAQ