REA: Let Your AI Agent Reverse Engineer the App Features You Wish You Had

You are using an app and notice a feature that just works. Instant offline search. A clever sync behavior. A smooth update flow. You want something similar in your own product, but you have no source code, no docs, and no idea where to start.

Traditionally, the answer was "learn reverse engineering." That means picking a disassembler, learning its API, digging through strings and symbols, following call graphs by hand, and copying findings between tools. It is a deep skill, and most application developers never have the time to pick it up.

REA takes a different approach: it hands that work to your AI coding agent.

In this post we will cover what REA is, how it works, how to set it up, and whether it is worth your time.

What is REA?

REA is an open-source (MIT) tool, written in TypeScript, that gives AI agents a consistent way to investigate software. It ships as:

• A CLI (rea) you can run from your terminal
• An MCP server that agents like Claude Code, Cursor, Codex, Gemini CLI, Windsurf, and Claude Desktop can call directly

The pitch is simple: point your agent at an app, ask how a feature works, and the agent uses REA to inspect the app, explain the feature with evidence, and then build a version adapted to your stack.

The mental model: Decompile, Understand, Recreate

REA frames every investigation in three stages:

1. Decompile - open the app and recover readable code, strings, symbol names, and other clues.
2. Understand - follow the code from one part of the app to another until the agent can explain how the feature actually works.
3. Recreate - turn what was learned into a feature for your own product, in your language and framework.

One thing worth stating up front: REA does not claim to recover the original source code, and it does not clone apps. It gives the agent pseudocode, assembly, symbols, strings, and relationships, and it shows the evidence behind every conclusion.

What a real investigation looks like

Say you ask your agent:

Reverse engineer the Notes app. Find how offline search works, explain it,
and build a version for my project using TypeScript and SQLite.

Behind the scenes, the agent works through roughly these steps using REA tools:

Step	What the agent does	Example REA tools
1	Opens and identifies the binary	open_binary, binary_overview
2	Looks for search-related clues	search_strings, search_procedures, list_names
3	Connects clues to actual code	find_xrefs_to_name, xrefs, procedure_callers
4	Rebuilds the control flow	get_call_graph, procedure_callees
5	Decompiles the important functions	procedure_pseudo_code, batch_decompile
6	Writes the feature in your project	Your agent's normal editing and test tools

REA handles steps 1 through 5. Step 6 is your agent doing what it already does well: writing code.

If you have done any manual reverse engineering, you will recognize this workflow. The difference is that the agent drives it instead of you.

How it works under the hood

REA itself is not a disassembler. It is an orchestration layer that sits between your agent and real analysis tools.

Agent / Terminal
      |
      v
  REA (CLI + MCP server)
      |
      +--> Deep analysis providers: Hopper, Ghidra
      +--> Native macOS utilities (Mach-O, code signatures, plists, Swift demangling)
      +--> Artifact provider (ZIP, APK, IPA, ASAR, MSIX inventory)
      +--> Browser provider (passive Chrome DevTools Protocol observation)
      +--> Process capture provider (controlled terminal sessions)
      |
      v
  Evidence records you can export, compare, and reuse

A few design choices stand out:

• Providers do the heavy lifting. Hopper is the main deep-analysis provider, and Ghidra is supported as a read-only, bring-your-own option on Linux (plus an experimental Windows x64 mode).
• Everything produces evidence. Each successful result is stored as a structured "Evidence v2" record that includes the provider, confidence, and known limitations. You can export these bundles, import them later, and diff them across app versions.
• Unknowns stay unknown. REA is strict about not presenting guesses as facts. Static inference and runtime observation are labeled separately, and incomplete data is reported as incomplete.
• Local by design. There is no hosted analysis service. The app you analyze stays on your machine (though your AI model provider still has its own data policy).
• Same engine for CLI and MCP. Whatever your agent can do, you can also do from the terminal.

What it can analyze today

Native binaries get the deepest support, but REA covers more than that:

• Native apps: Mach-O, ELF, PE, and macOS .app bundles, including Swift and Objective-C metadata
• Packages and archives: ZIP, APK, IPA, ASAR, plus file-level inventory without extraction
• Electron and JavaScript apps: static mapping of entry points, modules, IPC channels, preload scripts, and source maps, without executing anything
• Websites: passive observation of a browser you already control, over a local Chrome DevTools endpoint
• .NET (managed PE/CLI): execution-free triage of metadata, members, and native boundaries
• Version diffs: compare two releases of an app and get a report of what changed

Getting started

Requirements

• macOS 12+, or Ubuntu 24.04+, Fedora 41+, or 64-bit Arch Linux (Windows x64 is experimental and Ghidra-only)
• Node.js 22.19+ or 24.11+
• A deep-analysis provider: Hopper (setup can install it, and the free demo mode works) or your own Ghidra 12.1.2 with JDK 21

Install and run setup

The quickest path:

npx --yes rea-agents@latest setup

Or install the CLI globally:

npm install --global rea-agents
rea setup

Setup is careful. It detects which agents you have installed, asks which capabilities you want, shows the exact files it will change, and defaults to "No" before applying anything. Use rea setup --dry-run if you want to preview the plan first.

When setup finishes, restart your agent so it picks up the new MCP server.

Check your environment

rea doctor

This tells you whether something is missing, misconfigured, or unsupported on your machine.

Try it from the terminal

rea analyze /Applications/Notes.app
rea search /Applications/Notes.app "offline"
rea trace /Applications/Notes.app "offline"

Or just ask your agent

Understand how search works in the Notes app, show me the evidence,
and build a similar feature for my project.

Manual MCP configuration

If your agent supports local MCP servers but is not auto-detected, add this to its config:

{
  "mcpServers": {
    "rea": {
      "command": "npx",
      "args": ["-y", "rea-agents@3.1.0", "mcp"]
    }
  }
}

Pin to the latest published version from npm.

Safety and permissions

Reverse-engineering tools can be risky if they run code you do not trust. REA leans heavily toward caution:

• Dynamic features (process capture, browser observation, runtime inspection) are disabled by default and need explicit environment variables plus per-call approval.
• File-based evidence commands only work inside directories you approve, using variables like REA_EVIDENCE_ROOTS_JSON.
• Static JavaScript analysis parses code without running it.
• REA never calls sudo, and it uses authenticated local sockets for provider communication.

The flip side: providers and launched targets still run with your user permissions. REA is not a security sandbox, so do not treat it as one when handling malware.

Is it worth a try?

Yes, if:

• You are on macOS or Linux and already use an MCP-capable agent like Claude Code or Cursor.
• You want to understand how a feature works in an app you use, especially a native or Electron app.
• You are curious about reverse engineering but never had time to learn Hopper or Ghidra.
• You need to document an undocumented file format, protocol, or interface for interoperability.
• You maintain software and want to diff behavior across versions.

Maybe hold off if:

• You are on Windows. Support there is experimental and limited.
• You want a quick, zero-config tool. REA has a lot of opt-in switches and environment variables, which is good for safety but takes time to learn.

A few practical notes:

• Hopper is separate commercial software. The demo mode works, but has vendor-defined limits.
• Deep investigations can use a lot of agent tokens, so watch your model costs.
• Respect the law and the software license. Reverse engineering for learning and interoperability is common, but some license agreements and jurisdictions restrict it. Recreate ideas and behavior, not copyrighted code or assets.

Summary

REA turns reverse engineering from a specialist skill into something you can delegate to your coding agent. You describe the feature, the agent investigates the app, shows you how it reached its conclusions, and then helps you build your own version.

• GitHub: github.com/morluto/rea