REA: reverse engineering con gli agenti AI via MCP

Articolo

Cybersecurity

Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.

Scopri →

CyberAgent

Vulnerability assessment continuo e gap analysis: scansione, mappatura sui requisiti dei framework, evidenze documentali pronte all’uso.

Scopri CyberAgent →

REA, Reverse Engineer Anything, è uno strumento open source (licenza MIT) che collega un agente di programmazione agli strumenti di reverse engineering attraverso un server MCP (Model Context Protocol). È stato pubblicato su GitHub il 14 aprile 2026 e il 18 ottobre è uscita la versione 6.7.0; il 19 ottobre il repository supera le 330.000 stelle.

Il README ne descrive così l’uso tipico: si vede in un’app una funzione che si vorrebbe nel proprio prodotto, si chiede all’agente di studiarla senza il codice sorgente e si ottengono la spiegazione, le evidenze raccolte e una versione da integrare nel proprio progetto. Lo stesso meccanismo serve all’analisi di malware, alla ricerca di vulnerabilità, all’interoperabilità e alla conservazione del software, che sono gli usi che il progetto indica come legittimi.

Come funziona

• Un server MCP. REA è distribuito come pacchetto npm rea-agents e richiede Node.js 22.19, 24.11 o 26 e successive. Il comando npx rea-agents setup lo registra presso l’agente (Claude Code, Codex, Cursor, Gemini CLI e altri), installa le istruzioni di lavoro corrispondenti e salva un backup della configurazione esistente. Gli stessi strumenti sono disponibili da riga di comando, con output JSON.
• Motori di analisi esterni. Per i binari nativi REA si appoggia a Hopper, Ghidra o IDA, e in modo opzionale a Kuna, GNU objdump e Rizin. Le licenze degli strumenti commerciali restano a carico di chi li usa: REA non ne fornisce.
• Evidenze e limiti. Ogni risultato riporta il codice e i riferimenti su cui si basa e ciò che resta ignoto, così l’agente può fare domande successive invece di dedurre.
• Analisi in locale. L’analisi gira sulla macchina dell’utente; i risultati però arrivano all’agente e quindi al fornitore del modello, che ha la sua politica sui dati.
• Nessuna approvazione per chiamata. Secondo la documentazione, REA non chiede conferme per le singole operazioni: le gestisce il client MCP. Alcuni strumenti eseguono il programma analizzato o modificano un dispositivo Android collegato; le annotazioni MCP li segnalano, ma sono indicazioni per il client, non controlli di accesso.

Cosa analizza

Dalla tabella del README, i principali obiettivi:

• binari nativi: pseudocodice, assembly, stringhe, simboli, chiamate e riferimenti;
• applicazioni JavaScript ed Electron: moduli, import, source map, route, IPC e add-on nativi;
• assembly .NET e APK Android (con JADX), anche con un dispositivo collegato via adb;
• firmware (con Binwalk o Unblob), WebAssembly e bytecode EVM;
• siti web e catture di rete (HAR, pcap);
• binari Go e Rust: versione del compilatore e moduli per Go, dipendenze per i binari Rust compilati con cargo-auditable.

I casi pubblicati sul sito del progetto mostrano il livello di dettaglio: in DX-Ball il calcolo del panning audio viene ricostruito in C e la versione ricostruita supera 3.205 casi di test sull’originale x86, riproducendo tutti i 63 byte della funzione compilata; in Notion viene tracciato il percorso degli appunti dall’interfaccia, attraverso preload e IPC, fino al processo principale di Electron.

Il reverse engineering assistito da agenti non nasce con REA: a settembre abbiamo scritto di x64dbg esposto via MCP, sul versante del debug dinamico. REA mette insieme più motori e più tipi di obiettivo dietro un’unica interfaccia.

Cosa prevede la legge

Il progetto avverte che il reverse engineering può essere limitato dalla legge o dalla licenza del software analizzato. In Europa il riferimento è la direttiva 2009/24/CE; in Italia le stesse regole sono negli articoli 64-ter e 64-quater della legge 633/1941:

