How to Turn Opus 5.5 Into a Reverse Engineer: The Full Guide to REA, Oracles and Clean-Room Loops
s697 FUNCTIONS IN 12 DAYS. AND ONE BUG THAT PASSED EVERY TEST.
that's the real story of the reverse-engineering wave. not the stars, not the "software is done" screenshots. the bug.
on october 7 the CEO of Replit posted that pretty soon all software will be de facto open-source. a million people read it.
the next day Matthew Berman posted four words under a screenshot of a github repo: "Software is done." 3.5 million views.
the repo is REA, Reverse Engineer Anything. it gives your coding agent the tools to look inside programs you don't have the source for, down to the machine code. it's at 143.7k stars right now.
since then the timeline has been full of install guides and prompt packs. they're fine. but they all skip the part that decided whether any of these rebuilds actually worked.
in my last article I turned Opus 5.5 into a motion studio. the model wrote the frames, but the thing that made it reliable was the checks: six counters at zero, frame 0 equal to frame 720, nothing ships until both pass.
reverse engineering is the same game with higher stakes. the model reads, explains and rewrites. the check decides if any of it is true.
the people who rebuild software with agents have a name for that check. they call it the oracle.
this guide is about building around it:
part 1, the stack: what REA is, in 60 seconds, plus the 5-minute install part 2, the myth: nobody decompiled Adobe, and the rule that proves it part 3, the oracle: the check that decides what's true, and the bug that fooled it part 4, the factory: why the second game took twelve days part 5, the model: what Opus 5.5 brings, and where it says no part 6, the loop: two rooms, one spec, and a /goal that won't stop early part 7, your first run: a real feature, end to end part 8, the line: what it can't do and what you're not allowed to do
THE STACK
REA IN 60 SECONDS
REA is an MCP server plus a CLI, MIT licensed, by @morluto.
the README's one line: "See a feature you like. Understand how it works, down to the binary level."
what it actually does:
your agent asks a question about a program on your machine REA loads it into the right engine (Hopper, Ghidra or IDA for native code, its own analysers for JavaScript, Electron, .NET, APKs, websites) and returns findings every finding comes with evidence: the function, the file, the call, and what is still unknown your agent uses that to explain the behaviour, or to write and test its own version
it runs locally. the program never gets uploaded. your agent sees the findings, and your model provider's data policy applies to those.
it works with Claude Code, Codex, Cursor, Gemini CLI, Windsurf, OpenCode, VS Code, Grok Build and more. Grok Bot's connector is added from its own chat.
WHAT IT CAN READ
JavaScript and Electron desktop apps: modules, imports, IPC, source locations. no extra install native programs and games: pseudocode, assembly, strings, symbols, calls. needs Hopper, Ghidra or IDA .NET assemblies: metadata and CIL. no extra tools android APKs: classes and decompiled methods, with JADX and a JDK websites and saved HAR captures: scripts, requests, responses firmware, WASM, Go binaries, EVM bytecode, recorded linux crashes
static JavaScript and .NET analysis only reads the files. it never runs the app.
THE INSTALL, IN ONE BOX
everything here is from the official get started page.
# 1. Node 22.19+, 24.11+ or 26+
node -v
# 2. connect REA to your agent (shows a plan, backs up your config, asks before changing anything)
npx rea-agents@latest setup
# 3. restart the agent, then check
npx -y rea-agents@latest doctor --client claude_code --json
# 4. only for native binaries: Ghidra 12.1.x + a 64-bit JDK 21 or newer
export GHIDRA_INSTALL_DIR=/absolute/path/to/ghidra_12.1.4_PUBLIC
export JAVA_HOME=/absolute/path/to/jdk-21
npx -y rea-agents@latest doctor --provider ghidra --jsonor skip the terminal and paste this into Claude Code:
Install REA and connect it to this coding agent using npx rea-agents@latest setup. Show me the setup plan for approval, then verify the installation.notes that save time:
Hopper on mac or linux: setup detects it or offers to install it. on first launch, pick demo mode or your license Ghidra on windows is experimental and read-only IDA: only if you already own it REA ships fixes almost daily. rea update, or rerun setup
NOBODY DECOMPILED ADOBE
THE LINE EVERYONE REPEATED
in the middle of the REA wave, a second story got attached to it: free, open-source Adobe alternatives, and one line repeated everywhere: "they decompiled the Adobe suite".
that is not what happened. and the real version is more useful than the myth.
WHAT ARTCRAFT SHIPPED
the ArtCraft team has published twelve native apps, all written from scratch in Rust, licensed MIT or Apache-2.0:
PhotoCraft · a clean-room reimplementation of Photoshop LightCraft · a clean-room reimplementation of Lightroom FilmCraft · a clean-room reimplementation of Premiere Pro VectorCraft, EffectCraft, DesignCraft, PdfCraft · illustration, motion graphics, layout, PDFs WordCraft, GridCraft, DeckCraft · documents, spreadsheets, slides SoundCraft, CADCraft · audio and CAD
and the details are not toys:
PhotoCraft opens and saves layered PSD files. on their test set, 134 of 135 real-world files round-trip byte for byte FilmCraft ships its own H.264, HEVC, ProRes and AAC codecs, written from the public specifications every app runs on one command registry, so an agent can drive it over a CLI or an MCP server. PhotoCraft has 500+ commands, FilmCraft 650+
most are marked "in development", PhotoCraft and PdfCraft are "early alpha". early, but real.
THE RULE THAT KILLS THE MYTH
open FilmCraft's AGENTS.md, the file every human and AI contributor has to follow. section 2:
"Never read, disassemble or copy anything inside Adobe application bundles; file names and listings only. Observe behaviour by using the app."
section 1 goes further: no Adobe icons, fonts, presets or screenshots in the repo, not even traced copies. reference screenshots stay in a local folder that is never committed.
notice what that means. the oracle for FilmCraft is not Premiere's code. it's Premiere's behaviour, observed from the outside, plus ffmpeg used only as an outside test oracle, never linked or shipped.
the people who rebuilt Adobe's workflow forbade themselves from reading Adobe. that's the whole trick.
CLEAN ROOM, THE 40-YEAR-OLD VERSION
one side studies the original and writes down what it does. behaviour, not code another side builds from that description only, never seeing the original code
that's how Compaq rebuilt the IBM PC BIOS in the early 80s, and why "IBM compatible" became a market.
the courts kept backing the reading half: Sega v. Accolade in 1992, where taking code apart to make compatible games was fair use, and Sony v. Connectix in 2000, where an emulator built after studying the PlayStation BIOS was allowed because it shipped none of Sony's code.
not legal advice. rules differ by country and by the license you accepted. but the pattern is consistent: understanding is protected far more than copying.
WHERE REA DRAWS ITS OWN LINE
REA's disclaimer says it's built for security research, malware analysis, vulnerability research with coordinated disclosure, CTFs and education, interoperability, preservation, and auditing software you own or are allowed to examine.
and it won't help with:
circumventing DRM, license checks, anti-cheat or other protection game cheats or tampering with online services bypassing authentication or access controls copying proprietary software or reproducing its protected code and assets
plus the line most guides skip: source-like output "does not grant rights to the original program, its data, or the generated output".
study the original. ship your own.
THE ORACLE
WHAT AN ORACLE IS
an oracle is any check that compares your reconstruction to a reference you trust.
in reverse engineering there are three kinds, and the official REA examples use all three:
the byte oracle: compile your version and compare it to the original's machine code the behaviour oracle: feed the same inputs to both and compare the outputs the runtime oracle: build the whole program and play it, use it, watch it
in my studio harness, the six-zero smoke test and the frame 0 = frame 720 seam check were oracles. same idea. the model proposes, the oracle decides.
THE BYTE ORACLE: 63 BYTES
DX-Ball is a 1996 windows game. REA followed a sound call into the helper that decides left-right audio balance, read its instructions and constants, and the agent turned incomplete pseudocode into a small C function.
then the oracle:
3,205 test cases against the original x86 code: all pass all 63 compiled bytes of the function: reproduced
that's not "looks right". that's proven.
THE BEHAVIOUR ORACLE: 200 + 10% = 220
on the REA homepage: why does Windows Calculator show 220 for 200 + 10%?
REA pulls the percent handler out of the installed app:
0x180124949: CMP EAX, 0x5c
0x18012494c: JZ 0x180124aba
0x180124952: CMP EAX, 0x5b
0x180124955: JZ 0x180124aba
0x18012495b: MOV EDX, 0x640x5c is multiply, 0x5b is divide, 0x64 is 100. the rule:
after × or ÷: percent = current / 100, so 10% becomes 0.1 after + or −: percent = current × previous / 100, so 10% of 200 is 20, and 200 + 20 = 220
and here's the oracle part: they didn't stop at the explanation. they cross-checked the branch against Microsoft's own public source for Calculator, with the exact version recorded: Windows Calculator 11.2508.4.0, REA 4.1.0.
same page, the Chrome dinosaur game. REA reads the speed rule (start at 6, add 0.001 per update, cap at 13), then they ran the original update function as a check: 10.0 after 4,000 updates, 13.0 after 10,000.
THE BUG THAT FOOLED THE ORACLE
now the paragraph almost nobody quotes. it's from the official REA blog, written by N0zoM1z0, who rebuilds Touhou games with agents.
in TH08, a function had already passed the exact byte comparison. then a downstream console port reported a bug in item auto-collection.
the reconstructed code checked player power against 0.0. the original used 128.0, the maximum-power threshold. one constant, different game.
how did it pass? the comparison tool adjusted addresses before comparing instructions, because a rebuild can place a constant somewhere else. but it never checked the floating-point value stored at that address. the instruction bytes matched. the meaning didn't.
the fix had two halves:
fix the source, and make the comparison check the constant's actual bytes audit everything that passed the weaker check: 1,548 floating-literal references, which turned up twelve more wrong ones across five functions that had already been "accepted"
his lesson, word for word: "Test the oracle too."
if you build anything with agents, read that twice. your checks are software. they have bugs. and an oracle with a blind spot doesn't fail one function, it quietly approves hundreds.
THE FACTORY
WHY THE SECOND GAME TOOK TWELVE DAYS
the same essay has the numbers that should make every builder sit up:
TH08: the continuation of an existing community reconstruction began on 13 August. by 19 August, source for all 1,107 identified game functions. a playable linux port on 24 August TH095: started on 29 August with zero confirmed functions. by 7 September, all 697 functions had source. by 8 September, 696 were exact matches. playable on 10 September, about twelve days in TH04: a 16-bit PC-98 DOS game, four cooperating programs. the DOS reconstruction works, the 64-bit port is in progress
the second game went faster because it didn't start from zero. the checks, the notes and the fixes from TH08 were already in the repo.
THE FOUR RULES OF THE FACTORY
straight from his takeaways:
give agents autonomy over the investigation. set a goal and acceptance criteria, then let the agent pick the next experiment use the repo and git as working memory. the conversation ends, the repo doesn't let evidence decide what you claim. "unknown" is a valid answer test the oracle too
this is harness engineering, applied to someone else's binary. guides (the goal, the notes), sensors (the oracles), and a loop that keeps going until the sensors agree.
THE PART THAT ISN'T SETTLED
he's honest about the cost. the community team whose work TH08 continued now develops privately, calls AI decompilations and ports "grifters" taking from their work, and won't accept pull requests made mainly with AI.
he keeps their history and credit in his continuation and works in the open so the new work can be reviewed.
fast is not the same as fair. if you build on someone's work, credit it.
THE MODEL
WHY OPUS 5.5 FOR THIS
REA hands the agent raw evidence: assembly, pseudocode, call graphs, unresolved references. the model has to turn that into explanations that are actually right, a spec someone else can build from, and code that passes the oracle.
long runs, lots of context. the shape of work Opus 5.5 was built for:
1M token context, 128K max output $4 / $20 per million input / output tokens cache reads at $0.20 per million, 60% less than Opus 5. on long agentic runs, that's most of the bill default effort is medium
and one result from the launch post is this whole article in miniature: Anthropic had Opus 5.5 and Fable 5.1 translate HAProxy from C into Rust. both rewrites passed nearly all of HAProxy's own regression tests. Opus 5.5 finished in 9.5 hours instead of 12, at 51% less cost.
rewrite a large program, keep its behaviour, prove it with the original's tests. that's the rebuild step, with the project's own test suite as the oracle.
EFFORT, PER ROOM
reading and mapping: medium, the default writing the spec: high, because every gap in the spec becomes a bug in the build verification and anything with heavy pointer maths: xhigh or max
WHERE IT SAYS NO
Opus 5.5 ships with cybersecurity safeguards similar to Fable 5.1's. most cybersecurity tasks get re-routed to Opus 4.8, and it's much less likely than earlier models to act outside the boundaries it's been given.
in practice:
tracing a feature in an app you own, rebuilding a game routine to understand it: fine anything that looks like breaking protection, building an exploit or cracking a license: expect a re-route or a refusal
that's not your setup failing. it's the same line REA draws, from the model side.
THE LOOP
TWO ROOMS, ONE WALL
the clean room from part 2, run by agents:
room A, the reader: a Claude Code session with REA. it investigates and writes SPEC.md. nothing else leaves this room the wall: SPEC.md. behaviour, inputs, outputs, edge cases, unknowns. no code, no addresses, no names from the decompile room B, the builder: a fresh session in a separate folder. it gets SPEC.md and nothing else. it never sees the analysis
ROOM A: THE READER
Use REA to investigate how [feature] works in [app]. Tag every claim as observation, inference or unknown, and cite the 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: THE BUILDER, ON A GOAL
this is where loop engineering comes in. Claude Code's /goal keeps a session working until a condition is met, and after every turn a separate model checks whether it holds. it doesn't run your tests itself, it reads what the session surfaced. so write the condition as something the tests print.
/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.one measurable end state. a stated check. a constraint. a turn limit. that's the shape the docs recommend.
THE PLANTED FAILURES
the "3 planted failures" in that goal are the TH08 lesson turned into a habit.
before you trust a passing run, give the oracle three cases that must fail: a wrong constant, a swapped branch, an off-by-one boundary. if any of them passes, the oracle is broken, and every green result before it is suspect.
Add three deliberately wrong variants of the implementation to ./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.YOUR FIRST RUN
WARM-UP: THE OFFICIAL NOTES APP
REA has a practice app: a tiny Notes app with an Export notes button.
Download https://rea.tools/examples/notes-example.zip into a new example folder and unpack it. Use REA to find what happens when I click Export notes.Show where notes.csv is written, which fields it contains, and the relevant files and lines.you get the path of one click, with a file and line for every hop: the button in the renderer, the API exposed by the preload script, the IPC message, the main process writing the CSV.
THE REAL ONE: THE % BUTTON, END TO END
all four steps, on a target that's safe and tiny.
room A:
Use REA to inspect Windows Calculator's % button. Recover the rules after +, −, × and ÷. Write SPEC.md with the rules, ten worked examples and the edge cases (0%, 100%, negative numbers, % with no previous number). No code.room B:
Build a small calculator from SPEC.md in ./my-calc. Write the ten examples as tests./goal all tests from SPEC.md pass in ./my-calc and 3 planted wrong variants are rejected by the tests. or stop after 15 turns.then the behaviour oracle: type the same ten sums into the real Calculator and compare. when they match, you've done the whole loop: read, spec, build, verify, on software you didn't write and without copying a line of it.
YOUR OWN APPS
every Electron app on your machine keeps its code in one file:
mac: /Applications/<App>.app/Contents/Resources/app.asar windows: C:\Users<you>\AppData\Local\Programs<App>\resources\app.asar linux: often /opt/<App>/resources/app.asa
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --jsonpick one feature you use every day. ask how it works. you'll learn more about software architecture in an hour than from a month of tutorials.
THE LINE
WHAT IT CAN'T DO
it can't touch the server. code that runs on a company's servers was never shipped to you decompiled code is not the original source. it's a reconstruction, which is why the oracle exists hard targets stay hard. a stripped C++ binary is a different job from an Electron app your model may refuse. some targets hit Opus 5.5's safeguards and get re-routed commercial tools need real licenses. REA gives you no IDA, Hopper or JEB license, and cracked copies are explicitly not allowed
WHAT YOU'RE NOT ALLOWED TO DO
understanding a feature and building your own version is the old, legal path. that's what clean room is.
using someone's paid feature without paying, shipping their code, or bypassing their protection is not. REA's own disclaimer says so, and Opus 5.5 will push back on it anyway.
an output is not a right. reading a program doesn't give you its code, its data or its name.
THE PROMPT PACK
setup:
Install REA and connect it to this coding agent using npx rea-agents@latest setup. Show me the setup plan for approval, then verify the installation.the reader:
Use REA to investigate how [feature] works in [app]. Tag every claim as observation, inference or unknown, and cite the evidence. Then write SPEC.md: behaviour, inputs, outputs, edge cases and open unknowns. No code, no addresses, no names or assets from the original.the builder:
Build [feature] from SPEC.md in ./my-version. Write tests from the behaviour in the spec and run them.the goal:
/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.the oracle check:
Add three deliberately wrong variants of the implementation: change one constant, swap one branch, shift one boundary by one. Confirm the tests reject all three. If any passes, fix the tests first.the 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.SOFTWARE ISN'T DONE
Berman was half right.
what ended is the idea that closed means unknowable. any feature on your disk can now be explained, with evidence, in an afternoon.
what didn't end is the difference between reading and taking. the team that rebuilt Adobe's workflow wrote a rule that forbids opening Adobe's code, and shipped twelve apps anyway.
and what decides whether any of it works was never the model. it's the oracle, and whether you tested it.
build the check first. then read anything.
SOURCES
REA (Reverse Engineer Anything) on GitHub, README and disclaimer https://github.com/morluto/reahttps://github.com/morluto/rea/blob/main/DISCLAIMER.md
REA official site: get started, guides, showcases, FAQ https://rea.toolshttps://rea.tools/get-started/https://rea.tools/guides/https://rea.tools/showcase/https://rea.tools/showcase/dx-ball/https://rea.tools/faq/
N0zoM1z0, "The industrial revolution in reverse engineering", REA blog (10 Oct 2026), and the TH08 oracle fix https://rea.tools/blog/touhou-reconstruction/https://github.com/N0zoM1z0/th08/pull/11
ArtCraft Crafting Apps, PhotoCraft, LightCraft, FilmCraft and FilmCraft's AGENTS.md https://getartcraft.com/appshttps://github.com/storytold/photocrafthttps://github.com/storytold/lightcrafthttps://github.com/storytold/filmcrafthttps://github.com/storytold/filmcraft/blob/main/AGENTS.md
Anthropic, "Introducing Claude Opus 5.5" (22 Sep 2026) and the Opus 5.5 model overview https://www.anthropic.com/claude-opus-5-5https://platform.claude.com/docs/en/models/opus-5-5/overview
Claude Code docs, /goal https://code.claude.com/docs/en/goal
Ghidra, NSA Research Directorate · Hopper disassembler https://github.com/NationalSecurityAgency/ghidrahttps://www.hopperapp.com/
Amjad Masad (7 Oct 2026) and Matthew Berman (8 Oct 2026) on X https://x.com/amasad/status/2107671204639465961https://x.com/MatthewBerman/status/2108245653843509415