Suppose you like the way an app searches your notes. It works offline, returns results instantly and even handles complicated queries. You want something similar in your own product. But there is a problem: you don't have its source code.
What can you do? You could inspect the interface and guess. You could read the app's documentation, if it has any. Or you could examine the program itself, follow the calculations that make the feature work, and reconstruct the relevant behavior.
The third approach is called reverse engineering. It has existed for decades. What is changing is who performs the investigation. A coding agent can now use specialized tools to search a program, identify interesting functions, follow their relationships and test explanations against evidence.
REA (Reverse Engineer Anything), an open-source project by Morluto, gives agents a common interface to do this. It connects them to binary-analysis engines and tools for inspecting JavaScript, Electron, Android and other software. The agent asks questions, REA returns observations, and the agent uses those observations to investigate further. [1]
The distinction between an agent that guesses and one that investigates is more important than it first appears.
Why Can't We Just Read the App?
When a programmer writes software, they usually start with source code: functions, variables and files with human-readable names. A compiled program is different. A compiler translates much of that code into machine instructions, the operations a processor actually runs.
Consider a small function that adds two numbers. The source might say return a + b. The compiled program might instead contain instructions that load values into registers, add them and return the result. Those instructions are meaningful, but the names a and b may be gone.
Now multiply this problem by thousands of functions. Add compiler optimizations that merge operations, move calculations or remove unused code. A function that looks obvious in source code may be difficult to recognize in the compiled program. And, in many applications, there are several languages and layers between the button the user clicks and the operation that matters.
This is why reverse engineers use tools called disassemblers and decompilers. A disassembler turns machine bytes into assembly instructions. A decompiler tries to reconstruct readable, higher-level code from those instructions. Neither necessarily restores the original source. Names, types and even the boundaries between functions can be uncertain.
One feature, several representations
- Visible behavior: Press Export.
- Program evidence: Strings, calls, references.
- Recovered logic: Instructions, pseudocode.
- Checked account: Inputs, outputs, tests.
Reverse engineering begins with an observable behavior, but understanding usually requires tracing it through multiple representations of the program.
Traditional reverse engineering therefore involves two kinds of work. There is the mechanical work of locating functions, searching strings and reading instructions. Then there is the interpretive work of deciding what the evidence means and what to inspect next.
REA is interesting because it gives an AI agent access to the first kind of work, so it can participate in the second.
How Does REA Actually Work?
REA uses the Model Context Protocol, or MCP. Think of MCP as a common language through which an AI agent calls tools. Instead of manually opening a decompiler and copying its output into a chat, the agent can request a function's pseudocode, callers, strings or instruction listing and receive a structured result.
For native binaries, REA can connect to existing analysis engines such as Ghidra, Hopper or IDA. For other targets, it uses different forms of inspection. Packaged JavaScript and Electron apps can be mapped into modules and IPC relationships. Android APKs can be examined through a decompilation provider. Browser analysis can expose selected page and network observations. These are different techniques behind a related investigative workflow, not a single universal decompiler. [1]
Suppose you want to find a function that checks whether a supplied input is valid. You might first search a binary for a string like "Incorrect!" Then you find which part of the executable references that string. Then you inspect the surrounding function and the functions it calls. Each result gives you a more precise next question.
In REA's published DownUnderCTF investigation, searching for the challenge's acceptance and rejection messages led to a stripped function that checked 36 input characters using 26 masked sums. An agent converted those checks into equations, solved them with a script and used the original program to confirm the answer. [2]
Notice what mattered. The agent did not infer the answer from the name of the challenge. It found code that referenced the error message, read the checks and tested a candidate against the executable. That sequence turned a plausible explanation into a falsifiable one.
REA's main contribution is not that it knows what every program does. It gives the agent ways to collect evidence, maintain the context of an investigation and ask more useful follow-up questions. The tool contracts and CLI documentation describe this evidence-oriented interface. [1]
What Does a Real Investigation Look Like?
One example is an old Windows game called DX-Ball. The game was released in 1996, and a reconstruction project is rebuilding parts of it in C from the original executable. REA was used to recover individual functions and connect their instructions to readable code. [3]
One recovered calculation controls the direction of a sound when a brick is hit. If a brick is near the left side of the screen, the sound should lean left. If it is near the right, the sound should lean right. Somewhere in the executable, a screen position must be converted into a panning value.
The initial decompiler output was misleadingly sparse. It appeared to show a function returning the result of a conversion call, without an obvious input or arithmetic. But the assembly instructions revealed a value arriving on the stack, followed by a multiplication, a subtraction and another multiplication. Examining the caller and the referenced constants supplied the missing details.
The recovered calculation was:
Here, is a screen coordinate, and is a panning scale. The conversion to an integer is truncated toward zero. The caller obtains the screen coordinate of a brick from its tile index, using .
Why subtract 500? Because the multiplication turns the center of the game's 640-pixel-wide field, , into 500. Subtracting 500 shifts that center to zero. The left edge becomes negative; the right becomes positive. This is exactly the kind of explanation that becomes visible once we connect the instructions to the caller and the constants. [3]
Try changing only the offset. The two functions may still agree at a few points, especially when the pan scale is zero. Yet a broader set of inputs exposes the mistake. This is why differential testing is useful: instead of deciding whether recovered code looks plausible, compare what it produces with a reference across many cases.
The DX-Ball reconstruction reports 55 maintained C functions, 45,380 comparisons with original x86 behavior and 33 functions whose compiled bytes match the original, as of its October 7, 2026 checkpoint. The game is not yet fully playable; ball and paddle physics, power-ups and Windows integration remain work in progress. [3]
That distinction matters. Recovering one function with strong evidence is an achievement. Recovering an entire application requires understanding how thousands of functions, assets and state transitions fit together. A successful local reconstruction should not be mistaken for a complete clone.
What Have People Actually Built With REA?
REA's maintainers and associated reconstruction projects have published several concrete investigations.
01 / WINDOWS GAME
Reconstructing DX-Ball in C
A 1996 brick-breaking game is being rebuilt function by function from its executable. The project has recovered board handling, animation, particles, bonus creation and the sound-pan calculation examined above. Tests compare recovered behavior against the original binary, and some compiled functions match byte for byte.
Reconstruction repository ↗ · REA investigation ↗
02 / PC-98 GAME
Recovering Touhou 4's Bullet Patterns
Touhou 4: Lotus Land Story runs on the Japanese PC-98 platform. A source-reconstruction project is recovering the game using C++ and assembly. Its bullet-ring code reveals a compact trick: directions are stored as values around a 256-unit circle, and each bullet receives an evenly spaced offset. The group can then rotate toward the player's position.
The project's recorded compiler checks match a 2,139-byte bullet-generation section. REA helped inspect the original 16-bit function and explain how its instructions correspond to the maintained code. [4]
Source reconstruction ↗ · Investigation ↗
Why would an old game store angles in only 256 units? Computers from that era had much tighter constraints, and a one-byte angle is convenient to store and combine. If a full turn has 256 units, a ring of sixteen bullets advances by 16 units per bullet. An entire ring can be aimed at the player by adding the same offset to each bullet's direction.
03 / ANDROID
Recreating an Authenticator's Changing Codes
REA's Aegis case study starts with a released Android APK. The investigation narrows 3,077 classes to the methods that generate a one-time login code. The recovered behavior groups time into 30-second windows, computes an HMAC-SHA1 value using the account key and time counter, then formats six digits.
The published reconstruction provides an adjustable clock and checks the extracted Java methods against an independent implementation, including 133 cases and the RFC 6238 reference examples. This is a reconstruction of a known algorithm, not a claim that the app's security depends on secret code. [5]
Inspect the code and clock demo ↗
04 / ELECTRON
Tracing Notion's Rich Clipboard
Copying text from Notion looks like a single action. Inside the desktop app, the request travels from the page-facing API through an Electron preload wrapper and IPC channel into a main-process handler. That handler checks the sender before calling the system clipboard.
REA's case study follows the actual channel name, notion:clipboard:write, across the packaged JavaScript. It also explains how copied HTML can contain an identifier connecting it to richer block information held by the editor. The result is a documented feature trace, not a published alternative Notion app. [6]
Read the clipboard investigation ↗
05 / REVERSE ENGINEERING CTF
Solving a Stripped Flag Checker
A DownUnderCTF executable checked a 36-character input using 26 overlapping sums. An agent used REA to locate the checking code, read the masks and recover the equations. A small Python program using the Z3 solver then found a candidate flag.
The crucial final step was checking it against the original executable. The accepted flag produced Correct!; a deliberately changed character produced Incorrect!. Here, REA supplied the code evidence and runtime observation, while a separate solver handled the mathematical search. [7]
Is Reverse Engineering Now Just a Prompt?
It's easy to imagine an agent that takes a binary and immediately hands back perfect source code. REA's documentation describes something less magical and, I think, more useful.
A decompiler can produce convincing-looking code that is wrong or incomplete. It might infer the wrong types or miss a function argument. A string may suggest a feature's location without proving that the string is used in the relevant path. Even a correct local explanation may fail when confronted with another input or a different runtime state.
Good reverse engineering therefore requires a chain of evidence. What did the tool actually observe? Which conclusions were inferred? Can a hypothesis be challenged? Can the recovered implementation be compared with original behavior? REA helps an agent conduct that investigation, but the agent still needs to make decisions, and the results still need testing.
There are also practical limits. Static analysis sees code that exists in a package, not necessarily every path that executes. Websites may behave differently depending on account state or server responses. Obfuscation can make structure harder to recover. Native analysis needs a suitable local provider and a supported host. REA says analysis runs locally, although any evidence sent to an external model remains subject to that model provider's data practices. [1]
And, of course, the ability to inspect a program doesn't settle whether you have permission to copy or redistribute its components. Reproducing a behavior, reusing copyrighted code and examining a system you don't own raise different questions. REA's published case studies typically identify their targets and separate recovered facts from newly written implementations.
How Can You Try It?
With Node.js and npm installed, the project's current getting-started command is:
npx rea-agents setupSetup can register the MCP server with supported coding agents, install matching investigation instructions and use local analysis providers where needed. Review the changes before approving them, and restart the agent after setup. Native analysis may require Hopper, Ghidra or IDA; static JavaScript analysis does not. The exact requirements depend on the target and host. [1]
A good first question is narrow: Where does this app write the exported CSV file? Or: Which function turns a brick's screen position into a sound-pan value? A narrow question gives the investigation something testable to pursue. Ask for the code locations and evidence, not only the explanation.
Once you have a plausible answer, change an input, inspect another caller or compare the behavior with the original program. If the explanation breaks, that's useful information. It tells you where to look again.
What Does REA Change?
Much of software has traditionally been opaque once its original source is unavailable. You can see what it does, but understanding why it does it requires a specialist willing to sift through unfamiliar binaries and application packages.
REA doesn't eliminate that difficulty. It makes the tools for investigating it accessible through a coding agent. The interesting shift is that an agent can move from asking broad questions about an app to collecting specific evidence from its code, and then use that evidence to build and test something new.
There is a temptation to treat this as an automatic cloning machine. The case studies point to a better interpretation. A sound calculation can be reconstructed and tested across thousands of inputs. A bullet pattern can be recovered from 16-bit arithmetic. An authenticator's timing rule can be reproduced from an APK. But each achievement depends on asking a precise question and following the evidence until the answer can be checked.
Perhaps the important thing isn't that an AI can now look inside software. It's that looking inside can become part of an ordinary programming workflow, rather than a separate, specialized investigation.