# REA (Reverse Engineer Anything): The Complete Guide to AI-Powered Reverse Engineering in 2026

Learn how REA uses AI agents, MCP, and decompilers to reverse engineer apps, binaries, and websites. Includes setup, examples, prompts, and limitations.

Canonical URL: https://aiidelist.com/blog/rea-reverse-engineer-anything

Language: en

Published: 2026-10-15

Updated: 2026-10-15

## Key Takeaways

- **REA (Reverse Engineer Anything)** is an open-source reverse-engineering toolkit that connects AI coding agents to software analysis tools through the Model Context Protocol (MCP). It helps agents investigate how software works and develop independently implemented features based on verified findings.
- **REA supports more than native binaries.** Its documented capabilities include JavaScript and Electron applications, websites, .NET assemblies, Android APKs, firmware, SQLite databases, saved network captures, and several specialized binary formats. Requirements vary by workflow and platform.
- **Installation starts with `npx rea-agents@latest setup`.** REA integrates with coding agents including Claude Code, Codex, Cursor, Gemini CLI, OpenCode, and other supported MCP clients.
- **A native decompiler is not always necessary.** JavaScript and .NET static analysis can work without Hopper, Ghidra, or IDA. Deep native-code analysis requires a compatible analysis provider.
- **REA emphasizes evidence rather than unsupported AI guesses.** Analysis results can identify artifact locations, call relationships, observations, inferences, incomplete coverage, and unresolved questions.
- **The strongest use case is feature-level investigation.** Understanding one search algorithm, Electron IPC bridge, calculation routine, or application workflow is generally more manageable than attempting to reconstruct an entire commercial application.
- **REA is not a universal source-code recovery engine.** Decompilation cannot reliably restore original source, comments, variable names, or development history. Results require verification, and software licensing and authorization restrictions still apply.

## What Is REA (Reverse Engineer Anything)?

**REA, short for Reverse Engineer Anything, is an AI-assisted software analysis framework that gives coding agents access to reverse-engineering capabilities through MCP and a command-line interface.**

