YouMind
Sign in

How to Turn Opus 5.5 Into a Reverse Engineering Machine with 8 Steps (full course)

@hanakoxbt
ENGLISHOct 13, 2026
194K
139
14
15
332

TL;DR

This guide details an 8-step workflow using the REA tool and Opus 5.5 to reverse engineer software. It covers target routing, installation, reconnaissance, decompilation, handling obfuscation, swarm analysis, clean-room rebuilding, and verification.

On October 8, 2026 a repository nobody had heard of three months earlier hit number one on GitHub trending.

It is called REA, Reverse Engineer Anything, and it gives your agent a real disassembler.

**Bookmark This - if you want the long version, the full 20-lesson course on this is live at**

reacourse.xyz

It takes you from a blank terminal to a rebuild that passes its own parity tests, with every command and prompt written out. START HERE.

The reaction was the same everywhere that week.

Matthew Berman put it in three words, and 3.6 million people saw it.

https://x.com/MatthewBerman/status/2108245653843509415

REA is an open-source MCP server plus CLI that plugs into Claude Code, Codex, Cursor and Gemini CLI.

MIT license, built by morluto, first release on July 12, 2026, and three months later past 100,000 GitHub stars.

Everything runs locally, and every conclusion comes tagged as an observation, an inference, or an unknown, with the address or call site behind it.

This is the whole path from a sealed binary to a rebuild you own, in eight steps.

Hanako - inline image

Before the steps: what people already shipped with this

The tool is not the story, what landed in four weeks is.

ArtCraft rebuilt seven Adobe apps as free open-source alternatives, then went after Office with WordCraft, GridCraft and DeckCraft.

Twelve apps now, all written from scratch in Rust, native on three platforms, and all but one also run in a browser tab through WebAssembly.

On the games side the receipts are more specific:

  • Super Mario Sunshine got a native PC port: about 365 agent hours and 17.3B tokens, using Claude and Codex together
  • A Touhou game rebuilt with agents on the official REA blog: 697 functions, 696 exact matches, playable in about 12 days
  • The Aegis authenticator (3,077 classes) taken apart and rebuilt, with all 133 test cases passing
  • The DX-Ball sound-pan function rebuilt in C, passing 3,205 original x86 test cases and reproducing all 63 compiled bytes

Notice what that list is not.

Nobody cracked a license check, nobody published someone else's source.

Every one of those is a behavior recovered, written down, and rebuilt in new code.

01. Route the target before you open anything

The reason this spread is not that it reads one thing well. It reads almost everything, and it shows the evidence for every claim it makes.

https://x.com/RoundtableSpace/status/2109165852578992582

That list is also the first decision you make. The most common way to lose an afternoon is reaching for a disassembler when the target is an Electron app whose JavaScript is sitting right there.

Point REA at Electron and you get modules, imports and IPC boundaries in seconds with no engine at all, while a native Mach-O or ELF opens a Hopper database, which is the deeper path and the slower one.

Knowing which one you are in saves hours, so make it the job of your first prompt.

markdown
1I want to understand how [FEATURE] works in [APP], which lives at [ABSOLUTE PATH].
2 First tell me what kind of target this is (native, Electron/JS, .NET, Go, APK, WASM)
3 and pick the right REA tool to open it. Do not start deep analysis yet.
4 Then map it in one paragraph: what it is built with, how big it is, where you would
5 look first for [FEATURE]. Keep observations, inferences and unknowns separate.
Hanako - inline image

The part almost nobody mentions: many Unity games ship their logic as .NET, and REA reads .NET with no extra engine.

That is the whole reason a purchased Steam game goes from binary to editable C# inside half an hour.

And every Electron app on your machine is readable right now, without even launching it:

bash
1# where the JavaScript lives
2macOS: /Applications/<App>.app/Contents/Resources/app.asar
3Windows: C:\Users\<you>\AppData\Local\Programs\<App>\resources\app.asar
4 npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

