From x64dbg-skills
Loads raw shellcode into x64dbg for unpacking, static disassembly, and dynamic analysis with breakpoints, stepping, and registers.
npx claudepluginhub dariushoule/x64dbg-skillsThis skill is limited to using the following tools:
Load a raw shellcode blob into x64dbg using a sacrificial process, then optionally unpack, statically analyze, and dynamically analyze it.
Hunts vulnerabilities in x64dbg debuggees: analyzes imports/exports, triages I/O attack surfaces, tests bugs like overflows/wraps, generates PoCs.
Reverse engineers malware binaries with Ghidra to analyze internal logic, cryptographic routines, C2 protocols, and evasion techniques at assembly and pseudo-C levels. For disassembly, decompilation, and binary analysis.
Reverse engineers malware binaries with Ghidra to analyze logic, crypto routines, C2 protocols, evasion at assembly/pseudo-C level. For post-triage disassembly, decompilation, binary analysis.
Share bugs, ideas, or general feedback.
Load a raw shellcode blob into x64dbg using a sacrificial process, then optionally unpack, statically analyze, and dynamically analyze it.
Ask the user (via AskUserQuestion) for:
Determine the CIP register name: rip for 64-bit, eip for 32-bit.
Determine the debugger variant: x64dbg.exe for 64-bit, x32dbg.exe for 32-bit.
Read the raw shellcode file as hex via Bash:
python -c "import sys; data=open(sys.argv[1],'rb').read(); print(data.hex())" "<shellcode_path>"
Capture the hex string and note the byte length (len(hex_string) // 2).
Use mcp__x64dbg__start_session with:
executable_path: path to timeout.exe (typically C:\Windows\System32\timeout.exe)x64dbg_path: path to the appropriate x64dbg/x32dbg binaryAlways start a new session, do not look for existing sessions. This ensures a clean environment and avoids conflicts with any active debugging sessions.
Note the session PID and x64dbg path from the result. Wait for the debugger to settle — call mcp__x64dbg__get_debugger_status and confirm the debuggee is paused. If running, call mcp__x64dbg__pause.
Allocate a region at least one full page (0x1000 bytes) larger than the shellcode size. Attempt to use static allocation at 0x0000020000000000 for x64 or 0x20000000 for x32, but if that fails, allow the OS to choose the base. This makes it easier for the analyst to refer to addresses in the shellcode without needing to work with relative offsets.
Call mcp__x64dbg__allocate_memory with this size. Record the returned base address.
Some shellcodes require a NOP sled to function properly. The user should answer yes if they don't know.
Ask the user via AskUserQuestion: "Would you like a 32-byte NOP sled before the shellcode?"
If yes:
mcp__x64dbg__write_memory with hex_data = "90" repeated 32 times ("9090909090909090909090909090909090909090909090909090909090909090")shellcode_offset = base address + 0x20 (32 bytes)entry_point = base address (start of NOP sled)If no:
shellcode_offset = base addressentry_point = base addressCall mcp__x64dbg__write_memory with:
address: the shellcode_offsethex_data: the hex string from step 2Call mcp__x64dbg__set_register with:
register: rip or eip (per bitness)value: the entry_point addressSome shellcodes are obscured by a packer/crypter. Ask the user via AskUserQuestion: "Shellcode loaded. Do you need help unpacking it?"
If yes:
entry_point using mcp__x64dbg__disassemblemcp__x64dbg__set_breakpointmcp__x64dbg__go to run until the breakpoint hitsAsk the user via AskUserQuestion: "Would you like help statically analyzing the shellcode?"
If yes:
entry_point (or decoded payload start if unpacked) using mcp__x64dbg__disassemble/yara-sigs via Skill("yara-sigs") to scan for crypto, packers, and anti-debug signatures
mcp__x64dbg__set_comment (import resolution, API calls, anti-debug, networking, control flow transitions)mcp__x64dbg__set_label (e.g., api_resolver, decode_loop, payload_entry)Ask the user via AskUserQuestion: "Would you like help dynamically analyzing the shellcode?"
If yes:
Use the static analysis as a roadmap. Step/run through key sections of the shellcode to:
mcp__x64dbg__read_memorymcp__x64dbg__trace_over or mcp__x64dbg__trace_into for targeted sections, or use /tracealyzer via Skill("tracealyzer") for deeper analysisUse breakpoints strategically — set them at critical points (API calls, post-decode, network setup), run to them, inspect state, then continue. Avoid running the shellcode to completion; stop before any destructive or network-active payloads execute.
Summarize dynamic findings to the user, noting any insights that differ from or extend the static analysis.
Refine static comments/labels based on dynamic insights.
Ask via AskUserQuestion: "Would you like a markdown report of the static analysis?" — if yes, read the template at ${CLAUDE_PLUGIN_ROOT}/skills/shellcode-analyzer/report_template.md and fill in every section based on analysis findings. Write the completed report to ./reports/shellcode_analysis_<timestamp>.md via Write. Omit table rows or sections that have no findings, but preserve the overall structure.
Always call mcp__x64dbg__refresh_gui as the final step.