REA: Reverse Engineer Apps with Claude, Codex & AI - ValuFlash

Introduction: What If You Could Understand How Software Works?

You are using an app and notice a search box that feels instant. It tolerates typos, narrows results as you type, and remembers your last filter. You want that behavior in your own product, but you do not want to guess, and you must not copy someone else’s code.

The usual route is slow. You poke at the interface, read minified JavaScript, open a decompiler, and lose an afternoon before you know whether the feature runs on the device or on a server. REA (Reverse Engineer Anything) shortens that loop. It gives an AI coding agent tools to inspect supported software artifacts and returns evidence the agent can reason from, instead of guesses.

This guide goes from zero to a working setup. You will install REA, connect it to Google Antigravity, Claude Code and OpenAI Codex, investigate a website feature and an Android app, and turn the findings into requirements for an original build. If you run a small team, it also helps to see where AI-assisted engineering fits into a wider operating model, which is what ValuFlash writes about.

One distinction matters throughout. Understanding how a feature behaves is legitimate engineering. Copying proprietary code, assets or protected logic is not. REA helps with the first. The second is on you, and the legal section below explains how to stay on the right side of it.

What REA will not do: it will not recreate any app automatically, recover every source file, bypass security protections, or produce a production-ready product from one prompt. It produces evidence and limitations. You and your agent still do the engineering.

What Is REA (Reverse Engineer Anything)?

REA is an open-source project (MIT license) whose tagline is “reverse engineer anything with agents, from app behavior down to native binaries.” It connects your agent to tools for inspecting native binaries, JavaScript and Electron apps, .NET assemblies and websites, runs analysis locally, and returns the evidence and limitations behind each conclusion. It ships as the npm package rea-agents, which installs a CLI (rea) and an MCP server. github

What MCP means

MCP (Model Context Protocol) is a standard way for an AI agent to call external tools. Your agent does not “know” how to decompile an APK. It asks an MCP server that does. REA is that server, running on your machine over stdio.

How the pieces fit

