Closed-Source Software Is Becoming Readable Specs: An 11-Step Reverse-Engineering Workflow, and the Boundaries It Doesn't Mention

On October 7, 2026, Replit CEO Amjad Masad tweeted that AI-driven reverse engineering and decompilation are making software effectively open source. In the comments, developer @morluto posted the REA project. The article claims it shot to 110,000 GitHub stars in a few days. Project URL: https://github.com/morluto/rea

Let's clarify the concepts first. Closed-source software ships compiled machine code that is hard for humans to read directly. Reverse-engineering tools disassemble machine code, then decompile it into C-like pseudocode. The AI doesn't run the disassembler directly; it asks questions through an intermediate layer, which returns addresses, bytes, pseudocode, and call sites. REA is exactly this MCP tool layer, connecting underneath to Hopper, Ghidra, or IDA. Analysis runs locally; the article says only findings that the model needs to reason about are uploaded, and each conclusion is labeled as observation, inference, or unknown.

This workflow solves a very concrete pain point: most people open a hex editor, scroll for twenty minutes, and close it. They don't know which tool to load first, or how to turn a wall of assembly into a spec that can support reconstruction. The article breaks the process into 11 steps. The core is not letting the model read binaries at will, but breaking reverse engineering into a verifiable engineering workflow.

The first step is routing. An Electron app's JavaScript may be right there in the files, so there's no need to start a disassembler immediately. REA chooses tools by target type; the article says there are 20 target types. The second step is reconnaissance: first look at file type, number of functions, strings, and cross-references. Strings contain URLs, error messages, and feature names, which can quickly reveal what the app does. A function called 147 times is core architecture; a small helper called twice can be deferred.

The third step is decompiling hot functions. Pseudocode will have names like var_28, and the logic will be messy, but it is readable. The fourth step is to have Opus 5.5 annotate and rename variables, explain function purpose, and flag bugs left behind in the original app. The article mentions that a REA showcase restored the sound-effect call chain of the old game DX-Ball into C; the original text says it passed 3,205 original test cases and reproduced 63 compiled bytes. Showcase page: https://rea.tools/showcase

Opus 5.5 has five effort levels: low, medium, high, xhigh, and max. The article recommends medium for inspection and navigation, high for commenting ordinary functions, and max for dealing with obfuscated code and heavy pointer arithmetic. Installation requires Node.js 22+ and npm, plus a disassembly engine of your choice.

Obfuscation is the hard part. The article cites Elastic Security Labs' Tigress benchmark: across 20 tasks, the solve rate on multi-layer obfuscation is 0%. Two practical conclusions: failed attempts cost about twice as much as successful ones, so set a budget for each function; and first remove junk from decompilation output—Caveman can delete about 75% of filler content, letting the model focus its attention on the real logic.

Once there are many functions, a single chat will forget things, rename inconsistently, and contradict itself. The article recommends one controller plus multiple workers; each worker handles only one function, and the controller stitches the global picture back together. After that comes the clean room. Four rules: observe only, do not copy code; specs come from public file-format standards, not from reading a competitor's parser; all assets are self-drawn, public domain, or openly licensed, with an attribution file; separate behavior recovery from implementation—one context writes the spec, and another context implements solely from the spec. Some teams turn these four rules into automated checks on every build.

The application example is ArtCraft's 12 apps. The article says they were rewritten from scratch in Rust, run natively on macOS, Windows, and Linux, and most can also run in the browser via WebAssembly. Every action is a named command; a human click, a keyboard shortcut, and an AI agent trigger the same command. This gives the rebuild a very practical outlet: package the functionality as an MCP server, and the next person's agent can drive it just like it drives REA.

Verification cannot rely on 'it feels similar to me.' Without the original source, compare behavior: given the same set of inputs, do the original app and the rebuild produce the same outputs? The article lists six weekend-wasting mistakes: opening a disassembler for an Electron app; doing a full dump before reading; reading functions in file order; grinding through multi-layer obfuscation; letting the model copy code into the rebuild; and shipping without a parity report.

The boundaries also need to be stated. Someone in the comments claims that Anthropic has already banned using their models for this kind of reverse engineering; this claim is not sourced in the material and needs independent verification. Another reply connects it to vulnerability-disclosure timelines and warns about the security boundary after capability diffusion. What deserves more attention is the value of the workflow itself: it breaks closed-source software into readable specs, then uses behavior tests to prove the rebuild. Without that last step, reconstruction is just guessing.

If you want to try it, start with REA and a free disassembler, pick a small target first, set a budget, do reconnaissance before decompiling, and finally run behavior comparisons. Original article URL: https://x.com/i/article/2109583646684315648