REA: Give Coding Agents a Way to Inspect Existing Software
An MIT-licensed CLI and MCP server connects coding agents to reverse-engineering tools. The useful question is how well an agent can explain existing behavior with evidence.
I’m interested in tools that help agents understand software before changing it. Generating a plausible replacement is one thing. Explaining what an existing application actually does is a different job.
REA, short for Reverse Engineer Anything, gives coding agents a CLI and MCP server for that investigation. It connects them to analysis tools for native binaries, JavaScript and Electron applications, .NET assemblies, and websites. Findings include evidence and limitations that the agent can use to guide its next question. Native analysis can use Hopper, Ghidra, or IDA; the available capabilities depend on the provider and host.
The current 6.4.0 release adds Android device inspection through ADB and resource decoding through Apktool. It also improves ways to inspect retained analysis evidence without loading every result at once. Those are practical improvements when an investigation is larger than one prompt.
For a team maintaining unfamiliar software, I would start with one bounded question about an application it owns or is authorized to examine. Ask the agent to explain a behavior, identify the supporting code or runtime observations, and state what it cannot establish. Compare that explanation with a known result before trusting it on a harder problem.
REA’s own code is MIT-licensed. External analysis tools have their own requirements and licenses. Static inspection and running a target are also different operations: runtime analysis can execute or interact with the application. The value I would test is whether REA makes the investigation more traceable and repeatable, not whether an agent can produce a convincing explanation.