The flow is: you ask the agent a question, the agent calls REA tools, REA drives the right analysis engine, and the result comes back as evidence (code, references, unknowns). The agent then uses those findings to ask follow-ups, explain the behavior, or write and test an implementation. github #mermaid-rfv-r1-2f7257725d6001e5 { font-family: system-ui, “Segoe UI”, Roboto, Helvetica, Arial, “PingFang SC”, “PingFang TC”, “Hiragino Sans”, “Apple SD Gothic Neo”, “Kohinoor Devanagari”, “Kohinoor Bangla”, “Kohinoor Telugu”, “Tamil Sangam MN”, “Kohinoor Gujarati”, “Malayalam Sangam MN”, “Nirmala UI”, “Noto Sans Devanagari UI”, “Noto Sans Devanagari”, “Noto Sans Bengali UI”, “Noto Sans Bengali”, “Noto Sans Telugu UI”, “Noto Sans Telugu”, “Noto Sans Tamil UI”, “Noto Sans Tamil”, “Noto Sans Gujarati UI”, “Noto Sans Gujarati”, “Noto Sans Kannada UI”, “Noto Sans Kannada”, “Noto Sans Malayalam UI”, “Noto Sans Malayalam”, Thonburi, “Leelawadee UI”, “Noto Sans Thai UI”, “Noto Sans Thai”, Kefa, Ebrima, “Noto Sans Ethiopic”, “Abyssinica SIL”, sans-serif, ui-sans-serif, system-ui, -apple-system, “Segoe UI”, Roboto, “PingFang SC”, “PingFang TC”, “Hiragino Sans”, “Apple SD Gothic Neo”, sans-serif; font-size: 16px; fill: rgb(229, 229, 229); } #mermaid-rfv-r1-2f7257725d6001e5 .edge-animation-slow { stroke-dashoffset: 900; animation: 50s linear 0s infinite normal none running dash; stroke-linecap: round; stroke-dasharray: 9, 5 !important; } #mermaid-rfv-r1-2f7257725d6001e5 .edge-animation-fast { stroke-dashoffset: 900; animation: 20s linear 0s infinite normal none running dash; stroke-linecap: round; stroke-dasharray: 9, 5 !important; } #mermaid-rfv-r1-2f7257725d6001e5 .error-icon { fill: rgb(204, 120, 92); } #mermaid-rfv-r1-2f7257725d6001e5 .error-text { fill: rgb(51, 135, 163); stroke: rgb(51, 135, 163); } #mermaid-rfv-r1-2f7257725d6001e5 .edge-thickness-normal { stroke-width: 1px; } #mermaid-rfv-r1-2f7257725d6001e5 .edge-thickness-thick { stroke-width: 3.5px; } #mermaid-rfv-r1-2f7257725d6001e5 .edge-pattern-solid { stroke-dasharray: 0; } #mermaid-rfv-r1-2f7257725d6001e5 .edge-thickness-invisible { stroke-width: 0; fill: none; } #mermaid-rfv-r1-2f7257725d6001e5 .edge-pattern-dashed { stroke-dasharray: 3; } #mermaid-rfv-r1-2f7257725d6001e5 .edge-pattern-dotted { stroke-dasharray: 2; } #mermaid-rfv-r1-2f7257725d6001e5 .marker { fill: rgb(161, 161, 161); stroke: rgb(161, 161, 161); } #mermaid-rfv-r1-2f7257725d6001e5 .marker.cross { stroke: rgb(161, 161, 161); } #mermaid-rfv-r1-2f7257725d6001e5 svg { font-family: system-ui, “Segoe UI”, Roboto, Helvetica, Arial, “PingFang SC”, “PingFang TC”, “Hiragino Sans”, “Apple SD Gothic Neo”, “Kohinoor Devanagari”, “Kohinoor Bangla”, “Kohinoor Telugu”, “Tamil Sangam MN”, “Kohinoor Gujarati”, “Malayalam Sangam MN”, “Nirmala UI”, “Noto Sans Devanagari UI”, “Noto Sans Devanagari”, “Noto Sans Bengali UI”, “Noto Sans Bengali”, “Noto Sans Telugu UI”, “Noto Sans Telugu”, “Noto Sans Tamil UI”, “Noto Sans Tamil”, “Noto Sans Gujarati UI”, “Noto Sans Gujarati”, “Noto Sans Kannada UI”, “Noto Sans Kannada”, “Noto Sans Malayalam UI”, “Noto Sans Malayalam”, Thonburi, “Leelawadee UI”, “Noto Sans Thai UI”, “Noto Sans Thai”, Kefa, Ebrima, “Noto Sans Ethiopic”, “Abyssinica SIL”, sans-serif, ui-sans-serif, system-ui, -apple-system, “Segoe UI”, Roboto, “PingFang SC”, “PingFang TC”, “Hiragino Sans”, “Apple SD Gothic Neo”, sans-serif; font-size: 16px; } #mermaid-rfv-r1-2f7257725d6001e5 p { margin: 0px; } #mermaid-rfv-r1-2f7257725d6001e5 .label { font-family: system-ui, “Segoe UI”, Roboto, Helvetica, Arial, “PingFang SC”, “PingFang TC”, “Hiragino Sans”, “Apple SD Gothic Neo”, “Kohinoor Devanagari”, “Kohinoor Bangla”, “Kohinoor Telugu”, “Tamil Sangam MN”, “Kohinoor Gujarati”, “Malayalam Sangam MN”, “Nirmala UI”, “Noto Sans Devanagari UI”, “Noto Sans Devanagari”, “Noto Sans Bengali UI”, “Noto Sans Bengali”, “Noto Sans Telugu UI”, “Noto Sans Telugu”, “Noto Sans Tamil UI”, “Noto Sans Tamil”, “Noto Sans Gujarati UI”, “Noto Sans Gujarati”, “Noto Sans Kannada UI”, “Noto Sans Kannada”, “Noto Sans Malayalam UI”, “Noto Sans Malayalam”, Thonburi, “Leelawadee UI”, “Noto Sans Thai UI”, “Noto Sans Thai”, Kefa, Ebrima, “Noto Sans Ethiopic”, “Abyssinica SIL”, sans-serif, ui-sans-serif, system-ui, -apple-system, “Segoe UI”, Roboto, “PingFang SC”, “PingFang TC”, “Hiragino Sans”, “Apple SD Gothic Neo”, sans-serif; color: rgb(229, 229, 229); } #mermaid-rfv-r1-2f7257725d6001e5 .cluster-label text { fill: rgb(51, 135, 163); } #mermaid-rfv-r1-2f7257725d6001e5 .cluster-label span { color: rgb(51, 135, 163); } #mermaid-rfv-r1-2f7257725d6001e5 .cluster-label span p { background-color: transparent; } #mermaid-rfv-r1-2f7257725d6001e5 .label text, #mermaid-rfv-r1-2f7257725d6001e5 span { fill: rgb(229, 229, 229); color: rgb(229, 229, 229); } #mermaid-rfv-r1-2f7257725d6001e5 .node rect, #mermaid-rfv-r1-2f7257725d6001e5 .node circle, #mermaid-rfv-r1-2f7257725d6001e5 .node ellipse, #mermaid-rfv-r1-2f7257725d6001e5 .node polygon, #mermaid-rfv-r1-2f7257725d6001e5 .node path { fill: transparent; stroke: rgb(161, 161, 161); stroke-width: 1px; } #mermaid-rfv-r1-2f7257725d6001e5 .rough-node .label text, #mermaid-rfv-r1-2f7257725d6001e5 .node .label text, #mermaid-rfv-r1-2f7257725d6001e5 .image-shape .label, #mermaid-rfv-r1-2f7257725d6001e5 .icon-shape .label { text-anchor: middle; } #mermaid-rfv-r1-2f7257725d6001e5 .node .katex path { fill: rgb(0, 0, 0); stroke: rgb(0, 0, 0); stroke-width: 1px; } #mermaid-rfv-r1-2f7257725d6001e5 .rough-node .label, #mermaid-rfv-r1-2f7257725d6001e5 .node .label, #mermaid-rfv-r1-2f7257725d6001e5 .image-shape .label, #mermaid-rfv-r1-2f7257725d6001e5 .icon-shape .label { text-align: center; } #mermaid-rfv-r1-2f7257725d6001e5 .node.clickable { cursor: pointer; } #mermaid-rfv-r1-2f7257725d6001e5 .root .anchor path { stroke-width: 0; stroke: rgb(161, 161, 161); fill: rgb(161, 161, 161) !important; } #mermaid-rfv-r1-2f7257725d6001e5 .arrowheadPath { fill: rgb(11, 11, 11); } #mermaid-rfv-r1-2f7257725d6001e5 .edgePaths .path { stroke: rgb(161, 161, 161); stroke-width: 1px; } #mermaid-rfv-r1-2f7257725d6001e5 .flowchart-link { stroke: rgb(161, 161, 161); fill: none; } #mermaid-rfv-r1-2f7257725d6001e5 .edgeLabel { background-color: transparent; text-align: center; } #mermaid-rfv-r1-2f7257725d6001e5 .edgeLabel p { background-color: transparent; } #mermaid-rfv-r1-2f7257725d6001e5 .edgeLabel rect { opacity: 0.5; background-color: transparent; fill: transparent; } #mermaid-rfv-r1-2f7257725d6001e5 .labelBkg { background-color: rgba(0, 0, 0, 0.5); } #mermaid-rfv-r1-2f7257725d6001e5 .cluster rect { fill: rgb(204, 120, 92); stroke: rgb(138, 115, 107); stroke-width: 1px; } #mermaid-rfv-r1-2f7257725d6001e5 .cluster text { fill: rgb(51, 135, 163); } #mermaid-rfv-r1-2f7257725d6001e5 .cluster span { color: rgb(51, 135, 163); } #mermaid-rfv-r1-2f7257725d6001e5 .node .collapsed-indicator { fill: rgb(138, 115, 107); stroke: none; opacity: 0.6; } #mermaid-rfv-r1-2f7257725d6001e5 .node .collapsed-separator { stroke: rgb(138, 115, 107); stroke-width: 0.75px; } #mermaid-rfv-r1-2f7257725d6001e5 div.mermaidTooltip { position: absolute; text-align: center; max-width: 200px; padding: 2px; font-family: system-ui, “Segoe UI”, Roboto, Helvetica, Arial, “PingFang SC”, “PingFang TC”, “Hiragino Sans”, “Apple SD Gothic Neo”, “Kohinoor Devanagari”, “Kohinoor Bangla”, “Kohinoor Telugu”, “Tamil Sangam MN”, “Kohinoor Gujarati”, “Malayalam Sangam MN”, “Nirmala UI”, “Noto Sans Devanagari UI”, “Noto Sans Devanagari”, “Noto Sans Bengali UI”, “Noto Sans Bengali”, “Noto Sans Telugu UI”, “Noto Sans Telugu”, “Noto Sans Tamil UI”, “Noto Sans Tamil”, “Noto Sans Gujarati UI”, “Noto Sans Gujarati”, “Noto Sans Kannada UI”, “Noto Sans Kannada”, “Noto Sans Malayalam UI”, “Noto Sans Malayalam”, Thonburi, “Leelawadee UI”, “Noto Sans Thai UI”, “Noto Sans Thai”, Kefa, Ebrima, “Noto Sans Ethiopic”, “Abyssinica SIL”, sans-serif, ui-sans-serif, system-ui, -apple-system, “Segoe UI”, Roboto, “PingFang SC”, “PingFang TC”, “Hiragino Sans”, “Apple SD Gothic Neo”, sans-serif; font-size: 12px; background: rgb(204, 120, 92); border: 1px solid rgb(138, 115, 107); border-radius: 2px; pointer-events: none; z-index: 100; } #mermaid-rfv-r1-2f7257725d6001e5 .flowchartTitleText { text-anchor: middle; font-size: 18px; fill: rgb(229, 229, 229); } #mermaid-rfv-r1-2f7257725d6001e5 rect.text { fill: none; stroke-width: 0; } #mermaid-rfv-r1-2f7257725d6001e5 .icon-shape, #mermaid-rfv-r1-2f7257725d6001e5 .image-shape { background-color: transparent; text-align: center; } #mermaid-rfv-r1-2f7257725d6001e5 .icon-shape p, #mermaid-rfv-r1-2f7257725d6001e5 .image-shape p { background-color: transparent; padding: 2px; } #mermaid-rfv-r1-2f7257725d6001e5 .icon-shape .label rect, #mermaid-rfv-r1-2f7257725d6001e5 .image-shape .label rect { opacity: 0.5; background-color: transparent; fill: transparent; } #mermaid-rfv-r1-2f7257725d6001e5 .label-icon { display: inline-block; height: 1em; overflow: visible; vertical-align: -0.125em; } #mermaid-rfv-r1-2f7257725d6001e5 .node .label-icon path { fill: currentcolor; stroke: revert; stroke-width: revert; } #mermaid-rfv-r1-2f7257725d6001e5 .node .neo-node { stroke: rgb(161, 161, 161); } #mermaid-rfv-r1-2f7257725d6001e5 [data-look=”neo”].node rect, #mermaid-rfv-r1-2f7257725d6001e5 [data-look=”neo”].cluster rect, #mermaid-rfv-r1-2f7257725d6001e5 [data-look=”neo”].node polygon { stroke: url(“#mermaid-rfv-r1-2f7257725d6001e5-gradient”); filter: drop-shadow(rgb(185, 185, 185) 1px 2px 2px); } #mermaid-rfv-r1-2f7257725d6001e5 [data-look=”neo”].swimlane.cluster rect { filter: none; } #mermaid-rfv-r1-2f7257725d6001e5 [data-look=”neo”].node path { stroke: url(“#mermaid-rfv-r1-2f7257725d6001e5-gradient”); stroke-width: 1px; } #mermaid-rfv-r1-2f7257725d6001e5 [data-look=”neo”].node .outer-path { filter: drop-shadow(rgb(185, 185, 185) 1px 2px 2px); } #mermaid-rfv-r1-2f7257725d6001e5 [data-look=”neo”].node .neo-line path { stroke: rgb(161, 161, 161); filter: none; } #mermaid-rfv-r1-2f7257725d6001e5 [data-look=”neo”].node circle { stroke: url(“#mermaid-rfv-r1-2f7257725d6001e5-gradient”); filter: drop-shadow(rgb(185, 185, 185) 1px 2px 2px); } #mermaid-rfv-r1-2f7257725d6001e5 [data-look=”neo”].node circle .state-start { fill: rgb(0, 0, 0); } #mermaid-rfv-r1-2f7257725d6001e5 [data-look=”neo”].icon-shape .icon { fill: url(“#mermaid-rfv-r1-2f7257725d6001e5-gradient”); filter: drop-shadow(rgb(185, 185, 185) 1px 2px 2px); } #mermaid-rfv-r1-2f7257725d6001e5 [data-look=”neo”].icon-shape .icon-neo path { stroke: url(“#mermaid-rfv-r1-2f7257725d6001e5-gradient”); filter: drop-shadow(rgb(185, 185, 185) 1px 2px 2px); } #mermaid-rfv-r1-2f7257725d6001e5 :root { –mermaid-font-family: system-ui,”Segoe UI”,Roboto,Helvetica,Arial,”PingFang SC”,”PingFang TC”,”Hiragino Sans”,”Apple SD Gothic Neo”,”Kohinoor Devanagari”,”Kohinoor Bangla”,”Kohinoor Telugu”,”Tamil Sangam MN”,”Kohinoor Gujarati”,”Malayalam Sangam MN”,”Nirmala UI”,”Noto Sans Devanagari UI”,”Noto Sans Devanagari”,”Noto Sans Bengali UI”,”Noto Sans Bengali”,”Noto Sans Telugu UI”,”Noto Sans Telugu”,”Noto Sans Tamil UI”,”Noto Sans Tamil”,”Noto Sans Gujarati UI”,”Noto Sans Gujarati”,”Noto Sans Kannada UI”,”Noto Sans Kannada”,”Noto Sans Malayalam UI”,”Noto Sans Malayalam”,Thonburi,”Leelawadee UI”,”Noto Sans Thai UI”,”Noto Sans Thai”,Kefa,Ebrima,”Noto Sans Ethiopic”,”Abyssinica SIL”,sans-serif,ui-sans-serif,system-ui,-apple-system,”Segoe UI”,Roboto,”PingFang SC”,”PingFang TC”,”Hiragino Sans”,”Apple SD Gothic Neo”,sans-serif; }asks a questionMCP tool callsfindings + limitationsevidencerequirements, plantestsDeveloperAI Coding AgentAntigravity / Claude Code /CodexREA MCP serverlocal, stdioAnalysis toolsJADX, Ghidra, Hopper, IDA,browser CDP, JS analyzersOriginal implementationin your own repository

