REA Investigated: How AI-Assisted Reverse Engineering Works

What is REA—and why are people paying attention?

You can use an application every day without knowing how its features work under the surface. REA gives AI assistants a way to investigate that behavior—even when the original source code is unavailable.

REA (Reverse Engineer Anything) is the open-source project at morluto/rea that connects AI agents to software-analysis workflows. It exposes analysis operations through a command-line interface—typed terminal commands—and a tool server for compatible AI applications. An agent is an AI application that can use tools across a multi-step task. REA supplies access to analysis tools, not the underlying AI model.

The distinction matters: investigating a finished application, writing a similar implementation, and recovering its original source are different achievements. REA’s usefulness depends on the evidence gathered, the checks applied, and the responsibilities that remain. “Anything” is the project’s name, not a guarantee that every product can be faithfully recreated.

Reverse engineering: learning from the finished program

Reverse engineering means learning how something works by examining the finished result. Think of a machine without its original design drawings: inspecting its parts and behavior can support a new design, but does not give you the designer’s original drawings. Likewise, understanding software’s behavior does not recover the source code its developers wrote.

For a native executable, the processor-ready form of a program, a compiler translates source code into machine instructions. These are operations the processor understands. Compilation can also optimize the program, rearranging or combining work while preserving its intended behavior. The result is executable software, not a compressed archive of the source project.

Disassembly presents machine instructions as readable assembly. Decompilation goes further, inferring higher-level, source-like logic called pseudocode. Tools such as Ghidra provide both views:

1) Forward production path:
Original source
       ↓
Compile / optimize
       ↓
Native executable

2) Separate analysis path:
Native executable
       ↓
Disassembly / decompilation
       ↓
Assembly / inferred pseudocode
  Original names, comments and structure may be missing
       ↓
Behavior to verify

Native-code case: compilation produces the executable; analysis infers a readable view and behavior to verify. There is no guaranteed reverse path to the original source files.

Information loss is uneven. Comments and many names can disappear, while text strings, some names, and descriptive metadata remain. Optimization may make familiar source structures hard to recognize. Different source implementations can also produce similar machine behavior, so a plausible reconstruction need not match the programmer’s original expression.

Not every application is native machine code. Packaged JavaScript may contain readable source or minified code, shortened for distribution. Reading source-like material already present in a package is different from inferring pseudocode from machine instructions. What survives determines what questions analysis can answer.

How REA turns a question into an evidence loop

The project’s DX-Ball investigation started with a practical question: how does a brick’s horizontal screen position determine sound panning, the balance between left and right audio? The first decompiler view showed a call that converted a number, but left out the input and calculation behind it. It was not enough to explain the sound’s position.

The instruction view revealed the missing input and arithmetic. Inspecting the function that called it showed that the input was the brick’s screen coordinate. Reading the stored values supplied the calculation’s fixed numbers and the setting that scaled the panning.

The result was a concrete rule: at the usual scale, the screen’s center maps to centered panning, while positions to either side shift the balance left or right. The reconstruction project could then write that rule in C and compare it with the original function.

Four roles make that investigation possible.

• You set the authorized question.
• The agent chooses follow-ups and interprets results.
• REA provides tool access and returns evidence.
• An analysis engine or parser inspects the target artifact—the file or package being examined.

Native engines include Ghidra, Hopper, and IDA.

The connection uses Model Context Protocol (MCP), a standard way for AI applications to reach external tools and systems. REA’s MCP server is the software exposing those operations, not a machine you must rent. A skill supplies investigation instructions for the agent; the server supplies access to the operations themselves. The core exchange looks like this:

Your feature question
         ↓
Agent
         ↕ MCP
REA tool server
         ↕
Analysis engine / parser
         ↕
Target software

Requests travel toward the target; evidence returns to the agent, which uses it to choose the next question. The exchange repeats as the investigation develops.

