The Pulse
REA collega gli agenti di programmazione agli strumenti di reverse engineering
REA collega gli agenti di programmazione a strumenti per esaminare binari, applicazioni e siti web tramite MCP e un’interfaccia a riga di comando. L’ultimo aggiornamento del progetto descrive ricostruzioni di giochi realizzate con l’aiuto d
AI.info Team · Scritto con l’IA ·
La ricostruzione di DX-Ball presentata da REA ha superato 3.205 casi di test sull’originale x86 e riprodotto tutti i 63 byte di una funzione compilata, secondo la pagina GitHub del progetto. L’esempio mostra che cosa offre questo strumento open source: un modo per consentire agli agenti di programmazione di esaminare un software, ricostruire il funzionamento di una sua funzionalità e usare quanto scoperto per realizzare un’implementazione separata. REA collega gli agenti agli strumenti di reverse engineering tramite il Model Context Protocol (MCP) e un’interfaccia a riga di comando.
Da una domanda a un percorso nel codice
Lo strumento è pensato per rispondere a domande su software di cui non è disponibile il codice sorgente, per esempio sul funzionamento di una funzionalità di un’applicazione. REA può esaminare binari nativi, applicazioni JavaScript ed Electron, assembly .NET e siti web, quindi restituire i risultati con le prove a sostegno e i relativi limiti. Un agente può usare questi risultati per spiegare un comportamento oppure per scrivere e testare un’implementazione adattata al progetto di uno sviluppatore.
Per l’analisi nativa, REA funziona con Hopper, Ghidra o IDA; secondo il progetto, l’esame di JavaScript e .NET può funzionare senza un motore di analisi nativa. I suoi flussi di lavoro sono accessibili anche da terminale, così uno sviluppatore può usare le stesse funzionalità senza una sessione con un agente. Il progetto descrive l’analisi come locale, precisando però che i risultati vengono inviati al fornitore del modello usato dall’agente.
La configurazione registra il server MCP e installa istruzioni per i flussi di lavoro degli agenti supportati, tra cui Claude Code, Codex, Cursor, Gemini CLI e Grok Build. Gli utenti esaminano e approvano le modifiche proposte alla configurazione prima di riavviare il proprio agente. L’installazione standard richiede versioni supportate di Node.js, mentre l’analisi nativa approfondita dipende da un fornitore di servizi di analisi disponibile separatamente.
Che cosa mostrano i risultati delle ricostruzioni
Nell’esempio di DX-Ball, REA segue il calcolo della posizione di un suono nell’eseguibile originale del gioco e verifica una ricostruzione sia con casi di test sia confrontando i byte della funzione compilata. Il progetto presenta anche un lavoro che ricostruisce il percorso dei dati nel collegamento agli appunti dell’applicazione Electron di Notion e la ricostruzione di un calcolo nel gioco DOS TH04. Gli esempi mostrano come gli autori intendono usare REA: non solo per produrre una spiegazione, ma per portare le prove a sostegno fino a un risultato verificabile.
In un articolo sul blog datato 10 ottobre, N0zoM1z0 descrive l’uso degli agenti per ricostruire diversi giochi Touhou e sostiene che le verifiche e le conoscenze accumulate sul progetto permettono di trasferire il lavoro da un’indagine all’altra. L’autore scrive: «Voglio che un’altra persona possa esaminare perché abbiamo scelto un’implementazione, anche se un agente ha svolto la maggior parte del lavoro». L’affermazione richiama un problema di revisione umana accanto a quello tecnico: anche una ricostruzione plausibile ha bisogno di prove che un’altra persona possa esaminare.
L’analisi locale non risolve la questione delle autorizzazioni
Secondo la documentazione di REA, lo strumento non carica l’applicazione esaminata su un servizio di analisi ospitato, ma distingue questo aspetto dal fornitore del modello usato dall’agente, che riceve i risultati dello strumento e applica le proprie regole sul trattamento dei dati. La distinzione conta quando il software esaminato è proprietario o sensibile. L’elaborazione locale indica dove REA svolge l’analisi; non dimostra che un utente abbia il permesso di esaminare un determinato programma.
La nota legale del progetto attribuisce all’utente la responsabilità di avere le necessarie autorizzazioni e di rispettare la legge, e afferma che il software è destinato alla ricerca, all’analisi e alla ricostruzione lecite. L’articolo di N0zoM1z0 affronta anche le tensioni che possono sorgere quando una ricostruzione assistita dagli agenti si basa su precedenti lavori della comunità, anche per quanto riguarda il riconoscimento dei contributi e le regole per contribuire al progetto. REA può organizzare le prove e i test, ma non può decidere se i responsabili di un progetto accetteranno il lavoro risultante o se un utente è autorizzato a esaminare il software originale.
Le prove non sono il codice sorgente originale
La documentazione di REA afferma che l’analisi nativa restituisce pseudocodice e assembly, mentre l’agente usa questi risultati per scrivere e testare una nuova implementazione. La distinzione è importante: il progetto non sostiene di recuperare il codice sorgente originale né di clonare automaticamente un’applicazione. Il risultato identico byte per byte mostrato nell’esempio riguarda la funzione specificata di DX-Ball, non programmi qualsiasi.
Per gli sviluppatori, la proposta concreta è un collegamento strutturato tra strumenti di analisi consolidati e agenti di programmazione, con prove a sostegno dei risultati. Che questo collegamento produca una ricostruzione affidabile dipende dal software esaminato, dal fornitore di servizi di analisi disponibile e dalle verifiche applicate al risultato. La responsabilità di ottenere le necessarie autorizzazioni prima di iniziare l’analisi resta all’utente.