What evidence looks like

Evidence is not a summary. Results carry things like the target’s hash, the exact request, which engine produced the output, and what coverage was complete or partial. For Android, for example, REA keeps the APK’s SHA-256 and the raw engine replies alongside its structured answer. Your agent should quote this evidence, not paraphrase it from memory. That is the habit this guide builds.

Where the setup is deliberately cautious

REA setup shows a plan and asks for approval before it changes anything. It makes backups of existing agent configuration and writes changes only after you confirm. Treat that review step as part of the workflow, not an obstacle. github

What Can REA Actually Analyze?

The README’s target table is long. This is the subset most developers will touch, with the dependencies that matter.

Target	What you can learn	Extra requirements	Key limitations
Websites	Page structure, scripts, network observations, screenshots	A Chrome-family browser started with a debugging port	Passive observation only; it does not click, navigate or evaluate code in the page
JavaScript apps	Modules, imports, routes, source maps	Node.js and npm (Linux: a procps-compatible `ps`)	Static analysis shows structure, not what happens at runtime
Electron apps	Modules, IPC boundaries, native add-on relationships	Same as above; extracted folder or ASAR	Native add-ons need native analysis
Native binaries	Pseudocode, assembly, strings, symbols, calls, references	Hopper, Ghidra or IDA	Decompiler output is derived, not original source; host support varies by engine
.NET assemblies	Metadata, CIL, declared native dependencies	None (static only)	Obfuscated assemblies reveal less
Android APKs	Manifest, classes, decompiled methods, references	Headless JADX and a full JDK	Static only; no signature validation, split APK/AAB handling or native-library analysis
Flutter apps	Dart snapshot hash, per-ABI library digests, engine build provenance	None (static APK parsing)	Does not recover typed Dart classes or functions
Runtime behavior	Terminal output, interactions, filesystem observations	Linux/macOS with a native PTY (process capture)	Runs the target with your permissions; read each guide’s effects first
Network captures	Requests, responses, payloads, source locations	HAR or Fiddler Everywhere SAZ files	Only what was captured

Static JavaScript and .NET inspection read the supplied files without running the application, whereas runtime capture runs or interacts with the target under your user permissions. Keep that distinction in your head. Static analysis tells you what the code can do. Runtime analysis tells you what it did in one session. Neither alone proves a complete picture. github

Released package versus repository main

REA moves fast, and the README tells you to check release availability for features added after the latest npm release. Before relying on a feature, run:

powershell

npm view rea-agents dist-tags.latest

Then confirm the tool exists in your connected server’s tool list. Some capabilities in the repository documentation may be newer than your installed package. I will flag the cases where this matters (Windows Android analysis is one).

REA vs Traditional Reverse-Engineering Tools

REA is not a replacement for the engines underneath. It orchestrates them and standardizes the evidence they return.

Tool	What it is	Relationship to REA
Ghidra	Free disassembler/decompiler	REA can use it as a native analysis provider (bring-your-own install)
Hopper	Commercial disassembler	Provider; setup can optionally install it with approval, under its own license
IDA	Commercial disassembler	Provider; uses your existing licensed install
JADX	Android DEX decompiler	REA wraps a headless JADX engine for APK analysis
Apktool	Android resource decoder	REA can use a caller-supplied launcher for resource analysis