The agent coordinates those follow-ups and connects the returned code and references into an explanation. Evidence records identify the file and code locations, separating observations from inferences and unresolved findings. A reviewer can therefore trace the explanation back to its supporting material. The agent may also draft candidate code and tests, as a separate step from establishing what the original does.

For any target, distinguish static inspection, which reads artifacts without running the program, from runtime observation or interaction, which examines it while running. Where that inspection happens is also separate from where the model processes its findings. If the agent uses a hosted model, returned results may leave the analysis machine.

What kinds of software can REA inspect?

Visibility depends on the target. Electron packages desktop software using web technologies, while .NET and Android represent distinct application families with different analysis paths. Each exposes different information, as the table shows:

REA documents broader artifact coverage beyond these categories. Check the official target overview and current documentation: requirements vary by engine, host platform, target, and release. These describe available inspection workflows, not verified reconstructions of each target.

A convincing demo is not a verified reconstruction

Public demonstrations give a more concrete picture of what REA can do. In one calculator recreation shared online, AI-assisted analysis produced a Python version of GNOME Calculator. Alongside visible recreations like this, narrower projects compare a rebuilt calculation directly with the original.

Public demonstration — reported secondhand
The recreation resembled GNOME Calculator and matched a basic arithmetic result. Reported resizing problems exposed a visible mismatch that a successful arithmetic check would not catch.

Project-reported function reconstruction
The DX-Ball showcase reports 3,205 original-x86 comparison cases for one position-to-sound-pan function, plus matching compiled bytes using a historical compiler.

The calculator demonstrates a visible recreation; DX-Ball documents checks of a specific calculation. Each result answers a different question.

For DX-Ball, the comparisons covered screen positions and several panning strengths. They checked the C function’s return values against those from executing the original instructions. Compiling that C with a historical compiler also reproduced the function’s bytes. These are two distinct checks: agreement on tested outputs and agreement on the compiled function, without requiring the programmer’s original source text.

GNOME Calculator also has advanced, financial, and programming capabilities. The simple arithmetic comparison leaves those features unassessed, rather than showing whether they work or fail in the recreation. Its source is public, so source review may be the more direct starting point when it answers your maintenance question. The useful progression is from visual resemblance to selected behavior checks, then systematic comparisons for the behavior you need.

Where the “anything” promise reaches its limits

Missing source context can make a component difficult to interpret. Optimization may obscure its logic, while obfuscation deliberately makes code harder to understand. External dependencies create another gap: some execution paths need inputs, services, or conditions unavailable during investigation. Even careful analysis can leave edge cases unresolved when a feature relies on behavior outside the inspected component.

An independent counterweight comes from Ishank Choudhary’s report of 14 October 2026, covering REA 6.4.0. He found useful Electron application structure but missed preload connections: the bridge code linking an Electron page with desktop-side capabilities. He tested static tools without an agent or native analysis engines; the findings concern that release and workflow, not every current version.

The report also described relationships omitted from the application summary because of result budgets—limits on retained output. Some facts remained at file level without their connections appearing in the summary. A completed scan with no match therefore meant the retained analysis had not found the relationship, not that the feature was absent. Its coverage limits explained the miss.

The effort starts with setting up the analysis engine and providing the processing power and memory it needs. Model use brings its own considerations: context determines how much material it can consider at once, while tokens are the units of text it processes. Repeated queries add effort, followed by testing and human repairs after the first output. Actual bills, hardware needs, and completion times depend on the target and question. Measuring REA’s own contribution to speed or quality would require a controlled comparison.

Useful applications beyond copying an app

For developers, self-hosters, and migration teams, the value often lies in answering a specific maintenance or compatibility question. The following scenarios are illustrative, not tested deployments or results from this publisher.

🛠️ Developer / maintainer

A maintainer comparing two authorized versions of a legacy utility might ask why an import result changed. REA could help locate the parsing logic and guide regression checks. If the complete source already answers that question, start there; otherwise, validate the inferred cause against the changed behavior.

