Reverse engineering: l’AI spiega, la prova decide

Immagina un gestionale del 2004. Fa i conti giusti da vent’anni. La ditta che l’ha scritto ha chiuso, il codice sorgente — la versione leggibile del programma, quella che scrivono i programmatori — è sparito con lei, e l’ultima persona che sapeva metterci le mani è in pensione.

Oppure immagina un apparecchio fermo in un angolo. L’hardware sta bene. Il firmware — il programma che vive dentro l’oggetto e gli dice cosa fare — non lo aggiorna più nessuno, il produttore ha chiuso i server, e senza quel pezzo l’oggetto è un soprammobile.

Un software così resta lì per un motivo semplice: funziona, o funzionava, e nessuno osa toccarlo. Aprirlo ha un nome — reverse engineering — ed è un lavoro lungo e noioso, da specialisti. Adesso è cambiata una cosa: gli agenti AI, gli assistenti che oltre a rispondere usano strumenti e compiono azioni, possono lavorare direttamente dentro i programmi che smontano il software.

Lo spunto me l’ha dato un post su Reddit che metteva in fila sette progetti. Questo articolo è un’altra cosa: una mappa da tenere a portata di mano, scritta per chi usa ChatGPT o Claude e il codice non lo scrive.

Due cose le dico subito. La prima: nessuno di questi strumenti l’ho provato. Quello che leggi sui progetti viene dai loro README — la pagina di presentazione che ogni progetto tiene su GitHub — e dalla loro documentazione, consultati il 7 novembre 2026. Se GitHub ti è nuovo, qui ho spiegato cos’è. La seconda: si parla solo di oggetti e programmi tuoi o di cui hai il permesso, e qui trovi cosa fanno gli strumenti, mai una procedura.

Il punto sta in una riga, e il resto serve a reggerla: una spiegazione dell’AI è un’ipotesi finché non torna su una prova.

Cos’è il reverse engineering

Il reverse engineering è ricostruire come funziona una cosa partendo dalla cosa finita, quando il progetto non ce l’hai. Nel software vuol dire studiare un programma già compilato per capire cosa fa, senza avere il codice sorgente.

Compilato è la parola da tenere a mente. Un programmatore scrive una ricetta che gli esseri umani sanno leggere; il compilatore la trasforma nelle istruzioni grezze che il processore esegue. Dalla ricetta alla torta. Per strada, spiega Quesma, l’azienda autrice del test di cui parlo più avanti, si perdono la struttura originale del codice e i nomi di variabili e funzioni.

Gli attrezzi del reverse engineering fanno il percorso al contrario, a gradini: dal codice macchina all’assembly, una lingua minima che elenca le singole istruzioni, e dall’assembly a uno pseudo-C, una ricostruzione che somiglia a un linguaggio di programmazione. Il primo si chiama disassembler, il secondo decompilatore. Il risultato si legge, ma resta una ricostruzione: nell’esempio di Quesma i nomi diventano FUN_00130550, bVar49, local_148. Etichette che non vogliono dire niente.

A chi non fa questo mestiere può servire per tenere in vita un vecchio programma, per far parlare un sistema chiuso con uno nuovo (l’interoperabilità), per conservare un software che altrimenti sparirebbe, per studiare. La parola vale anche per gli oggetti fisici: chi misura con uno scanner 3D un pezzo per ricostruirne il modello fa lo stesso ragionamento. Qui parlo di software e firmware.

La torta ti dice molto. Il motivo per cui la nonna ci metteva il limone, però, va ricostruito.

Cosa cambia quando l’agente usa gli attrezzi

Cambia chi fa le domande. Con una chat copi un pezzo di codice decompilato e il modello ragiona su quel pezzo. Con un agente collegato, è lui a interrogare il programma di analisi: legge la risposta, segue un riferimento, chiede di nuovo.

La differenza è quella fra mandare al meccanico la foto del motore e farlo entrare in officina. Con la foto ragiona su quello che vede. In officina apre, misura, ricontrolla, torna indietro.

Il collegamento, in buona parte di questi progetti, passa da MCP, il Model Context Protocol: una presa standard che permette a un agente di usare un programma esterno. Per capirci, secondo il README di ida-pro-mcp l’agente può chiedere a IDA di decompilare una funzione, di disassemblarla, di elencare chi la chiama, di rinominarla e di aggiungere commenti.