Deep native analysis uses Hopper, Ghidra or IDA, while static JavaScript and .NET inspection work without any of them. If you already use JADX or Ghidra by hand, REA does not make you obsolete. It lets an agent drive them and keeps the output auditable. If you do not know these tools, REA lowers the entry cost but does not remove the need to read results critically. github

Step 1: Prepare Your Computer

These steps assume Windows 10/11 with PowerShell. macOS/Linux differences are noted.

Install the basics

You need Git, Node.js with npm, an editor, and an AI coding agent. REA requires Node.js 22.x (22.19 or newer), 24.x (24.11 or newer), or 26 and later, plus npm. Choose Node 24 LTS unless you have a reason not to, and re-check the README if your version is borderline. github

winget is built into current Windows. Run these in PowerShell (they are standard Windows package IDs, not REA-specific):

powershell

winget install --id Git.Git -e
winget install --id OpenJS.NodeJS.LTS -e
winget install --id Microsoft.VisualStudioCode -e

Close PowerShell and open a new window so the updated PATH is picked up. On macOS, use the official Node installer or your preferred version manager. On Linux, use your distribution’s package manager or a version manager, and see the Linux note below.

Check your environment

powershell

node --version
npm --version
git --version

You should see version numbers, and Node should satisfy the ranges above. For example, v24.11.0 or higher passes.

If a command is “not recognized,” the program is not on your PATH. The fix is almost always to close and reopen the terminal after installation. If it still fails, reinstall and tick the option that adds it to PATH, or sign out and back in.

Linux note

On Linux, JADX, Ghidra, firmware-tool launches and static JavaScript/Electron analysis need a procps-compatible ps on REA’s PATH. Most desktop distributions have it already. Verify with ps --version.

Choose an AI coding agent

You need at least one agent that supports local MCP servers. The three covered here are Google Antigravity, Claude Code and OpenAI Codex. You can install only the one you use. Authentication and billing for these agents are separate from REA and are not covered here.

Optional, target-specific dependencies

Install these only when a target needs them:

Android APKs: a full JDK 17 or newer and the headless JADX engine (Project Two below).
Native binaries: Hopper, Ghidra or IDA.
Websites: Chrome, Edge or another Chrome-family browser.
Android devices/emulators: adb (caller-supplied).

Step 2: Find and Understand the Official GitHub Repository

Open github.com/morluto/rea. The README is the front page. Scroll to Quick start, How REA works, What you can analyze, FAQ and Documentation. The docs folder holds the detailed guides, including installation. The official website is rea.tools, and the package is rea-agents on npm.

Beware of lookalikes

The README warns that a similar repository name or a copied README does not make a download official, and tells you to follow install and release links from the official sources only. There are unrelated projects named “rea” on GitHub. This guide uses morluto/rea and rea-agents, nothing else. github

Optional: clone the repository

powershell

git clone https://github.com/morluto/rea.git
cd rea

Cloning is optional. It does not configure REA. For normal use you install through npm, which is the next step. Clone only if you want to read the source, run its verification scripts, or contribute.

Step 3: Install and Configure REA

Run the guided setup

Open PowerShell anywhere (you do not need to be inside a project) and run:

powershell

npx rea-agents@latest setup

The installation docs show the equivalent npx --yes rea-agents@latest setup. The @latest matters: it stops a stale npx cache entry or a project dependency from choosing the setup version for you. github

What happens, in order:

npm package approval. npm may ask whether to download and run rea-agents. That approval covers only the package-runner invocation. It does not authorize any configuration change. github
Capability picker. REA lists detected agents and offers “Agent integration” (the MCP registration plus matching workflow instructions) and, optionally, Hopper.
Agent selection. You choose which detected agents receive a registration.
Plan review. REA prints the exact files it will touch, backups it will create, and any external software or network origins involved.
REA setup approval. A separate final prompt. The default answer is Yes, but you can deselect anything or cancel at any prompt, and declining makes no changes. github
Optional native dependencies. Hopper is offered but never forced. Setup does not install Node.js, npm, Java, Ghidra, IDA or JADX.

Read the plan before you approve. Check that the paths belong to the agents you intend to configure.

Restart the agent

Agents load MCP servers at startup. After setup, fully quit and reopen the agent. A reload of a single window is often not enough.

Optional: install the global CLI

powershell

npm install --global rea-agents
rea --help

This gives you a shell-visible rea command for terminal use. It is separate from MCP registration. Running npm install rea-agents without --global only places the executable in the project’s node_modules/.bin, so rea will not be on your shell PATH. githubusercontent

Installing the CLI is not the same as registering the MCP server. A global CLI lets you run rea. Registration lets your agent call REA. You can have either, or both.

Dry-run first (recommended)

To preview exactly what setup would do for one agent without writing anything:

powershell

npx rea-agents@latest setup --client claude_code --dry-run --json

Swap in the client ID you need. The dedicated sections below use this pattern.

Manual registration (fallback)

If your client is not supported by setup, add REA to its MCP configuration by hand using the shape the installation docs publish:

json

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

For reproducible setups, replace @latest with an exact version. REA is also listed in the official MCP Registry as io.github.morluto/rea.

Step 4: Verify the Installation

REA ships a read-only diagnostic command. Use it before you debug anything else.

powershell

npx -y rea-agents@latest doctor

With the global CLI installed:

powershell

rea doctor --json

doctor accepts --client to check one agent’s registration, --provider hopper|ghidra|ida to check one analysis engine, --skill to check the bundled skill file, and --json for machine-readable output. Examples: linuxcommandlibrary

powershell

rea doctor --client claude_code --json
rea doctor --provider ghidra --json
rea providers --json

What to verify

Check	How	Healthy looks like
CLI available	`rea --help`	Help text prints
MCP registration	`rea doctor --client <id> --json`	Registration entry reports healthy
Agent connection	Ask the agent to list its REA tools	REA tools appear
Analysis engine	`rea doctor --provider <name> --json`	Provider reports ready
Target readiness	`rea doctor --json`	No missing-dependency failures for your target type

doctor is read-only and distinguishes unsupported hosts, missing dependencies, a missing local analysis engine, configuration drift and healthy checks. If a registration shows configuration drift, the remedy is to rerun setup for that client and restart it, not to hand-edit files. glama

Keep REA current

REA releases frequently. For a global install, run rea update, then rerun the setup command it prints to refresh agent registrations. For npx users, rerun npx rea-agents@latest setup. Restart your agent afterward.

How to Use REA with Google Antigravity

Antigravity is Google’s agentic development environment. This section covers the REA side precisely and tells you where to consult Antigravity’s own documentation, because I could not verify its menu names and I will not invent them.

Step 1: Install or open Antigravity

Install Antigravity from Google’s official source, sign in, and confirm it can run an agent task. Do this before adding REA so you can separate Antigravity problems from REA problems.

Step 2: Prepare a workspace

Create two folders. Keeping them apart protects your implementation from analysis clutter:

powershell

mkdir $HOME\work\rea-lab
mkdir $HOME\work\my-original-app

Put your authorized targets in rea-lab. Open my-original-app as the workspace you build in.

Step 3: Register REA for Antigravity

