Cybersecurity
Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.
Scopri →
Servizi & Sistemi Linux
Domini, hosting, PEC, infrastruttura email, servizi di rete e sistemi Linux. Assistenza e gestione dell'infrastruttura Open Source.
Scopri →
x64dbg-mcp-server è un plugin nativo per x64dbg, il debugger open source per Windows, che ne espone le funzioni via Model Context Protocol su HTTP. Repository aperto il 22 agosto, licenza MIT, e in due settimane ha superato le 1.800 stelle.
È scritto in Zig, senza dipendenze, produce un binario singolo e compila sia x32 sia x64 da un solo comando, con cross-compilazione da Linux o macOS verso Windows. Nessun runtime .NET, nessun Python, nessun framework: il file si copia nella cartella dei plugin e l’MCP server parte da solo all’avvio del debugger.
Cosa mette a disposizione di un agente
L’elenco dei tool è la parte che dice di più, perché descrive un flusso di lavoro invece di una funzionalità. Ne abbiamo contati 80 nelle tabelle del README, divisi in 11 sempre disponibili e 69 che richiedono una sessione di debug attiva.
| Area | Operazioni esposte |
|---|---|
| Controllo esecuzione | run, StepInto, StepOver, StepOut, PauseDebug, RestartDebug |
| Breakpoint | INT3, hardware su DR0-DR3 in lettura, scrittura o esecuzione, condizionali con espressione e log |
| Memoria e codice | Disassemble, DisassembleFunction, ReadMemory, allocazione, pattern scanning |
| Ricognizione | SearchForStrings, xrefs, simboli, moduli, thread, call stack |
| Analisi del formato | analisi PE, rilevamento dell’OEP, dump dei moduli, ispezione di PEB e SEH |
| Attacco a processo | AttachProcess per PID, LoadBinary, ExecuteDebuggerCommand |
Due voci meritano di essere lette insieme, perché non sono generiche. Il rilevamento dell’OEP, cioè l’original entry point, insieme al dump dei moduli sono i due passaggi con cui si sconfeziona un eseguibile compresso o offuscato: si lascia che il packer si srotoli in memoria, si individua il punto in cui salta al codice originale e da lì si scarica l’immagine ricostruita. È lavoro manuale, ripetitivo e costoso in ore. È esattamente il tipo di attività che un agente può condurre a colpi di tentativi.
C’è poi un tool che rende possibile il resto: WaitForEvent, un long-poll sugli eventi del debugger. Senza quello un agente dovrebbe interrogare ciclicamente lo stato; con quello può fermarsi e aspettare che scatti un breakpoint o arrivi un’eccezione. Insieme ai 22 callback di evento che il plugin registra, fra cui caricamento e scaricamento delle DLL, creazione dei thread ed eccezioni, è ciò che trasforma un debugger in qualcosa che un ciclo agentico può guidare.
Il gancio con i numeri di venerdì
Questa è la stessa capacità che compare nell’annuncio di GPT-6 Astra di quattro giorni fa, dove il numero più alto di tutte le tabelle è l’88% su SRE-Bench al primo tentativo, contro il 55,9% del modello precedente e il 12,5% del secondo classificato.
SRE-Bench misura la capacità di capire la logica di un binario senza avere il sorgente. Un plugin come questo è il pezzo che manca fra quella capacità e un campione reale: il modello sa leggere un binario e da qui ottiene la possibilità di eseguirlo un’istruzione alla volta, guardarne la memoria e osservarne il comportamento.
Il modello di rischio, letto per intero
Va detto per intero, perché il progetto non nasconde nulla e le scelte fatte hanno un contesto.
Il server si mette in ascolto su 0.0.0.0:9094 per la versione a 64 bit e su 0.0.0.0:9095 per quella a 32, cioè su tutte le interfacce e non solo sull’indirizzo di loopback. L’autenticazione è obbligatoria, con un bearer token generato al primo avvio e richiesto su ogni chiamata. Dal menu dei plugin si possono cambiare indirizzo, porta e token.
Il contesto conta: x64dbg si usa quasi sempre dentro una macchina virtuale di analisi, isolata dalla rete, dove il binding su tutte le interfacce serve proprio a far arrivare il client MCP dall’host. In una rete di laboratorio meno curata è invece un servizio raggiungibile che comanda un debugger, quindi vale la pena metterlo nella lista delle cose da verificare prima di lasciarlo acceso.
C’è poi una considerazione di contenimento che riguarda l’insieme. Qui l’agente non gira dentro la sandbox: la pilota dall’esterno, mentre il campione in analisi gira nella macchina che il debugger controlla. È una geometria diversa da quella di cui avevamo scritto in harness e sandbox, dove il problema era confinare il codice generato dal modello. Il confine da progettare qui non è attorno all’agente ma attorno alla macchina di analisi. La domanda pratica è cosa succede se il campione tenta di uscire mentre un processo automatico gli sta aprendo dei breakpoint.
Due cose da verificare prima di adottarlo
La revisione del protocollo. Il README dichiara MCP 2024-11-05, con trasporti Streamable HTTP e SSE su JSON-RPC 2.0. È una revisione di quasi due anni fa: quella corrente è la 2026-07-28, che abbiamo commentato ad agosto e che ha introdotto il modello stateless e deprecato alcune parti. Non è un difetto in sé, perché i client vecchi continuano a funzionare, ma chi standardizza su una versione recente deve sapere che questo plugin parla un dialetto precedente.
Il conteggio dei tool. Il README non è coerente con sé stesso: nella sezione delle feature dichiara 84 tool, nell’intestazione della sezione Tools ne dichiara 72 e le tabelle ne elencano 80. È un dettaglio piccolo, segnalato perché quando si valuta uno strumento che verrà messo in mano a un agente il conteggio delle capacità esposte è esattamente il numero da cui parte una revisione di sicurezza.
Cosa ne pensiamo
Per chi fa analisi, il valore è concreto e non teorico. Il triage di un campione è fatto di sequenze lunghe e note: attacca il processo, metti un breakpoint sulla API sospetta, esegui, guarda i registri, cerca la stringa, ripeti. Sono le sequenze che costano tempo esperto senza richiederne il giudizio. Sono quelle che un ciclo agentico può percorrere. Il giudizio resta dove è sempre stato, cioè nel decidere cosa vale la pena guardare e nel leggere quello che è venuto fuori.
Il criterio con cui lo valuteremmo per un laboratorio è di trattarlo come strumentazione, non come automazione. Un agente che propone dove mettere il prossimo breakpoint e riassume cosa ha visto è un moltiplicatore. Un agente che decide da solo di far ripartire un campione ostile su una macchina collegata alla rete aziendale è un incidente in preparazione. La differenza fra le due cose non sta nel plugin ma in come è disegnato l’ambiente attorno.
Sul progetto in sé, la scelta di Zig con zero dipendenze e binario singolo è quella giusta per un plugin che deve stare dentro un debugger: meno superficie, niente runtime da aggiornare, più la possibilità di compilarlo per Windows da una macchina che Windows non lo esegue. È il tipo di ingegneria sobria che in questo ambito si vede raramente.