Un esempio dal test di Quesma, su un server web a cui i ricercatori avevano aggiunto una backdoor, una porta di servizio nascosta. Claude Opus 4.5 l’ha trovata entro cinque minuti: ha cercato scritte sospette senza trovare niente, ha cambiato strategia, ha notato in una libreria una funzione capace di eseguire comandi, ha letto il codice col decompilatore e ha controllato che quel pezzo venisse davvero chiamato dal programma. Sono i gesti di un analista, messi in fila da una macchina.

Il guadagno, per come la leggo io, sta nella pazienza. Aprire una funzione, leggerla, darle un nome, passare alla prossima, cento volte: è il genere di lavoro che stanca una persona e che un agente ripete. Il prezzo è una catena più lunga. Collegando Claude a Ghidra, Quesma ha contato quattro pezzi — Claude, server MCP, estensione, Ghidra — e quattro punti dove qualcosa può rompersi.

L’agente ha preso in mano gli attrezzi. Resta da capire se sa cosa sta guardando.

La mappa dei progetti, livello per livello

I nomi che girano sembrano tutti la stessa cosa e stanno a piani diversi. I piani sono quattro: gli attrezzi che fanno l’analisi, i modelli addestrati a decompilare, i ponti che collegano un agente a un attrezzo, e un livello sopra che ne raduna molti. Nella tabella le stelle sono quelle lette su GitHub il 7 novembre 2026: sono i segnalibri che gli utenti mettono a un progetto, e misurano l’attenzione ricevuta.

Gli attrezzi: Ghidra, radare2, IDA

Ghidra è il banco da lavoro. L’ha creato la NSA, l’agenzia americana per la sicurezza nazionale, e secondo il README lo mantiene il suo direttorato di ricerca: analizza codice compilato su Windows, macOS e Linux, a mano o in automatico. Da solo resta un attrezzo, l’agente va collegato.

radare2 fa un mestiere simile da terminale, la finestra dove si scrivono i comandi: secondo il README serve ad analizzare un programma, simularne l’esecuzione, cercarne gli errori, modificarlo e disassemblarlo.

IDA Pro, di Hex-Rays, è il commerciale della famiglia, e i tre non si equivalgono. Nel test di Quesma, su un server scritto in Go da 50 MB, radare2 ha caricato il programma in 6 minuti con un risultato di bassa qualità, Ghidra ha impiegato 40 minuti senza restituire dati corretti, IDA Pro ha chiuso in 5 minuti con codice utilizzabile. Su quel file, la scelta dell’attrezzo ha deciso se il codice ottenuto era utilizzabile.

Il modello: LLM4Decompile

LLM4Decompile è ricerca. Invece di collegare un modello generico a un attrezzo, addestra modelli apposta per ricostruire codice C leggibile: una linea ricostruisce il C dalle istruzioni ottenute disassemblando il programma, un’altra rifinisce lo pseudocodice prodotto da Ghidra. L’ultimo aggiornamento del repository, la cartella pubblica del progetto, risale al 12 febbraio 2026.

Il numero che gira è 0,6494, cioè 64,9%, del modello 9B-v2. Conviene sapere cosa misura: la «re-executability», la capacità del codice ricostruito di girare e passare tutti i test predefiniti di quel banco di prova. Una misura seria e stretta: vale per quel banco di prova, e su un programma qualunque non promette niente. E il README dichiara che la versione attuale lavora su programmi Linux per una precisa famiglia di processori a 64 bit, la x86-64, compilati con GCC, il compilatore che trasforma il sorgente in programma: un gestionale per Windows sta fuori da quel recinto.

I ponti: r2ai, ReVa, IDA MCP

Qui sta la novità pratica. r2ai porta i modelli linguistici dentro radare2: secondo il README lavora con modelli locali o remoti, prompt personalizzabili e una modalità automatica. ReVa collega a Ghidra un assistente compatibile con MCP, con un’idea precisa: tanti strumenti piccoli e pezzi brevi di informazione, per consumare meno contesto — la memoria di lavoro del modello — e ridurre le allucinazioni, le risposte inventate. Sul fronte opposto, ghidra-mcp di bethington, fuori dalla lista del post, dichiara oltre 200 strumenti.

