Skip to main content
Glama
I-CAN-hack
by I-CAN-hack

vtable

Recover C++ virtual function tables from a given address: read pointer slots, classify code pointers, and optionally create structs, labels, and typed methods in Ghidra.

Instructions

Recover a C++ vtable: type the function-pointer table at address.

Point this at the start of a vtable (the address an object's vptr holds,
i.e. the first virtual-function slot — not the Itanium offset-to-top/typeinfo
prefix). It reads consecutive pointer-sized words, classifies each as a code
pointer or not (respecting the program's pointer size, endianness, and the
ARM/Thumb low bit), and reports the slots as JSON. This is discovery-by-hand:
you supply the address; it does not scan memory for vtables.

With `count` unset, slots are read until the first non-code pointer (bounded
by `max_count`). With `count` set, exactly that many slots are read.

When `apply` is true it also:
- creates a struct (`<class>_vtable` or `vtable_<address>`) of function
  pointers — one named `vfuncN` field per slot, with the target function in
  the field comment — and applies it at `address`;
- labels the table (as `<class>::vftable` when `class_name` is given);
- creates a function at each code slot when `create_functions` is true. A
  slot whose target is not yet an instruction (stale data, or bytes left
  decoded in the wrong ISA mode such as PowerPC VLE vs Book-E) is cleared
  and re-disassembled in the language's correct default mode before the
  function is created; slots that still can't be recovered are reported in
  `unrecovered_slots` rather than silently skipped;
- when `class_name` is given and `type_methods` is true, reparents each slot
  method into the class and sets its first parameter to `<class> *this`
  (adding one if the method has no parameters), so the decompiler propagates
  the class type. Reports `typed_methods`.

Set `apply=false` for a read-only report (always safe).

Args:
    address: Start of the vtable (address or exact label).
    program: Required Ghidra project path or name to target.
    count: Exact number of slots to read. Omit to auto-detect by code-run.
    max_count: Upper bound on slots when auto-detecting. Default 256.
    apply: Create the struct/label/functions. False = report only.
    create_functions: Create functions at slot targets (recovering stale or
        wrong-ISA-mode targets first).
    class_name: Associate the table with this class (created if missing);
        the table is labeled `<class_name>::vftable`.
    type_methods: When a class is given, reparent slot methods into the
        class and type their `this` pointer. Default true; no-op without
        `class_name`.
    timeout: Bridge execution timeout in seconds.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
applyNo
countNo
addressYes
programYes
timeoutNo
max_countNo
class_nameNo
type_methodsNo
create_functionsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden, and it does so thoroughly. It discloses side effects: creating a struct, labeling the table, creating functions, clearing and re-disassembling stale/wrong-ISA-mode targets, reporting unrecovered slots, reparenting methods, and setting the 'this' parameter. It also explains the safe read-only mode and the JSON reporting behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence earns its place: it front-loads the core purpose, explains behavioral modes, details side effects, and then lists parameter semantics. The structure is logical and scannable, with no filler or repetition despite the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, nine parameters, and no annotations, the description is fully complete. It covers required parameters, edge cases like stale data and wrong ISA mode, defaults, failure reporting through unrecovered_slots, and the distinction between report-only and apply modes. An output schema exists, so return-value details do not need to be duplicated here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does. The Args section explains every parameter, including optionality, defaults, and behavioral meaning: count's exact vs auto-detect mode, max_count bounding auto-detection, apply=false being read-only, type_methods being a no-op without class_name, and timeout as the bridge execution limit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line states a specific verb and resource: 'Recover a C++ vtable: type the function-pointer table at address.' It further distinguishes the tool from memory-scanning approaches by saying 'This is discovery-by-hand: you supply the address; it does not scan memory for vtables.' An agent can clearly identify what this tool does and how it differs from other discovery tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives precise placement guidance ('Point this at the start of a vtable... not the Itanium offset-to-top/typeinfo prefix') and explains the count behavior with and without a value. It also advises 'Set apply=false for a read-only report (always safe).' It does not name specific sibling alternatives or list explicit exclusions, but the context is clear enough for correct selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.