Scripting the disassembler: Local agentic reverse engineering through vbdec’s live COM object model

Analysis tools can be extended for agentic workflows without requiring built-in artificial intelligence, provided they expose their data through external scripting interfaces. This approach allows even traditional graphical applications to become accessible to AI agents by publishing their internal object models. Agents can then query and automate analysis tasks without needing modifications to the core application. This method often involves minimal engineering effort by leveraging existing scripting technologies and data structures. By offering structured data rather than pre-defined AI features, users can enhance a tool's capabilities through prompts, transforming new analysis ideas into automated workflows. The application functions as both an interactive viewer and a persistent data server, enabling local data to be parsed once and queried across multiple agent sessions, while keeping sensitive data on the analyst's machine.

The challenge with analyzing Visual Basic 6 (VB6) binaries lies in their complex file format and embedded metadata. Extracting advanced data embeddings requires reimplementing VB6's internal file structure, including the header, object table, and P-code layout. This specialized task typically necessitates dedicated tools, but not all such tools provide accessible programmatic libraries. The technique described demonstrates how AI agents can automate existing tools and access detailed results.

This method involves three key components. First, the disassembler, vbdec, makes its parsed model accessible externally. When a binary is loaded and remote scripting is enabled, vbdec registers its central CVBProject object and main form in the Windows Running Object Table (ROT) using specific monikers. The ROT acts as a system-wide directory for live Component Object Model (COM) objects, allowing any process to retrieve a reference to a running instance by its moniker. From a script, this is achieved with a single command, granting access to the entire parsed project, including forms, classes, modules, APIs, P-code, controls, and strings, presented as a navigable object graph. This effectively allows a script to control the disassembler. This capability can even be added to VB6 host applications without source code access.

Second, to make this live model usable by an agent, vbdec includes an AI agent support package. This package consists of an operator briefing file, which informs the agent about vbdec, how to bind to the ROT, and the structure of the object model. Additionally, a set of auto-generated class definitions, covering every public class and form exposed by vbdec, serves as an authoritative reference for the agent regarding member names and types.

Third, the agent itself performs the analysis. In this context, Claude Code was used, running locally on the workstation. The user initiates the process by opening a terminal, pointing the AI to the briefing and prototype files, and describing the desired analysis. Claude Code then executes multiple Visual Basic Scripting Edition (VBScript) files using cscript, iterating through the data. This approach avoids embedding AI integrations directly into vbdec, eliminates the need to upload binaries, and does not require maintaining separate glue code. The agent and disassembler share the same machine and file system, with analysis occurring locally. Only model inference requests are sent off the workstation. Any new capabilities added by the agent extend vbdec without requiring changes to the tool itself, and users can choose their preferred AI model.

The practical application of this technique is demonstrated through several examples. Analysts can request the decompilation of a specific function. The agent retrieves the P-code, traverses the VB-VM opcode stream, maps each construct to its VB6 equivalent, and generates a source-level reconstruction with inline comments. While the reconstruction may not be byte-for-byte identical to the original, it substantially recovers the control flow and includes agent-generated comments. The AI can also identify and rename subfunctions to aid in the parent function's decompilation, producing usable reverse-engineering output rapidly.

Another capability is building a call graph for a selected function. The agent iterates through the disassembler's code body, identifies call opcodes, and emits a Graphviz DOT file representing the call graph with depth tracking. For more extensive automation, an agent can enumerate every function within a binary and export statistics, such as address, size, module, instruction count, callees, and external API calls, into a SQLite database. This transforms the binary into a queryable dataset, making complex, whole-program analyses feasible with simple database queries.

This methodology also extends to creating reference data, such as a comprehensive opcode database for the VB6 P-code interpreter. By analyzing examples from a real binary using vbdec and cross-referencing with runtime handler functions from the VB runtime, an agent can synthesize a detailed database. This database includes operand decoding, verified semantics, alias relationships, corpus statistics, and descriptions for each opcode, which can then be used to improve P-code decompilation.

Furthermore, this mechanism can be employed for application testing. An agent can interact with the COM interface of the tool directly, exposing potential issues like method signature drift, type regressions, malformed objects, or edge-case P-code, without the need for mock objects or UI automation layers. The prototype files and operator briefing are effectively tested alongside the API implementation.

This design pattern is broadly applicable. Any analysis tool that exposes its internal model via the ROT and provides an operator briefing with prototypes can serve as a foundation for local agentic automation. The interactive GUI remains available for exploration, while the agent handles tasks that benefit from repeatability, comprehensiveness, or speed. The core architectural shift is enabling tool authors to publish their models and delegate the development of new analyses to users via prompts. This approach keeps sensitive binaries local, avoids reliance on external APIs or services, and allows users to leverage their existing AI agents. The contract between the agent and the tool is managed through simple text files.