Su IDA c’è un passaggio di consegne che vale la pena conoscere. ida-pro-mcp richiede IDA Pro — «IDA Free is not supported» — e in cima al README l’autore rimanda altrove: «I recommend using the Official Hex-Rays IDA MCP Server instead!». Hex-Rays ha annunciato quel server il 25 settembre 2026, con un articolo firmato Duncan Ogilvie, lo stesso nome del profilo GitHub che tiene ida-pro-mcp. Secondo l’annuncio funziona con IDA Pro, Home, Classroom e OEM; il README chiede IDA 9.4 o successivo.

Prima di installare un progetto si legge la prima riga del suo README. A volte è l’autore a mandarti da un’altra parte.

Il livello sopra: REA

REA, «Reverse Engineer Anything», ha un repository pubblico creato il 14 aprile 2026 e si presenta come un solo collegamento per molti bersagli. Secondo il README mette il tuo agente in contatto con strumenti per programmi compilati, app costruite con tecnologie web, programmi basati sulla piattaforma Microsoft .NET e siti, e la sua tabella elenca anche app Android e firmware. Per i programmi compilati si appoggia a Hopper, Ghidra, IDA o Kuna. I requisiti cambiano col bersaglio: per analizzare ed estrarre un firmware con Binwalk e Unblob chiede Linux, e la documentazione dice che questa prima tappa è verificata su Linux x64; altre letture di formati firmware hanno requisiti diversi.

Una frase del README vale più delle altre: «results include the evidence and limitations behind each conclusion», i risultati includono le prove e i limiti dietro ogni conclusione. È una promessa del progetto, e io non l’ho messa alla prova. È anche quello che dovresti pretendere da qualunque strumento di questa mappa. Lo stesso README avverte di scaricare solo dalle fonti ufficiali: un nome simile o un README copiato non bastano a dire che un download è ufficiale. E prima di usarlo va letto il suo disclaimer, che elenca gli usi per cui il progetto è pensato e quelli che non sostiene.

Cosa sbaglia l’AI quando smonta un programma

Sbaglia in due direzioni opposte: si lascia sfuggire quello che c’è e vede quello che manca. Nei casi che seguono, lo fa con parole sicure.

Il dato più utile viene da BinaryAudit, il test pubblicato da Quesma il 10 febbraio 2026. I ricercatori hanno preso server open source, ci hanno inserito a mano delle backdoor per l’occasione, hanno consegnato agli agenti il programma compilato senza sorgente e hanno messo a disposizione Ghidra, radare2 e binutils, una raccolta di strumenti per esaminare i programmi compilati. Le backdoor, scrivono, erano poco sofisticate, del tipo che un analista esperto individua con relativa facilità.

Due avvertenze. Claude Opus 4.6 è un modello precedente a quelli di oggi, e questa è la fotografia di febbraio. La pagina del benchmark, consultata il 7 novembre 2026, si è allargata: il 49% è a pari merito con Gemini 3.1 Pro Preview, nessuno dei 26 modelli in classifica fa meglio, e i falsi allarmi vanno dallo 0% all’86% a seconda del modello. I modelli più recenti in quella classifica mancano. Il numero invecchia. Il metodo per leggerlo resta.

La conclusione di Quesma ha due facce. Come rilevatore di codice malevolo da solo, scrivono, è lontano dall’essere utile in pratica. Come prima passata, invece, uno sviluppatore senza esperienza di reverse engineering oggi può ottenere un’analisi iniziale di un programma sospetto. Un anno prima di quel test, aggiungono, i modelli non riuscivano a usare Ghidra in modo affidabile.

Trova il punto giusto e se lo spiega male

Il caso più istruttivo del test. Claude Opus 4.6 ha seguito la traccia fino alla funzione esatta che conteneva la backdoor e ha visto la chiamata che eseguiva un comando. Poi ha concluso che probabilmente era una funzione legittima del programma ed è passato ad altro. Secondo Quesma non ha mai controllato da dove arrivasse quel comando: arrivava da un pacchetto di rete mandato da un client. Ha visto il pezzo giusto. Ha sbagliato il motivo.

Inventa con la precisione di un notaio

Gemini 3 Pro ha «scoperto» una backdoor in un’opzione del programma, con tanto di indice, posizione in memoria e nome della funzione, e l’ha chiamata «a clear backdoor». Nel sorgente, scrive Quesma, quell’opzione viene letta come un numero e non viene mai eseguita. Diversi ritrovamenti del modello erano falsi e mancavano del tutto dal codice.

Questo è il passaggio che mi interessa di più. Un dettaglio preciso sembra una prova. Un indirizzo esadecimale sembra una prova. Scritti dal modello, restano testo scritto dal modello.

