Cisco Talos researcher David Zimmer has published a technique showing how AI agents can automate existing reverse engineering tools without any modifications to those tools, as long as the tool exposes its internal data through a scripting interface. The approach, demonstrated using the VB6 decompiler vbdec and Anthropic’s Claude Code, offers a practical model for local, analyst-controlled agentic analysis.

The Core Idea

The technique rests on a straightforward observation: an application does not need embedded AI features to participate in an agentic workflow. It only needs to publish its internal object model in a way that external processes can reach. In vbdec, enabling remote scripting registers the tool’s central CVBProject object in the Windows Running Object Table (ROT), a system-wide directory of live COM objects. Any process on the same machine can then bind to the running instance with a single line of script:

Set o = GetObject("vbdec.vbp")

That reference exposes the entire parsed project, including every form, class, module, declared API, P-code body, control, and string, as a navigable object graph. The script is, in effect, driving the disassembler itself.

Three Components Working Together

Zimmer describes the technique as three interlocking pieces:

  • The live model. vbdec’s COM object, accessible via the ROT once remote scripting is enabled, serves as a persistent data server. A binary is parsed once and can be queried repeatedly across multiple agent sessions.
  • The contract. An AI agent support package ships with vbdec, comprising an operator briefing in Markdown that explains the object model and how to bind to it, plus roughly 90 auto-generated class definitions covering every public class and form the tool exposes. The agent uses these as its authoritative reference.
  • The local agent. Claude Code runs on the analyst’s workstation, reads the briefing and class definitions, and then writes and executes .vbs files via cscript to interrogate the live object model. Only model inference requests leave the machine; the binary and all parsed data remain local.

Practical Demonstrations

Talos tested the workflow against a P-code build of PDFStreamDumper, a known open-source tool, illustrating three analyst tasks:

  • Function decompilation. Given a function name, the agent retrieves the P-code, walks the VB virtual machine opcode stream, maps constructs to VB6 equivalents, and produces annotated source-level pseudocode. The agent independently descended into called subfunctions, inferred their purpose, and assigned meaningful names to complete the reconstruction.
  • Call graph generation. Asked for a Graphviz DOT call graph, the agent walked each CCodeBody.Disasm, identified call opcodes such as ImpAdCallI2, VCallHresult, and LateMemCall, and emitted a depth-tracked graph.
  • SQL database export. The agent enumerated every function in the binary and populated a SQLite database with address, size, module, instruction count, callees, and external API calls. For PDFStreamDumper, the result was a database of more than 600 rows, enabling queries such as locating all functions that reference RtlMoveMemory.

Implications for Security Tooling

The broader implication is architectural. Rather than waiting for tool vendors to ship discrete AI features, analysts can treat any COM-capable application as a queryable backend. New analysis workflows become prompt exercises rather than feature requests, and the approach requires minimal engineering effort on the tool side. Zimmer notes that for VB6 host applications specifically, the COM exposure can even be added retroactively without source code access, extending the pattern to tools whose authors are no longer maintaining them.