02. Install it in five minutes, then add one engine

The thing that makes this work is not a clever prompt. It is a real disassembly engine wired to the agent, which is exactly how one developer described it.

https://x.com/techNmak/status/2108431092462338178

Setup registers the MCP server with your agent and installs the matching workflow skill.

It shows every change before writing anything and backs up what it touches.

node -v # Node 22.19+, 24.11+ or 26+. Versions 23 and 25 are not supported

bash
1npx rea-agents@latest setup # registers the MCP server, asks before writing
2npm install --global rea-agents # the short rea command, forever
3rea --help
4# restart the agent, then verify. doctor only checks, it never changes anything
5npx -y rea-agents@latest doctor --client claude_code --json

The restart matters more than it sounds: a terminal session has to be started fresh, and desktop apps need a full quit, because closing the window is not enough.

Then add an engine only for what you actually want to read:

One file is worth writing before your first real target: house rules in claude-md.

Only analyze what you own, tag every claim as observation, inference or unknown, cite the address behind it, and never let a recovered behavior count as done without a passing test.

bash
1# native programs and games: Ghidra 12.1.x and JDK 21 or newer
2 export GHIDRA_INSTALL_DIR=/absolute/path/to/ghidra_12.1.4_PUBLIC
3 export JAVA_HOME=/absolute/path/to/jdk-21
4 npx -y rea-agents@latest doctor --provider ghidra --json
5
6 # Android apps: JDK 17+ and jadx-headless-mcp 0.7.1
7 export REA_JADX_MCP_JAR=/absolute/path/jadx-headless-mcp-0.7.1-all.jar
8 rea inspect-android-package /path/App.apk
9
10 # smart contract bytecode, Linux x64 for now
11 rea inspect-evm-interface ./runtime.hex hex --json

03. Recon: the map comes before the code

Do not open a single function yet.

One command tells you what machine the binary runs on, how many functions are inside, and all the readable text buried in it.

That text is the fastest clue you get all day: endpoints, error strings and feature names describe the app before you read any logic.

json
1rea.open_binary { path: "/Applications/Target.app/Contents/MacOS/Target" }
2rea.binary_overview {}
3 arch: arm64
4 functions: 1,284 identified
5 entry: _main @ 0x1000051c0
6
7rea.search { query: "http" }
8 0x10004a2c0 "https://api.target.app/v3/sync"
9 0x10004a300 "Authorization: Bearer "
10
11rea.xrefs { address: "0x100012ab0" }
12 147 references -> core config loader, called everywhere
Hanako - inline image

REA counts how many times each function gets called, and that count is the cross-reference numbe

A function called 147 times is the architecture of the app, one called twice is a helper that can wait.

Sort by that number and work down, never in file order, because file order is how people lose a weekend inside a binary that had four interesting functions in it.

04. Decompile one function, then make Opus name everything in it

A decompiler turns raw machine instructions back into something close to C.

It comes out rough: names like var_28, casts everywhere, tangled branches, and rough is fine, because readable is all the model needs.

bash
1# one function by address, as JSON you can save and reuse
2rea decompile /path/to/Target 0x100012ab0 --provider hopper --json > fn_config.json
3
4# or find it by name and follow its references
5rea function /path/to/Target parseConfig --provider hopper --json
6rea xrefs /path/to/Target 0x100012ab0 --provider hopper --json

Then hand that output to Opus 5.5 and make it do the part the disassembler cannot:

markdown
1Here is decompiled pseudocode from a function with 147 cross-references.
2
31. Rename every variable based on how it is used, and state the purpose in one sentence.
42. List the data structures it reads and writes, and name the pattern it follows.
53. Rewrite it as clean idiomatic code in the language the calling conventions imply.
64. Flag any missing error handling, input validation or security check.
7
8Think at xhigh effort before answering. Mark anything you are unsure of.
Hanako - inline image

Opus 5.5 ships five effort levels: low, medium, high, xhigh and max.