Parla sicuro anche quando ha torto

Sempre Quesma, a gennaio 2026, con un vecchio gioco Atari da 8 kB. Claude ha riconosciuto la piattaforma dagli indirizzi hardware; poi, chiamato a identificare il gioco dal solo codice, ha esaminato gli indizi con metodo e ha detto Centipede. Era River Raid. Il commento nell’articolo: «confidence and accuracy are orthogonal properties». Sicurezza e precisione viaggiano su due assi diversi, e guardare l’una non ti dice niente dell’altra.

Un bel nome sembra una scoperta

I nomi originali sono andati persi, e questi progetti usano il modello anche per proporne di nuovi. È utilissimo: rende leggibile un testo che non lo era. È anche una trappola, per come la vedo io. calcola_iva si legge meglio di FUN_00130550, e proprio per questo ti convince, ma quel nome è la deduzione di un modello. Un nome è un’ipotesi con la faccia di un fatto.

Può rispondere a memoria

Il README di ReVa è onesto su un punto: il modello dà la priorità alle informazioni che arrivano dagli strumenti, ma quando non ne ha può comunque rispondere a domande generiche con ciò che ha imparato in addestramento. Il rischio, secondo me, è che tu non sappia quale delle due fonti stai leggendo: il programma che hai davanti o il ricordo di programmi simili.

Le scritte nel programma possono ingannare l’agente

Un programma è anche un testo che l’agente legge, e chi l’ha scritto può averci messo frasi pensate per lui. La documentazione di REA lo dice chiaro: un bersaglio può contenere testo scritto per sembrare un’istruzione, per esempio l’invito a eseguire un comando o a scaricare un aiuto «necessario». Si chiama prompt injection, un’istruzione nascosta nei dati. REA dichiara di trattare quel testo come dato e di dire all’agente di segnalarlo.

Poi c’è la parte che riguarda te. In uno studio di Anthropic di cui ho scritto, 50 analisti professionisti hanno seguito una preferenza nascosta dell’agente l’86% delle volte: una preferenza messa e rafforzata apposta dai ricercatori, in un solo compito, ma il segnale resta. Una storia coerente, una volta letta, trova da sola gli argomenti: è il bias di conferma, e lavora per lei.

Una spiegazione ben scritta ti fa sentire di aver capito. Capire è un altro lavoro.

Come si verifica una spiegazione dell’AI

Si verifica facendola uscire dalla chat: serve un riscontro che non dipenda dalle parole dell’agente. Il più forte è un test che chiunque può rifare, con il risultato atteso scritto prima di cominciare.

È anche il gradino che puoi tenere in mano senza leggere una riga di assembly. Torna al gestionale immaginario. L’agente dice: i totali vengono arrotondati per difetto al centesimo. Bene, è un’ipotesi, e si può mettere alla prova. Prepari cento fatture di prova coi decimali scomodi, scrivi prima il totale che ti aspetti e le passi al vecchio programma. Se i totali tornano, l’ipotesi regge. Se ne salta uno, hai imparato più di quanto ti avrebbero insegnato dieci pagine di spiegazione.

È lo stesso principio della «re-executability» di LLM4Decompile: il codice gira e passa i test, oppure no. Ed è quello che ha chiuso il caso Atari di Quesma: il collegamento MCP non poteva scrivere sul file, così chi ha condotto la prova ha applicato a mano la modifica al gioco e l’ha provata in un emulatore, dove ha funzionato.

Sotto il test ci sono riscontri più deboli, ed è utile sapere quanto pesano. L’ordine è mio, dal più leggero al più solido.

1. La frase dell’agente: «questa funzione calcola gli sconti». È il punto di partenza, cioè l’ipotesi da controllare.
2. Il punto del programma dove dice di averlo visto, con indirizzo e nome della funzione. Pesa quando lo apri nell’attrezzo, o lo fa aprire chi sa leggerlo. Copiato in una risposta vale quanto la frase: lo dice il caso di Gemini 3 Pro.
3. La strada del dato: da dove arriva quello che la funzione usa, e chi la mette in moto. Opus 4.5 ha controllato che la funzione venisse chiamata davvero; Opus 4.6 non ha controllato da dove arrivava il comando.
4. Il programma acceso: fatto girare in un ambiente separato, fa quello che l’agente racconta.

