PE二进制交互式逆向探索

---
name: pe-binary-exploration
description: >
  Interactive PE binary exploration using peek-a-bin's MCP server. Load Windows
  executables, DLLs, and drivers for disassembly, decompilation, cross-reference
  analysis, anomaly detection, and collaborative annotation — all without
  uploading files to external services. Ideal for agent-assisted reverse
  engineering workflows where an AI iteratively explores a binary, annotates
  findings, and produces a structured analysis export.
---

# PE Binary Exploration

Explore Windows PE binaries interactively through peek-a-bin's MCP server.
This skill guides an iterative workflow: load a sample, triage anomalies,
survey functions, decompile and disassemble targets of interest, trace
cross-references, annotate findings, and export a portable analysis file.
Every step maps to an MCP tool call, making the entire workflow automatable
by an AI agent while optionally syncing live to a browser UI.

## Prerequisites

- **peek-a-bin** installed locally (`git clone` + `npm install`) or running in Docker
- **Node.js 18+** and **npm** (for `npm run mcp` or `npx tsx`)
- **MCP server** configured in your AI tool's MCP settings (stdio transport):
  ```json
  {
    "mcpServers": {
      "peek-a-bin": {
        "command": "npx",
        "args": ["tsx", "src/mcp/index.ts"],
        "cwd": "/path/to/peek-a-bin"
      }
    }
  }
  ```
- **Optional**: Ghidra server container for enhanced decompilation:
  ```bash
  cd peek-a-bin/ghidra-server
  docker build -t peek-a-bin-ghidra .
  docker run -p 8765:8765 peek-a-bin-ghidra --api-key YOUR_SECRET
  ```
  Then enable in peek-a-bin Settings with the server URL and API key.
- **Optional**: peek-a-bin browser UI open at `http://localhost:5173/peek-a-bin/`
  for real-time annotation sync

## Step-by-Step Instructions

### Step 1: Start the MCP Server

Launch the peek-a-bin MCP server so tool calls are available:

```bash
cd /path/to/peek-a-bin
npm run mcp
```

Or configure it as a persistent MCP server in your AI tool's settings (see
Prerequisites). The server communicates over stdio and optionally exposes a
WebSocket on port 19283 for browser sync.

### Step 2: Load the PE File

Use the `load_pe` tool with the absolute path to your sample:

```
load_pe(filePath: "/samples/suspicious.exe")
```

Record the returned metadata:
- **Architecture**: `is64` (true = x64, false = x86)
- **Image base** and **entry point** addresses
- **Subsystem**: GUI, console, or driver
- **Counts**: sections, imports, exports, functions, anomalies
- **Driver info**: present for `.sys` files with IRP dispatch table locations

If analyzing multiple samples, use `list_files` to see all loaded binaries
and their IDs.

### Step 3: Triage via Anomaly Detection

Call `detect_anomalies` immediately after loading:

```
detect_anomalies(fileId: "suspicious.exe")
```

This returns severity-ranked security anomalies such as:
- Suspicious section permissions (writable + executable)
- Missing ASLR, DEP, or CFG mitigations
- Unsigned or invalidly signed code
- Abnormal section entropy (packed/encrypted indicators)
- Entry point outside expected sections

Prioritize **high-severity** findings for deeper investigation in subsequent
steps. This triage focuses your analysis on the most suspicious areas first.

### Step 4: Survey the Function List

Enumerate detected functions with `list_functions`:

```
list_functions(fileId: "suspicious.exe", limit: 50)
```

Use the `filter` parameter to search for functions by name pattern:

```
list_functions(fileId: "suspicious.exe", filter: "crypt")
list_functions(fileId: "suspicious.exe", filter: "http")
list_functions(fileId: "suspicious.exe", filter: "socket")
list_functions(fileId: "suspicious.exe", filter: "reg")
list_functions(fileId: "suspicious.exe", filter: "inject")
```

Note the distinction between **thunk functions** (thin wrappers that jump to
imports) and **real functions** containing actual logic. Focus analysis on
non-thunk functions. Use `offset` for pagination through large function lists.

### Step 5: Decompile Key Functions

For each function of interest, get C-like pseudocode:

```
decompile_function(fileId: "suspicious.exe", address: "0x401000")
```

Start with:
1. The **entry point** function (address from Step 2)
2. Functions with **suspicious names** found in Step 4
3. Functions at addresses flagged by **anomaly detection** in Step 3

Read the pseudocode to understand logic, identify called subroutines, and
discover strings or constants. Follow interesting calls by decompiling those
target functions next.

If the Ghidra server is enabled, decompilation quality improves significantly
for optimized code, C++ vtable dispatch, and complex control flow.

### Step 6: Disassemble for Precision

When decompilation is ambiguous or you need exact instruction-level detail:

```
disassemble_function(fileId: "suspicious.exe", address: "0x401000")
```

This returns the raw assembly listing with formatted instructions. Use
disassembly to:
- Verify decompiler output against ground truth
- Analyze anti-analysis tricks (opaque predicates, stack manipulation)
- Identify shellcode patterns or hand-written assembly
- Examine specific instruction sequences (syscalls, CPUID, RDTSC)

### Step 7: Trace Cross-References

Map the call graph and data flow using `get_xrefs`:

```
get_xrefs(fileId: "suspicious.exe", address: "0x401000")
```

