REA, short for Reverse Engineer Anything, is an open-source project by morluto released under the MIT license. It gives an AI assistant a disciplined way to look inside software: compiled binaries, mobile apps, Electron bundles, firmware images, network captures and more. This page explains the idea in plain terms. The components page names the moving parts, the requirements page covers what it takes to run it, and the possibilities and limits page sets expectations.

One question, many tools

Reverse engineering is normally a toolbox problem. A disassembler for native code, a decompiler for Android, a bundle parser for JavaScript, a packet dissector for captures, each with its own interface and output format. REA sits in front of these tools and exposes them through one Model Context Protocol server. Your assistant asks a question in natural language, REA runs the right tool against the target, and the answer comes back with the code, references and unknowns attached.

The same workflows are available as terminal commands. The MCP server and the CLI share one codebase, so what an assistant can do, you can also script.

The investigation loop

A typical session looks like this.

  1. You point the assistant at a target. The target is a file or directory on the machine where REA runs: an application bundle, an APK, an executable, an extracted firmware image, a saved capture.
  2. The assistant asks REA to inspect it. First calls are broad: what kind of file is this, what modules or classes does it contain, which strings and symbols stand out.
  3. REA returns findings with evidence. Each answer carries where it came from: the file, offset, function or module, and whether the fact was read directly or derived.
  4. The assistant narrows down. It follows references, decompiles a function, traces an IPC bridge, compares two builds, until it can explain the behavior you asked about.
  5. You use the result. Explain how a feature works, reproduce it in your own code, confirm a security property, document a legacy system, or decide what to investigate next.

Nothing in this loop is magic. REA does not guess what a program does. It runs established analysis engines and organises their output so a language model can reason over it without losing track of what is proven and what is assumed.

Evidence stays visible

The design principle that distinguishes REA from a chat wrapper is that facts keep their status. Results separate what was observed in the target, what was derived from observations, and what remains unknown. When an engine cannot process a file, or processes it partially, the answer says so instead of filling the gap. Artifacts keep their digests, so a claim can be traced back to the exact bytes it came from.

For you this means an assistant using REA is less likely to invent a function name or a protocol detail. It can still misread evidence, which is why REA's output is built to be checked.

Static first, runtime when you ask

Most of REA's capabilities are static: they read the supplied files without running the program. Decompilation, symbol and string extraction, bundle and manifest parsing, and capture analysis all work this way. Static analysis is safe to run on anything you are allowed to examine and is what a hosted service can offer.

REA also has runtime capabilities for cases where reading is not enough: capturing a process's terminal behavior, instrumenting a running application, observing a website in a browser, or working with an attached Android device. These run or interact with the target using your user permissions on your machine. Each runtime guide in the upstream documentation describes its effects before you use it.

Where your data goes

REA itself does not upload the target anywhere. It reads files locally and returns text to the client that called it. That text, including decompiled code and strings, then goes to whichever assistant you connected, and that assistant's provider processes it under its own terms. Keep this in mind when the target contains secrets or personal data.

Lawful use

REA is for research, education, interoperability, software preservation and analysis of software you own or are authorized to examine. The project's disclaimer states this position for every version and distribution channel, and we apply the same rule to anything we build on it. See our REA project page for how we use REA with local clients and the dedicated REA MCP page for the hosted endpoint we are preparing.