The official project is maintained at [morluto/rea on GitHub](https://github.com/morluto/rea), with documentation and practical demonstrations available through [rea.tools](https://rea.tools/).

Traditional reverse engineering involves manually examining compiled executables, application packages, network behavior, and runtime observations. Analysts use specialized tools to identify functions, trace data flows, interpret instructions, and reconstruct program behavior.

REA introduces an agent-oriented workflow. Rather than requiring every investigation to begin with manual function browsing, a developer can ask a coding agent a focused question. The agent uses REA tools to gather evidence, follow relevant relationships, and explain what the available evidence supports.

For example, consider a developer building an offline notes application. A useful investigation might determine how an authorized reference application indexes notes, performs searches, updates its local database, and handles search results.

REA can help the agent investigate those mechanisms and produce a technical explanation. The coding agent can then create an original implementation adapted to a different application architecture.

The distinction matters: **REA supplies analysis capabilities; the coding agent interprets results and performs ordinary software development.** Successful reconstruction depends on both the reliability of the investigation and the quality of the subsequent implementation and tests.

As of October 2026, the project documents workflows covering native analysis, application graphs, browser observation, managed code, mobile artifacts, and additional specialized formats. Availability must still be checked against the installed release rather than assumed from repository documentation alone.

## How REA Works: From Software Artifacts to Verified Behavior

REA is best understood as an investigation pipeline, not a single decompiler or an AI model capable of automatically cloning arbitrary software.

The typical workflow contains six stages.

### 1. Identify the target and investigation scope

The agent begins with a supplied software artifact or an authorized runtime observation target.

Examples include a macOS application bundle, an Electron ASAR archive, an executable, a .NET assembly, or an application running in a local Chromium browser.

A well-scoped investigation also identifies the specific behavior to explain. Searching for an application's complete internal architecture is far less efficient than examining one observable feature and its dependencies.

### 2. Choose an appropriate analysis provider

Different software formats require different capabilities.

For native binaries, REA can connect to compatible providers such as Ghidra, Hopper, or IDA. For JavaScript applications, REA can perform static artifact analysis without launching a native decompiler. Website inspection uses browser-related capabilities with their own observation boundaries.

Provider selection matters because a tool capable of reading machine instructions does not automatically understand a browser's DOM, while a browser debugger cannot recover every internal native function.

### 3. Collect structural evidence

Depending on the target, REA may recover:

- Executable sections, symbols, strings, and references.
- Assembly instructions and decompiler-produced pseudocode.
- Function callers, callees, and control-flow relationships.
- JavaScript modules, imports, exports, and application routes.
- Electron renderer, preload, IPC, and native-addon relationships.
- Browser resources, scripts, DOM structure, and selected runtime observations.
- Managed assembly metadata and Common Intermediate Language instructions.

A particularly important capability is connecting information across layers. A visible interface action may correspond to a JavaScript handler, an IPC request, a native module, and a database operation. Examining only the first layer can produce an incomplete explanation.

### 4. Trace the feature

The agent starts from evidence associated with the feature, such as a string literal, function name, API endpoint, IPC channel, or module.

It then follows relationships to identify the components responsible for the observed behavior.

For native applications, this can involve checking cross-references, inspecting callers, reading pseudocode, and verifying suspicious decompiler output against actual instructions.

For JavaScript applications, REA provides workflows such as `trace_application_feature` and `trace_javascript_semantics`, which operate on previously collected application-graph evidence.

### 5. Distinguish findings from assumptions

REA's Evidence model is one of its most useful architectural characteristics.

An analyst should distinguish between three categories:

| Evidence category | Example | Appropriate interpretation |
|---|---|---|
| Direct observation | A binary contains a particular instruction or string | Supported for the examined artifact |
| Static inference | A recovered relationship suggests that one function influences another | Requires awareness of unresolved dynamic behavior |
| Unknown or incomplete | A call target cannot be resolved, or coverage is partial | Cannot be treated as proof of absence |

This distinction addresses a common weakness in AI-assisted reverse engineering: plausible explanations can sound authoritative even when the required implementation details have not been observed.

### 6. Reimplement and validate

After the investigation, the coding agent can translate a verified behavioral specification into original code.

A complete workflow should include unit tests, boundary conditions, compatibility checks, and documentation of assumptions.

The resulting implementation should be evaluated independently. A successful decompilation does not automatically establish that newly generated code behaves correctly.

The project's [MCP runtime contracts](https://github.com/morluto/rea/blob/main/docs/mcp-contracts.md) explain how results, Evidence identities, coverage, and execution errors are represented.

## What Can REA Reverse Engineer?

REA's scope is considerably broader than traditional native-code decompilation, but the phrase Reverse Engineer Anything should not be interpreted as a guarantee of universal format coverage.

| Target | Available analysis | Important requirements or boundaries |
|---|---|---|
| Native executables and libraries | Assembly, pseudocode, symbols, references, call relationships | Compatible Hopper, Ghidra, or IDA installation for deep native analysis |
| JavaScript and Electron apps | Module graphs, imports, source maps, routes, IPC, native-addon relationships | Local extracted files or ASAR; native decompiler not required for static JS |
| Websites | DOM, scripts, resources, bounded runtime observations, selected screenshots | Supported Chrome-family browser and relevant browser workflow |
| .NET assemblies | Assembly identity, metadata, CIL, declared native dependencies | Static inspection; managed metadata must be present |
| Android APKs | Manifest information, classes, methods, and references | Compatible JADX and full JDK for the documented static workflow |
| SQLite databases | Schema, tables, indexes, triggers, and selected rows | Local database snapshot; runtime and Node version constraints apply |
| Go binaries | Embedded compiler, module, and build metadata | Supported binary container and available embedded metadata |
| Rust binaries | Embedded auditable dependency information | Available supported metadata; absence is not proof of no dependencies |
| WASM artifacts | Sections, validation, and WAT-related representations | Compatible caller-supplied WABT |
| EVM bytecode | Dispatch selectors and structural bytecode interpretation | Supported offline local workflow |
| Firmware | Region discovery and extraction handoffs | Compatible Binwalk or Unblob and supported host |
| Saved network captures | Request, response, protocol, and traffic evidence | Supported capture format and analysis provider |

Additional documented workflows cover recorded Linux crashes, process behavior, Android device operations, selected packet analysis, and logic-signal recordings.

Not every capability is available on every operating system or in every released package version. The [official capability documentation](https://github.com/morluto/rea) and installed tool catalog should be treated as authoritative for the particular environment.

## REA System Requirements and Compatibility

REA is distributed through the `rea-agents` npm package.

The official repository specifies these supported Node.js release ranges:

- Node.js 22.x, beginning with 22.19.
- Node.js 24.x, beginning with 24.11.
- Node.js 26 or newer, subject to the project's documented compatibility requirements.
- npm must also be available.

Additional dependencies depend on the chosen investigation.

**For static JavaScript or Electron analysis**, the basic Node.js environment may be sufficient.

**For native binary analysis**, configure a supported provider. Ghidra and IDA normally use existing installations, while guided setup can offer an optional Hopper installation with approval. Proprietary tools retain their own licensing requirements.

**For browser observation**, use a compatible Chromium-family browser and follow the relevant Chrome DevTools Protocol configuration requirements.

**For Android APK inspection**, supply compatible Java and JADX installations.

On Linux, some workflows also require a procps-compatible `ps` command for process ownership checks. Windows native-provider coverage has additional restrictions, including experimental Ghidra workflows.

These distinctions explain why a successful REA installation does not necessarily mean every advertised analysis capability is ready.

## How to Install REA with Claude Code, Codex, or Cursor

The recommended setup command is straightforward, but the configuration process should be treated as an explicit trust and permissions decision.

### Step 1: Verify Node.js

Open a terminal and check the installed runtime:

```bash
node --version
npm --version
```

Verify that the Node.js version satisfies the requirements of the REA release being installed.

### Step 2: Run guided setup

Execute the official package setup:

```bash
npx rea-agents@latest setup
```

The setup process allows selection of supported agents, previews configuration changes, and asks for approval before applying them.

It also installs corresponding investigation workflow instructions for selected integrations by default.

REA supports clients including Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Windsurf, and other integrations. Exact client support is release-dependent.

### Step 3: Review the installation plan

Before approving, verify:

- Which coding agents will receive an MCP registration.
- Which configuration and skill directories will change.
- Whether an external native-analysis provider is being installed.
- Whether existing configurations will be backed up.
- Whether the selected package and provider originate from official distribution channels.

For unattended or customized environments, the CLI supports explicit client selection and dry-run configuration planning.

For example, after installing the global CLI:

```bash
npm install --global rea-agents
rea setup --client codex --dry-run
```

Reviewing the plan is especially important when several coding agents are installed on the same machine.

### Step 4: Restart the coding agent

Restart the clients identified in the setup completion message. An existing agent session may not automatically discover a newly registered MCP server.

The workflow instructions and actual MCP server registration are separate components. Installing a skill alone does not guarantee that REA's analysis tools are connected.

### Step 5: Verify readiness

Use the diagnostic command when checking configuration or investigating a failure:

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

For a configured native provider, a scoped diagnostic can be more useful:

```bash
npx -y rea-agents@latest doctor --provider ghidra --json
```

A global readiness report can contain failures for optional capabilities that are irrelevant to a specific JavaScript investigation. Diagnose the required workflow instead of assuming every warning blocks all REA functionality.

The [official installation guide](https://github.com/morluto/rea/blob/main/docs/installation.md) documents client-specific configuration, setup permissions, updates, and troubleshooting.

## REA Tutorial 1: Analyze an Electron Application Without Running It

Electron applications are useful reverse-engineering targets because they often combine JavaScript bundles, browser APIs, local storage, native modules, and IPC communication.

An application may contain code split between its renderer process, preload scripts, and main process. Reconstructing a feature requires understanding how those components interact.

### Inspect an extracted application or ASAR

REA provides a static JavaScript analysis command:

```bash
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app.asar --json
```

Replace the example path with an authorized local application archive or extracted application directory.

The command generates structured analysis evidence, which can include module relationships, import information, Electron boundaries, and limitations.

For larger applications, save the output:

```bash
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app.asar --json > app-evidence.json
```

Large applications can generate substantial evidence files. REA also supports projecting summaries and module-specific views from saved evidence instead of repeatedly sending the full application graph into an AI context window.

### Trace one feature

A productive investigation begins with a clearly identifiable feature.

For example:

```text
Use REA to inspect the authorized Electron application at /absolute/path/to/app.asar. Find how the copy-to-clipboard feature works. Trace the renderer, preload, IPC channel, main-process handler, and system clipboard operation. Identify supporting artifact locations, unresolved relationships, and security checks. Produce a feature specification without copying proprietary source code.
```

The important question is not merely where the word clipboard appears. The agent needs to determine how the action crosses process boundaries.

### Real-world example: Notion's Electron clipboard bridge

REA's published [Notion clipboard investigation](https://rea.tools/showcase/notion/) demonstrates this approach using Notion Desktop 7.6.1.

The documented investigation follows this sequence:

1. The page-facing clipboard API exposes a write operation.
2. A preload wrapper forwards the call through `ipcRenderer.invoke`.
3. The main process registers a receiver through `ipcMain.handle`.
4. The receiver checks the sending web contents.
5. Electron's clipboard API writes the supplied data.

The case study identifies `notion:clipboard:write` as the relevant IPC channel in the examined package.

This is more informative than searching for one function name. It explains how a user-visible action travels between architectural layers and where an authorization check participates in the operation.

For a separate application, the engineering takeaway is to design a deliberate renderer-to-main IPC interface, validate request origin and data, and test clipboard behavior independently.

The published case study is a focused investigation of particular application artifacts, not evidence that all versions of Notion use an identical implementation.

## REA Tutorial 2: Reverse Engineer a Native Binary with Ghidra

Native binaries require a different approach because source-level abstractions may have been removed during compilation.

An executable can preserve instructions, constants, imported functions, and some metadata while losing original variable names, comments, and high-level structure.

REA exposes native-provider analysis through CLI commands and MCP tools.

### Check the provider

After configuring a compatible Ghidra installation, inspect available providers:

```bash
rea providers --json
rea capabilities --json
```

These commands help identify provider availability and supported operations.

### Analyze an authorized executable

A basic Ghidra-backed analysis uses:

```bash
rea analyze /absolute/path/to/program --provider ghidra --json
```

The actual target must be compatible with the provider and platform.

The CLI also exposes commands for searching, function inspection, decompilation, cross-references, and tracing:

```bash
rea search /absolute/path/to/program 'search' --provider ghidra --json
rea function /absolute/path/to/program main --provider ghidra --json
rea trace /absolute/path/to/program 'search' --provider ghidra --json
```

The function name and search term are examples. Stripped executables may not contain a symbol named `main`, so addresses or other recovered identifiers may be needed.

### Understand the analysis sequence

A focused native investigation typically proceeds through these stages:

1. Identify relevant functions using strings, symbols, imports, and call references.
2. Locate the routines that process the selected input or state transition.
3. Inspect decompiler output and the corresponding assembly instructions.
4. Trace callers to understand the meaning of function parameters.
5. Inspect constants and memory accesses that influence the calculation.
6. Reconstruct a behavioral model and compare it with the original program where lawful and technically feasible.

The most important step is validating what the decompiler appears to show. Decompiled pseudocode is a representation produced by an analysis engine, not recovered original source.

## Case Study: Reconstructing DX-Ball's Sound-Panning Calculation

REA's [DX-Ball reverse-engineering case study](https://rea.tools/showcase/dx-ball/) provides a concrete example of why instruction-level verification matters.

The investigation examined a function in DX-Ball 1.07 that converts a horizontal screen coordinate into a sound-panning value.

An initial decompiler view showed little more than a conversion call, providing insufficient information to describe the actual calculation.

By following the caller, inspecting original x86 instructions, and reading constants from the executable, the reconstruction recovered the essential arithmetic.

The resulting calculation can be represented as:

```c
double pan = (double)x;
pan = pan * 1.5625;
pan = pan - 500.0;
pan = pan * pan_scale;
return (int)pan;
```

The simplified code illustrates the recovered arithmetic; it is not a universal audio-panning algorithm.

At a pan scale of 1, the documented calculation produces:

| Input coordinate | Output |
|---|---:|
| 0 | -500 |
| 320 | 0 |
| 640 | 500 |

The case study reports **3,205 original-x86 behavior comparisons** for this function across integer positions from 0 through 640 and five scale values. It also reports a **63-byte compiled-function match** using a pinned historical compiler with reviewed relocations.

These figures are project-specific verification results, not a general benchmark of REA's accuracy across unrelated binaries.

Nevertheless, they demonstrate an important principle: a recovered behavior becomes significantly more credible when it can be checked against the original executable rather than accepted solely because the generated source looks reasonable.

## REA Tutorial 3: Inspect a Website with Browser Evidence

REA also provides website-observation capabilities through the Chrome DevTools Protocol.

This workflow is particularly relevant for developers investigating application architecture, route behavior, resource loading, or frontend implementation patterns in websites they are authorized to examine.

Unlike full browser-automation systems, REA's passive CDP observation tools attach to an existing browser and collect bounded evidence. Other documented REA browser workflows have different runtime-ownership and execution semantics.

### Start a dedicated browser session

For example, on a system with a compatible `google-chrome` executable:

```bash
google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/rea-browser-profile http://127.0.0.1:3000
```

This example opens a local development application using an isolated browser profile.

Never expose a browser debugging port to the public network. A debugging endpoint can provide powerful access to the browser session.

### Discover page targets

With the global REA CLI installed:

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

The returned result identifies eligible page targets. Select the correct target ID for subsequent operations.

### Capture page evidence

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

REA can collect information about DOM structure, scripts, resources, accessibility nodes, and selected network or console observations, subject to the chosen operation's scope and limitations.

A separate bundle-analysis workflow can recover static candidate relationships from selected website scripts:

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

An authorized user-driven observation window is also available:

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

The documented passive observation window records supported events while an external user performs the action. It should not be mistaken for unrestricted agent-controlled browser interaction.

The [browser observation guide](https://github.com/morluto/rea/blob/main/docs/browser-observation.md) describes endpoint restrictions, capture coverage, browser compatibility, and runtime boundaries.

### What website reverse engineering can establish

Browser evidence can help identify:

- Which scripts and resources are loaded.
- Which client-side routes and module candidates appear in static artifacts.
- How selected user actions affect observed page state.
- Whether frontend changes correspond to captured requests and navigation events.
- How a JavaScript bundle organizes visible application functionality.

However, **frontend inspection does not expose an application's private server-side source code**. Network responses reveal observed external behavior, not necessarily the implementation of the remote backend.

Likewise, an inferred endpoint is not proof that a particular backend framework, database, or internal service is responsible for it.

## Best REA Prompts for AI Coding Agents

Good reverse-engineering prompts specify a target, a narrowly defined question, the required evidence, and the expected deliverable.

Broad instructions create too much freedom for unsupported assumptions. A focused prompt gives the agent a reason to stop investigating when sufficient evidence has been collected.

The following prompts are reusable templates, not claims that these investigations have been executed.

### Prompt 1: Understand a desktop application's search behavior

```text
Use REA to investigate the search feature in the authorized application at [LOCAL_APP_PATH]. Identify the input handler, query-processing logic, indexing or persistence layer, and result-ranking or filtering behavior where observable. Trace the relevant call or module relationships and provide artifact locations supporting each conclusion. Mark unknown details explicitly. Produce a technology-independent feature specification and a plan for an original implementation.
```

**Best for:** Desktop-app modernization, offline search, and compatibility research.

### Prompt 2: Reconstruct an algorithm from a native executable

```text
Use REA with the available native-analysis provider to inspect [BINARY_PATH]. Investigate the function responsible for [FEATURE]. Identify candidate routines, inspect their callers and callees, recover the relevant constants, and verify decompiler interpretations against assembly. Provide pseudocode, supporting evidence, unresolved assumptions, and a boundary-focused test plan. Do not modify or execute the target without explicit approval.
```

**Best for:** Legacy algorithms, software preservation, and documented interoperability work.

### Prompt 3: Trace an Electron IPC workflow

```text
Analyze the authorized Electron application at [APP_PATH] using REA. Trace [FEATURE] from renderer code through preload APIs and IPC to the main process. Identify channel names, request parameters, handlers, sender checks, native dependencies, and filesystem effects supported by the evidence. Explain which findings are directly observed and which remain inferred. Provide an independent TypeScript implementation design with validation and test cases.
```

**Best for:** Electron architecture, application migration, and secure IPC design.

### Prompt 4: Investigate a website feature

```text
Use REA to inspect the authorized local website running in the configured browser session. Focus on [FEATURE]. Record relevant DOM structure, loaded scripts, route candidates, and bounded behavior observations. Distinguish static bundle findings from runtime observations. Avoid authenticated accounts or third-party endpoints outside the approved scope. Produce a concise architecture report and an original implementation plan.
```

**Best for:** Frontend architecture research, UI workflow analysis, and debugging.

### Prompt 5: Audit a previous reverse-engineering conclusion

```text
Review the existing REA Evidence for [FEATURE]. Separate direct observations, static inferences, and unresolved claims. Identify incomplete coverage, contradictory findings, and any assumptions introduced by the coding agent. Recommend the smallest set of additional authorized investigations or tests needed to establish the expected behavior. Do not treat missing evidence as proof that a behavior does not exist.
```

**Best for:** Improving the reliability of AI-generated technical explanations.

## REA vs. Ghidra, IDA, Hopper, Frida, and Chrome DevTools

REA overlaps with traditional reverse-engineering tools, but it generally serves a different role.

It acts as an agent-oriented integration and investigation layer. Many of the underlying analysis capabilities still depend on established specialized tools.

| Tool | Primary role | Main strength | Key limitation or distinction |
|---|---|---|---|
| **REA** | AI-agent-oriented reverse-engineering workflows | Combines MCP, CLI operations, evidence handling, and cross-format investigation | Requires suitable providers and verification; not an independent universal decompiler |
| **Ghidra** | Static native binary analysis | Disassembly, decompilation, program navigation, and extensibility | Agent-driven orchestration is not its primary standalone interface |
| **IDA / Hex-Rays** | Professional native reverse engineering | Mature binary navigation and decompiler tooling | Commercial capabilities and licensing depend on the selected edition |
| **Hopper** | Native disassembly and decompilation | Interactive analysis of supported native binaries | Separate product, licensing, and platform constraints |
| **Frida** | Dynamic instrumentation | Observing and instrumenting running processes | Requires a suitable runtime and careful execution permissions |
| **Chrome DevTools** | Browser debugging and profiling | Direct inspection of frontend runtime state and browser behavior | Does not recover private backend source code |
| **JADX** | Android application analysis | Recovering readable representations from supported DEX bytecode | Recovered code can be incomplete or semantically imperfect |

The tools are often complementary rather than direct substitutes.

For example, Ghidra can provide the low-level code evidence needed for a native investigation, while REA can make that evidence accessible to a coding agent carrying out a structured investigation.

Frida can be appropriate when authorized dynamic instrumentation is necessary, but static REA analysis is often a safer starting point for an unfamiliar artifact because it does not require executing the application.

Chrome DevTools remains valuable for interactive frontend debugging. REA adds structured analysis workflows that can be consumed through an agent or CLI.

**Practical selection rule:** Choose the underlying analysis technology based on the target format and evidence required. Choose REA when an agent-assisted workflow, repeatable queries, or integration with a coding project would materially improve the investigation.

## Advanced REA Techniques for More Reliable Results

### Preserve artifact identity

A reverse-engineering conclusion applies to the examined artifact, not automatically to every release of the software.

Record the original artifact's filename, version, and cryptographic digest when available. When investigating a changed release, confirm that the analysis corresponds to the new bytes.

REA's Evidence and snapshot workflows support artifact identity and repeatable analysis, but a saved result should never be presented as evidence for a different executable merely because the filenames match.

### Treat static analysis as a starting point

Static analysis can establish that certain instructions, literals, or relationships exist in the examined artifact.

It does not necessarily prove that a particular runtime path is executed under a given condition.

Dynamic property access, indirect calls, runtime configuration, feature flags, reflection, code generation, and server-controlled behavior can create blind spots.

Where permitted, corroborate important static inferences with controlled runtime observations or behavioral tests.

### Follow data across boundaries

Modern applications frequently cross several architectural boundaries:

- Renderer to preload to main process.
- JavaScript to native addon.
- UI event to local persistence.
- Browser client to remote API.
- Managed code to native dependency.

A useful investigation records both sides of a boundary and the data transferred across it.

For example, finding `ipcRenderer.invoke` does not establish what the main process does. The associated channel and receiver must also be examined.

### Reduce context-window waste

Large analysis results can consume substantial storage and AI context.

The official CLI documentation describes an example in which a large Obsidian application evidence file is reduced to a much smaller summary view.

For similar investigations, prefer this pattern:

1. Save complete evidence locally.
2. Inspect a summary or relevant module page.
3. Select specific identifiers or relationships.
4. Request detailed evidence only for those selected components.
5. Preserve references to the original evidence for later verification.

This makes the investigation more economical without requiring the agent to disregard important raw findings.

### Maintain an explicit confidence ledger

A useful investigation report can contain the following fields:

| Field | Purpose |
|---|---|
| Claim | The proposed behavioral or structural conclusion |
| Artifact | The exact binary, archive, or runtime target |
| Evidence | Relevant instruction, source location, observation, or Evidence ID |
| Confidence | An analyst-assigned confidence assessment |
| Limitation | Missing coverage, alternative explanations, or provider restrictions |
| Verification | A test or additional inspection capable of confirming the claim |

This is a recommended reporting practice, not a claim that REA automatically generates this exact table.

### Reproduce behavior before optimizing

A reconstructed algorithm should initially preserve confirmed behavior, including edge cases that may appear unusual.

Only after correctness is established should implementation-specific optimizations be introduced.

For example, replacing a native arithmetic routine with mathematically equivalent code can still produce different results if integer overflow, floating-point rounding, truncation, or historical compiler behavior differs.

The DX-Ball case study illustrates why exact comparisons can reveal issues that ordinary code review would miss.

## Common REA Installation and Analysis Problems

### Problem 1: The coding agent cannot find REA tools

**Likely causes:** The client registration was not selected, configuration has not been refreshed, or the agent session has not restarted.

**Recommended action:** Inspect the exact client configuration, run a scoped doctor check, and restart the client after approved setup changes.

### Problem 2: Ghidra or Hopper is unavailable

**Likely causes:** The provider is missing, improperly configured, incompatible with the target, or not supported in the current host environment.

**Recommended action:** Run a provider-specific readiness check and verify the provider's installation and target support. Do not assume that installing the REA npm package also installs every external analysis engine.

### Problem 3: Native analysis takes too long

**Likely causes:** Large binaries, cold provider startup, expensive decompilation, or client timeouts.

**Recommended action:** Investigate a smaller target or narrower function set, review provider startup settings, and follow the documented timeout and session-recovery procedures.

A client timeout does not necessarily mean the underlying analysis process has stopped.

### Problem 4: The returned JavaScript evidence is enormous

**Likely causes:** Large bundles, extensive module graphs, or complete structured evidence being returned when only a feature summary is required.

**Recommended action:** Save the full output locally and use supported analysis-view or feature-tracing workflows to retrieve relevant information.

### Problem 5: Website target discovery returns nothing

**Likely causes:** The browser debugging endpoint is unavailable, the browser was launched with incompatible debugging settings, or the supplied endpoint does not match the supported connection form.

**Recommended action:** Use a dedicated compatible browser profile, confirm the debugging endpoint, and follow the browser guide's endpoint restrictions. Keep the debugging interface bound to the local machine.

### Problem 6: The agent invents relationships between functions

**Likely causes:** Minification, unresolved dynamic calls, incomplete graphs, missing symbols, or unsupported assumptions.

**Recommended action:** Require exact artifact locations and evidence references. Request further investigation when a relationship remains ambiguous. Never interpret an empty result from incomplete analysis as proof that no relationship exists.

### Problem 7: A documented feature is missing from the installed package

**Likely cause:** The repository's main branch and the published npm package are not at the same development checkpoint.

**Recommended action:** Check the published version:

```bash
npm view rea-agents dist-tags.latest
```

Then compare the installed release against the documentation and the connected MCP server's actual advertised tools.

The project explicitly distinguishes current repository documentation from functionality included in published releases.

## Is REA Free? Licensing and Operational Costs

The REA project publishes its own code under the MIT License. The official repository and npm package provide the open-source software distribution.

However, that does not mean every complete reverse-engineering environment is free of charge.

Potential costs include:

- **Native-analysis software:** Proprietary providers such as Hopper, IDA Pro, and commercial decompiler components have their own licensing conditions.
- **AI coding agent usage:** Depending on the selected model and service, token consumption or subscription charges may apply.
- **Compute resources:** Large application graphs and native decompilation can require significant processing time and memory.
- **Engineering and validation:** Human review, testing, and compatibility work remain necessary even when the initial investigation is automated.

Ghidra offers an alternative for many native-analysis tasks, but compatibility and capability requirements should be verified for the specific target.

The relevant financial question is not just whether REA is free. It is whether agent-assisted investigation reduces the total effort required to reach a correct, tested result.

## Is REA Safe? Privacy, Permissions, and Legal Boundaries

REA describes local analysis as a core design characteristic. That provides meaningful control over where artifacts are inspected, but several security distinctions remain important.

### Local execution does not guarantee that every finding stays local

REA can process supported artifacts on the user's machine. However, evidence returned to a cloud-hosted coding agent may be transmitted to the model provider under that provider's own data-handling policies.

Before investigating confidential software, determine what information the agent will receive and where that information may be processed or retained.

### Static inspection and runtime execution have different risks

Static JavaScript and .NET inspection can read supported artifacts without executing the target application.

Other workflows may launch tools, attach to processes, observe browsers, access devices, or inspect network captures.

Those operations have different side effects and permission requirements.

Use an appropriate isolated environment for untrusted artifacts, protect credentials and personal data, and approve consequential runtime actions explicitly.

### Reverse engineering is not unlimited permission to reproduce software

Authorization depends on applicable law, licenses, contracts, and the intended activity.

Legitimate use cases can include permitted interoperability research, software preservation, security analysis, incident investigation, and examining applications that the analyst owns or is authorized to study.

REA does not provide authorization to bypass access controls, remove licensing restrictions, extract protected assets for redistribution, or copy another application's proprietary source.

Where an independently implemented compatible feature is the goal, document the observed behavior and implement original code without reproducing protected expression.

The project's [responsible-use guidance](https://github.com/morluto/rea/blob/main/DISCLAIMER.md) explains these boundaries and the responsibilities of users operating REA and its associated tools.

## When Should Developers Use REA?

REA is particularly useful when a developer needs to answer a precise technical question about software for which complete source code is unavailable.

High-value situations include:

- **Legacy modernization:** Recovering the behavior of a function or subsystem before replacing it.
- **Authorized interoperability:** Understanding data formats, message flows, and compatibility requirements.
- **Electron architecture research:** Tracing IPC paths and dependencies in packaged applications.
- **Software preservation:** Documenting important behavior in older binaries whose original development environments are unavailable.
- **Security review:** Investigating authorized targets while retaining evidence about identified behavior and uncertainty.
- **Regression investigation:** Comparing supported application artifacts or evidence across versions.
- **Independent feature development:** Translating lawful behavioral observations into new designs appropriate for a different product.

REA may be unnecessary when complete source code, accurate architecture documentation, and reliable tests are already available.

It may also be a poor fit when the target is unsupported, the required runtime access is not authorized, or a developer only needs a straightforward browser inspection available directly through DevTools.

The strongest engineering strategy is to select one question, gather sufficient evidence to answer it, and stop expanding the investigation when additional analysis no longer improves the implementation decision.

## REA Frequently Asked Questions

### Is REA an AI model?

No. REA is a software-analysis toolkit and integration layer. It provides tools and workflows that coding agents can invoke through MCP or the CLI. The selected AI model performs reasoning and development tasks using the returned information.

### Can REA recover the original source code of any application?

No. It can recover certain source-like representations, metadata, and structural relationships, depending on the target. Native decompilation may produce pseudocode, but original names, comments, project structure, and exact source are generally not guaranteed to be recoverable.

### Does REA work with Claude Code and Codex?

Yes. Both are among the project's documented MCP client integrations. Setup and compatibility should be verified using the installed package and client-specific readiness checks.

### Can REA analyze Electron applications without Ghidra?

Yes. The static JavaScript/Electron analysis workflow does not require a native decompiler. Native addons or compiled dependencies may still require separate analysis to understand their internal behavior.

### Can REA analyze websites without downloading their server source?

REA can inspect supported browser-visible artifacts and observations in an authorized browser session. It cannot infer private backend source code merely from page access or observed requests.

### Does REA automatically build a working clone of an app?

No. The coding agent may create an implementation informed by the investigation, but behavior, security, compatibility, and maintainability require testing. Legal rights to study software also do not automatically grant rights to copy its proprietary code or assets.

### Is REA better than Ghidra?

The tools serve different roles. Ghidra is a native reverse-engineering platform. REA can use Ghidra as a provider while making analysis operations available through an agent-oriented workflow. For manual binary research, Ghidra alone may be sufficient; for agent-assisted workflows, the combination may be more convenient.

### Does REA require internet access?

Local artifact analysis can operate on supported local files with the necessary tools installed. Initial package installation and certain setup operations may require network access. A cloud-hosted coding agent can introduce separate connectivity and data-transfer requirements.

### How can REA analysis results be verified?

Verification methods include examining exact source or instruction locations, checking constants and control flow, comparing independent observations, testing boundary inputs, and executing lawful differential tests against the original behavior. Evidence completeness should be assessed before making strong conclusions.

## Conclusion

**REA (Reverse Engineer Anything) represents a practical development in AI-assisted software analysis: it connects coding agents to specialized reverse-engineering capabilities while preserving a stronger relationship between technical claims and their supporting evidence.**

Its value is not that an agent can magically recover the complete source code of any program. The advantage is that a developer can investigate a narrowly defined behavior using relevant tools, connect findings across implementation layers, and turn supported observations into a testable engineering specification.

For native binaries, REA can work alongside established decompilers. For JavaScript and Electron applications, it offers static analysis and relationship tracing. For websites, it provides structured browser evidence within documented boundaries.

The best starting point is a small, authorized target and one concrete question.

Visit the [official REA repository](https://github.com/morluto/rea) or [REA website](https://rea.tools/), review the setup plan, connect a supported coding agent, and investigate a single feature. Preserve the evidence, identify what remains unknown, and validate any independently developed implementation before relying on it.