🏠 Self-hoster

A self-hoster working with an old local file format might use REA to understand its fields. Those findings could help define an independently implemented compatibility bridge. A lawful, drop-in replacement for the proprietary dependency would still require testing undocumented cases and checking the applicable rights.

💼 Business / migration team

A migration team may need to know whether a required export behavior can be supported before commissioning implementation. REA could help establish technical feasibility and clarify what needs building. That finding can inform an investment decision, while delivery estimates, support commitments, and full compatibility require further assessment.

Education and authorized security research can use the same approach. Before moving from an explanation to further action, define what may be inspected, run, or shared. That scope governs the investigation even when the technical question seems straightforward.

Technical access does not settle authorization, privacy, or trust

Permission to inspect a file may differ from permission to run it, observe its traffic, publish findings, or reuse protected material. Rights depend on applicable law and contracts: conditional interoperability rights, including those in the US, are not worldwide rules, and owning a copy does not authorize every operation.

REA’s MIT license covers REA-authored code, not target applications, protected assets, or automatically generated output. Commercial analysis engines need their own licenses. The responsible-use disclaimer defines intended uses and community support boundaries without amending MIT; recovered source does not automatically become open source or redistributable.

⚠️ Warning: Privacy and execution risks

Local analysis can send findings—including code, credentials, or personal data—to the agent’s model provider. Check outbound data and provider terms before analyzing confidential targets. REA is not a sandbox: static parsing can expose tool vulnerabilities, while running or interacting with targets can alter files or affect accounts and services. Review the actual operations and containment, not just where tools run.

Use official package and update sources, but also review dependencies, generated output, maintenance ownership, and how fixes arrive. Apply the same scrutiny to vendor software, open-source projects, and AI-generated alternatives: official origin, price, source availability, or building from source cannot replace a clear provenance and review history.

What REA means for software ownership and the cloud

Reconstructing software once does not fund its future. Someone must keep vulnerabilities patched and preserve compatibility. Supporting users and developing the product require continuing work too. More accessible investigation may complement expert work; these examples do not show developers or paid software becoming obsolete. Dependable updates and accountable support remain reasons to choose a product, even when its implementation becomes easier to understand.

Vendors could respond by moving more functionality to remote-only delivery, but the evidence here does not establish a REA-driven trend. The technical distinction is client versus server: a browser receives interface code and responses, while server-side implementation normally stays with the operator.

Browser / client: delivered UI and scripts
Inspectable to the extent delivered / authorized
                   ↕
           Requests / responses
                   ↕
Server: application logic and database
Behavior observed ≠ exact private source revealed

A visibility boundary, not a complete security boundary: browser resources and responses can be examined; backend code normally stays remote. Exposed data and other security problems remain possible.

Those API responses—data exchanged with the service—may reveal enough about a feature’s behavior to inform a new implementation. That route relies on observable inputs and outputs rather than access to the backend code. Keeping the code remote also does not eliminate bugs, exposed data, or the possibility of authorized investigation.

With SaaS, software as a service, a vendor operates the application.

• Self-hosting an authorized application gives you more control over deployment. You then take responsibility for patching and managing access.
• Backups, monitoring, and recovery also become part of keeping that application running.

An AlexHost Ubuntu VPS is one infrastructure option for a reviewed application or compatibility bridge. Full root access gives you control over the guest operating system. It does not secure the application automatically or make external model processing private.

The takeaway: easier investigation, not automatic recovery

A recognizable calculator window can be a promising first result. The next questions are whether the behavior you need has been checked and who will maintain it. REA helps investigate that behavior; implementation, verification, and dependable operation remain separate work.

For deeper reading, start with the official REA project and its DX-Ball showcase. Focus on one small, authorized question and the evidence behind the answer. That is a more useful starting point than asking whether AI can copy an entire product.