Talos Intelligence ha documentato una tecnica che trasforma vbdec, disassembler storico per Visual Basic 6, in un nodo di automazione agentica locale. La ricerca dimostra che l'esposizione del modello interno del tool tramite Windows Running Object Table (ROT), combinata con un pacchetto di supporto per agenti AI, permette operazioni avanzate di decompilazione e analisi senza modificare il software originale né inviare binari a servizi remoti.
- vbdec registra il proprio oggetto CVBProject e la main form nel Windows ROT con i moniker
vbdec.vbpevbdec.frmMainquando è attivato il remote scripting - Un pacchetto di supporto AI include un briefing operativo per l'agente e 90 class definition auto-generate nella cartella proto
- L'automazione è stata validata su PDFStreamDumper con quattro task concreti: decompilazione funzione, generazione graph DOT, export database SQLite da 600+ righe, e mappatura di 1.165 dispatch slots P-code
- Solo le richieste di inference del modello LLM lasciano la workstation; i binari analizzati restano in locale senza API key integrate nel prodotto
Il meccanismo ROT: un canale trentennale reso agentico
Il Windows Running Object Table esiste dal 1993 come infrastruttura COM per la registrazione di oggetti attivi consultabili da altri processi. vbdec lo utilizza in modo specifico: con l'opzione "Enable Remote Scripting" attivata nei settings, il tool registra il proprio oggetto centrale CVBProject e la main form con moniker leggibili.
Da script esterno, un processo può recuperare questi oggetti tramite GetObject("vbdec.vbp"). La variabile risultante espone l'intero progetto parsato: ogni form, class, module, API dichiarata, corpo P-code, control e string. Questo modello a oggetti non è aggiunto per l'occasione: è il modello interno stesso del disassembler, reso esternamente navigabile.
La novità architetturale non sta nel meccanismo ROT, consolidato da tre decenni, ma nel suo abbinamento a un contratto testuale per agenti AI. La fonte descrive un "AI agent support package" composto da un file markdown di istruzioni operative — _claude_vbdec_ai_instructions.txt — e da una cartella proto con 90 class definition auto-generate. Queste ultime fungono da schema di interfaccia tra il linguaggio naturale dell'agente e il modello a oggetti COM esposto.
Quattro task che dimostrano la generalizzabilità
La prova tecnica si è concentrata su PDFStreamDumper, strumento di analisi di stream PDF che Talos ha utilizzato come bersaglio rappresentativo. Il primo task ha prodotto la decompilazione di una singola funzione P-code, con il control flow sostanzialmente recuperato e commenti aggiuntivi generati dall'agente. Il secondo ha generato un file in formato DOT per la visualizzazione dei call graph.
Il terzo task ha esportato un database SQLite contenente più di 600 righe con tutte le funzioni del binario analizzato. Il quarto, più ambizioso, ha coordinato vbdec con il server MCP di IDA Pro (idalib) per costruire un database completo degli opcode VB6 P-code, mappando tutti i 1.165 dispatch slots della DLL MSVBVM60.dll.
Tutte le operazioni sono state condotte tramite Claude Code in esecuzione locale, con script VBS intermedi gestiti da cscript. La fonte specifica esplicitamente che vbdec non include alcuna integrazione AI predefinita: l'agente interroga il tool come qualsiasi altro processo COM, senza modifiche al codice sorgente originale.
La rottura del vincolo vendor-feature
"The capability surface of the tool has decoupled from the feature list of the tool." — Talos Intelligence
Questa frase, riportata dalla fonte primaria, identifica il punto di svolta architetturale. Tradizionalmente, ogni nuova capacità di automazione richiedeva che il vendor la implementasse come feature nativa: esportazioni specifiche, API dedicate, plugin system. Il pattern documentato da Talos inverte il rapporto: il vendor espone il modello dati, l'utente formula la richiesta in linguaggio naturale, l'agente traduce in sequenze di chiamate COM.
Un secondo passaggio della stessa fonte chiarisce il principio operativo: "Publish the model, write the briefing, and hand the keys over to the user. Every user wish list idea now collapses into the same answer: Ask the agent." La riduzione di tutte le richieste future a un'unica modalità di interazione — interrogare l'agente — rappresenta una semplificazione radicale rispetto al backlog feature tipico dei tool di analisi.
Il vantaggio per l'analista di malware è duplice. Il binario sensato non abbandona la workstation, eliminando i vincoli di non-disclosure e i rischi di esposizione su piattaforme cloud. Non esiste API key integrata nel prodotto, né servizio che possa essere discontinuato: la dipendenza da vendor esterni si limita al modello LLM per l'inference, che può essere ospitato localmente.
Precedenti tecniche e distanze misurabili
Il contesto storico merita attenzione. Gen Digital aveva già esplorato la possibilità di scriptare applicazioni VB6 arbitrarie tramite COM/ROT, ma quella tecnica richiedeva DLL injection e hooking runtime — un approccio invasivo, potenzialmente instabile, e con profilo di sicurezza diverso. vbdec offre invece l'esposizione nativa del modello a oggetti, senza necessità di modifiche post-compilation.
Un esempio di codice su GitHub, citato nella matrice fonti, corrobora la fattibilità tecnica del meccanismo COM/ROT in VB6 generico. Tuttavia, la fonte primaria non verifica che questo esempio specifico sia stato utilizzato nello sviluppo della tecnica Talos, né che rappresenti lo stesso approccio architetturale.
Cosa fare adesso
Per i vendor di tool di reverse engineering esistenti, il pattern Talos offre un modello di estensione a costo marginale: pubblicare il modello a oggetti interno al ROT, redigere un briefing operativo in linguaggio naturale, e generare proto file che mappino le classi esposte. Questi tre elementi — modello, briefing, proto — sono sufficienti a trasformare un'applicazione desktop legacy in substrate per automazione agentica locale.
Per gli analisti di malware che operano su binari sensibili, la tecnica documentata rappresenta una via concreta per preservare la riservatezza operativa senza rinunciare all'automazione. La workstation rimane il perimetro di sicurezza: i 90 proto file e il briefing testuale non contengono logica di business, ma solo metadati di interfaccia, quindi non espongono informazioni sul binario analizzato.
Per il settore nel suo complesso, i 1.165 dispatch slots mappati e le 600+ righe del database SQLite dimostrano che la qualità dell'output agentico è comparabile a quella di operazioni manuali complesse, con il vantaggio della riproducibilità e della documentazione automatica dei passaggi intermedi.
Limiti documentati e incertezze residue
La fonte non specifica se il pacchetto di supporto AI sia vincolato a Claude Code o utilizzabile con altri agenti LLM locali. Non è documentata la versione esatta di vbdec che include questa funzionalità, né se esistano limitazioni di sicurezza nel modello COM esposto — ad esempio, se altri processi sullo stesso sistema possano accedere all'object graph senza autorizzazione.
Il tempo effettivo di esecuzione dei task non è quantificato con precisione: la fonte utilizza espressioni generiche senza specificare a quale task ciascuna si riferisca. Non è infine chiaro se altri tool di reverse engineering abbiano adottato pattern analoghi.
Ciò che il dossier documenta con certezza è sufficiente a delineare un cambiamento di paradigma. Il pattern architetturale si generalizza: qualsiasi tool di analisi che pubblichi il proprio modello interno al ROT, accompagnato da briefing e proto file, può fungere da substrate per automazione agentica locale. Non è richiesta riscrittura del software, né dipendenza da ecosistemi cloud specifici.
Il binario analizzato viene mai trasmesso a servizi cloud?
No. Secondo la fonte primaria, solo le richieste di inference del modello LLM lasciano la workstation. Il binario analizzato resta in locale, senza upload né API key integrate nel prodotto.
Perché COM/ROT piuttosto che API REST o gRPC?
La fonte non espone confronti espliciti tra tecnologie. Il pattern ROT+COM emerge come soluzione pratica per tool legacy esistenti: non richiede riscrittura dell'applicazione né aggiunta di server network, sfruttando un'infrastruttura già presente in Windows.
È necessario modificare vbdec per attivare questa automazione?
No. La fonte specifica esplicitamente che non esiste integrazione AI predefinita in vbdec. L'automazione si attiva tramite l'esposizione nativa del modello a oggetti già presente, abilitata dall'opzione "Enable Remote Scripting" nei settings del tool.
Fonti
- https://blog.talosintelligence.com/scripting-the-disassembler/
- https://sandsprite.com/vbdec/
- https://github.com/dzzie/tests/blob/master/rot_test_3/CRemotelyScriptable.cls
- https://www.gendigital.com/blog/insights/research/scripting-arbitrary-vb6-applications
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.