Cybersecurity

CISO-as-a-service consulting: posture, remediation roadmap, ongoing support.

CyberAgent

Continuous vulnerability assessment and gap analysis: scanning, mapping onto framework requirements, documentary evidence ready to use.

Discover CyberAgent →

Four figures on REA, the reverse engineering tool for AI agents — Data from the REA repository and documentation. Sources at the end.

REA, Reverse Engineer Anything, is an open-source tool (MIT licence) that connects a coding agent to reverse engineering tools through an MCP (Model Context Protocol) server. It was published on GitHub on 14 April 2026 and version 6.7.0 came out on 18 October; on 19 October the repository has more than 330,000 stars.

The README describes the typical use like this: you see a feature in an app that you would like in your own product, ask the agent to study it without the source code, and get an explanation, the evidence gathered and a version to integrate into your project. The same mechanism serves malware analysis, vulnerability research, interoperability and software preservation, which are the uses the project lists as legitimate.

How it works

An MCP server. REA ships as the npm package rea-agents and requires Node.js 22.19, 24.11 or 26 and later. The npx rea-agents setup command registers it with the agent (Claude Code, Codex, Cursor, Gemini CLI and others), installs the matching workflow instructions and backs up the existing configuration. The same tools are available from the command line, with JSON output.
External analysis engines. For native binaries REA relies on Hopper, Ghidra or IDA, and optionally on Kuna, GNU objdump and Rizin. Licences for commercial tools are the user’s responsibility: REA provides none.
Evidence and limits. Each result reports the code and references it is based on and what remains unknown, so the agent can ask follow-up questions instead of guessing.
Local analysis. Analysis runs on the user’s machine; the results, however, reach the agent and therefore the model provider, which has its own data policy.
No per-call approval. According to the documentation, REA does not ask for confirmation of individual operations: that is left to the MCP client. Some tools run the analysed program or change a connected Android device; MCP annotations flag them, but they are hints for the client, not access controls.

What it analyses

From the README table, the main targets:

native binaries: pseudocode, assembly, strings, symbols, calls and references;
JavaScript and Electron applications: modules, imports, source maps, routes, IPC and native add-ons;
.NET assemblies and Android APKs (with JADX), also with a device connected over adb;
firmware (with Binwalk or Unblob), WebAssembly and EVM bytecode;
websites and network captures (HAR, pcap);
Go and Rust binaries: compiler version and modules for Go, dependencies for Rust binaries built with cargo-auditable.

The cases published on the project website show the level of detail: in DX-Ball the audio panning calculation is reconstructed in C and the reconstruction passes 3,205 test cases against the original x86, reproducing all 63 bytes of the compiled function; in Notion the clipboard path is traced from the interface, through preload and IPC, to Electron’s main process.

Agent-assisted reverse engineering did not start with REA: in September we wrote about x64dbg exposed over MCP, on the dynamic debugging side. REA brings several engines and several kinds of target behind a single interface.

What the law says

The project warns that reverse engineering may be restricted by law or by the licence of the software analysed. In Europe the reference is Directive 2009/24/EC; in Italy the same rules are in Articles 64-ter and 64-quater of Law 633/1941:

anyone entitled to use a program may observe, study and test its functioning to determine its ideas and principles (Art. 5(3));
decompilation is permitted only when indispensable for interoperability with an independently created program, and the information obtained may not be used to develop a substantially similar program (Art. 6);
licence terms contrary to these two exceptions are void (Art. 8), and the ideas underlying a program are not protected by copyright, while its code is (Art. 1(2)).

REA’s disclaimer excludes circumventing DRM, licence checks and anti-cheat systems, unauthorised access and copying proprietary software, and points out that possessing a file does not by itself authorise running it or intercepting its traffic.

What changes for those defending their software

The cost of understanding a binary falls, for defenders and attackers alike. Some practical consequences:

Distributed code should be treated as readable. API keys, secrets and sensitive logic inside a desktop app, a JavaScript bundle or an APK were already exposed; with an agent looking for them systematically, the time to find them shortens. Source maps published by mistake and the IPC surfaces of Electron apps are the first things to check.
From patch to vulnerability. Comparing two versions of a binary to understand what a patch fixes is a known technique; an agent connected to a decompiler can make it faster. It is reasonable to expect the time between a fix and an exploit to shrink, so updating quickly matters more.
Supply chain. Extracting the dependencies embedded in Go binaries, and in Rust binaries built with cargo-auditable, also helps defenders: it shows which libraries and versions actually run inside third-party binaries in the company.
Malware analysis and incident response. An agent that answers with evidence speeds up the first triage, provided a person verifies the conclusions.
Isolating the tool. Tools that run the analysed program should be used in a virtual machine or an isolated environment, especially with suspicious samples; approval of operations with effects has to be configured in the client, because REA does not enforce it.

Where the data ends up

If the binary to analyse is proprietary software, a client’s code under NDA or a sample linked to an incident, the point is not only where the analysis runs but where the results end up. With a cloud provider’s model, extracted pseudocode and strings leave the perimeter. With a local open-weight model the whole chain, analysis engine, agent and model, stays in house, and it is easier to document who analysed what.

What we think

REA is a good example of how MCP is turning specialist tools into capabilities available to any agent: Ghidra and IDA already existed, what changes is that an agent uses them in sequence and returns verifiable evidence. The value for security is concrete, in malware analysis, supply-chain checks and vulnerability research. The same ease applies to attackers and to anyone who wants to copy a feature: that is why software should be designed on the assumption that distributed code will be read, and why reverse engineering should stay within the limits set by European law. For the broader picture, what happens to software when rewriting it becomes cheap, we refer to Stefano Noferi’s article Intelligence is eating software.

What to watch

How the project evolves: it ships new versions a few days apart.
The use of similar tools in patch analysis and in the time it takes for exploits to be published.
The terms of the vendors of Hopper, IDA and JEB for automated use of their tools, which REA’s README refers to.

Company

Actions

Links

Products

Solutions

Industries

REA: reverse engineering with AI agents over MCP