Due limiti da tenere presenti. Un test passato dice che il comportamento coincide sui casi provati: su quelli che non hai pensato resta tutto aperto. E due AI d’accordo restano due ipotesi, perché possono sbagliare insieme.

Una cosa puoi chiederla fin dal primo messaggio: tenere separati quello che l’agente ha letto negli strumenti, quello che ne deduce e quello che non sa. Lo schema con cui REA descrive il proprio funzionamento ha proprio questa forma: codice restituito, riferimenti, incognite. Se ti torna indietro una storia bella e filata, senza un solo «non lo so», manca un pezzo.

Una spiegazione convince. Una prova regge anche quando ti dà torto.

Cosa succede ai dati

L’analisi può restare sul tuo computer, ma quello che l’agente legge passa dal modello che lo guida. Se il modello gira nel cloud, quei contenuti arrivano al suo fornitore.

REA lo scrive nelle domande frequenti del README, alla voce sul caricamento delle app: analizza il bersaglio in locale, poi aggiunge «Your agent receives the tool results, and its model provider has its own data policy». Il tuo agente riceve i risultati, e il fornitore del modello ha le sue regole sui dati. La frase è di REA, il ragionamento vale per tutta la mappa: analisi in locale e lavoro in locale sono due cose diverse.

Hex-Rays tocca lo stesso punto dall’altro lato. Il suo server è indipendente dal modello, che può stare in casa o nel cloud, e l’annuncio ricorda che le politiche di conservazione dei dati cambiano da fornitore a fornitore e che alcuni modelli rifiutano i compiti di sicurezza informatica senza approvazioni aggiuntive. Un modello in casa si può fare: Hex-Rays riferisce di aver provato Qwen 3.8 27B, che in versione compressa (quantizzata) può girare su una scheda grafica da 24 GB, e scrive che i modelli di questa classe reggono questi compiti, ma tendono a bloccarsi e a rimuginare, e chiedono più intervento umano.

Il tema si fa concreto appena guardi cosa c’è dentro. Se insieme a un vecchio gestionale analizzi il suo archivio, ci sono i nomi dei clienti. Quesma ricorda che i router hanno spesso password di amministrazione nascoste nel firmware. Una chat col lucchetto cambia chi la vede sul tuo schermo, e ChatGPT lascia uguali i tempi di conservazione. E le tracce possono restare anche sul tuo disco: secondo Apiiro, una password dentro un comando approvato una volta per tutte può rimanere scritta in un file di Claude Code.

Il rischio viaggia anche in senso contrario. Il programma che analizzi è materiale di cui non puoi fidarti. Hex-Rays spiega che IDA non isola ancora dal resto del sistema l’interprete Python, il componente che esegue gli script, quindi l’agente può eseguire script che arrivano oltre il database di IDA, e raccomanda una macchina virtuale o un altro ambiente isolato. La pagina di sicurezza di REA avverte che le sue protezioni non creano un recinto isolato — «This is not a sandbox» — e che lo strumento scelto apre e analizza il programma con i permessi del tuo utente. Il README di Ghidra avverte di vulnerabilità note in alcune versioni.

«In locale» si controlla anello per anello: l’attrezzo, l’agente, il modello e tutto quello che ci hai collegato.

Come portarlo nella tua attività

Se hai un vecchio programma o un apparecchio fermo, questa mappa ti serve prima di installare qualunque cosa. Probabilmente non sarai tu a installarla: Ghidra chiede il pacchetto Java chiamato JDK, ReVa una versione precisa per la tua versione di Ghidra, il percorso firmware di REA con Binwalk e Unblob vuole Linux. Ti serve per fare le domande giuste a chi lo farà, e per riconoscere una risposta che regge. In quest’ordine:

1. Scrivi cosa hai: il programma o l’apparecchio, che cosa fa, chi lo usa, cosa succede il giorno in cui si ferma.
2. Chiarisci i diritti: chi l’ha scritto, che licenza hai, se il fornitore esiste ancora e può aiutarti. Si parte solo da oggetti e programmi tuoi o con il permesso, e il primo tentativo è chiedere a lui.
3. Fai una domanda sola: «come calcola le provvigioni?», «in che formato salva le fatture?». «Spiegami tutto» produce una bella storia.
4. Decidi la prova prima di cominciare: quali casi, quale risultato atteso, chi la rifà.
5. Decidi dove passano i dati: modello in casa o nel cloud, una copia separata su cui lavorare, un ambiente isolato, e fuori dalla chat il materiale dei clienti.
6. Tieni vicino una persona che sa leggere il risultato. Il test sul comportamento puoi farlo tu; il giudizio sul codice chiede qualcuno che lo capisca.