REA’s own agent skill lists antigravity among its supported client identifiers, alongside claude_code, codex, cursor, gemini_cli and others. Preview first: githubusercontent

powershell

npx rea-agents@latest setup --client antigravity --dry-run --json

Read the proposed config path and backup location. Do not assume where Antigravity stores MCP configuration. Let REA show you. Then apply:

powershell

npx rea-agents@latest setup --client antigravity

Review and approve the plan.

Step 4: Restart and verify

Fully quit and reopen Antigravity. Then check REA’s side:

powershell

npx -y rea-agents@latest doctor --client antigravity --json

Then verify inside Antigravity by asking the agent: “List the REA tools you can call.” If none appear, check Antigravity’s MCP status area (consult its documentation for the exact location) and look for a launch error rather than rerunning setup repeatedly.

Step 5: Open an authorized target and ask

Point the agent at your authorized target and give it a bounded task. Three reusable prompts:

Analyze an application

text

Use the connected REA tools to inspect the authorized target at <PATH OR URL>.
Identify its type, main components, and technology stack. For each claim, cite
the REA evidence. List what you could not determine and why. Do not modify the
target.

Understand a feature

text

Using REA, trace how the <FEATURE, e.g. search> feature works in <TARGET>.
Start from the user-visible entry point and follow it to the code or network
call that implements it. Separate confirmed findings from assumptions. Stop
and tell me if the evidence is incomplete.

Build from verified findings

text

Based only on the confirmed findings above, write an implementation plan for an
original version of this feature in my project in <WORKSPACE>. Use my existing
stack. Do not copy target source code or assets. List tests that would prove
each requirement.

When to use what

Use the agent for investigation and planning. Use the editor for reading and refactoring generated code. Use the terminal to run the REA CLI directly when you want raw evidence without agent interpretation, and to run your project’s tests. Normal tools such as Git, linters and test runners remain yours.

How to Use REA with Claude Code

Chat versus Claude Code

Claude’s ordinary chat interface cannot reach tools on your computer. Claude Code runs in your terminal or editor, can read your project directory, and can load local MCP servers. REA needs the latter, because REA runs on your machine and inspects files on your disk.

Step 1: Install and sign in to Claude Code

Follow Anthropic’s official installation instructions and confirm Claude Code starts in a project directory.

Step 2: Register REA

powershell

npx rea-agents@latest setup --client claude_code --dry-run --json
npx rea-agents@latest setup --client claude_code

Setup does two things for Claude Code: it adds the REA MCP server entry, and it installs REA’s workflow instructions (the bundled skill) that teach the agent how to investigate with REA. Both are shown in the plan. Existing configuration entries are preserved, and a backup is created. github

Step 3: Restart and check

Quit Claude Code completely and start it again. Then run:

powershell

npx -y rea-agents@latest doctor --client claude_code --skill --json
claude mcp list

doctor checks REA’s view. claude mcp list shows Claude Code’s view and should list rea as connected. If the two disagree, trust Claude Code’s MCP status for what is actually loaded, and use doctor to find why.

Step 4: Open the project and select a target

Start Claude Code inside your implementation repository (my-original-app). Keep analysis targets in a separate folder and give REA absolute paths. For Windows, use forward slashes or quoted paths with spaces.

Step 5: Request an evidence-backed investigation

Use this prompt, adapted from the master brief:

text

Use the connected REA tools to inspect this authorized application. Identify
the architecture and trace its search feature. Separate confirmed findings from
assumptions. Show supporting evidence, explain limitations, and prepare an
implementation plan for an original feature in my project. Do not copy
proprietary source code or modify the target.

Step 6: Convert findings into artifacts

Once the investigation is done, ask Claude Code for four things in sequence, reviewing each before the next:

An architecture note (docs/reference-analysis.md) containing only confirmed findings and cited evidence.
A task list derived from requirements, not from the target’s code.
The implementation, in small commits.
Tests that encode the requirements, written before or alongside the code.

The separation matters. The analysis note describes behavior. The code is written from requirements. That is how you stay on the “understanding” side of the line.

How to Use REA with ChatGPT Codex

ChatGPT versus Codex

A regular ChatGPT conversation runs in OpenAI’s cloud and cannot start a local MCP server on your machine. For REA you need a Codex environment that runs locally and supports MCP configuration, such as the Codex CLI. Use whichever Codex client you have, as long as it can load local MCP servers.

The workflow

1. Prepare the environment. Complete Steps 1 to 4 above and install Codex per OpenAI’s instructions.

2. Configure REA.

powershell

npx rea-agents@latest setup --client codex --dry-run --json
npx rea-agents@latest setup --client codex

For Codex, setup also adds a 30-second MCP startup timeout, because starting an npx-launched server can take a moment. You will see this in the reviewed plan. github

3. Restart or reconnect Codex. Quit and relaunch it.

4. Confirm MCP availability.

powershell

npx -y rea-agents@latest doctor --client codex --json

Then, in Codex, ask it to list available REA tools. If your Codex build provides an MCP listing command, use that too.

5. Open the intended repository. Start Codex in your implementation repo, not in the target folder.

6. Give a bounded task. Use this reusable evidence-first prompt:

text

Task: investigate ONE feature of the authorized target at <PATH OR URL> using
the connected REA tools.

Rules:
- Make no claim without citing REA evidence (tool name, input, result).
- Mark each statement as CONFIRMED, INFERRED, or UNKNOWN.
- If a tool errors or returns partial coverage, say so; do not fill gaps.
- Do not modify the target. Do not copy source code or assets.
- Stop after the investigation and wait for my approval before writing code.

Deliverable: a findings report, a list of unknowns, and proposed requirements.

7. Review the findings yourself. Open the evidence. Check that the claims match it.

8. Approve a plan. Ask for a short plan with files to create and tests to write.

9. Generate original code. Ask Codex to implement from the approved requirements only.

10. Run tests and review the diff. Run your tests, read every change, and reject anything that resembles target code.

Separating analysis from implementation

Use two directories, or two repositories. Keep REA outputs (evidence JSON, notes) in rea-lab/, and keep only your requirements document in the implementation repo. This makes it easy to prove later that your code came from requirements. It also keeps target files out of your commits.

One REA Installation, Multiple AI Agents

Yes. A single local REA install can be registered with several clients. Registration is per-client: setup writes an entry into each selected agent’s configuration. You can repeat --client in one command:

powershell

npx rea-agents@latest setup --client claude_code --client codex --client antigravity --dry-run --json

Or use --all-detected to select every detected client.

Client	Client ID	Setup approach	Practical workflow	Suited for
Google Antigravity	`antigravity`	`setup --client antigravity`	Agent-driven in its environment; check its docs for MCP status	Exploratory investigations with an IDE around them
Claude Code	`claude_code`	`setup --client claude_code`	Terminal/editor session in your repo	Evidence-heavy investigation, then requirements and tests
Codex	`codex`	`setup --client codex`	Local Codex session in your repo	Bounded tasks and code generation with review
Gemini CLI	`gemini_cli`	`setup --client gemini_cli`	Terminal agent	Quick one-off questions in a shell
Cursor	`cursor`	`setup --client cursor`	Editor-integrated chat/agent	Implementing while inspecting side by side

Supported MCP integration does not mean identical behavior. Clients differ in permission prompts, tool timeouts, context window size, how many tools they load at once, and how they display evidence. A prompt that works well in one may need tuning in another. If a client loads too many tools and fills its context, consult that client’s guidance on trimming the tool list.

