REA, or Reverse Engineer Anything: What It Does and How to Try It Carefully
By Deepu
I often see a feature in an app and want to know how it works well enough to build something similar. The source code is not available, the docs say little, and guessing takes a long time.
That is the gap REA tries to fill. REA stands for Reverse Engineer Anything. Its own description says it can reverse engineer anything with agents, from app behavior down to native binaries. Everything factual here comes from the project itself, its repository, README, and disclaimer file.
When I checked the GitHub API on 18 October 2026 at 10:00 AM IST, morluto/rea showed 309,890 stars and 78,444 forks, and the latest release was rea-agents version 6.6.0, published the same morning. I read a star count as attention, not proof of quality, so the rest of this post is about what the tool actually does.
What REA is
REA is a single MCP server and command line tool that connects your AI agent to reverse engineering tools. MCP is the open protocol that lets an agent call outside tools in a structured way. Instead of opening five analysis programs and copying results between them, your agent calls REA, REA runs the right analysis, and the agent gets back findings with evidence.
You can ask your agent in plain words, for example to explain how search works in a notes app and show the evidence, or run the same workflows from the terminal. Analysis runs locally. Your agent receives the results, and your model provider then handles them under its own data policy.
Setup is one command with Node.js and npm installed. You run npx rea-agents setup, choose your agents, review the proposed changes, and approve them. Setup registers the MCP server, installs workflow instructions, and keeps backups of your existing configuration. The README lists Claude Code, Codex, Cursor, Gemini CLI, and Grok Build among the supported agents. You restart your agent afterward.
I wrote recently about letting a coding agent review code from the CLI, and REA follows the same pattern. The agent is where you ask questions. REA is the specialist it calls about a program you cannot open as source.
How it works, step by step
The flow has four parts.
First, you point REA at a target and ask a question. The target can be a native binary, an extracted JavaScript or Electron app, a .NET assembly, a website, or an Android package. A focused question, such as how a clipboard feature moves data between parts of an app, beats asking for everything the program does.
Second, REA inspects the target with the right underlying tool. Deep native analysis uses an existing Hopper, Ghidra, or IDA installation, and setup can install Hopper if you approve it. Static JavaScript and .NET work reads the files you give it without running the app.
Third, REA returns findings with evidence. This is the part I care about most. Evidence means the pseudocode, assembly, module names, imports, strings, calls, and references behind each claim, plus the limits of what the tool could see. You can follow it back and judge the claim yourself.
Fourth, your agent uses the findings. It can ask follow up questions, explain the behavior, or write and test an implementation for your own project. Reading and writing stay as separate steps, and you decide whether the second step happens.
From the terminal, you can run the JavaScript analysis command against an extracted app folder or ASAR file and get modules, imports, Electron boundaries, and evidence as JSON. For regular use you can install the rea command globally and update it with rea update.
What you can point it at
The range of targets is wide, so I will group them the way I would think about my own work.
For native code, REA returns pseudocode, assembly, strings, symbols, calls, and references, using Hopper, Ghidra, or IDA. It also covers Go and Rust binaries, WebAssembly artifacts, EVM bytecode, offline ELF layout, and recorded Linux crashes, each with its own requirements and extra tools in the README table.
For everyday app code, it covers JavaScript and Electron apps, recovering modules, imports, source maps, routes, IPC, and native add on relationships. It covers .NET assemblies with metadata and CIL instructions, static only. For Android it covers APK files, connected devices, Flutter apps, and decoded resources, each with its own extra tools.
For the web and network side, it can observe websites in a Chrome family browser, read saved HAR or Fiddler captures, and summarise packet captures and recorded signals. It can also inspect firmware, SQLite databases, packages, and process behavior. Each target has different prerequisites, so check the README table for your exact case before you install anything.
REA needs Node.js 22.x at 22.19 or later, 24.x at 24.11 or later, or version 26 or later, plus npm. On Linux, several paths also need a procps compatible ps command, because REA checks process ownership before launching tools.
What good looks like, from the project showcase
The project publishes three worked examples on its site and in the README, and they show the shape of a good investigation better than any feature list.
In the DX Ball example, the investigation follows a sound call into the helper that turns position into stereo pan, inspects the instructions, and turns incomplete pseudocode into C. The README says the reconstruction passes 3,205 original x86 test cases and reproduces all 63 compiled function bytes. That is what I want from a tool like this, a claim you can count and a result you can compare against the original.
In the Notion example, the investigation finds the clipboard API in the renderer, follows it through preload and IPC into the main process, and inspects the rich clipboard format. If you build Electron apps, you know this shape well. The interesting logic often sits across a boundary, and tracing it by hand is slow.
In the TH04 example, the investigation inspects a 16 bit DOS game, recovers the angle calculations behind a bullet pattern, and compares reconstructed C++ with the historical compiler output. It shows the preservation side of this work, understanding old software nobody can rebuild from source.
Each example starts with one clear question, follows evidence through the program, and ends with output checked against the original. If you try REA, copy that shape.
In my guide to watching what AI apps and agents actually do, I argued you should be able to explain every step an agent took. The same rule applies here, only more so, because the agent is reading a program you did not write.
Where humans need to stay close
REA does not remove the human from this work. It moves the human to better questions.
You choose the target and the question. You read the evidence and decide whether the conclusion holds up, because decompiled output can be incomplete and an agent can sound sure about something it only partly saw. You also decide what happens next. Explaining a feature and writing your own version are separate decisions, and both are yours.
Some workflows do more than read files. The project explains that some run or interact with the target, attach to runtime or browser endpoints, capture network traffic, or operate on connected devices, all with your user permissions. Before you approve a plan that runs an unknown target, ask where it will run, what it can reach, and what it might change. Use a throwaway environment you can rebuild for untrusted targets.
My simple rule is this. Let the agent read widely and explain freely. Make it pause and show you the plan before it runs anything, installs anything extra, or touches a device or a live service. That one habit prevents most of the trouble this kind of tool can cause.
If you want more defender tools from GitHub, my list of security repos worth knowing includes Ghidra and other reverse engineering picks.
Risks, limits, and the legal line
I want to be plain about this section, because reverse engineering carries real legal and safety weight, and the project itself says so at length in its disclaimer.
Only analyse software you own or have clear written permission to inspect. The project states that REA is for lawful research, education, interoperability, software preservation, and analysis of software you own or are authorised to examine. Owning a copy of a file does not by itself give you permission for every operation, and authorisation to inspect a file does not automatically cover running it, intercepting its traffic, or changing a connected device. The laws and the licence of the software you analyse can also restrict reverse engineering where you live. If the work touches an employer, a client, or a paid product, get the permission in writing before you start, and keep the scope narrow and agreed.
The project also lists uses it will not help with, including getting around DRM or licence checks, bypassing authentication, accounts, or access controls on systems you are not authorised to test, and copying proprietary software or its protected code and assets. I agree with that line, and I would add the practical version. If your goal needs you to defeat a protection rather than understand a behavior, stop and rethink the goal.
On accuracy, the disclaimer is honest. Decompilation, reconstruction, and AI assisted analysis can be incomplete or wrong, and results carry no promise of accuracy, completeness, security, or legal compliance. Treat every conclusion as a lead. Check the underlying evidence before you rely on it, and test any code you write from it as carefully as you would test code from any other source.
On privacy, analysis runs locally, but your agent sends tool results to its model provider under that provider’s policy. If a target holds personal data, credentials, or captured traffic, those can travel with the results. Clean your targets and protect your captures and reports.
On licensing, REA itself is under the MIT licence, and its own code is free to use under those terms. Third party tools keep their own licences. If you use IDA Pro, Hopper, or JEB through REA, you need your own lawful licence for each one. REA gives you no licence, key, or activation for them, and its docs are explicit that trials and demos stay under vendor terms. Getting source like output from a target also gives you no rights over that target. Check the target’s terms before you publish, share, or build on what you found.
My take, and a careful first try
As a product person, the shift for me is who can ask the question. Reading binaries used to belong to a small group of specialists. REA puts a first investigation within reach of a generalist like me, in the agent I already use, with evidence I can inspect. That does not make me a specialist. It makes my first hour better spent, and tells me sooner whether I need one.
The cost of that reach is responsibility. The same run that explains a clipboard bridge for your own app can be pointed at software you have no right to open. The tool cannot tell the difference. You have to.
So here is the first try I would suggest for this week. Pick a program you own outright or an open source app you are allowed to study, and pick one small feature you genuinely want to understand. Install REA with the setup command, ask your agent that one question, and require it to show you the evidence for every claim it makes. Read the evidence yourself. Then stop, and write down what you learned, what stayed unclear, and what you would ask next. If that hour teaches you something real about software you own, you understand both the promise and the limits of REA far better than any star count can tell you.
By Deepu
Leave a comment