> ## Content Index
> Fetch the complete content index at: https://theseguysknow.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# REA: How AI Agents Reverse Engineer Existing Software
- URL: https://theseguysknow.io/rea-ai-reverse-engineering/
- Published: 2026-10-13T05:51:30.000Z
- Updated: 2026-10-13T05:51:30.000Z
- Description: REA lets coding agents inspect packaged apps and native binaries, then use the findings to understand or recreate behaviour. We looked at its code, setup and the Notion, DX-Ball and Touhou examples to see what that means in practice.
- Author: Mike Hazard
- Tags: AI & Tech, AI Tools & Models

When you copy a block in Notion, the app can remember more than just the text by storing information about the block and adding an ID to the copied HTML, which helps preserve its structure when you paste it. REA's published walkthrough traces this process through the desktop app and identifies the code responsible, showing why the tool is useful for AI coding agents that need to understand how software works rather than simply copy what it looks like.

## Quick Answer

REA, short for Reverse Engineer Anything, is an open-source CLI and MCP server that connects AI coding agents to software-analysis tools. It can help an agent inspect packaged JavaScript, Electron applications, .NET assemblies, and native executables, then use the findings to explain a feature or implement similar behaviour. Native analysis uses engines such as Ghidra, Hopper, or IDA; several static workflows work without them. The agent still has to interpret the results and test the code it writes.