If you are deciding how much of your workflow should depend on agents at all, How to Build an AI-First Business System covers the operating-model side of that question.

Hands-On Project One: Reverse Engineer a Website Feature

Authorization first. Use a site you own, a local demo, or one that explicitly permits analysis. For this walkthrough, assume a local demo at http://127.0.0.1:3000 with a search box.

1. Define the objective

Write one sentence: “Determine how the search box fetches and ranks results, and whether filtering happens on the client or server.” Narrow objectives produce usable evidence.

2. Prepare the target

REA attaches to a browser you start, using the Chrome DevTools Protocol. Start a separate browser profile with an explicit debugging port, and do not expose that port on a non-loopback interface. In PowerShell (adjust the Chrome path if needed): github

powershell

& "C:\Program Files\Google\Chrome\Application\chrome.exe" `
  --remote-debugging-port=9222 `
  --user-data-dir="$env:TEMP\rea-browser-profile" `
  http://127.0.0.1:3000

Use a dedicated profile so your normal browsing data is not in scope. REA does not launch or close this browser. You do.

3. Start the analysis

The CDP endpoint must be a literal loopback address such as http://127.0.0.1:9222. localhost, private LAN addresses and HTTPS endpoints are not valid. List targets first, because target IDs are specific to each browser instance: github

powershell

rea list-browser-targets http://127.0.0.1:9222 --json

Copy the TARGET_ID for your page.

4. Inspect page structure

powershell

rea inspect-web-page http://127.0.0.1:9222 TARGET_ID --observation-ms 1000 --json

This returns DOM structure, accessibility nodes, scripts, resources and network/console metadata for the window you observed. REA’s data minimization keeps DOM node types and attribute names but not text or attribute values, and it never retains cookies or authorization headers. github

5. Investigate JavaScript behavior

powershell

rea analyze-web-bundle http://127.0.0.1:9222 TARGET_ID --json

This parses the page’s scripts without executing them and derives chunk relationships, route and endpoint candidates, and vendor fingerprints. Source maps are fetched only if you opt in with the relevant option.

6. Observe network activity (authorized)

Network and console coverage begins only after REA attaches, so earlier activity is not captured. Start an observation window, then type in the search box yourself:

powershell

rea observe-web-session http://127.0.0.1:9222 TARGET_ID --observation-ms 10000 --json

You perform the action during those ten seconds. REA records the ordered navigation and lifecycle metadata. To see request shapes, use inspect-web-page with --include-json-body-shapes, which records value-free JSON structure rather than the data itself.

7. Identify components and dependencies

Ask your agent to summarize from the evidence: the search input component’s likely framework, the endpoint it calls, debounce behavior if visible, and libraries fingerprinted in the bundle.

8. Document confirmed findings

Use this template in docs/search-evidence.md:

markdown

# Search Feature Evidence Report

Target: <URL or name>          Authorization: <owner / written permission>
Date: <date>                   REA version: <output of rea --version>

## Objective
<one sentence>

## Confirmed findings
| # | Finding | Evidence (tool, input, evidence ID) | Coverage |
|---|---------|-------------------------------------|----------|
| 1 | Search calls GET /api/search?q= | observe-web-session, <ID> | complete_within_window |

## Inferred (not directly shown)
- <statement> | Why inferred | How to confirm

## Unknown / not captured
- <e.g., ranking algorithm: server-side, not observable>

## Limitations
- <partial coverage, window length, auth-gated behavior not tested>

9. Identify missing information

Typical gaps: server-side ranking logic, rate limiting, authentication-gated filters, and behavior outside your observation window. Write these down. They become decisions you make in your own design.

10. Design an original implementation

Turn findings into requirements, not code. For a React or Next.js app:

markdown

## Functional requirements
- FR1: Typing in the search field triggers a query after 250 ms of inactivity.
- FR2: Results update without a full page reload.
- FR3: Empty results show a clear empty state.

## Non-functional requirements
- NFR1: Results render within 300 ms on the demo dataset.
- NFR2: Keyboard accessible (arrow keys, Enter, Escape).

## Plan (Next.js)
- /app/api/search/route.ts (own data source, own ranking)
- components/SearchBox.tsx (debounced input, aria-live results)
- tests/search.spec.ts (Playwright)

Notice what is absent: the target’s implementation. Only the observable behavior (debounce, partial updates) crossed over.

Verify with functional tests

Write tests that assert behavior from your requirements: typing “red” shows matching items, clearing the input clears results, no network call fires for an empty query, and results are reachable by keyboard. A short Playwright test per requirement is enough. When they pass, the feature meets your spec, whatever the target does internally.

Hands-On Project Two: Analyze an Android Application

This is the most dependency-heavy exercise. Use a self-built sample APK or an open-source app you may analyze. REA’s own showcase traces how the open-source Aegis authenticator generates login codes, which makes a good public reference once you finish this walkthrough. Never use an app you lack authorization to analyze. rea

Concepts you need

APK structure. An APK is a ZIP containing AndroidManifest.xml, compiled code in DEX files, resources, and native libraries per CPU architecture.
AndroidManifest.xml. Declares the package name, permissions, and components (activities, services, receivers, providers). It is the app’s table of contents.
JADX. Decompiles DEX bytecode to approximate Java. REA wraps a headless JADX engine.
JDK. Needed to run the JADX bridge. A runtime-only JRE is not enough.
ADB. Android Debug Bridge, for talking to an emulator or device. Needed only for device or runtime work.
Apktool. Decodes resources (manifest, strings, locales). REA can use a caller-supplied launcher.
Static versus runtime analysis. Static reads files. Runtime watches execution. REA’s APK operations are static: they do not execute the APK or provide split APK/AAB handling, signature validation, full resource-table semantics, native-library analysis or Android runtime capture. github

Prerequisites and how to verify each

JDK. REA needs a full JDK 17 or newer including its compiler module, plus the pinned jadx-headless-mcp 0.7.1 JAR. Install a JDK: github

powershell

winget install --id EclipseAdoptium.Temurin.21.JDK -e

Reopen PowerShell and verify:

powershell

java --version
javac --version
java --list-modules | Select-String jdk.compiler

All three should succeed. If javac is missing, you installed a JRE, not a JDK.

JADX engine JAR. Download and verify the SHA-256 digest, using REA’s documented PowerShell commands:

powershell

$jar = Join-Path $HOME '.local\share\rea\android\jadx-headless-mcp-0.7.1-all.jar'
New-Item -ItemType Directory -Force (Split-Path $jar) | Out-Null
Invoke-WebRequest -Uri 'https://github.com/1013503897/jadx-headless-mcp/releases/download/v0.7.1/jadx-headless-mcp-0.7.1-all.jar' -OutFile $jar
if ((Get-FileHash -Algorithm SHA256 $jar).Hash.ToLowerInvariant() -ne '6e5eacf500b64292bfb73c49797c1958f6ee44646e43e868039ae7feb573ff75') { throw 'JADX JAR SHA-256 does not match REA pinned metadata' }
$env:REA_JADX_MCP_JAR = $jar
$env:JAVA_HOME = 'C:\Program Files\Eclipse Adoptium\jdk-21.0.x-hotspot'   # adjust to your install

Pin versions and hashes from the current REA Android guide, because they can change between releases. $env: variables last only for that PowerShell session. To make them persist for your agent, set them as user environment variables or in the MCP server’s environment, then restart the agent. Check:

powershell

rea doctor --json

Windows caveat. The Android guide describes Windows x64 support as depending on a REA package that bundles matching native controls, and says an older released package can reject the host. If doctor reports an unsupported host on Windows, update REA first (rea update or @latest) and re-check. If it still fails, use WSL or a Linux machine, which is the better-verified path.

ADB (optional). Only for emulators/devices: install Android platform-tools and verify adb version. REA’s device analysis uses a caller-supplied adb. github

Apktool (optional). Needed only for resource decoding. Verify apktool --version. For the exact configuration, follow REA’s Apktool resource guide rather than guessing variable names.

The investigation workflow

1. Prepare the authorized APK. Put it in rea-lab\targets\Example.apk. Record where it came from and why you may analyze it.

2. Identify the package. The first command inspects the package and manifest:

powershell

rea inspect-android-package C:\Users\you\work\rea-lab\targets\Example.apk

Read the package name, SDK levels and declared permissions. Signature verification is reported as not_performed, so APK authenticity is unverified. Do not treat the app as genuine just because it analyzed cleanly. github

3. Inspect the manifest. Note launcher activities, exported components, and permissions that hint at features (camera, network, storage).

4. Investigate components. Search classes by name:

powershell

rea search-android-classes C:\...\Example.apk MainActivity
rea inspect-android-class C:\...\Example.apk example.MainActivity

5. Review methods and references.

powershell

rea inspect-android-method C:\...\Example.apk example.MainActivity onCreate
rea trace-android-references C:\...\Example.apk example.MainActivity --method-name onCreate

If a method name has overloads, REA rejects the ambiguous request, so use inspect-android-class to choose an overload index. Overload indices are tied to the current artifact and engine and are not stable across builds. Reference results are static relationships, not observed runtime calls. github

6. Identify screens and navigation. Use the manifest’s activities plus references from the main activity to map which screen starts which. Ask your agent to draw this as a Mermaid diagram from the evidence only.

7. Examine resources. Use the decoded manifest, string tables and locales (via Apktool if configured) to learn user-facing labels, supported languages and version facts.

8. Inspect runtime behavior where permitted. On an emulator you control, REA’s ADB tooling can list packages, processes and logs. Only do this for apps you may test, and do not capture other people’s data.

9. Document findings in the same evidence template as Project One. Include APK SHA-256, tool versions and coverage flags.

10. Convert to a plan. Write requirements for the behavior you need (for example “list view with text filter and category chips”), then choose Flutter or native Android.

Flutter targets

If the app is Flutter, Java-level decompilation reveals little, because the app logic is compiled Dart. REA offers two static commands:

powershell

rea identify-flutter-build C:\...\Example.apk
rea inspect-dart-aot C:\...\Example.apk

They report the Dart snapshot hash, per-ABI library digests, engine build provenance, and a dependency inventory drawn from package: URIs. REA does not map the snapshot hash to a Dart SDK release, and the string-pool output is a byte-pattern projection rather than recovered classes and functions. Expect an inventory of what the app is built from, not its source. github

What compiled artifacts cannot reliably give you

Original variable names, comments, project structure and build configuration are usually gone. Decompiled code is a derived representation: a complete text result does not establish complete semantics or a byte-identical reconstruction. Server-side logic is invisible. Reflection and dynamic loading hide call relationships. Obfuscated code reveals less. github

Hard boundary: do not use any of this to bypass licensing, authentication, payments, DRM, encryption or anti-tamper protections. If a feature is protected, the answer is to design your own, not to defeat theirs.

From Reverse Engineering to Building Your Own App

Reverse engineering is the first third of the job. This is the process that gets you to something shippable and original. If you want a deeper treatment of how engineering teams run this lifecycle, The Real Engineering Process Behind Successful Startups is a good companion.

Worked example. A developer studies the search and filtering feature of an authorized open-source sample app, then builds an original Flutter app with similar functional goals.

Phase 1: Investigation

Understand the reference feature using REA: entry screens, data flow, and where filtering happens. Output: raw evidence.

Phase 2: Evidence

Sort every statement into confirmed, inferred, or unknown. Anything unknown is a design decision, not a thing to guess at.

Phase 3: Requirements

Write functional requirements (what the user can do) and non-functional ones (speed, accessibility, offline behavior). Write them in your own words, about behavior. A good test is whether someone could implement them without ever seeing the target.

Phase 4: Architecture

Choose a stack based on your team and constraints, not because the target used it. Flutter suits one codebase across Android and iOS. Native Android suits deep platform integration. For a general framework for this decision, see Choosing the Right Tech Stack. Document the choice and the reason.

Phase 5: Development

Implement original code from the requirements, using your agent as an assistant, not a copier. Small commits, one requirement each.

Phase 6: Testing

Unit tests for filtering logic, widget tests for the list and filter UI, and integration tests for the end-to-end flow. Test against requirements, not against the target.

Phase 7: Security

Review authentication and authorization (if any), data storage and transport, permissions you request, and third-party dependencies and licenses. Run dependency audits. Do not carry over anything from the target’s security design you cannot justify.

Phase 8: Deployment

Prepare for the intended platform: signing keys you generate, store listings with your own assets, privacy policy, and release builds. Confirm that no target assets or branding remain.

Who does what

REA supports the investigation phases. Antigravity, Claude Code or Codex supports requirements, implementation and tests. You approve at every phase boundary.

Example folder structure

text

work/
├── rea-lab/                      # analysis only, never shipped
│   ├── targets/Example.apk
│   ├── evidence/
│   │   ├── package.json.evidence.json
│   │   └── methods/…
│   └── notes/search-evidence.md
└── my-original-app/              # your implementation repo
    ├── docs/
    │   ├── requirements.md       # written from findings, no target code
    │   └── architecture.md
    ├── lib/
    │   ├── features/search/
    │   └── main.dart
    ├── test/
    └── pubspec.yaml

Development workflow

Run REA investigation in rea-lab; save evidence.
Write requirements.md in my-original-app/docs.
Ask the agent for a plan; review.
Implement requirement by requirement; run tests after each.
Review the diff for anything target-derived.
Security pass, then release.

Ready-to-Copy AI Agent Prompts

Each prompt states deliverables, verification, and how to report uncertainty. Replace the angle-bracket placeholders.

Prompt A: Investigate an authorized application

text

Use the connected REA tools to investigate the authorized target at <PATH/URL>
(authorization: <owner/permission>). Deliver: (1) target type and technology
stack, (2) main components, (3) a list of REA tool calls you made with their
inputs. Verification: cite evidence for every claim. Uncertainty: label each
item CONFIRMED, INFERRED or UNKNOWN, and report any partial coverage or tool
errors verbatim. Do not modify the target or copy its code.

Prompt B: Trace a feature and produce an evidence report

text

Trace the <FEATURE> feature in <TARGET> from the user-visible entry point to the
implementing code or network call using REA. Deliver a report using this
template: Objective, Confirmed findings (with tool, input, evidence ID,
coverage), Inferred, Unknown, Limitations. Verification: re-run one key tool
call to confirm the result is stable. Uncertainty: if two readings of the
evidence are possible, list both.

Prompt C: Convert findings into a requirements document

text

From the attached evidence report only, write a software requirements
document: purpose, functional requirements (numbered), non-functional
requirements, out-of-scope items, and open questions. Describe behavior, not
the target's implementation. Verification: map each requirement to the finding
ID that justifies it. Uncertainty: any requirement without a confirmed finding
goes under "Assumptions needing my decision".

Prompt D: Build an original app from approved requirements

text

Implement requirements FR1-FR<N> from docs/requirements.md as an original
<Flutter / Next.js + API> application in this repository. Use my chosen
architecture in docs/architecture.md. Deliver: working code, tests for each
requirement, and a short README. Do not use any code, assets or strings from
the analyzed target. Verification: run the tests and show the output.
Uncertainty: if a requirement is ambiguous, stop and ask rather than guessing.

Prompt E: Review, test, debug and improve

text

Review the current implementation against docs/requirements.md. Deliver: a list
of requirements met/unmet, failing or missing tests, bugs with reproduction
steps, security concerns (auth, data handling, dependencies), and a check that
no target-derived code or assets are present. Fix issues in small commits and
re-run tests after each. Uncertainty: separate confirmed bugs from suspicions.

Common Errors and Troubleshooting

Problem	Likely cause	Verified fix
Node.js version error	Node older than the supported range	Install Node 22.19+ or 24.11+ (or 26+); recheck with `node --version`
`npm`/`npx` not recognized	Node not on `PATH` or terminal not restarted	Close and reopen PowerShell; reinstall Node with the `PATH` option
PowerShell blocks `npm.ps1`	Execution policy	Run `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` (user scope only), or run `npm.cmd`/`npx.cmd` instead; do not disable policy machine-wide
REA tools not in agent	Not registered, or agent not restarted	`rea doctor --client <id> --json`; if unhealthy, rerun `setup --client <id>`; fully restart agent
Agent not restarted	Agents load MCP servers at launch	Quit the agent completely and reopen
Wrong MCP registration	Stale or hand-edited entry; configuration drift	Preview with `--dry-run --json`, apply setup, restart
Missing JDK	JRE installed, or Java not on `PATH`	Install a full JDK 17+; confirm `javac --version` and the `jdk.compiler` module
JADX not found	`REA_JADX_MCP_JAR` unset or wrong path	Set the variable to the verified JAR path in the agent’s environment; restart
Missing native provider	No Hopper/Ghidra/IDA configured	`rea doctor --provider <name> --json`; install the engine yourself or approve Hopper in setup
Unsupported target format	e.g. an `.aab` or split APK	Convert to a standalone APK or use archive inventory tools; check the guide for your format
Analysis timeout	Large app; default JADX operation deadline is 120 seconds	Raise `REA_JADX_OPERATION_TIMEOUT_MS` and the client’s tool timeout
Incomplete evidence	Partial coverage, short observation window, truncation	Read the coverage fields; lengthen the window; mark the gap as UNKNOWN
Windows path issues	Spaces, backslashes, relative paths	Use absolute paths in quotes; prefer a short path like `C:\work`
Insufficient permissions	Protected folders, locked files	Copy the target into your own folder; do not run the agent as administrator to work around it
Unexpected setup changes	Approved too quickly	Restore from the backup REA created; rerun with `--dry-run` and read the plan; `rea uninstall` removes only REA-owned registrations

If a problem persists, update first, then retry the same task, and if it still fails, open an issue with your REA version, target type, steps and error output. github

Limitations, Legal Use, and Security

What REA’s maintainers say

The project positions REA for lawful research, education, interoperability, software preservation, and analysis of software you own or are authorized to examine. Read the repository’s DISCLAIMER file before use. This guide is not legal advice, and rules vary by country. github

Responsible-use principles

Authorization. Own it, or have written permission. “It was online” is not permission.
Software licenses. Terms of service and EULAs may restrict reverse engineering even where law allows some of it. Read them.
Intellectual property. Behavior and ideas are generally treated differently from source code and creative assets. Do not copy code, text, images, icons, sounds or branding.
Privacy and sensitive information. Runtime capture and browser observation can expose personal data and secrets. REA reduces some of this by design, but explicitly selected options (accessibility text, script sources, console text) may include secrets. Do not extract credentials, and do not store or share evidence containing other people’s data.
Interoperability. Some jurisdictions allow reverse engineering to achieve interoperability under conditions. Get qualified advice before relying on that.
Clean-room implementation. Keep analysis and implementation separate: one stage produces behavior-level requirements, the next builds from them without referencing target code. The two-folder workflow above supports this.

Technical limits

Evidence is bounded by what was observed. Decompiled code is approximate. Static analysis cannot show server-side logic or runtime-only behavior. Runtime analysis runs code with your permissions and can have side effects, so use a disposable environment. REA’s browser observation is not a sandbox. The attached page and browser keep running with their existing privileges.

Human review is not optional

An agent can misread evidence or overstate certainty. You review findings, requirements, code and licensing. Teams that treat AI output as a draft rather than a decision tend to build more durable engineering habits, which is the theme of Building Skills That Create Long-Term Business Value.

FAQ

What is REA?
REA (Reverse Engineer Anything) is an open-source tool that gives AI coding agents local reverse-engineering capabilities through MCP, returning evidence and limitations for supported targets.

Is REA free and open source?
REA’s own code is MIT-licensed. Third-party tools it can use have their own terms. Commercial tools such as IDA Pro, Hopper and JEB must be legally obtained and used under their own licenses, and REA grants no licenses for them. github

How do I install REA on Windows?
Install Node.js (22.19+ or 24.11+) and Git, then run npx rea-agents@latest setup in PowerShell, review the plan, approve it, and restart your agent.

Does REA work with Google Antigravity?
antigravity is a supported client ID in REA’s skill file. Run npx rea-agents@latest setup --client antigravity. Confirm where Antigravity shows MCP status in Google’s documentation.

Can Claude Code use REA?
Yes. Use setup --client claude_code, restart Claude Code, and check with claude mcp list and rea doctor --client claude_code.

How do I connect REA to Codex?
Use setup --client codex with a Codex environment that supports local MCP servers, then restart it.

Does REA require Ghidra?
No. Ghidra is one of three native providers (with Hopper and IDA). JavaScript, Electron, .NET, website and APK analysis do not need it.

Can REA analyze Android APKs?
Yes, statically, with a full JDK and the headless JADX engine. It does not execute the APK or handle split APKs and AABs.

Can REA analyze Flutter applications?
It can identify the build and inspect the Dart AOT snapshot facts. It does not recover typed Dart classes or functions.

Can REA recover complete source code?
No. Output is decompiled or derived representation, with stated limitations.

Can REA help build an original application?
It helps you understand behavior and produce evidence. Your agent and you then write requirements and original code.

What is the difference between REA and JADX?
JADX is a decompiler for Android bytecode. REA is an MCP layer that drives JADX (and other engines) and packages results as evidence for an agent.

Is reverse engineering legal?
It depends on jurisdiction, purpose, contracts and the software involved. Analyze only what you own or are authorized to examine, and get legal advice for anything commercial.

Why is REA not appearing in my AI agent?
Usually the registration is missing or the agent was not fully restarted. Run rea doctor --client <id> --json, rerun setup for that client, and restart.

What should beginners build first?
Start with the guide’s website exercise on your own demo site, or REA’s own Notes first-investigation example, before touching APKs or native binaries.