• chi ha il diritto di usare un programma può osservarne, studiarne e provarne il funzionamento per capirne idee e principi (art. 5, par. 3);
• la decompilazione è ammessa solo quando è indispensabile per l’interoperabilità con un programma creato in modo indipendente, e le informazioni ottenute non possono servire a sviluppare un programma sostanzialmente simile (art. 6);
• le clausole di licenza contrarie a queste due eccezioni sono nulle (art. 8), e le idee alla base del programma non sono protette dal diritto d’autore, il codice sì (art. 1, par. 2).

Il disclaimer di REA esclude l’aggiramento di DRM, controlli di licenza e anti-cheat, l’accesso non autorizzato e la copia di software proprietario, e ricorda che possedere un file non autorizza automaticamente ad eseguirlo o a intercettarne il traffico.

Cosa cambia per chi difende il proprio software

Il costo di capire un binario scende, per chi difende e per chi attacca. Alcune conseguenze pratiche:

• Il codice distribuito va considerato leggibile. Chiavi API, segreti e logiche sensibili dentro un’app desktop, un bundle JavaScript o un APK erano già esposti; con un agente che li cerca in modo sistematico il tempo per trovarli si accorcia. Le source map pubblicate per errore e le superfici IPC delle app Electron sono i primi punti da controllare.
• Dalla patch alla vulnerabilità. Confrontare due versioni di un binario per capire cosa corregge una patch è una tecnica nota; un agente collegato a un decompilatore può renderla più rapida. È ragionevole aspettarsi che il tempo fra una correzione e un exploit si riduca, e quindi che aggiornare in fretta conti di più.
• Supply chain. L’estrazione delle dipendenze incorporate nei binari Go, e in quelli Rust compilati con cargo-auditable, serve anche a chi difende: aiuta a verificare quali librerie e versioni girano davvero nei binari di terzi presenti in azienda.
• Analisi di malware e incident response. Un agente che risponde con le evidenze accelera il primo triage, purché le conclusioni vengano verificate da una persona.
• Isolare lo strumento. Gli strumenti che eseguono il programma analizzato vanno usati in una macchina virtuale o in un ambiente isolato, soprattutto con campioni sospetti; l’approvazione delle operazioni con effetti va configurata nel client, perché REA non la impone.

Dove finiscono i dati

Se il binario da analizzare è software proprietario, codice di un cliente sotto NDA o un campione legato a un incidente, il punto non è solo dove gira l’analisi ma dove finiscono i risultati. Con un modello di un fornitore cloud, pseudocodice e stringhe estratte escono dal perimetro. Con un modello open weight in locale l’intera catena, motore di analisi, agente e modello, resta in azienda, ed è più semplice documentare chi ha analizzato cosa.

Cosa ne pensiamo

REA è un buon esempio di come MCP stia trasformando strumenti specialistici in capacità a disposizione di qualunque agente: Ghidra e IDA esistevano già, quello che cambia è che un agente li usa in sequenza e restituisce evidenze verificabili. Il valore per la sicurezza è concreto, nell’analisi di malware, nella verifica della supply chain e nella ricerca di vulnerabilità. La stessa facilità vale per chi attacca e per chi vuole copiare una funzione: per questo conviene progettare il software partendo dall’idea che il codice distribuito venga letto, e muoversi entro i limiti che la legge europea fissa al reverse engineering. Sullo scenario più ampio, cioè cosa succede al software quando costa poco riscriverlo, rimandiamo all’articolo di Stefano Noferi Intelligence is eating software.

Cosa monitorare

• L’evoluzione del progetto, che rilascia nuove versioni a pochi giorni di distanza.
• L’uso di strumenti simili nell’analisi delle patch e nei tempi di pubblicazione degli exploit.
• Le condizioni d’uso dei produttori di Hopper, IDA e JEB per l’uso automatizzato dei loro strumenti, che il README di REA richiama.

Fonti

• REA, repository su GitHub
• REA, README
• REA, Disclaimer
• REA, contratti MCP ed effetti degli strumenti
• REA, release 6.7.0
• REA, sito e casi d’uso
• Direttiva 2009/24/CE sulla tutela giuridica dei programmi per elaboratore
• Legge 22 aprile 1941, n. 633 (Normattiva)
• Stefano Noferi, Intelligence is eating software
• Reverse engineering agentico: x64dbg esposto via MCP