Skip to main content
Glama

DumpModule

Destructive

Create a verified unpacked dump of a loaded module: locate the OEP, rebuild imports, and validate PE/IAT integrity before reporting success.

Instructions

Produce a VERIFIED unpacked dump of a module to disk. With find_oep=True (default) this drives the packer-agnostic OEP engine (FindOEP) — which works for the unpack-in-memory-then-jump class (UPX, ASPack, FSG, MPRESS, PECompact, Petite, simple crypters) — then dumps via Scylla and VERIFIES the result before reporting ok: the entry must have moved out of the packer stub to the real OEP, the IAT must resolve cleanly (no garbage descriptors), and the imports must be non-trivial. A dump that merely landed on disk is NOT a success. On failure it returns ok:false with a reason and keeps the raw memory dump for manual recovery. Virtualizing protectors have no generic recoverable OEP contract here and are reported honestly (isLikelyVirtualized), never faked. The optional virtualization research backend is disabled in this build.

find_oep=False dumps the selected loaded module at the current/module entry. It still performs independent PE/IAT verification by default and never treats mere file creation as success.

Args: module: Module name to dump (e.g. "target.exe"). Empty = the main debuggee module. output_path: Destination path for the dumped file. Empty = a default path derived from the module. find_oep: When True (default) find + verify the OEP before dumping; when False dump from the current state (no verification). timeout_ms: Budget for OEP discovery (default 30000). fix_imports: Reconstruct imports with Scylla (default true). verify: Require independent PE/IAT verification (default true). overwrite: Explicitly authorize replacing dump artifacts. keep_raw_dump: Preserve Scylla's pre-IAT raw image. iat_start/iat_size: Optional exact live IAT range; both are required together. module_strategy: auto, overlay, or scylla. Auto uses a reloadable source-backed executable overlay for non-main DLLs. timeline_path: Optional unpack-workflow-v1 JSON path. When OEP discovery is enabled and omitted, <output>.workflow.json is written automatically.

Returns: {"ok": bool, "verified": bool, "path": str, "exists": bool, "size": int, "module": str, "findOep": bool, "oep"?: str, "confidence"?: str, "reason"?: str, "isLikelyVirtualized"?: bool, "rawDumpPath"?: str, "result": ..., "hint"?: str}.

Input Schema

NameRequiredDescriptionDefault
moduleNo
verifyNo
find_oepNo
iat_sizeNo
iat_startNo
overwriteNo
timeout_msNo
fix_importsNo
output_pathNo
keep_raw_dumpNo
timeline_pathNo
create_new_iatNo
module_strategyNoauto
advanced_iat_searchNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.9

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare destructiveHint=true/idempotentHint=false/openWorldHint=true; the description adds what actually matters beyond that: dumps write to disk, verification criteria (OEP moved, clean IAT, non-trivial imports), that file creation alone is NOT success, that failures retain the raw dump for manual recovery, that results are never faked for virtualized protectors, and that overwrite explicitly authorizes replacement.

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

Conciseness4/5

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

Front-loaded with the core promise and organized into prose plus an Args/Returns block, which suits a 14-param tool. It is longer than necessary, with some restatement ('a dump that merely landed on disk is NOT a success' is echoed as 'never treats mere file creation as success').

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?

No output schema, and the description compensates with an inline Returns shape covering ok/verified/path/exists/size/reason/isLikelyVirtualized/rawDumpPath. Combined with the detailed arg semantics and the annotation-supplied safety profile, an agent has everything needed to call this correctly.

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

Parameters4/5

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

Schema description coverage is 0%, so the description carries the burden, and it documents most of the 14 params with real semantics: module default, iat_start/iat_size must be supplied together, module_strategy values (auto/overlay/scylla) and what auto does, keep_raw_dump meaning, plus find_oep/verify/fix_imports behavior. However create_new_iat and advanced_iat_search are left entirely unexplained in both schema and description, so compensation is strong but not complete.

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?

Opens with a specific verb+resource+quality bar: 'Produce a VERIFIED unpacked dump of a module to disk.' It also distinguishes itself from siblings by describing the internal flow (FindOEP engine -> Scylla dump -> verification) rather than a generic 'dump' operation.

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?

Explicitly states the when/when-not for the central toggle (find_oep=True for packer-agnostic OEP recovery on UPX/ASPack/FSG/MPRESS/etc.; find_oep=False to dump at current/module entry), and states that virtualizing protectors have no recoverable OEP contract here. It does not, however, route the agent between sibling tools like FindOEP, DumpPeFromMemory, or ValidateDump, so the guidance stops short of full alternative comparison.

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