REA is powerful in a specific way: it makes established analysis tools usable through an assistant, with evidence attached. It is not a universal decompiler and it does not remove the need to understand what you are looking at. This page lists what it does well and where it stops.
What it does well
- Explain how a feature is implemented. Point it at an application you are allowed to examine and ask how search, sync, clipboard handling or a file format works. REA finds the modules, functions and references, and the assistant turns them into an explanation you can verify.
- Recover structure from JavaScript and Electron apps. Modules, imports, source maps, routes, the IPC boundary between renderer and main process, native add-on relationships, and Electron fuse settings.
- Decompile native functions. With Ghidra, Hopper or IDA configured: pseudocode, assembly, strings, symbols, calls and cross-references for ELF, PE and Mach-O binaries, including several embedded architectures and 16-bit DOS through Ghidra.
- Read Android packages. Manifest declarations, classes, decompiled methods and references through JADX, decoded resources through Apktool, and device inspection through adb.
- Inspect Apple applications. Bundle anatomy, property lists including keyed archives, Interface Builder documents and entitlements, without running the app.
- Extract metadata from managed and modern binaries. .NET metadata and CIL, Go and Rust build information and dependencies, Flutter snapshot provenance, WebAssembly sections, EVM dispatch tables, SQLite schemas and rows.
- Analyse recordings. HTTP captures in HAR or SAZ form, packet captures, logic analyser recordings and recorded Linux crashes, with fields, repeated values and source locations.
- Compare builds. Diff two versions of an application to see what changed, with digests for every artifact involved.
- Observe behavior when reading is not enough. Capture a process's terminal interaction, instrument a running application with Frida, or watch a website in a real browser, on your machine, with your permissions.
What it will not do
- Defeat protections. REA is not a tool for bypassing licensing, access controls, payment restrictions or copy protection. The project's position is explicit and ours is the same.
- Produce a source tree from a binary. Decompilers return pseudocode, not the original code. Names, types and comments are gone unless symbols were kept. REA labels derived names as derived so the assistant does not present them as fact.
- Undo heavy obfuscation on its own. Obfuscated JavaScript, packed executables and string-encrypted Android apps still require manual work. REA gives you the structure and the evidence to start from.
- Install or update engines. You install Ghidra, JADX and the rest. REA detects them and tells you, through
rea doctor, what is missing. - Run on hosted assistants without a bridge. The server speaks stdio. ChatGPT on the web and Claude's remote connectors need an HTTP endpoint, which is what our dedicated REA MCP provides.
- Keep your target private from the assistant. REA does not upload anything, but everything it returns goes to the assistant you connected. Treat decompiled output as data you are sending to that provider.
Limits that come from the engines
- Format coverage follows the provider. An architecture Ghidra has no language for, such as big-endian RISC-V in the current release, is refused rather than guessed. Hopper and IDA have their own lists.
- Large binaries take time and memory. Headless Ghidra analysis of a large executable can run for minutes and hold gigabytes of heap. Startup deadlines and heap settings are configurable, and REA reports when an analysis timed out instead of returning partial code as if complete.
- Platform gaps exist. Firmware extraction, packet and signal recordings, EVM bytecode and offline ELF diagnostics are Linux-only. Windows Ghidra support is experimental.
- Incomplete results are marked, not hidden. When a parser hits something it cannot interpret, the result carries an incomplete flag. This is a feature; it is also a limit, because the assistant may need you to decide what to do next.
Limits that come from the model
REA controls what the assistant receives, not what it concludes. An assistant can still misread evidence, over-generalise from one function or skip a reference. The skill installed by npx rea-agents setup tells it to show evidence and to say what it does not know, and the output structure makes this checkable. Reviewing the evidence before acting on a conclusion is part of using REA correctly.
Limits that come from the law
Use REA only on software you own or are authorized to analyse, within the terms that apply to it. Authorized security work, interoperability research, education, preservation and understanding your own dependencies are what the project exists for. Our REA project page documents how we use it with local clients, and our how it works page describes the investigation loop.