REA AI Reverse Engineering: How It Works and Its Limits

REA connects AI to reverse engineering tools so it can investigate how an app works. Public examples show that specific features can be analyzed and potentially reimplemented. They are not evidence that the software industry is ending or that entire services can be copied.

The DX-Ball verification figures are based on the official case record from October 7, 2026.

What is REA?

REA stands for Reverse Engineer Anything. It is a project that connects software analysis tools to AI agents. It is not a single AI model that performs every analysis on its own.

Reverse engineering is the work of tracing the structure and behavior of finished software. Its aim is to understand what is needed to explain a feature or achieve compatibility.

Compilation turns human-written code into an executable form. Comments and some name information may be lost in the process. Optimization can also change how functions and calculations appear.

Not every app, however, is reduced to machine code with no names. Some distributed packages include JavaScript code or debugging information. The analysis method therefore depends on the file format and the information that remains.

×

Security risks should be controlled before analyzing an untrusted app.

How do AI and Ghidra connect?

REA passes an agent's analysis requests to tools through MCP. MCP is a connection protocol for exchanging requests and results between AI and external tools. Ghidra is a reverse engineering tool for examining executable files.

The official README also describes integrations with Hopper and IDA. JavaScript static analysis does not require a native analysis engine. Describing REA solely as a way to automate Ghidra therefore understates its scope.

Analysis usually follows this sequence.

1. Choose the app and feature to investigate.
2. Find relevant locations through strings or function calls.
3. Interpret the behavior by following instructions and data flow.
4. Check gaps in the evidence with additional tool calls.
5. Compare the reimplementation with the original behavior.

Ghidra already has automated analysis features. REA connects an agent so it can continue making analysis requests. Actual accuracy depends on the target, analysis engine, model, and verification method.

Scope of analysis under different conditions

What REA can check depends on the files and execution environment it can access. A local app may contain code that communicates with a server. That does not mean it contains the server's internal implementation.

Reimplementing a service also requires addressing requirements beyond the observed features. Account permissions and error handling are examples. Even if the interface behaves similarly, that does not establish that the entire service is the same.

What the 8-minute, 41-second calculator experiment verifies

The 8-minute, 41-second figure is a demonstration claim for which the original record has not been verified. The accompanying claim says there were 17 tool calls. The claim that 4 calculation rules were found has not been independently verified either.

The test conditions need to be checked against the original video and execution record. The time required varies with the model and program size. One success is not enough to judge general analysis speed or accuracy.

For a calculator analysis, reading the formulas does not complete verification. The order in which discounts and coupons are applied can change the result. Truncation in integer division also needs to be checked separately.

• The order in which discounts and coupons are applied
• The amount used as the basis for tax calculation
• Where intermediate calculations are rounded or truncated
• Outputs at boundary values where conditions change
• Records comparing the original and reimplemented code with the same inputs

Demonstrating fast analysis requires records beyond the successful answer. Failed runs and the number of retries affect the comparison. The evidence checked so far does not support a general claim that it outperforms people.

Results confirmed in public cases

The official cases cover Notion's clipboard path and a DX-Ball calculation function. Both specify the scope of the feature investigated. It is also important to distinguish these as records published by the REA project.

The Notion case traces how a call from the interface passes through internal communication. It ultimately reaches Electron's clipboard-writing function. This is an example that explains the processing path of a specific feature.

The DX-Ball case confirmed function inputs and calculation constants in the executable file. The function underwent 3,205 comparison tests. After the reviewed relocation handling was accounted for, 63 bytes of the compiled result matched.

This record supports the reimplementation of a specific function. The official document says work on a runnable restoration of the entire game is ongoing. Verification of some functions must be distinguished from completion of the whole product.

What do observation and inference labels guarantee?

Evidence labels distinguish where conclusions came from. REA documentation separates observations, inferences, and unverified information. Not every tool, however, uses the same four labels.

The official documentation uses different status and confidence terms for different types of analysis. It helps to distinguish their meanings as follows. The categories in the table are provided to aid understanding.

The official DISCLAIMER.md states the limits of analysis results.

Decompilation, reconstruction, heuristics, and AI-assisted analysis may be incomplete or incorrect.

Source: REA DISCLAIMER.md

This means decompilation and AI analysis can be incomplete or wrong. An observation label does not eliminate the possibility of a tool error. The value of evidence labels is that they identify what can be reviewed again.

Common mistakes

The most common mistake is treating a plausible explanation as a verified result. Readable code can behave differently from the original. Paths that were not investigated must be noted separately.

REA's CLI documentation also distinguishes successful completion from a complete analysis. Some evidence or questions may remain unresolved even after a task finishes. Check the limitations of the result rather than relying on the completion message.

Records that allow analysis results to be verified again

Reproducible analysis must retain the conditions under which a conclusion was reached. Code can change with an update even when the app name stays the same. Recording only a function address makes it difficult to find the target in another version.

REA's Evidence records preserve target identifiers and evidence locations. Snapshots allow analysis results to be reused when the conditions match. A saved result does not mean the latest version has been verified.

To keep a verification record, follow these steps.

1. Record the target file's version and hash.
2. Record the versions of REA and the analysis engine.
3. Link each conclusion to a file location or function address.
4. Keep the inputs and outputs of the original and reimplemented code together.
5. List conditions that could not be investigated and tests that failed separately.

A hash is an identifier used to compare whether files are the same. Keeping it makes it possible to trace which distributed package an explanation applies to. It also helps distinguish the scope of a result when AI cites it later.

Local analysis and external data transfer

Saying that analysis takes place locally does not rule out external transfer during the overall process. According to the official README, REA analyzes the target locally. The connected AI agent receives the tool results.

If an external model is used, analysis results may be sent to the model provider. The applicable data policy depends on the connected service. For company apps or private files, check the transfer path first.

• The scope of code and strings sent to the model
• Account information and access tokens included in logs
• Personal information in communication records
• Where analysis results are stored and the retention policy

Examining static files must also be distinguished from running a program. Observing execution can affect files or account status. Handle untrusted programs in an isolated test environment.

Security and rights for developers to check

Secrets placed in an app can be exposed through reverse engineering. OWASP describes the problem of putting sensitive information in distributed packages. This risk existed before REA.

In particular, an app must not include a secret API key with server privileges. OWASP advises keeping static secrets on the server. Obfuscation can make extraction harder but does not guarantee secrecy.

• Check distributed files for passwords and secret keys.
• Limit the permissions and validity period of authentication tokens.
• Verify requesters' permissions on the server.
• Replace exposed credentials.

The permitted scope of reverse engineering varies by country, contract, and type of work. It cannot be assumed that every action is permitted because the purpose is compatibility. Analysis and redistribution of code or images must be considered separately.

REA's MIT license does not grant rights to the software being analyzed. The project's usage principles can be checked in the official DISCLAIMER.md. Check the applicable law and the target software's terms for the actual permitted scope.

What changes could this bring to the software industry?

REA shows the potential to lower the cost of understanding existing features. That is a prospect that can be drawn from the published analysis cases. There are no verified figures for cost savings across the industry.

Knowing how some features are implemented is separate from being able to operate a service. Data quality and incident response cannot be copied simply by analyzing an executable file. The ease of imitating features and business competitiveness should therefore be assessed separately.

REA's public cases show a change in how software can be understood. They are not evidence that demand for development is disappearing. Even after a feature is reimplemented, compatibility and operational quality still need to be verified.