Medium inspects and navigates, high annotates ordinary functions, max is for obfuscated code and heavy pointer math.

Effort is the single biggest quality knob in this pipeline, and most people leave it on default and then blame the model.

Decompilation gives you what the code does, the model gives you why, and the names to rebuild it.

05. Obfuscation: break what is worth breaking, budget the rest

Some apps are built to resist exactly what you are doing: logic shuffled, strings encrypted, fake branches added purely to waste your attention.

This is the one place even the best model struggles, and there are measured numbers for it.

Elastic Security Labs pointed Claude Opus at the Tigress scrambler across 20 tasks, and two lessons fall straight out.

A failed attempt costs roughly twice a successful one, because the model keeps pushing before it gives up, and multi-layer obfuscation came back at zero, so grinding it is the most expensive way to learn nothing.

Hanako - inline image

The practical rule is a budget per function, not per session.

Strip the filler first, because a free tool called Caveman removes about 75% of decompiled junk and the model then spends attention on real logic.

markdown
1This function looks obfuscated. Work at max effort.
2
31. Identify the techniques present (control-flow flattening, opaque predicates,
4 dead code, string encryption, function splitting) and point to each one here.
52. Resolve them: remove dead branches, evaluate opaque predicates, unflatten the
6 dispatch, decrypt inline strings if the key is recoverable. Show what remains.
73. Rate confidence 1-10. Below 6, name the uncertain parts and what context would
8 resolve them. Do not guess silently.

06. The swarm: one controller, many workers

A single chat cannot read 500 functions well.

It forgets what it saw forty functions ago, names the same struct three different ways, and starts quietly contradicting itself.

The fix is not more context, it is a split of roles: a controller that hands out work, and workers that each take one function and stop.

Hanako - inline image
markdown
1You are a reverse-engineering controller. The function map is in functions.json
2(address, name, size, xref_count).
3
41. Cluster functions by call-graph proximity; order clusters by xref count.
52. Dispatch each cluster to a worker. Never analyze a function yourself.
63. Inject already-resolved structs into each brief so names stay consistent.
74. Confidence below 6 gets a second pass with context from resolved neighbors.
85. Track cumulative token spend and report it after each cluster.
9
10You are a worker. You get one decompiled function and the structs resolved so far.
11Return exactly: address, purpose, confidence (1-10), structs_used, structs_new,
12clean_source, flags. Reuse existing struct names, never invent a second name for
13a struct the controller already gave you. One function only. Stop when done.

REA also ships guided workflows built into the MCP server that most people never open:

  • - investigate_feature - trace a feature from discovery to the exact functions
  • - compare_application_versions - diff two releases and see what actually changed
  • - verify_reconstruction - check your rebuild against the saved evidence
  • - audit_residual_unknowns - list what is still unproven

07. Clean room: the wall between two contexts is the product

A clean-room rebuild means you copy what the app does and never the code inside it.

Get it right and what you ship is fully yours, get it wrong and you are carrying someone else's copyright inside your own repository.

This is a 40-year-old method, not a 2026 invention.

In the early 80s Compaq rebuilt IBM's BIOS this way for about $1 million, which is the only reason PCs from other brands exist.

In 1992 the court in Sega v. Accolade said taking apart code can be fair use when it is the only way to understand how it works, and in 2000 Sony lost Sony v. Connectix 3-0 because the finished emulator contained none of Sony's code.

The other side of the line is just as clear: in 2011 George Hotz settled with Sony and agreed to stop after the PS3 root key went public.

Hanako - inline image

Four rules keep you on the right side, and the ArtCraft team checks all four automatically on every build:

  • - Observe, never copy. Run the target black-box, screenshot only its own window, never paste its code into your project
  • - Specs, not sources. File formats come from public standards (OOXML is ECMA-376 / ISO 29500, plus the published RTF and ODF specs), never from reading a competitor's parser
  • - Original assets only. Every icon, font, template and sound is drawn in code, public-domain or openly licensed, with a row in an attribution file
  • - Separate the two jobs. One agent recovers behavior and writes the spec, a different context implements from that spec alone