The project is maintained under the GitHub account [morluto](https://github.com/morluto/rea?ref=theseguysknow.io), and its own code uses the [MIT licence](https://github.com/morluto/rea/blob/main/LICENSE?ref=theseguysknow.io). The latest release we checked was [REA 6.4.0, published on 11 October 2026](https://github.com/morluto/rea/releases/tag/rea-agents-6.4.0?ref=theseguysknow.io).

*We reviewed the repository, selected tool contracts, installation documentation, and published case studies on 12 October 2026\. We haven't run a TGK reconstruction test; the results discussed below belong to the linked projects.*

## What REA does

Reverse engineering means working backwards from existing software to understand its structure or behaviour. You might have an executable, an application package, or recorded network traffic without having the original development project.

What you can learn depends on the material available: packaged JavaScript can still contain readable code, although names and formatting may have been compressed. A compiled native program usually needs a disassembler to expose its machine instructions and a decompiler to turn those instructions into something closer to readable code. That reconstruction can lose names, types, and other information, so it needs checking.

REA gives agents a common way to use these different routes. Through [MCP, the Model Context Protocol](https://modelcontextprotocol.io/docs/learn/architecture?ref=theseguysknow.io), an agent can discover the available tools, request an analysis, and receive structured results. The terminal commands provide access to the same workflows.

You keep the coding environment you use, such as Claude Code or Codex, and add REA's analysis tools to it. If the distinction between a model and the software running it is still confusing, our [AI coding harness comparison](https://theseguysknow.io/best-ai-coding-harnesses/) explains that part.

REA supplies an investigation workflow: identify the target, inspect it, follow the relevant functions or modules, and keep the findings available for later questions. The agent can then use that material to write an implementation. Whether the implementation behaves correctly is a separate question that testing has to answer.

## What it can inspect

The [project's target list](https://github.com/morluto/rea?ref=theseguysknow.io#what-you-can-analyze) covers several kinds of software, with different requirements for each.

| **Target**                   | **What an agent can investigate**                                                            | **What it needs**                                                                             |
| ---------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| Native executables           | Instructions, decompiled pseudocode, strings, function calls and references                  | A suitable Ghidra, Hopper or IDA installation, with support for the target and host           |
| JavaScript and Electron apps | Modules, imports, source maps, process boundaries and communication between parts of the app | Node.js and the local application directory or ASAR package                                   |
| .NET assemblies              | Assembly metadata, types, method instructions and declared native dependencies               | An assembly containing supported PE/CLI metadata; no native engine for this static inspection |
| Websites                     | Page structure, scripts and observable browser behaviour                                     | A supported Chrome-family browser                                                             |
| Saved network captures       | Recorded requests, responses and available payloads                                          | A supplied HAR file; native mitmproxy captures have additional requirements                   |
| Android APKs                 | Manifest declarations, classes, decompiled methods and references                            | Headless JADX and a full JDK on a supported host                                              |
| WebAssembly files            | Imports, exports, sections and a readable text representation of the module                  | A supplied WABT installation supported by REA                                                 |

ASAR is the archive format commonly used to package Electron application files. CIL, which appears in the .NET documentation, means Common Intermediate Language, the instructions stored in ordinary managed assemblies.

Having a route for native binaries doesn't mean every executable on every operating system can be analysed equally well, and a file ending in `.dll` doesn't automatically contain .NET code.

For example, REA's [managed-code guide](https://github.com/morluto/rea/blob/main/docs/managed-code-analysis.md?ref=theseguysknow.io) explicitly excludes unpacking .NET single-file hosts and decoding IL2CPP metadata from its ordinary static parser. NativeAOT compilation also changes the route: native method bodies need native analysis. These distinctions matter if you're investigating games or an unfamiliar Windows application.

## How the agent follows a feature

Suppose you want to understand how an Electron app exports a document. The useful starting point is its local application package and a question about that operation.

REA's [JavaScript guide](https://rea.tools/guides/javascript/?ref=theseguysknow.io) includes a small export example. The visible page calls an API exposed by a preload script, which is the layer connecting the page to selected desktop capabilities. That script sends a message to the main process, where a handler formats the data and writes a CSV file.

The agent can follow the operation across those boundaries. IPC, or inter-process communication, is how those separate parts of an Electron application exchange messages; finding the message name and its receiver helps establish where the work happens.

The repository's [JavaScript tool contract](https://github.com/morluto/rea/blob/main/src/contracts/javascript/electronToolContracts.ts?ref=theseguysknow.io) adds a useful detail: `analyze_javascript_application` can inspect a local ASAR or extracted application without executing it. Its results include a graph of the application, relevant relationships, coverage and limitations. A summary request can keep the complete analysis in the session while returning a smaller view, after which the agent can inspect selected modules.

That gives the model a more manageable investigation than receiving an enormous dump of every file. It can find the export route, read the relevant code and ask the next question from there.

With a native executable, the agent opens the binary through an appropriate provider and requests a function by its symbol or an address returned by the analysis. REA's [analyze\_function](https://github.com/morluto/rea/blob/main/src/contracts/functionWorkflowToolContracts.ts?ref=theseguysknow.io)[ contract](https://github.com/morluto/rea/blob/main/src/contracts/functionWorkflowToolContracts.ts?ref=theseguysknow.io) describes a result containing pseudocode, assembly, calls, references and other available function details.

A reference means another place in the program that points to or uses the item being examined. Following those references can reveal what a function receives and how its output is used, which is often more helpful than trying to interpret it in isolation.

## Why the evidence matters

An agent can give you a very confident explanation after reading incomplete information, and adding a decompiler doesn't automatically fix that.

REA's [evidence schema](https://github.com/morluto/rea/blob/main/src/domain/evidence.ts?ref=theseguysknow.io) records more than an answer. Depending on the result, it can identify the analysed artifact, its SHA-256 digest, the provider and version, the operation, relevant locations and stated limitations. It distinguishes findings labelled observed, derived or inferred.

SHA-256 provides an identifier for the particular file's contents. That matters when two versions of an app have similar names but different code: a finding about one build shouldn't quietly become a claim about the other.

We also like that the [runtime contracts](https://github.com/morluto/rea/blob/main/docs/mcp-contracts.md?ref=theseguysknow.io) address incomplete analysis directly. An empty list of calls doesn't prove a function calls nothing when the underlying coverage is unknown or partial. A traversal that stops at an unresolved relationship can't establish that the destination is unreachable.

Those rules are useful because an agent needs to recognise where its explanation runs out of support. They still depend on the agent reading the limitations and responding sensibly; a structured evidence record can't guarantee a correct conclusion by itself.

Static analysis and runtime observation answer different questions. Reading code can identify a possible route through a program, while recording an operation can show what happened in that particular run. REA's [JavaScript workflow documentation](https://github.com/morluto/rea/blob/main/docs/javascript-application-workflows.md?ref=theseguysknow.io) keeps those claims distinct. Finding a function in the package doesn't establish that a specific button press executed it.

## What the published examples show

### Notion clipboard

The [Notion case study](https://rea.tools/showcase/notion/?ref=theseguysknow.io) follows a clipboard operation through the app's packaged JavaScript. The agent uses source ranges to locate the exposed API, follows Electron's IPC wrappers and finds the main-process handler that writes to the system clipboard after checking the sender.

For copied blocks, the walkthrough describes Notion retaining structured block data locally and putting a matching ID into the copied HTML. On paste, that ID can connect the ordinary clipboard material to the saved block data.

That explains behaviour a lookalike interface would leave unresolved. It also gives a developer a specific mechanism to study: where the data is retained, how the identifier travels and what happens when the matching entry is unavailable. The published example uses REA 4.1.0 and reports clipboard material from assets cached on 13 July 2026; it isn't a claim about every subsequent Notion release.

### DX-Ball sound calculation

In the [DX-Ball walkthrough](https://rea.tools/showcase/dx-ball/?ref=theseguysknow.io), the first decompiler view was incomplete. It showed a conversion call but missed the input and arithmetic that the machine instructions exposed.

Following the caller established that the input was a brick's horizontal screen position. Reading constants from the executable supplied the calculation:

`pan = (x × 1.5625 − 500) × pan_scale`

At a scale of 1, that gives −500 at the left edge, 0 at the centre and 500 at the right edge.

[N0zoM1z0's reconstruction project](https://github.com/N0zoM1z0/dx-ball?ref=theseguysknow.io) reports matching the original function's output across **3,205 cases**, then reproducing **all 63 compiled function bytes** with its pinned historical compiler after the required relocations. Those are checks of this recovered function, and the wider game reconstruction remains unfinished.

We find that much more persuasive than a clip showing a vaguely similar game running. It identifies what was recovered and gives us a way to assess whether the calculation survived the reconstruction.

### Touhou 4 bullet patterns

The [TH04 example](https://rea.tools/showcase/th04/?ref=theseguysknow.io) examines a ring attack in an old PC-98 game. Its angle system divides a full turn into 256 units, so a ring of 16 bullets spaces them 16 units apart. Adding the player's direction turns the ring towards the player.

The walkthrough connects that behaviour to the original 16-bit instructions and maintained C++ source. [N0zoM1z0's existing reconstruction work](https://github.com/N0zoM1z0/th04?ref=theseguysknow.io) provides names and context, which the agent can check against the executable; credit belongs to that project as well as the tools assisting it.

## Where this could be useful

For game preservation and modding, a recovered calculation or an understood file format can be valuable long before anyone has reconstructed an entire game. Sound, movement, resource loading and save data are all possible areas to investigate when the relevant material is available.

That connects with the [game mashups we've been covering](https://theseguysknow.io/game-mashups-mario-elden-ring-minecraft-gta/). Communities already spend time figuring out how systems behave so they can adapt or combine them. REA is another way of giving an agent access to that investigative work, although it doesn't establish that any particular crossover used REA.

Compatibility work is another sensible use. A developer might need to understand an old application's export format, compare two builds or recreate an abandoned feature in software they maintain. An investigation tied to specific files and code locations gives them something they can return to when the first implementation fails.

For someone who only wants a similar-looking website, this is probably unnecessary setup. REA becomes more interesting when your question concerns behaviour you can't establish from public documentation, your own source code or the interface.

## What REA cannot recover

Inspecting a desktop app or a website doesn't give an agent the private source code of the service behind it. It may find API addresses, request construction and responses visible to the client, but the implementation on the remote server can remain unavailable.

REA's [network-capture workflow](https://github.com/morluto/rea/blob/main/docs/web-network-captures.md?ref=theseguysknow.io) illustrates the boundary. It examines supplied recordings offline, preserving what the capture contains; it doesn't fetch the recorded URLs or reconstruct missing response bodies.

A similar limit applies to native decompilation. Readable pseudocode is an interpretation of compiled instructions, with potentially missing information. You may need further code inspection, runtime observations and comparisons with the original before trusting a replacement.

There's also a difference between understanding a feature and having a finished product. A recovered clipboard route won't supply your app's permissions, error handling, updates or security requirements. Our [checks for AI-built apps](https://theseguysknow.io/claude-code-security-checklist-before-launch/) deal with some of the work that still follows implementation.

The reasonable promise is narrower than cloning an application in one command: REA can help an agent investigate supported software and carry the findings into development.

## How to set it up

The [installation guide](https://github.com/morluto/rea/blob/main/docs/installation.md?ref=theseguysknow.io) lists support for Node.js 22.19 or later within the 22.x series, 24.11 or later within 24.x, and 26+. It excludes Node.js 23, 25 and prereleases, so “any recent Node version” would be misleading advice.

To install a globally available `rea` command and configure the agent, run:

```bash
npm install --global rea-agents
rea setup
```

The project also documents a direct setup route:

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

Setup lets you select the supported agent, review the proposed changes and approve them. It registers the MCP server, installs matching workflow instructions and backs up existing configuration. Restart the agent afterwards so it connects to the server.

Installing the skill alone supplies instructions; it doesn't register the MCP server or provide the analysis engines. If native analysis is your goal, configure a supported provider. Ghidra and IDA use existing installations, while setup can offer a Hopper installation for approval. Those tools have their own requirements and licences.

You can start with static JavaScript analysis without configuring a native engine:

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

Replace the path with an application directory or ASAR you are authorised to examine. A useful first question for the agent is:

> Use REA to trace the export operation in this local application. Show the relevant code locations, distinguish what you observed from what you inferred, and identify anything still missing before proposing an implementation.

### Check the installed version

The version distinction deserves attention because the repository changes quickly. On 12 October, the installation documentation identified npm release **6.4.0** as the published checkpoint and listed DeepSeek Harness support on the newer GitHub `main` branch only. Asking that npm release to configure `dsh` therefore wouldn't establish support.

The documentation also says persistent MCP registrations are pinned to the version that performed setup. Updating instructions doesn't necessarily update the server registration or the running process. Use the setup and update guidance for your installed version, then restart or reconnect the agent.

## What about security

We're enjoying what people are doing with old games and software, but the same analysis tools can help investigate login checks and other security controls. [Researchers already use reverse engineering](https://ccdcoe.org/library/publications/malware-reverse-engineering-handbook/?ref=theseguysknow.io) to understand malware and protect systems, which is valuable work; the concern is that easier investigation could also help someone trying to break into accounts or steal data. For the people affected, it stops being a fun experiment as soon as their security is compromised.

[REA's responsible-use policy](https://github.com/morluto/rea/blob/main/DISCLAIMER.md?ref=theseguysknow.io) rejects unauthorised access, authentication bypasses on systems you're not allowed to test, and circumvention of DRM or anti-cheat protections. It sets the project's support boundaries, but doesn't establish that misuse is technically prevented.

## Final Verdict

REA is worth looking at if you're trying to understand existing software before rebuilding a feature, adapting a system or preserving part of an old game. We like its insistence on retaining file identities, code locations and unresolved questions, because those details let you challenge an agent's explanation when it sounds too confident.

The published examples give the project substance, especially DX-Ball's comparison with original machine code. Start with one question about one supported target, follow the evidence and compare the resulting behaviour with the original before expanding the job.

## FAQ

### Is REA free

REA's own code is open source under MIT. Your coding agent, model usage and external analysis tools may have separate costs or licence requirements; installing REA doesn't include a commercial decompiler licence.

### Does local analysis keep everything off the internet

REA analyses the target locally, but the agent receives its tool results. If the agent uses a hosted model, those results are subject to that provider's data handling. Local analysis alone doesn't establish that the complete workflow stays offline.

### Can I use it by uploading the skill to an ordinary chat

Uploading instructions doesn't give a chat access to local executables, an MCP server or a decompiler. You need an environment able to connect to REA's local tools; the documented setup supports clients including Claude Code, Claude Desktop and Codex, with version-specific configuration.

### Does the MIT licence let me copy another app

The licence covers REA's code and doesn't grant rights to the software being inspected. [Software and creative assets have their own copyright protection](https://www.copyright.gov/help/faq/faq-protect.html?ref=theseguysknow.io), and tool licences and applicable rules still matter. Understanding an implementation and having permission to redistribute it are separate questions.

#### Sources

****REA source and documentation**

- [REA repository and README](https://github.com/morluto/rea?ref=theseguysknow.io), reviewed 12 October 2026.
- [REA MIT licence](https://github.com/morluto/rea/blob/main/LICENSE?ref=theseguysknow.io).
- [REA 6.4.0 release](https://github.com/morluto/rea/releases/tag/rea-agents-6.4.0?ref=theseguysknow.io), 11 October 2026.
- [Installation and setup](https://github.com/morluto/rea/blob/main/docs/installation.md?ref=theseguysknow.io), including the npm/main distinction.
- [Native function tool contracts](https://github.com/morluto/rea/blob/main/src/contracts/functionWorkflowToolContracts.ts?ref=theseguysknow.io).
- [JavaScript and Electron tool contracts](https://github.com/morluto/rea/blob/main/src/contracts/javascript/electronToolContracts.ts?ref=theseguysknow.io).
- [Evidence schema](https://github.com/morluto/rea/blob/main/src/domain/evidence.ts?ref=theseguysknow.io).
- [MCP runtime contracts](https://github.com/morluto/rea/blob/main/docs/mcp-contracts.md?ref=theseguysknow.io).
- [Cross-layer JavaScript application workflows](https://github.com/morluto/rea/blob/main/docs/javascript-application-workflows.md?ref=theseguysknow.io).
- [Managed-code analysis](https://github.com/morluto/rea/blob/main/docs/managed-code-analysis.md?ref=theseguysknow.io).
- [Saved web network captures](https://github.com/morluto/rea/blob/main/docs/web-network-captures.md?ref=theseguysknow.io).
- [JavaScript and Electron worked guide](https://rea.tools/guides/javascript/?ref=theseguysknow.io).
- [REA responsible-use policy](https://github.com/morluto/rea/blob/main/DISCLAIMER.md?ref=theseguysknow.io), reviewed 12 October 2026.

****Published case studies**

- [Notion's Electron clipboard bridge](https://rea.tools/showcase/notion/?ref=theseguysknow.io), including material recorded with REA 4.1.0.
- [DX-Ball sound panning](https://rea.tools/showcase/dx-ball/?ref=theseguysknow.io), with behaviour and compiler-replay checks.
- [DX-Ball reconstruction repository](https://github.com/N0zoM1z0/dx-ball?ref=theseguysknow.io).
- [TH04 DOS bullet patterns](https://rea.tools/showcase/th04/?ref=theseguysknow.io).
- [TH04 reconstruction repository](https://github.com/N0zoM1z0/th04?ref=theseguysknow.io).

****Technical background and copyright**

- [CCDCOE Malware Reverse Engineering Handbook](https://ccdcoe.org/library/publications/malware-reverse-engineering-handbook/?ref=theseguysknow.io), on defensive malware analysis.
- [Model Context Protocol architecture](https://modelcontextprotocol.io/docs/learn/architecture?ref=theseguysknow.io).
- [U.S. Copyright Office: What Does Copyright Protect?](https://www.copyright.gov/help/faq/faq-protect.html?ref=theseguysknow.io).

****TGK**

- [Best AI Coding Harnesses: Top 10 and Tier List](https://theseguysknow.io/best-ai-coding-harnesses/).
- [Mario in Elden Ring, Minecraft in GTA: Game Mashups](https://theseguysknow.io/game-mashups-mario-elden-ring-minecraft-gta/).
- [Vibe-Coded App Security: Checks Before Launch](https://theseguysknow.io/claude-code-security-checklist-before-launch/).