Use xrefs to answer:
- **Who calls this function?** — Find all callers to understand execution paths
- **What references this address?** — Locate code that uses a string, constant,
  or API import
- **How is this data used?** — Trace from a suspicious string back to the code
  that processes it

Follow xref chains to discover hidden functionality: start from a known
interesting address and walk callers/callees to build a picture of the
binary's behavior.

### Step 8: Annotate as You Go

Document findings directly in the binary using three annotation tools:

**Add comments** to explain what code does at specific addresses:
```
add_comment(fileId: "suspicious.exe", address: "0x401050", text: "C2 beacon URL decryption routine")
```

**Rename functions** to replace generic `sub_XXXX` names:
```
rename_function(fileId: "suspicious.exe", address: "0x401000", name: "decrypt_c2_config")
```

**Bookmark key locations** for quick navigation:
```
add_bookmark(fileId: "suspicious.exe", address: "0x401000", label: "Main C2 handler")
```

Annotations sync to any connected peek-a-bin browser instance in real-time,
enabling visual navigation and team collaboration. To remove an annotation,
call `add_comment` with an empty `text`, `rename_function` with an empty
`name`, or `add_bookmark` again to toggle it off.

### Step 9: Review All Annotations

Periodically consolidate your findings:

```
list_comments(fileId: "suspicious.exe")
```

This returns all comments, renames, and bookmarks in one view. Use it to:
- Verify you have annotated all key functions
- Check naming consistency across related functions
- Identify gaps in coverage that need further exploration

### Step 10: Iterate on Unexplored Areas

Repeat Steps 4-9 with different focus areas:

- Use `list_functions` with new filter terms based on what you have learned
- Follow xref chains into code paths you have not yet examined
- Focus on specific capability areas:
  - **C2 communication**: network-related functions, URL/IP string references
  - **Persistence**: registry, service, scheduled task functions
  - **Crypto routines**: functions with high cyclomatic complexity and
    mathematical operations
  - **Anti-analysis**: timing checks, debugger detection, environment queries
  - **Privilege escalation**: token manipulation, impersonation functions

For driver (`.sys`) files, use the `driverInfo` from Step 2 to locate the
IRP dispatch table and analyze each handler function.

### Step 11: Export the Analysis

Save all annotations as a portable JSON file:

```
export_analysis(fileId: "suspicious.exe", outputPath: "/output/analysis.json")
```

The exported ExportSchemaV1 JSON contains:
- All bookmarks, renames, and comments with their addresses
- Function metadata
- Hex patches (if any were applied)
- Timestamp and source filename

This file is your primary deliverable and checkpoint. Export frequently
during long analysis sessions.

### Step 12: Import Previous Work

When resuming analysis or collaborating with another analyst:

```
load_pe(filePath: "/samples/suspicious.exe")
import_analysis(fileId: "suspicious.exe", inputPath: "/output/analysis.json")
```

This restores all annotations from a prior session. Use `list_files` to
manage multiple loaded samples when comparing variants or analyzing
multi-stage malware.

## Output Format

The primary output is peek-a-bin's ExportSchemaV1 JSON from `export_analysis`:

```json
{
  "version": 1,
  "fileName": "suspicious.exe",
  "exportedAt": "2026-03-22T14:30:00.000Z",
  "bookmarks": [
    { "address": "0x401000", "label": "Main C2 handler" }
  ],
  "renames": [
    { "address": "0x401000", "name": "decrypt_c2_config" },
    { "address": "0x401200", "name": "beacon_loop" }
  ],
  "comments": [
    { "address": "0x401050", "text": "C2 beacon URL decryption routine" },
    { "address": "0x401100", "text": "XOR key = 0x5A derived from PE timestamp" }
  ],
  "functions": [],
  "hexPatches": []
}
```

Use the `analysis_exporter.py` script to convert this JSON into markdown
reports or CSV for spreadsheet analysis.

## Tips

- **Start with anomalies** — `detect_anomalies` highlights the most suspicious
  areas before you read a single instruction
- **Filter aggressively** — `list_functions` with terms like "crypt", "http",
  "socket", "reg", "inject", "dll", "thread" quickly surfaces interesting code
- **Cross-check decompilation** — when pseudocode looks wrong, verify with
  `disassemble_function`; the raw assembly is always ground truth
- **Annotate early and often** — renaming even a few functions dramatically
  improves readability of decompiled code that calls them
- **Use bookmarks as a roadmap** — they mark your progress and sync to the
  browser for visual navigation
- **Export frequently** — it is your checkpoint/save mechanism; treat it like
  saving a document
- **Driver analysis shortcut** — for `.sys` files, `load_pe` returns
  `driverInfo` with IRP dispatch table locations; start your analysis there
- **Enable Ghidra server for complex binaries** — its decompilation handles
  optimized code and C++ vtables much better than the built-in IR decompiler
- **Combine with other skills**:
  - `mitre-attack-mapping` — map discovered capabilities to ATT&CK techniques
  - `yara-rule-development` — generate detection rules from patterns found
  - `ioc-extraction` — extract IOCs from strings discovered during exploration
  - `malware-report-writing` — use the exported analysis as input for a
    structured report
- **Multi-sample workflows** — load multiple related samples (dropper + payload,
  or variants) and use `list_files` to switch between them, comparing functions
  and annotations
- **Real-time collaboration** — annotations made via MCP push to any connected
  browser instance; useful for team walkthroughs and presentations