That last rule is the one people skip, and it is the actual boundary.

Your investigating agent is contaminated by definition, because it read the decompile, and your building agent must not be.

markdown
1From the completed analysis, write a clean-room specification for a reimplementation.
2
3Describe BEHAVIOR only: every public interface, the data model, each user-visible
4feature as a testable requirement, the file formats read and written, error handling.
5
6Do NOT include addresses, offsets, decompiled variable names, assembly, or anything
7copied from the original. A developer who never saw the binary must be able to
8implement a compatible version from this document alone.
9
10Sections: Architecture, Data Model, Public API, File Formats, Test Cases.

Working from a description is not only legal cover.

It lets you make the right call for your own language instead of inheriting decisions someone made two decades ago, which is why WordCraft is faster than Word in places.

08. Verify parity, then ship it over MCP

You never had the original source, so you cannot diff line by line.

You compare behavior: same inputs into both builds, same outputs back.

markdown
1Build a behavioral test harness comparing the original binary and my rebuild.
2
3Generate 50 inputs: 30 normal, 10 edge (empty, max size, unicode), 10 error
4(malformed, corrupt). Run each through both, compare byte-for-byte where possible
5and semantically otherwise. Report match rate, divergences, and a severity for each
6(cosmetic / behavioral / critical). Save to report.md.

"I think it matches" is not evidence, a match rate is, and that report is the most convincing thing you can put at the top of a release post.

Then release the rebuild the way REA and the Craft apps did, as an MCP server, so the next person's agent can drive your tool the way you drove REA.

Give every function a clear name and a one-line install, and every action becomes a named command that a click, a shortcut and an agent trigger identically.

bash
1claude mcp add wordcraft -- wordcraft-cli mcp
2
3> Open report.docx, make every heading 14pt bold, export to PDF
4 ok select.all-headings -> 12 selected
5 ok format.font-size 14 . format.bold
6 ok export report.pdf (selectable text, bookmarks kept)

The limits, and the five mistakes that waste a weekend

REA cannot touch the server, because it reads what is on your machine and code running on a company's servers was never shipped to you.

Decompiled code is a reconstruction, not the original source, which is the entire reason step 08 exists.

Stripped C++ binaries stay far harder than Unity .NET games, and commercial engines still need real licenses.

  • - Opening a disassembler on an Electron app when the JavaScript is right there
  • - Dumping the whole binary before reading a summary, which buries the logic and runs up the bill
  • - Reading functions in file order instead of by cross-reference count
  • - Letting the model copy code into your rebuild, which breaks the clean room in one paste
  • - Shipping without a parity report

The honest line on the legal side, since half of X spent a week screaming about piracy: reading an app on your own computer is learning, rebuilding a feature from its behavior is how the industry has worked since the 80s, and copying code or cracking paid features is the part that gets you sued.

Study the original, ship your own.

Every one of these eight steps has a lesson behind it at

reacourse.xyz , with the exact prompts, the failure modes, and the parts where this stops working.

Closed source used to mean you will never know.

Now it means show me the evidence.

Most people will keep paying monthly for a feature they could understand in an afternoon and rebuild in a weekend.

The few who learn to read software will build whatever they want.

Follow me and subscribe to my Telegram channel:

https://t.me/+75nMf005jRpjMDU1

One-click save

Use YouMind for AI deep reading of viral articles

Save the source, ask focused questions, summarize the argument, and turn a viral article into reusable notes in one AI workspace.

Explore YouMind
For creators

Turn your Markdown into a clean 𝕏 article

When you publish your own long-form writing, images, tables, and code blocks make 𝕏 formatting painful. YouMind turns a full Markdown draft into a clean, ready-to-post 𝕏 article.

Try Markdown to 𝕏

More patterns to decode

Recent viral articles

Explore more viral articles