Talos Intelligence has documented a technique that transforms vbdec, a long-standing Visual Basic 6 disassembler, into a node for local agentic automation. The research shows that exposing the tool's internal object model through the Windows Running Object Table (ROT), combined with an AI agent support package, enables advanced decompilation and analysis operations without modifying the original software or sending binaries to remote services.
- vbdec registers its CVBProject object and main form in the Windows ROT under the monikers
vbdec.vbpandvbdec.frmMainwhen remote scripting is enabled - An AI support package includes an operational briefing for the agent and 90 auto-generated class definitions in the proto folder
- Automation was validated on PDFStreamDumper across four concrete tasks: function decompilation, DOT graph generation, export of a 600+ row SQLite database, and mapping of 1,165 P-code dispatch slots
- Only LLM inference requests leave the workstation; analyzed binaries remain local with no API keys embedded in the product
The ROT Mechanism: A Three-Decade Channel Made Agentic
The Windows Running Object Table has existed since 1993 as COM infrastructure for registering active objects queryable by other processes. vbdec uses it in a specific way: with the "Enable Remote Scripting" option activated in settings, the tool registers its central CVBProject object and main form with readable monikers.
From an external script, a process can retrieve these objects via GetObject("vbdec.vbp"). The resulting variable exposes the entire parsed project: every form, class, module, declared API, P-code body, control, and string. This object model is not added for the occasion; it is the disassembler's own internal model, made externally navigable.
The architectural novelty lies not in the ROT mechanism, consolidated over three decades, but in its pairing with a textual contract for AI agents. The source describes an "AI agent support package" composed of a markdown file of operational instructions — _claude_vbdec_ai_instructions.txt — and a proto folder with 90 auto-generated class definitions. These serve as an interface schema between the agent's natural language and the exposed COM object model.
Four Tasks Demonstrating Generalizability
The technical proof focused on PDFStreamDumper, a PDF stream analysis tool that Talos used as a representative target. The first task produced the decompilation of a single P-code function, with control flow substantially recovered and additional agent-generated comments. The second generated a DOT-format file for call graph visualization.
The third task exported a SQLite database containing over 600 rows with all functions from the analyzed binary. The fourth, more ambitious, coordinated vbdec with IDA Pro's MCP server (idalib) to build a complete database of VB6 P-code opcodes, mapping all 1,165 dispatch slots of the MSVBVM60.dll.
All operations were conducted via locally running Claude Code, with intermediate VBS scripts managed by cscript. The source explicitly states that vbdec includes no built-in AI integration: the agent interrogates the tool like any other COM process, without modifications to the original source code.
Breaking the Vendor-Feature Constraint
"The capability surface of the tool has decoupled from the feature list of the tool." — Talos Intelligence
This statement, reported from the primary source, identifies the architectural turning point. Traditionally, every new automation capability required the vendor to implement it as a native feature: specific exports, dedicated APIs, plugin systems. The pattern documented by Talos inverts the relationship: the vendor exposes the data model, the user formulates the request in natural language, the agent translates it into sequences of COM calls.
A second passage from the same source clarifies the operating principle: "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." The reduction of all future requests to a single interaction mode — query the agent — represents a radical simplification compared to the typical feature backlog of analysis tools.
The advantage for the malware analyst is twofold. The sensitive binary never leaves the workstation, eliminating non-disclosure constraints and exposure risks on cloud platforms. No API key is embedded in the product, nor is there a service that can be discontinued: dependency on external vendors is limited to the LLM for inference, which can be hosted locally.
Technical Precedents and Measurable Distances
The historical context deserves attention. Gen Digital had already explored the possibility of scripting arbitrary VB6 applications via COM/ROT, but that technique required DLL injection and runtime hooking — an invasive, potentially unstable approach with a different security profile. vbdec instead offers native exposure of its object model, without need for post-compilation modifications.
A code example on GitHub, cited in the source matrix, corroborates the technical feasibility of the COM/ROT mechanism in generic VB6. However, the primary source does not verify that this specific example was used in developing the Talos technique, nor that it represents the same architectural approach.
What to Do Now
For vendors of existing reverse engineering tools, the Talos pattern offers a marginal-cost extension model: publish the internal object model to the ROT, draft an operational briefing in natural language, and generate proto files that map the exposed classes. These three elements — model, briefing, proto — are sufficient to transform a legacy desktop application into a substrate for local agentic automation.
For malware analysts operating on sensitive binaries, the documented technique represents a concrete path to preserve operational confidentiality without sacrificing automation. The workstation remains the security perimeter: the 90 proto files and textual briefing contain no business logic, only interface metadata, so they do not expose information about the analyzed binary.
For the sector as a whole, the 1,165 mapped dispatch slots and the 600+ rows of the SQLite database demonstrate that the quality of agentic output is comparable to that of complex manual operations, with the advantage of reproducibility and automatic documentation of intermediate steps.
Documented Limitations and Residual Uncertainties
The source does not specify whether the AI support package is bound to Claude Code or usable with other local LLM agents. The exact version of vbdec that includes this functionality is not documented, nor are any security limitations in the exposed COM model — for example, whether other processes on the same system can access the object graph without authorization.
Actual task execution time is not precisely quantified: the source uses generic expressions without specifying which task each refers to. Finally, it is unclear whether other reverse engineering tools have adopted similar patterns.
What the dossier documents with certainty is sufficient to outline a paradigm shift. The architectural pattern generalizes: any analysis tool that publishes its internal model to the ROT, accompanied by briefing and proto files, can serve as a substrate for local agentic automation. No software rewrite is required, nor dependency on specific cloud ecosystems.
Is the analyzed binary ever transmitted to cloud services?
No. According to the primary source, only LLM inference requests leave the workstation. The analyzed binary remains local, with no upload and no API keys embedded in the product.
Why COM/ROT rather than REST API or gRPC?
The source does not provide explicit technology comparisons. The ROT+COM pattern emerges as a practical solution for existing legacy tools: it requires no application rewrite or addition of network servers, leveraging infrastructure already present in Windows.
Is it necessary to modify vbdec to activate this automation?
No. The source explicitly states that no built-in AI integration exists in vbdec. Automation activates through the native exposure of the object model already present, enabled by the "Enable Remote Scripting" option in the tool's settings.
Sources
- 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
Information is based on the cited source and current as of publication.