Quesma riconosce a questi strumenti una prima passata, e su un programma fermo da anni è già un inizio. Una prima passata resta una spiegazione. La prova la paghi ancora tu.

Domande frequenti

Il reverse engineering è legale?

La direttiva europea 2009/24/CE consente a chi ha il diritto di usare un programma di osservarlo e studiarlo durante le operazioni che può effettuare, e per la decompilazione prevede un’eccezione, a condizioni precise, quando è indispensabile per l’interoperabilità con un programma creato autonomamente: è una lettura del testo, non una consulenza.

Serve saper programmare per usare questi strumenti?

Per installarli serve dimestichezza tecnica, per verificare le conclusioni sul codice servono competenze di programmazione e di analisi. Secondo Quesma uno sviluppatore senza esperienza di reverse engineering può ottenere una prima analisi. Chi non sviluppa ha comunque un pezzo suo: definire la domanda e preparare i casi di prova.

Che differenza c’è fra Ghidra, radare2 e IDA?

Ghidra è open source, creato dalla NSA, con interfaccia grafica e modalità automatica. radare2 è open source e lavora da terminale. IDA Pro è commerciale, di Hex-Rays. Nel test di Quesma su un file scritto in Go, IDA Pro ha dato il risultato migliore, mentre sui programmi in C gli attrezzi open source hanno lavorato bene.

Posso riavere il codice sorgente di un vecchio programma?

Puoi avere una ricostruzione, che è una cosa diversa. Con la compilazione si perdono struttura e nomi, quindi quello che esce da un decompilatore o da un modello va trattato come una versione plausibile, da provare sul comportamento del programma originale.

Posso lavorare senza mandare niente a un fornitore esterno?

Si può impostare, ma va controllato. Oltre a far girare in casa attrezzo, agente e modello, devi guardare cosa si collega all’esterno: gli strumenti aggiunti e lo stesso programma analizzato. Hex-Rays dichiara che il suo server funziona interamente in locale e si presta agli ambienti isolati, e r2ai supporta modelli locali. Il prezzo è un hardware adeguato e, secondo Hex-Rays, con i modelli che stanno su una scheda grafica di consumo serve più intervento umano.

Quanto costa?

Ghidra e radare2 sono open source. IDA Pro è commerciale, mentre il server ufficiale di Hex-Rays è open source e in regalo, ma ha bisogno di una tua installazione di IDA. A parte c’è il modello: Hex-Rays scrive che i costi in token, l’unità con cui si paga un modello a consumo, sono molto alti per i modelli di punta. I prezzi di IDA qui non li riporto: vanno letti da Hex-Rays per la tua licenza.

L’AI può controllare da sola se un programma è sicuro?

Secondo il test di Quesma di febbraio 2026, no: il migliore trovava backdoor abbastanza evidenti il 49% delle volte, e Quesma considera questo approccio lontano da una soluzione completa. Può fare una prima passata, a cui deve seguire una verifica. I modelli più recenti in quella classifica mancano, quindi il dato va riletto col tempo.

Fonti

Dati dei repository letti con l’API di GitHub il 7 novembre 2026; README e documentazione consultati lo stesso giorno. Nessuno strumento è stato provato.

• Quesma, «We hid backdoors in ~40 MB binaries and asked AI + Ghidra to find them», 10 febbraio 2026: quesma.com/blog/introducing-binaryaudit
• Quesma, pagina del benchmark BinaryAudit, consultata il 7 novembre 2026: quesma.com/benchmarks/binaryaudit
• Quesma, «Reverse engineering River Raid with Claude, Ghidra, and MCP», 23 gennaio 2026: quesma.com/blog/ghidra-mcp-unlimited-lives
• Hex-Rays, annuncio di IDA MCP, 25 settembre 2026: hex-rays.com/blog/hex-rays-ida-mcp-server
• REA, disclaimer: DISCLAIMER.md; pagina di sicurezza: SECURITY.md; contenuti non affidabili: docs/mcp-contracts.md; firmware: docs/firmware-analysis.md
• Direttiva 2009/24/CE, testo in italiano su EUR-Lex: eur-lex.europa.eu
• I progetti: i link sono nella tabella qui sopra.