REA Open-Source Tool Lets AI Agents Reverse Engineer Closed-Source Apps
A tool that lets an AI agent produce a working behavior description of a closed-source binary, evidence included, moves reverse engineering from a specialist solo activity toward something a coding agent can attempt as part of an ordinary build task.
Key Facts
- REA (Reverse Engineer Anything) is an open-source tool hosted at github.com/morluto/rea that lets an AI agent inspect software without source code and explain how its features work.
- REA works with AI agents including Claude Code, Codex, Cursor, Gemini CLI, and Grok Build through MCP or from the terminal.
- All REA analysis runs in a local environment, and native binary analysis requires Hopper, Ghidra, or IDA while static analysis of JavaScript does not.
Reporting from 2 sources: GIGAZINE, GameBusiness.jp.
Developers who want to understand how an app works without access to its source code can now point an AI agent at the binary and ask. The tool is called REA, short for Reverse Engineer Anything. It runs through MCP or a terminal and works with agents including Claude Code, Codex, Cursor, Gemini CLI, and Grok Build. The agent calls REA, REA inspects the target and reports findings with supporting evidence, and the agent uses that output to explain behavior, write code, and run tests. Analysis happens in a local environment. The project is open source and hosted on GitHub under the repository morluto/rea. Sample tasks in the documentation include asking why 200 plus 10 percent returns 220 in Windows Calculator and why the Chrome dinosaur game speeds up, then rebuilding a small version with adjustable speed.
REA ships as an open-source project with a documented target list that runs well past native executables. The analysis targets named across the project pages include Go binaries, WASM artifacts, EVM bytecode, SQLite databases, recorded Linux crashes, websites, saved network captures, .NET assemblies, Android APKs, Android devices, JEB projects, Android resources, Flutter apps, firmware, recorded packets, recorded logic signals, packages and resources, and process behavior.
- Native binaries and Go binaries: native analysis needs Hopper, Ghidra, or IDA installed.
- JavaScript and Electron apps: static analysis of JavaScript alone does not require those disassemblers.
- Websites and saved network captures: inspected for runtime behavior.
- EVM bytecode, WASM artifacts, and SQLite databases: listed among the supported targets.
- .NET assemblies, Android APKs, Android resources, and Android devices: covered through agent-driven inspection.
- JEB projects and Flutter apps: named in the target list.
- Firmware, recorded packets, recorded logic signals, and recorded Linux crashes: supported inputs.
- Process behavior and packages and resources: also listed.
Each result comes back with supporting evidence, constraints, and documentation, and the project is updated frequently with bug fixes and new features. The Windows Calculator task turned on a specific find: the percentage button calculates differently for addition and multiplication, which is why 200 + 10% gives 220. The dinosaur game task found the speed settings and update function in the running script. Both examples ended with a rebuilt small version, one calculator that works for addition and multiplication, one game with a slider for speed.
Synthesized by Yomimono from the 2 cited sources below, including Japanese-language reporting where cited, then editorially reviewed before publishing.