# Reversecore MCP (oci · ghcr.io/sjkim1127/reversecore_mcp:3.0.3)

Security-first MCP server for reverse engineering, malware analysis, forensics, and SAST.

- Trust score: 45/100 (low)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-22

## Components

- oci · `ghcr.io/sjkim1127/reversecore_mcp:3.0.3`: 45/100 (this document), [markdown](https://verifymcp.io/servers/sjkim1127-reversecore-mcp/ghcr-io-sjkim1127-reversecore-mcp-3-0-3.md), [page](https://verifymcp.io/servers/sjkim1127-reversecore-mcp/ghcr-io-sjkim1127-reversecore-mcp-3-0-3)
- pypi · `reversecore-mcp`: 37/100, [markdown](https://verifymcp.io/servers/sjkim1127-reversecore-mcp/reversecore-mcp.md), [page](https://verifymcp.io/servers/sjkim1127-reversecore-mcp/reversecore-mcp)

## Channel facts

- Registry: `oci`
- Package: `ghcr.io/sjkim1127/reversecore_mcp:3.0.3`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-22.

- **Supply Chain Security**: 0/100
  - Malware scan not yet available for this package.
  - Known CVEs could not be checked: this artifact ships no SBOM, so there is no dependency list to read. Publishing one would let us assess it.
  - Install-script risk not yet assessed.
  - Dependency health could not be checked: this artifact ships no SBOM, so there is no dependency list to read. Publishing one would let us assess it.
- **Provenance & Transparency**: 48/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 8 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 82/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 15131 tokens (~117/item across 129 items; 125 tools + 4 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 30/100
  - Stability observed for 9 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 97/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 88% of tool parameters carry a description.
  - Structured output schemas are declared (97% of tools); any adoption earns full credit.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### Claude

```bash
claude mcp add sjkim1127-reversecore-mcp -- docker run --rm -i ghcr.io/sjkim1127/reversecore_mcp:3.0.3
```

### Codex

```bash
codex mcp add sjkim1127-reversecore-mcp -- docker run --rm -i ghcr.io/sjkim1127/reversecore_mcp:3.0.3
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "sjkim1127-reversecore-mcp": {
      "type": "local",
      "command": [
        "docker",
        "run",
        "--rm",
        "-i",
        "ghcr.io/sjkim1127/reversecore_mcp:3.0.3"
      ],
      "enabled": true
    }
  }
}
```

### Hermes

```yaml
mcp_servers:
  sjkim1127-reversecore-mcp:
    command: "docker"
    args: ["run", "--rm", "-i", "ghcr.io/sjkim1127/reversecore_mcp:3.0.3"]
```

### Other

```json
{
  "mcpServers": {
    "sjkim1127-reversecore-mcp": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/sjkim1127/reversecore_mcp:3.0.3"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-22 (score 45, +4)

- [functional improvement] Stability: unverified → 0.30

### 2026-08-13 (score 41)

First indexed and scored.

## MCP tools (125)

### `generate_advanced_yara_rule` (~116 tokens)

Generate an advanced YARA rule based on radare2 disassembly opcodes.
This masks offsets in CALL/JMP instructions to reduce false positives.

Input parameters:

- `address` (string, required): Start address
- `file_path` (string, required): Path to the binary
- `mask_operands` (boolean): Whether to mask CALL/JMP operands
- `num_instructions` (integer): Number of instructions to process
- `rule_name` (string): Name of the generated YARA rule
- `timeout` (integer): Execution timeout

Output parameters:

- `result`

### `diff_binaries` (~273 tokens)

Compare two binary files to identify code changes and modifications.

This tool uses radiff2 to perform binary diffing, which is essential for:
\- **Patch Analysis (1-day Exploits)**: Compare pre-patch and post-patch binaries
  to identify security vulnerabilities fixed in updates
\- **Game Hacking**: Find offset changes after game updates to maintain functionality
\- **Malware Variant Analysis**: Identify code differences between malware variants
  (e.g., "90% similar to Lazarus malware, but C2 address generation changed")

The tool provides:
\- Similarity score (0.0-1.0) between binaries
\- List of code changes with addresses and descriptions
\- Optional function-level comparison for targeted analysis

Input parameters:

- `file_path_a` (string, required): Path to the first binary file (e.g., pre-patch version)
- `file_path_b` (string, required): Path to the second binary file (e.g., post-patch version)
- `function_name`: Optional function name to compare (e.g., "main", "sym.decrypt").           If None, performs whole-binary comparison.
- `max_output_size` (integer): Maximum output size in bytes (default: 10MB)
- `timeout` (integer): Timeout in seconds (default: 300s)

Output parameters:

- `result`

### `analyze_variant_changes` (~181 tokens)

Analyze structural changes between two binary variants (Lineage Mapper).

This tool combines binary diffing with control flow analysis to understand
\*how* a binary has evolved. It identifies the most modified functions and
generates their Control Flow Graphs (CFG) for comparison.

\**Use Cases:**
\- **Malware Lineage**: "How did Lazarus Group modify their backdoor?"
\- **Patch Diffing**: "What logic changed in the vulnerable function?"
\- **Variant Analysis**: "Is this a new version of the same malware?"

Input parameters:

- `file_path_a` (string, required): Path to the original binary
- `file_path_b` (string, required): Path to the variant binary
- `timeout` (integer): Execution timeout in seconds
- `top_n` (integer): Number of top changed functions to analyze in detail (default: 3)

Output parameters:

- `result`

### `match_libraries` (~279 tokens)

Match and filter known library functions to focus on user code.

This tool uses radare2's zignatures (FLIRT-compatible signature matching) to:
\- **Reduce Analysis Noise**: Skip analysis of known library functions (strcpy, malloc, etc.)
\- **Focus on User Code**: Identify which functions are original vs library code
\- **Save Time & Tokens**: Reduce analysis scope by 80% by filtering out standard libraries
\- **Improve Accuracy**: Focus AI analysis on the actual malicious/interesting code

Common use cases:
\- Analyzing large binaries (>25MB) where most code is OpenSSL, zlib, MFC, etc.
\- Game client reverse engineering (filter out Unreal Engine / Unity standard library)
\- Malware analysis (focus on custom malware code, skip Windows API wrappers)

The tool automatically uses built-in signature databases for common libraries
and can optionally use custom signature databases for specialized analysis.

Input parameters:

- `file_path` (string, required): Path to the binary file to analyze
- `max_output_size` (integer): Maximum output size in bytes (default: 10MB)
- `signature_db`: Optional path to custom signature database file (.sig format).          If None, uses radare2's built-in signature databases.
- `timeout` (integer): Timeout in seconds (default: 600s)

Output parameters:

- `result`

### `patch_diff_1day` (~99 tokens)

Analyze patch differences for 1-day vulnerability analysis.

This tool focuses on identifying security fixes between two versions of a binary.
It highlights changed functions, basic blocks, and potential vulnerability indicators
that were patched (e.g. added bounds checks).

Input parameters:

- `file_path_a` (string, required): Path to pre-patch binary.
- `file_path_b` (string, required): Path to post-patch binary.
- `timeout` (integer): Timeout in seconds.

Output parameters:

- `result`

### `parse_binary_with_lief` (~89 tokens)

Parse binary metadata using LIEF and return structured results.

Memory-safe implementation with progressive limits:
\- Under 100MB: Full parsing with all details
\- 100-500MB: Warning + reduced extraction limits
\- Over 500MB: Minimal parsing (headers only)
\- Over config limit: Rejected

Input parameters:

- `file_path` (string, required)
- `format` (string)

Output parameters:

- `result`

### `generate_signature` (~227 tokens)

Generate a YARA signature from opcode bytes at a specific address.

This tool extracts opcode bytes from a function or code section and formats
them as a YARA rule, enabling automated malware detection. It attempts to
mask variable values (addresses, offsets) to create more flexible signatures.

\**Use Cases:**
\- Generate detection signatures for malware samples
\- Create YARA rules for threat hunting
\- Automate IOC (Indicator of Compromise) generation
\- Build malware family signatures

\**Workflow:**
1\. Extract opcode bytes from specified address
2\. Apply basic masking for variable values (optional)
3\. Format as YARA rule template
4\. Return ready-to-use YARA rule

Input parameters:

- `address` (string, required): Start address for signature extraction (e.g., 'main', '0x401000')
- `file_path` (string, required): Path to the binary file (must be in workspace)
- `length` (integer): Number of bytes to extract (default 32, recommended 16-64)
- `timeout` (integer): Execution timeout in seconds (default 300)

Output parameters:

- `result`

### `generate_yara_rule` (~144 tokens)

Generate a YARA rule from function bytes.

This tool extracts bytes from a function and generates a ready-to-use
YARA rule for malware detection and threat hunting.

Input parameters:

- `byte_length` (integer): Number of bytes to extract (default 64, max 1024)
- `file_path` (string, required): Path to the binary file (must be in workspace)
- `function_address` (string, required): Function address to extract bytes from (e.g., 'main', '0x401000')
- `rule_name` (string): Name for the YARA rule (default 'auto_generated_rule')
- `timeout` (integer): Execution timeout in seconds (default 300)

Output parameters:

- `result`

### `run_strings` (~68 tokens)

Extract printable strings using the ``strings`` CLI.

Input parameters:

- `_bypass_queue` (boolean)
- `file_path` (string, required)
- `max_output_size` (integer)
- `min_length` (integer)
- `run_async` (boolean)
- `timeout` (integer)

Output parameters:

- `result`

### `run_binwalk` (~49 tokens)

Analyze binaries for embedded content using binwalk.

Input parameters:

- `depth` (integer)
- `file_path` (string, required)
- `max_output_size` (integer)
- `timeout` (integer)

Output parameters:

- `result`

### `run_binwalk_extract` (~257 tokens)

Extract embedded files and file systems from a binary using binwalk.

This tool performs deep extraction of embedded content, including:
\- Compressed archives (gzip, bzip2, lzma, xz)
\- File systems (squashfs, cramfs, jffs2, ubifs)
\- Firmware images and bootloaders
\- Nested/matryoshka content (files within files)

\**Use Cases:**
\- **Firmware Analysis**: Extract file systems from router/IoT firmware
\- **Malware Unpacking**: Extract payloads from packed/embedded malware
\- **Forensics**: Recover embedded files from disk images
\- **CTF Challenges**: Extract hidden data from challenge files

Input parameters:

- `depth` (integer): Maximum extraction depth for nested content (default: 8)
- `file_path` (string, required): Path to the binary file to extract
- `matryoshka` (boolean): Enable recursive extraction (files within files)
- `max_output_size` (integer): Maximum output size in bytes
- `output_dir`: Directory to extract files to (default: creates temp dir)
- `timeout` (integer): Extraction timeout in seconds (default: 600 for large files)

Output parameters:

- `result`

### `scan_for_versions` (~159 tokens)

Extract library version strings and CVE clues from a binary.

This tool acts as a "Version Detective", scanning the binary for strings that
look like version numbers or library identifiers (e.g., "OpenSSL 1.0.2g",
"GCC 5.4.0"). It helps identify outdated components and potential CVEs.

\**Use Cases:**
\- **SCA (Software Composition Analysis)**: Identify open source components
\- **Vulnerability Scanning**: Find outdated libraries (e.g., Heartbleed-vulnerable OpenSSL)
\- **Firmware Analysis**: Determine OS and toolchain versions

Input parameters:

- `file_path` (string, required): Path to the binary file
- `timeout` (integer): Execution timeout in seconds

Output parameters:

- `result`

### `extract_rtti_info` (~75 tokens)

Extract RTTI (Run-Time Type Information) from C++ binaries.

RTTI provides class names and inheritance hierarchies in C++ binaries,
which is invaluable for understanding object-oriented malware and game clients.

Input parameters:

- `file_path` (string, required): Path to the binary file
- `timeout` (integer): Execution timeout in seconds

Output parameters:

- `result`

### `detect_packer` (~48 tokens)

Detect packer, compiler, and protector using LIEF and Strings heuristics.
(Replaces legacy Detect It Easy tool)

Input parameters:

- `file_path` (string, required): Path to the binary file to analyze

### `detect_packer_deep` (~50 tokens)

Deep scan for packer/compiler/protector detection.
Combines LIEF section entropy analysis with full strings heuristic scanning.

Input parameters:

- `file_path` (string, required): Path to the binary file to analyze

### `run_capa` (~105 tokens)

Analyze binary capabilities using CAPA (Mandiant FLARE).

CAPA identifies capabilities in executable files and provides high-level
behavioral information such as:
\- "encrypt data using AES"
\- "delete files"
\- "communicate via HTTP"
\- "create persistence via registry"

Input parameters:

- `file_path` (string, required): Path to the binary file to analyze
- `output_format` (string): Output format - "summary" (default), "detailed", or "json"

### `run_capa_quick` (~69 tokens)

Quick CAPA scan returning only high-risk capabilities.

Faster than full run_capa, focuses on:
\- Anti-analysis techniques
\- Persistence mechanisms
\- C2 communication
\- Data exfiltration
\- Impact capabilities

Input parameters:

- `file_path` (string, required): Path to the binary file

### `emulate_binary` (~189 tokens)

Emulate the execution of a binary using the Qiling framework.

Allows running PE, ELF, and Mach-O binaries under dynamic OS-level sandbox emulation.
Captures register states, memory modifications, stdout/stderr, and API/syscall traces.

Input parameters:

- `end_address`: Hexadecimal or decimal address to stop emulation at (optional).
- `file_path` (string, required): Absolute or workspace-relative path to the binary to emulate.
- `mock_files`: Dictionary of virtual file paths and content to mock in the filesystem.
- `registers`: Dictionary of initial register values to set before emulation (e.g. {"eax": 1}).
- `stack_inputs`: List of integer values to push onto the stack before starting.
- `start_address`: Hexadecimal or decimal address to start emulation from (optional).
- `timeout` (integer): Maximum execution timeout in seconds (default is 10s).

Output parameters:

- `result`

### `generate_fuzzing_harness` (~147 tokens)

Generate a dynamic fuzzing harness (Qiling + AFL++) for a vulnerable function.

Instead of running a heavy fuzzer within the MCP server, this tool generates
a ready-to-use Python script that the user can run with AFL++ to prove
vulnerability exploitability.

Input parameters:

- `file_path` (string, required): Path to the vulnerable binary.
- `fuzzer_type` (string): The type of harness to generate (default: "qiling").
- `save_to_workspace` (boolean): If True, saves the generated harness to the workspace.
- `target_function_or_addr` (string, required): The function name or hex address to fuzz (e.g. 0x401234).

Output parameters:

- `result`

### `run_fuzzing_campaign` (~464 tokens)

Run a real AFL++ fuzzing campaign and automatically triage all crashes.

This tool bridges ``generate_fuzzing_harness`` and ``triage_crash`` into a
complete, automated fuzzing pipeline:

1\. **Setup**: Creates a temporary seed corpus and output directory.
2\. **Fuzz**: Runs ``afl-fuzz`` for ``timeout_seconds``, sending inputs via
   \``@@`` file substitution or stdin depending on ``use_stdin``.
3\. **Collect**: Gathers all unique crash files from the AFL++ output
   directory, deduplicated by content signature.
4\. **Triage**: Runs ``triage_crash`` (GDB) on each unique crash to assess
   exploitability (CONFIRMED / LIKELY / POSSIBLE / UNKNOWN).
5\. **Report**: Returns a structured report with crash statistics, triage
   results sorted by severity, and actionable next steps.

Input parameters:

- `afl_extra_args` (string): Space-separated extra arguments for afl-fuzz (e.g., ``"-D"`` for deterministic mode, ``"-p exploit"`` for exploit schedule).
- `file_path` (string, required): Workspace-relative or absolute path to the target binary.
- `fuzzer_type` (string): The type of harness to generate (default: "qiling").
- `max_crashes_to_triage` (integer): Maximum number of unique crashes to triage with GDB. Higher values give more coverage but take longer. Default: 20.
- `seed_corpus`: Optional path to a directory containing seed input files. If ``None``, a minimal corpus (empty file + single byte) is created.
- `target_function_or_addr`: If provided, automatically generates a fuzzing harness for this target function or address before fuzzing.
- `timeout_seconds` (integer): How long to run the fuzzer in seconds. Default: 300 (5 min). For meaningful coverage, use at least 3600 (1 hour) in production.
- `use_stdin` (boolean): If ``True``, crash files are fed via stdin for triage. Set to ``False`` if the binary expects a file path as argv[1].

Output parameters:

- `result`

### `triage_crash` (~101 tokens)

Analyze a crash file against a binary using GDB to determine exploitability.

Input parameters:

- `binary_path` (string, required): Path to the executable binary.
- `crash_file` (string, required): Path to the crash input file (e.g., from AFL++ crashes/ dir).
- `timeout` (integer): Maximum execution time in seconds.
- `use_stdin` (boolean): If True, pipe the crash file to stdin. If False, pass it as an argument.

Output parameters:

- `result`

### `verify_path_and_get_args` (~119 tokens)

Run symbolic execution using angr to verify path reachability and extract inputs.

Allows proving path reachability to a target instruction and extracting concrete inputs.

Input parameters:

- `avoid_addrs`: Optional list of instruction addresses to avoid.
- `file_path` (string, required): Workspace-relative or absolute path to the binary to analyze.
- `start_addr`: Optional starting instruction address. If omitted, starts from entry point.
- `target_addr` (string, required): The target instruction address to reach (hex or integer).
- `timeout` (integer): Maximum execution timeout in seconds.

Output parameters:

- `result`

### `analyze_patch_diff_auto` (~326 tokens)

Automatically infer vulnerabilities from binary patch differences.

This tool goes beyond structural binary diffing (``diff_binaries``,
\``patch_diff_1day``) by applying a **security pattern recognition engine**
to the changed functions. It answers: *"What vulnerability was fixed?"* and
\*"How can I exploit the old version?"*

The workflow:
1\. Compute overall similarity and identify the most-changed functions via
   \``radiff2``.
2\. For each changed function, extract disassembly diffs and structural
   metadata (size change, basic block delta).
3\. Apply 10 security patch pattern rules (bounds check added, safe API
   migration, null check, integer overflow, command injection, etc.).
4\. Score matches by confidence and severity, generating per-function
   vulnerability inferences with exploitation hints.
5\. Return a ranked report with CVE-style vulnerability candidates and
   actionable next steps.

Input parameters:

- `auto_infer_vuln` (boolean): When ``True`` (default), runs the pattern recognition engine on each changed function. Set to ``False`` for raw diff only.
- `file_path_new` (string, required): Path to the **post-patch** binary.
- `file_path_old` (string, required): Path to the **pre-patch** (vulnerable) binary.
- `timeout` (integer): Total analysis timeout in seconds. Default: 300.
- `top_functions` (integer): Maximum number of changed functions to analyse in detail. Higher values are slower but more thorough. Default: 10.

Output parameters:

- `result`

### `taint_trace` (~423 tokens)

Automatically trace taint paths from user input sources to dangerous sinks.

This tool performs automated taint analysis by:

1\. **Source discovery**: Finds all calls to user-input functions (``read``,
   \``fgets``, ``recv``, ``getenv``, ``argv``, etc.) via radare2 xrefs.
2\. **Sink discovery**: Finds all calls to dangerous functions (``strcpy``,
   \``system``, ``execve``, ``sprintf``, etc.) and maps their CWE class.
3\. **Path verification** (optional): For each source→sink pair, invokes the
   angr symbolic execution engine (``angr_worker.py``) to check whether the
   sink is actually reachable from the source with user-controlled data.
   If reachable, angr also extracts a **concrete input** that triggers the sink.
4\. **Report**: Returns ranked taint paths sorted by severity and reachability.

Input parameters:

- `file_path` (string, required): Workspace-relative or absolute path to the target binary.
- `max_paths` (integer): Maximum number of source→sink paths to analyse and return. Default: 10.
- `sinks`: Optional list of sink function names to trace to. If ``None``, uses the full default sink database (``strcpy``, ``system``, ``execve``, etc.). Example: ``["system", "strcpy"]``.
- `sources`: Optional list of source function names to trace from. If ``None``, uses the full default source database (``read``, ``fgets``, ``recv``, ``getenv``, ``argv``, etc.). Example: ``["fgets", "recv"]``.
- `timeout` (integer): Total analysis timeout in seconds. Default: 300.
- `verify_with_angr` (boolean): When ``True`` (default), attempts symbolic execution to verify path reachability and extract concrete inputs. Set to ``False`` for fast static-only analysis (no angr).

Output parameters:

- `result`

### `vt_lookup` (~226 tokens)

Look up IOC reputation using the VirusTotal API v3.

Accepts a list of file hashes (MD5/SHA1/SHA256), IP addresses, domain
names, and URLs. Returns per-IOC verdict, detection counts, and
enrichment data from VirusTotal's 70+ security vendors.

\**API key required**: Set ``REVERSECORE_VT_API_KEY`` environment variable,
or pass the key directly via the ``api_key`` parameter.

Input parameters:

- `api_key`: VirusTotal API key. If omitted, uses ``REVERSECORE_VT_API_KEY`` environment variable.
- `iocs` (array, required): List of IOCs to look up (max 20 per call). Supported types: - File hashes: MD5 (32 chars), SHA1 (40), SHA256 (64) - IP addresses: IPv4 (e.g. ``8.8.8.8``) - Domain names: (e.g. ``evil.example.com``) -…

Output parameters:

- `result`

### `audit_source_code` (~144 tokens)

Perform a security audit on a source code file (SAST).

This tool analyzes source code (C, C++, Python, Go, etc.) to identify
potential security vulnerabilities such as buffer overflows, injection flaws,
and weak cryptography. It provides a structured breakdown of dangerous patterns
found in the code to guide deeper manual or AI-driven analysis.

Use this tool when you have access to original source code or when you
want to analyze decompiled output exported to a file.

Input parameters:

- `file_path` (string, required): Path to the source code file.
- `language`: Optional language hint (e.g., 'c', 'python'). If None, inferred from extension.

Output parameters:

- `result`

### `create_memory_session` (~109 tokens)

Create a new memory session to store memories.

Use this when starting a new reverse engineering analysis.
The session name should be descriptive and follow a template format
like 'malware_analysis_2024_001' or 'game_cheat_detection'.

Input parameters:

- `binary_name`: Name of the binary being analyzed (optional)
- `binary_path`: Path to binary for automatic hash calculation (optional)
- `name` (string, required): Template name for the session (e.g., 'malware_sample_001')

### `save_memory_item` (~209 tokens)

Save important information to long-term memory.

Use this to remember:
\- Function addresses and their purposes
\- Vulnerability patterns discovered
\- API call sequences
\- User instructions and preferences
\- Interesting strings or structures

Input parameters:

- `category`: Optional category: - 'function': Function-related info - 'vulnerability': Security issues - 'string': Important strings - 'structure': Data structures - 'api': API usage patterns
- `content` (string, required): The actual content to remember (text or JSON string)
- `importance` (integer): Importance level 1-10 (default 5, higher = more important)
- `memory_type` (string, required): Type of memory: - 'finding': Analysis discoveries - 'pattern': Code/behavior patterns - 'instruction': User preferences/instructions - 'context': General context information
- `session_id` (string, required): Session ID from create_memory_session
- `user_prompt`: The user's prompt when this was discovered (optional)

### `recall_memory_item` (~98 tokens)

Search and recall memories from past analyses.

Use this when you need to remember something from earlier,
or when the user asks about previous findings.

Input parameters:

- `limit` (integer): Maximum number of results (default 10)
- `memory_type`: Filter by type ('finding', 'pattern', 'instruction', 'context')
- `query` (string, required): Search query (keywords or phrases)
- `session_id`: Limit search to specific session (optional)

### `list_memory_sessions` (~67 tokens)

List all analysis sessions with timestamps and status.

Use this to see what analyses have been done before,
or to find a session to resume.

Input parameters:

- `limit` (integer): Maximum number of sessions to return
- `status`: Filter by status ('in_progress', 'completed', 'paused')

### `get_memory_session_detail` (~54 tokens)

Get complete details and context for a specific session.

Use this when resuming an analysis or reviewing past work.
Returns all memories and patterns associated with the session.

Input parameters:

- `session_id` (string, required): Session ID to retrieve

### `resume_memory_session` (~67 tokens)

Resume a previous analysis session with full context restoration.

Use this when the user says "continue where we left off" or
"resume yesterday's analysis".

Input parameters:

- `binary_name`: Find latest session for this binary (optional)
- `session_id`: Specific session ID to resume (optional)

### `complete_memory_session` (~60 tokens)

Mark an analysis session as completed with a summary.

Use this when finishing an analysis to save a summary
for future reference.

Input parameters:

- `session_id` (string, required): Session ID to complete
- `summary` (string, required): AI-generated summary of the analysis findings

### `save_pattern` (~134 tokens)

Save a code/behavior pattern for cross-session similarity search.

Use this when you discover a notable pattern that might appear
in other samples. This enables "Hey, this looks similar to before!"

Input parameters:

- `description`: Human-readable description of the pattern
- `pattern_signature` (string, required): Normalized pattern signature for matching Example: "VirtualAlloc,WriteProcessMemory,CreateRemoteThread"
- `pattern_type` (string, required): Type of pattern: - 'api_sequence': Sequence of API calls - 'code_pattern': Assembly/code pattern - 'behavior': Behavioral pattern
- `session_id` (string, required): Current session ID

### `find_similar_patterns` (~83 tokens)

Find similar patterns from previous analyses.

Use this to check if current findings match anything
from past analyses. Enables knowledge transfer across projects.

Input parameters:

- `current_session_id`: Exclude current session from results
- `limit` (integer): Maximum results
- `pattern_signature` (string, required): Pattern to search for
- `pattern_type`: Limit to specific type (optional)

### `get_relevant_context` (~72 tokens)

Get relevant context from past analyses for current work.

Use this proactively when analyzing something new to check
if there's relevant knowledge from previous sessions.

Input parameters:

- `current_session_id`: Current session to exclude
- `description` (string, required): Description of what you're currently analyzing
- `limit` (integer): Maximum relevant items

### `update_memory_session_time` (~55 tokens)

Update the cumulative analysis time for a session.

Call this periodically to track how long an analysis takes.

Input parameters:

- `duration_seconds` (number, required): Additional time to add (in seconds)
- `session_id` (string, required): Session ID

### `get_server_health` (~91 tokens)

Get the current health status and resource usage of the MCP server.

Use this to monitor the server's uptime, memory consumption,
and tool execution statistics.

Returns:
    ToolResult containing:
    - uptime_seconds: Server uptime
    - memory_usage_mb: Current memory usage in MB
    - status: 'healthy' or 'degraded'
    - tool_stats: Summary of tool execution success/failure

Output parameters:

- `result`

### `get_tool_metrics` (~31 tokens)

Get detailed execution metrics for specific or all tools.

Input parameters:

- `tool_name`: Optional tool name to filter results

Output parameters:

- `result`

### `run_file` (~34 tokens)

Identify file metadata using the ``file`` CLI utility.

Input parameters:

- `file_path` (string, required)
- `timeout` (integer)

Output parameters:

- `result`

### `copy_to_workspace` (~111 tokens)

Copy any accessible file to the workspace directory.

This tool allows copying files from any location (including AI agent upload directories)
to the workspace where other reverse engineering tools can access them.

Supports files from:
\- Claude Desktop uploads (/mnt/user-data/uploads)
\- Cursor uploads
\- Windsurf uploads
\- Local file paths
\- Any other accessible location

Input parameters:

- `destination_name`: Optional custom filename in workspace (defaults to original name)
- `source_path` (string, required): Absolute or relative path to the source file

Output parameters:

- `result`

### `create_directory` (~61 tokens)

Create a new sub-directory within the workspace.

This tool allows AI agents to dynamically create isolated sub-workspaces
for different tasks or sessions.

Input parameters:

- `directory_path` (string, required): Relative or absolute path of the directory to create.            Must be within the workspace boundary.

Output parameters:

- `result`

### `list_workspace` (~28 tokens)

List all files in the workspace directory.

Returns:
    ToolResult with list of files in workspace

Output parameters:

- `result`

### `scan_workspace` (~197 tokens)

Batch scan all files in the workspace using multiple tools in parallel.

This tool performs a comprehensive scan of the workspace to identify files,
analyze binaries, and detect threats. It runs 'run_file', 'parse_binary_with_lief',
and 'run_yara' (if rules exist) on all matching files concurrently.

\**Workflow:**
1\. Identify files matching patterns (default: all files)
2\. Run 'file' command on all files
3\. Run 'LIEF' analysis on executable files
4\. Run 'YARA' scan if rules are available
5\. Aggregate results into a single report

Input parameters:

- `ctx`: FastMCP Context for progress reporting (auto-injected)
- `file_patterns`: List of glob patterns to include (e.g., ["*.exe", "*.dll"]).           Default is ["*"] (all files).
- `timeout` (integer): Global timeout for the batch operation in seconds.

Output parameters:

- `result`

### `explain_patch` (~131 tokens)

Analyze differences between two binaries and explain changes in natural language.

This tool combines binary diffing with decompilation to help understand security patches.
It identifies changed functions, decompiles them, and uses heuristics to explain
the nature of the changes (e.g., "Added bounds check", "Replaced unsafe API").

Input parameters:

- `file_path_a` (string, required): Path to the original binary (e.g., vulnerable version).
- `file_path_b` (string, required): Path to the modified binary (e.g., patched version).
- `function_name`: Optional specific function to analyze. If None, analyzes top changes.

Output parameters:

- `result`

### `assemble_instructions` (~144 tokens)

Assemble assembly instruction strings into raw machine byte values using Keystone.

Input parameters:

- `arch` (string): Target architecture (e.g., 'x86', 'arm', 'arm64', 'mips', 'sparc', 'ppc', 'systemz').
- `assembly_code` (string, required): The assembly instruction(s) to compile (separated by newlines or semicolons).
- `base_address` (string): Base address of instructions, useful for resolving relative offsets (hex or decimal string).
- `mode` (string): Target mode/width (e.g., '16', '32', '64' for x86; 'arm', 'thumb' for arm).

Output parameters:

- `result`

### `memory_list_symbols` (~95 tokens)

List available Volatility3 symbol tables for a memory dump.

Volatility3 requires OS-specific symbol tables (ISF files) to run most plugins.
Use this tool to inspect which symbol tables are currently available, then load
the appropriate one using ``memory_load_symbols`` before running analysis plugins.

Input parameters:

- `dump_path` (string, required): Path to the memory dump file (e.g., .raw, .vmem, .mem).

Output parameters:

- `result`

### `memory_analyze` (~182 tokens)

Run a Volatility3 plugin against a memory dump file.

Supports Windows, Linux, and macOS memory dumps. Heavy plugin operations
(malfind, psscan, netscan) are queued via ARQ for non-blocking execution.

Input parameters:

- `_bypass_queue` (boolean): Internal — set True to skip ARQ queueing.
- `dump_path` (string, required): Path to the memory dump file (.raw, .vmem, .mem, .dmp).
- `extra_args`: Additional plugin arguments as a space-separated string (e.g., "--pid 1234").
- `plugin` (string): Volatility3 plugin name. Run ``memory_analyze`` with plugin='help' to see all supported plugins.
- `symbol_path`: Optional path to an ISF symbol table file. Required for some plugins on unknown OS versions.

Output parameters:

- `result`

### `memory_list_processes` (~65 tokens)

List all running processes from a memory dump.

Input parameters:

- `dump_path` (string, required): Path to the memory dump file.
- `include_hidden` (boolean): If True, also run psscan to detect hidden/unlinked processes. Hidden processes may indicate rootkits or process injection.

Output parameters:

- `result`

### `memory_detect_injections` (~86 tokens)

Detect process injection and suspicious memory regions using Volatility3 malfind.

Uses the ``malfind`` plugin to identify memory regions with executable permissions
that contain suspicious patterns (MZ headers, shellcode signatures).

Input parameters:

- `_bypass_queue` (boolean): Internal — set True to skip ARQ queueing.
- `dump_path` (string, required): Path to the memory dump file.

Output parameters:

- `result`

### `memory_extract_strings` (~69 tokens)

Extract ASCII and Unicode strings from a memory dump.

Input parameters:

- `dump_path` (string, required): Path to the memory dump file.
- `limit` (integer): Maximum number of strings to return (default: 500).
- `min_length` (integer): Minimum string length to include (default: 6).

Output parameters:

- `result`

### `memory_dump_module` (~104 tokens)

Dump a loaded module or DLL from a memory dump via Volatility3.

Input parameters:

- `dump_path` (string, required): Path to the memory dump file.
- `module_name`: Name of the module/DLL to dump. If None, dumps all modules for the specified process.
- `output_dir`: Directory to save the dumped module. Defaults to the workspace directory.
- `process_name` (string, required): Name of the target process (e.g., 'explorer.exe').

Output parameters:

- `result`

### `disk_list_partition` (~50 tokens)

List partition layout of a disk image using Sleuth Kit mmls.

Input parameters:

- `image_path` (string, required): Path to the raw disk image file (.img, .dd, .raw, .iso).

Output parameters:

- `result`

### `disk_list_files` (~143 tokens)

List all files and directories in a disk/filesystem image.

Input parameters:

- `directory` (string): Directory path within the image to list (default: root '/').
- `image_path` (string, required): Path to the disk or filesystem image file.
- `include_deleted` (boolean): If True, also show deleted/unallocated files (marked with '*').
- `limit` (integer): Maximum number of entries to return (default: 1000).
- `offset`: Partition start offset in sectors (from disk_list_partition output). Leave None if image_path is a filesystem image (not a full disk image).
- `recursive` (boolean): If True, recursively list all subdirectories.

Output parameters:

- `result`

### `disk_recover_deleted` (~122 tokens)

Recover a deleted file from a disk/filesystem image by inode number.

Use ``disk_list_files`` with ``include_deleted=True`` first to find the
inode number of the deleted file, then pass it to this tool.

Input parameters:

- `image_path` (string, required): Path to the disk or filesystem image file.
- `inode` (string, required): Inode number of the file to recover (from disk_list_files output).
- `offset`: Partition start offset in sectors (from disk_list_partition).
- `output_path` (string, required): Destination path to write the recovered file.

Output parameters:

- `result`

### `disk_analyze_mft` (~100 tokens)

Analyze the NTFS Master File Table (MFT) for file timeline and metadata.

Provides full filesystem metadata including file creation/modification/access
times, which is critical for establishing a forensic timeline.

Input parameters:

- `image_path` (string, required): Path to an NTFS disk or filesystem image.
- `limit` (integer): Maximum MFT entries to return (default: 500).
- `offset`: Partition start offset in sectors (from disk_list_partition).

Output parameters:

- `result`

### `disk_extract_file` (~82 tokens)

Extract a live (non-deleted) file from a disk image by inode number.

Input parameters:

- `image_path` (string, required): Path to the disk or filesystem image file.
- `inode` (string, required): Inode number of the file to extract.
- `offset`: Partition start offset in sectors.
- `output_path` (string, required): Destination path to write the extracted file.

Output parameters:

- `result`

### `disk_hash_verify` (~102 tokens)

Compute and verify the integrity hash of a disk image or recovered file.

Essential for forensic chain of custody — verifies that an image has not
been tampered with since acquisition.

Input parameters:

- `algorithm` (string): Hash algorithm to use ('sha256', 'sha1', 'md5'). Default: 'sha256'.
- `expected_hash`: Optional expected hash value to verify against.
- `image_path` (string, required): Path to the disk image or file to hash.

Output parameters:

- `result`

### `pcap_analyze` (~116 tokens)

Summarize sessions, protocols, and packet statistics from a PCAP file.

Provides a high-level overview including total packets, unique hosts,
protocol distribution, top talkers, and session summary — ideal as a
first-pass triage of a PCAP capture.

Input parameters:

- `max_packets` (integer): Maximum number of packets to process (default: 10,000). For large captures, use a smaller value or filter first.
- `pcap_path` (string, required): Path to a PCAP or PCAPNG capture file.

Output parameters:

- `result`

### `pcap_list_connections` (~81 tokens)

List all unique IP/port connections observed in a PCAP capture.

Input parameters:

- `max_packets` (integer): Maximum packets to process (default: 50,000).
- `pcap_path` (string, required): Path to a PCAP or PCAPNG capture file.
- `protocol`: Filter by protocol ('tcp', 'udp', or None for all).

Output parameters:

- `result`

### `pcap_extract_dns` (~108 tokens)

Extract DNS queries and responses from a PCAP capture.

Useful for identifying C2 domain lookups, DGA patterns, DNS tunneling,
and suspicious resolution activity.

Input parameters:

- `include_responses` (boolean): If True, also extract DNS response records (A, AAAA, MX, TXT).
- `max_packets` (integer): Maximum packets to process (default: 50,000).
- `pcap_path` (string, required): Path to a PCAP or PCAPNG capture file.

Output parameters:

- `result`

### `pcap_extract_c2` (~123 tokens)

Detect potential C2 traffic patterns in a PCAP capture.

Detects:
\- Beaconing behavior (periodic connections to same host)
\- Connections to known suspicious ports
\- Unusually long/persistent connections
\- DNS-over-HTTPS (DoH) patterns

Input parameters:

- `beacon_threshold_sec` (integer): Maximum jitter window (seconds) to consider as beaconing.
- `max_packets` (integer): Maximum packets to process (default: 100,000).
- `pcap_path` (string, required): Path to a PCAP or PCAPNG capture file.

Output parameters:

- `result`

### `pcap_reconstruct_stream` (~152 tokens)

Reconstruct TCP stream payload from a PCAP capture.

Reassembles the raw payload of a specific TCP conversation, useful for
extracting transferred files, command output, or HTTP request/response bodies.

Input parameters:

- `dst_ip` (string, required): Destination IP address of the stream.
- `dst_port` (integer, required): Destination TCP port of the stream.
- `max_bytes` (integer): Maximum payload bytes to reconstruct (default: 1 MB).
- `max_packets` (integer): Maximum packets to process (default: 10,000).
- `pcap_path` (string, required): Path to a PCAP or PCAPNG capture file.
- `src_ip` (string, required): Source IP address of the stream.

Output parameters:

- `result`

### `artifact_collect` (~146 tokens)

Collect and normalize forensic artifacts from analysis results.

Use this tool to register artifacts discovered during memory, disk, or network
analysis. Artifacts are normalized and stored for subsequent correlation with
\``artifact_correlate_ioc`` and YARA rule generation via ``artifact_generate_yara``.

Input parameters:

- `artifact_type` (string): Type of artifact (see ARTIFACT_TYPES for valid values).
- `artifacts` (array, required): List of artifact dictionaries. Each should have at least a 'value' or 'name' key. Additional fields are stored as metadata.
- `source` (string): Human-readable source label (e.g., 'memory_malfind', 'pcap_c2_detect').

Output parameters:

- `result`

### `artifact_correlate_ioc` (~136 tokens)

Correlate collected forensic artifacts against IoC patterns.

Runs IoC extraction patterns (IP, URL, hash, CVE, registry) against all
artifact values to automatically enrich them with threat intelligence signals.
Uses the existing ``extract_iocs`` infrastructure from the malware module.

Input parameters:

- `artifacts` (array, required): List of normalized artifacts (from ``artifact_collect`` output).
- `check_domains` (boolean): Extract and flag suspicious domains.
- `check_hashes` (boolean): Extract and flag file hashes (MD5/SHA1/SHA256).
- `check_ips` (boolean): Extract and flag suspicious IP addresses.

Output parameters:

- `result`

### `artifact_generate_yara` (~125 tokens)

Auto-generate YARA rules from collected forensic artifacts.

Integrates with the adaptive vaccine pipeline to create detection signatures
from suspicious strings, process names, network indicators, and injection
patterns found during forensics analysis.

Input parameters:

- `artifacts` (array, required): List of artifacts (from ``artifact_collect`` or ``artifact_correlate_ioc``).
- `output_path`: Optional path to save the generated .yar rule file. If None, returns rule content only.
- `rule_name` (string): Base name for the generated YARA rule (default: 'forensics_auto').

Output parameters:

- `result`

### `artifact_timeline` (~112 tokens)

Build a chronological event timeline from multi-source forensic artifacts.

Aggregates artifacts from memory, disk (MFT timestamps), and network captures
into a single unified timeline, sorted by timestamp.

Input parameters:

- `artifacts` (array, required): List of artifacts (from ``artifact_collect`` or ``artifact_correlate_ioc``). Artifacts with ``collected_at`` or timestamp fields will be sorted.
- `sort_order` (string): Sort order — 'asc' (oldest first) or 'desc' (newest first).

Output parameters:

- `result`

### `artifact_report` (~127 tokens)

Export a comprehensive forensics investigation report.

Combines artifact collection summary, IoC correlation results, timeline,
and optionally auto-generated YARA rules into a structured Markdown report.

Input parameters:

- `analyst` (string): Analyst name to include in the report header.
- `artifacts` (array, required): All collected and enriched artifacts from the investigation.
- `case_name` (string): Name/identifier for this forensics case.
- `include_yara` (boolean): If True, auto-generate and include YARA rules in the report.
- `output_path`: Optional path to save the report as a Markdown file.

Output parameters:

- `result`

### `dormant_detector` (~227 tokens)

Detect hidden malicious behaviors using static analysis + emulation.

This tool performs a hybrid analysis:
1\. **Scan**: Finds "Orphan Functions" (not called by main) and "Suspicious Logic" (magic value checks).
2\. **Hypothesize**: (Optional) If `hypothesis` is provided, it sets up emulation conditions.
3\. **Emulate**: (Optional) If `focus_function` is provided, it emulates that specific function
   to verify the hypothesis (e.g., "If register eax=0x1234, does it call system()?").

Input parameters:

- `file_path` (string, required): Path to the binary.
- `focus_function`: (Optional) Name or address of a specific function to emulate.
- `hypothesis`: (Optional) Dictionary defining emulation parameters:         {             "registers": {"eax": "0x1234", "zf": "1"},             "args": ["arg1", "arg2"],             "max_steps": 100         }
- `timeout` (integer): Execution timeout.

Output parameters:

- `result`

### `adaptive_vaccine` (~184 tokens)

Generate automated defenses against detected threats.

Actions:
\- "yara": Generate YARA detection rule
\- "patch": Generate binary patch (requires file_path)
\- "both": Generate both YARA rule and patch

Input parameters:

- `action` (string): Type of defense to generate
- `dry_run` (boolean): If True, only preview patch without applying
- `file_path`: Path to binary (required for "patch" action)
- `threat_report` (object, required): Threat information from Ghost Trace or Trinity Defense           Format: {               "function": "func_name",               "address": "0x401000",               "instruction": "cmp eax, 0xDEADBEE…

Output parameters:

- `result`

### `vulnerability_hunter` (~273 tokens)

Automated vulnerability discovery combining multiple analysis techniques.

This tool performs a comprehensive security analysis:
1\. Scans for dangerous API calls (buffer overflow, command injection, etc.)
2\. Traces back to find how each dangerous call is reached
3\. Identifies if inputs are user-controllable (light taint analysis)
4\. Generates vulnerability report with YARA detection rules

Input parameters:

- `_bypass_queue` (boolean)
- `auto_dynamic_verify` (boolean): If True and angr finds a concrete input, automatically run it in GDB to verify exploitability (default: True)
- `file_path` (string, required): Path to the binary file to analyze
- `generate_yara` (boolean): Generate YARA rules for detected vulnerabilities (default: True)
- `max_depth` (integer): Maximum backtrace depth for call chain analysis (default: 3)
- `run_async` (boolean): If True, run task in background and return job ID immediately (default: False)
- `severity_filter` (string): Filter by severity - "all", "critical", "high", "medium" (default: "all")
- `timeout` (integer): Analysis timeout in seconds (default: 300)
- `use_symbolic_execution` (boolean): Enable angr to verify paths and extract concrete values (default: True)

Output parameters:

- `result`

### `extract_iocs` (~240 tokens)

Extract Indicators of Compromise (IOCs) from text or file using regex.

This tool automatically finds and extracts potential IOCs like IP addresses,
URLs, and email addresses from any text input (e.g., strings output,
decompiled code, logs).

Input parameters:

- `extract_bitcoin` (boolean): Whether to extract Bitcoin addresses (default: True)
- `extract_emails` (boolean): Whether to extract email addresses (default: True)
- `extract_hashes` (boolean): Whether to extract MD5/SHA1/SHA256 hashes (default: True)
- `extract_ips` (boolean): Whether to extract IPv4 addresses (default: True)
- `extract_others` (boolean): Whether to extract CVEs, Registry keys, MAC addresses (default: True)
- `extract_urls` (boolean): Whether to extract URLs (default: True)
- `file_path` (string): Alternative: path to a file to extract IOCs from
- `limit` (integer): Maximum number of IOCs to return per category (default: 100)
- `text` (string): The text to analyze for IOCs (can also be a file path)

Output parameters:

- `result`

### `run_yara` (~63 tokens)

Scan binaries against YARA rules via ``yara-python``.

Input parameters:

- `_bypass_queue` (boolean)
- `file_path` (string, required)
- `rule_file` (string, required)
- `run_async` (boolean)
- `timeout` (integer)

Output parameters:

- `result`

### `generate_poc_exploit` (~238 tokens)

Generate and verify a pwntools proof-of-concept exploit script.

Converts the output of ``vulnerability_hunter`` (symbolic execution concrete
input + crash metadata) into a runnable Python POC script using pwntools.
Automatically verifies the POC by executing it against the binary and
checking for fatal crash signals.

Input parameters:

- `concrete_input` (string): Raw exploit input bytes as a string — typically the ``concrete_input`` field from ``vulnerability_hunter`` output. If empty, a cyclic De Bruijn sequence is used for offset discovery.
- `crash_offset` (integer): Byte offset from the start of the input buffer to the saved return address (RIP/EIP). Set to 0 if unknown — the generated script will use ``cyclic()`` to probe for it. Default: 0.
- `file_path` (string, required): Path to the target binary inside the workspace.
- `vulnerability_class` (string): Category of vulnerability to exploit. Supported values: ``"buffer_overflow"`` (default), ``"format_string"``, ``"command_injection"``.

Output parameters:

- `result`

### `build_rop_chain` (~288 tokens)

Automatically build a Return-Oriented Programming (ROP) exploit chain.

Enumerates available ROP gadgets with ROPgadget, then uses the pwntools
\``ROP`` class to construct a working chain for the specified exploit
objective. Supports three strategies: spawning a shell via execve or
\``system()``, returning into libc, and leaking a libc address to defeat ASLR.

Input parameters:

- `file_path` (string, required): Path to the target binary inside the workspace.
- `libc_path` (string): Absolute path to the libc shared object. Required when ``objective="ret2libc"``. Ignored otherwise. Default: ``""``.
- `objective` (string): Exploit goal. One of: ``"shell"`` — call execve('/bin/sh') or plt.system('/bin/sh') (default), ``"ret2libc"`` — call libc.system('/bin/sh') (requires ``libc_path``), ``"leak_libc"`` — leak a GOT addr…
- `offset` (integer): Byte offset from the start of the input buffer to the saved return address (RIP on x86-64, EIP on x86). If ``0``, the chain is returned without padding — prepend ``b'A' * offset`` manually. Default:…

Output parameters:

- `result`

### `autonomous_vuln_hunt` (~708 tokens)

Fully autonomous end-to-end vulnerability discovery and exploit generation.

Orchestrates a complete security research pipeline without manual
intervention:

\**Phase 1 — Enumerate**: Lists all application functions via radare2
and filters out compiler stubs and import trampolines.

\**Phase 1.5 — Taint**: Runs ``taint_trace`` to automatically map
source→sink data-flow paths (stdin/argv/recv → strcpy/system/execve).
Paths reachable by angr are marked with a concrete exploit input.

\**Phase 2 — Hunt**: Runs ``vulnerability_hunter`` which combines static
taint analysis (dangerous API detection), symbolic execution (angr), and
dynamic crash triage (GDB) to confirm exploitability.

\**Phase 2.5 — Fuzz** (optional): When ``enable_fuzzing=True``, runs
\``run_fuzzing_campaign`` (AFL++) for ``fuzzing_timeout`` seconds to
discover crashes that static analysis may have missed.

\**Phase 3 — POC**: For every vulnerability where angr verified a concrete
input and GDB confirmed a crash, automatically generates a pwntools POC
script and verifies it locally.

\**Phase 4 — ROP**: For buffer-overflow POCs rated CONFIRMED or LIKELY,
automatically enumerates gadgets (ROPgadget) and builds a ROP chain
(pwntools) aimed at spawning a shell.

Input parameters:

- `auto_poc` (boolean): When ``True``, automatically call ``generate_poc_exploit`` for every confirmed vulnerability. Default: ``True``.
- `auto_rop` (boolean): When ``True``, automatically call ``build_rop_chain`` for buffer-overflow vulnerabilities whose POC is CONFIRMED or LIKELY. Default: ``True``.
- `enable_fuzzing` (boolean): When ``True``, run ``run_fuzzing_campaign`` (AFL++) in Phase 2.5 after vulnerability_hunter. Requires afl-fuzz on PATH. Default: ``False`` to keep default runtime predictable.
- `enable_taint` (boolean): When ``True`` (default), run ``taint_trace`` in Phase 1.5 to discover source→sink paths before vulnerability_hunter.
- `file_path` (string, required): Path to the target binary inside the workspace.
- `fuzzing_timeout` (integer): How long to run AFL++ in Phase 2.5 (seconds). Default: 120. For meaningful coverage use 3600+ in production.
- `max_functions` (integer): Upper bound on the number of functions to analyse. Increase for larger binaries at the cost of longer runtime. Default: 30.
- `objective` (string): Analysis focus. ``"full"`` analyses all vulnerability classes. Other valid values: ``"buffer_overflow"``, ``"command_injection"``, ``"format_string"``. Default: ``"full"``.
- `severity_filter` (string): Minimum severity level to include in the report. Accepted values: ``"critical"``, ``"high"`` (default), ``"medium"``, ``"all"``.
- `timeout_per_function` (integer): Seconds allocated to ``vulnerability_hunter`` per function batch.  Longer values find deeper bugs.  Default: 90.

Output parameters:

- `result`

### `analyze_heap_exploit` (~491 tokens)

Analyze heap corruption crashes and generate exploitation strategies.

This tool bridges the gap between a raw heap crash and a practical exploit
by performing:

1\. **Crash Analysis**: If a crash file is provided, runs GDB triage via
   \``triage_crash`` to extract the crash signal, address, and backtrace.
2\. **Mitigation Assessment**: Uses LIEF to detect binary protections (PIE,
   NX, canary, RELRO, FORTIFY) and provides bypass strategies for each.
3\. **Heap Technique Selection**: Based on the overflow size, crash signal,
   and detected vulnerability class, selects applicable heap exploitation
   techniques (tcache poisoning, fastbin dup, house of spirit, etc.).
4\. **Chunk Size Analysis**: Calculates the nearest glibc chunk size class
   and estimates the heap layout needed for exploitation.
5\. **Grooming Pseudocode**: Generates pseudocode for setting up the required
   heap layout (grooming) for the selected technique.
6\. **ROP Integration**: Checks if gadgets are available for post-exploitation
   code execution.

Input parameters:

- `crash_file`: Optional path to an AFL++ crash input file. If provided, ``triage_crash`` is run to extract crash context automatically.
- `file_path` (string, required): Workspace-relative or absolute path to the target binary.
- `glibc_version` (string): Target glibc version string for technique selection. Default: ``"2.35"`` (current Ubuntu LTS).
- `overflow_size` (integer): Estimated heap overflow size in bytes. If ``0`` and a ``crash_file`` is provided, the tool attempts to infer the size from the crash backtrace. Default: 0.
- `simulate_esil` (boolean): If ``True``, runs a virtual heap manager via Radare2 ESIL to trace heap layout and verify payload injection. Default: ``False``.
- `target_object` (string): Optional name or description of the heap object being targeted (e.g., ``"file_t struct"``). Used in documentation only.
- `use_stdin_for_crash` (boolean): If ``True``, feeds crash file to binary via stdin. If ``False``, passes as argv[1]. Default: ``True``.

Output parameters:

- `result`

### `Radare2_open_file` (~66 tokens)

Opens a binary file with radare2 for analysis.

Call this tool before any other r2mcp tool. Use an absolute file_path.

Input parameters:

- `arch`
- `bits`
- `file_path` (string, required): Absolute path to the binary file to analyze

### `Radare2_close_file` (~37 tokens)

Close the currently open radare2 session for a file.

Input parameters:

- `file_path` (string, required): Path to the file to close

### `Radare2_analyze` (~176 tokens)

Run binary analysis with optional depth level.

Input parameters:

- `arch`: Optional architecture (e.g., 'mips', 'arm64', 'riscv', 'x86_64')
- `bits`: Optional architecture bits (e.g., 32, 64)
- `file_path` (string, required): Path to the binary file
- `level` (integer): Analysis depth as an INTEGER from 0 to 4 (default: 2). IMPORTANT: Must be an integer. Do NOT pass strings like "full", "deep", or "auto" — those will be rejected. 0 = aa  (basic, fastest) 1 = aaa (au…

### `Radare2_run_command` (~62 tokens)

Execute a raw radare2 command directly.

NOTE: Only analysis commands are allowed. Write and shell commands are blocked.

Input parameters:

- `command` (string, required): The radare2 command to execute
- `file_path` (string, required): Path to the binary file

### `Radare2_calculate` (~80 tokens)

Evaluate a math expression using radare2's number parser.

Useful for: 64-bit math, resolving addresses for symbols,
avoiding hallucinated results.

Input parameters:

- `expression` (string, required): Math expression to evaluate (e.g., "0x100 + sym.flag - 4")
- `file_path` (string, required): Path to the binary file

### `Radare2_list_functions` (~58 tokens)

List all functions discovered during analysis.

Input parameters:

- `file_path` (string, required): Path to the binary file
- `filter`: Regular expression to filter results
- `only_named` (boolean): If true, exclude functions with numeric suffixes

### `Radare2_list_functions_tree` (~34 tokens)

List functions and their successors (call tree).

Input parameters:

- `file_path` (string, required): Path to the binary file

### `Radare2_show_function_details` (~45 tokens)

Display detailed information about a function.

Input parameters:

- `address`: Function address (uses current if not specified)
- `file_path` (string, required): Path to the binary file

### `Radare2_get_current_address` (~34 tokens)

Show the current seek position and function name.

Input parameters:

- `file_path` (string, required): Path to the binary file

### `Radare2_get_function_prototype` (~46 tokens)

Retrieve the function signature at the specified address.

Input parameters:

- `address` (string, required): Address of the function
- `file_path` (string, required): Path to the binary file

### `Radare2_set_function_prototype` (~62 tokens)

Set the function signature (return type, name, arguments).

Input parameters:

- `address` (string, required): Address of the function
- `file_path` (string, required): Path to the binary file
- `prototype` (string, required): Function signature in C-like syntax

### `Radare2_show_headers` (~31 tokens)

Display binary headers and file information.

Input parameters:

- `file_path` (string, required): Path to the binary file

### `Radare2_list_sections` (~33 tokens)

Display memory sections and segments from the binary.

Input parameters:

- `file_path` (string, required): Path to the binary file

### `Radare2_list_imports` (~52 tokens)

List imported symbols.

Note: Use list_symbols for addresses with sym.imp. prefix.

Input parameters:

- `file_path` (string, required): Path to the binary file
- `filter`: Regular expression to filter results

### `Radare2_list_symbols` (~47 tokens)

Show all symbols (functions, variables, imports) with addresses.

Input parameters:

- `file_path` (string, required): Path to the binary file
- `filter`: Regular expression to filter results

### `Radare2_list_entrypoints` (~35 tokens)

Display program entrypoints, constructors and main function.

Input parameters:

- `file_path` (string, required): Path to the binary file

### `Radare2_list_libraries` (~34 tokens)

List all shared libraries linked to the binary.

Input parameters:

- `file_path` (string, required): Path to the binary file

### `Radare2_list_strings` (~82 tokens)

List strings from data sections with optional regex filter.

Input parameters:

- `cursor`: Pagination cursor (line number to start from)
- `file_path` (string, required): Path to the binary file
- `filter`: Regular expression to filter results
- `page_size` (integer): Number of lines per page (default: 1000, max: 10000)

### `Radare2_list_all_strings` (~75 tokens)

Scan the entire binary for strings with optional regex filter.

More thorough than list_strings, but slower.

Input parameters:

- `cursor`: Pagination cursor
- `file_path` (string, required): Path to the binary file
- `filter`: Regular expression to filter results
- `page_size` (integer): Number of lines per page

### `Radare2_list_classes` (~53 tokens)

List class names from various languages (C++, ObjC, Swift, Java, Dalvik).

Input parameters:

- `file_path` (string, required): Path to the binary file
- `filter`: Regular expression to filter results

### `Radare2_list_methods` (~48 tokens)

List all methods belonging to the specified class.

Input parameters:

- `classname` (string, required): Name of the class to list methods for
- `file_path` (string, required): Path to the binary file

### `Radare2_disassemble` (~91 tokens)

Disassemble a specific number of instructions from an address.

Use this to inspect a portion of memory as code without depending
on function analysis boundaries.

Input parameters:

- `address` (string, required): Address to start disassembly
- `file_path` (string, required): Path to the binary file
- `num_instructions` (integer): Number of instructions to disassemble (default: 10, max: 1000)

### `Radare2_disassemble_function` (~134 tokens)

Show assembly listing of the function at the specified address.

Input parameters:

- `address` (string, required): Address OR symbol name of the function to disassemble. Accepts hex addresses (e.g. '0x401000', '0x8d4') as well as function/symbol names (e.g. 'main', 'sym.secret_backdoor', 'sym.process_request'). S…
- `cursor`: Pagination cursor
- `file_path` (string, required): Path to the binary file
- `page_size` (integer): Number of lines per page

### `Radare2_decompile_function` (~92 tokens)

Show C-like pseudocode of the function at the given address.

Use this to inspect code in a function. Do not run multiple times
on the same offset.

Input parameters:

- `address` (string, required): Address of the function to decompile
- `cursor`: Pagination cursor
- `file_path` (string, required): Path to the binary file
- `page_size` (integer): Number of lines per page

### `Radare2_list_decompilers` (~34 tokens)

Show all available decompiler backends.

Input parameters:

- `file_path` (string, required): Path to the binary file

### `Radare2_use_decompiler` (~54 tokens)

Select which decompiler backend to use.

Input parameters:

- `file_path` (string, required): Path to the binary file
- `name` (string, required): Decompiler name (ghidra, r2dec, pdc)

### `Radare2_xrefs_to` (~53 tokens)

Find all code references TO the specified address.

Input parameters:

- `address` (string, required): Address to check for cross-references (hex or symbol name)
- `file_path` (string, required): Path to the binary file

### `Radare2_rename_function` (~56 tokens)

Rename the function at the specified address.

Input parameters:

- `address` (string, required): Address of the function to rename
- `file_path` (string, required): Path to the binary file
- `name` (string, required): New function name

### `Radare2_rename_flag` (~71 tokens)

Rename a flag (variable or data reference) at the specified address.

Input parameters:

- `address` (string, required): Address of the flag
- `file_path` (string, required): Path to the binary file
- `name` (string, required): Current flag name
- `new_name` (string, required): New flag name

### `Radare2_set_comment` (~52 tokens)

Add a comment at the specified address.

Input parameters:

- `address` (string, required): Address to add comment
- `file_path` (string, required): Path to the binary file
- `message` (string, required): Comment text

### `run_radare2` (~54 tokens)

Execute vetted radare2 commands for binary triage.

Input parameters:

- `file_path` (string, required)
- `max_output_size` (integer)
- `r2_command` (string, required)
- `timeout` (integer)

Output parameters:

- `result`

### `trace_execution_path` (~302 tokens)

Trace function calls backwards from a target function (Sink) to find potential execution paths.

This tool helps identify "Exploit Paths" by finding which functions call a dangerous
target function (like 'system', 'strcpy', 'execve'). It performs a recursive
cross-reference analysis (backtrace) to map out how execution reaches the target.

\**Use Cases:**
\- **Vulnerability Analysis**: Check if user input (main/recv) reaches 'system'
\- **Reachability Analysis**: Verify if a vulnerable function is actually called
\- **Taint Analysis Helper**: Provide the path for AI to perform manual taint checking

\**Performance Optimizations (v3.0):**
\- Reduced default depth (3→2) for faster analysis
\- Sink-aware pruning: prioritizes paths through dangerous APIs
\- Dynamic timeout based on file size

Input parameters:

- `file_path` (string, required): Path to the binary file
- `max_depth` (integer): Maximum depth of backtrace (default: 2, reduce for speed)
- `max_paths` (integer): Maximum number of paths to return (default: 5)
- `prioritize_sinks` (boolean): Prioritize paths through dangerous sink APIs (default: True)
- `target_function` (string, required): Name or address of the target function (e.g., 'sym.imp.system', '0x401000')
- `timeout`: Execution timeout in seconds (uses dynamic timeout if None)

Output parameters:

- `result`

### `generate_function_graph` (~148 tokens)

Generate a Control Flow Graph (CFG) for a specific function.

This tool uses radare2 to analyze the function structure and returns
a visualization code (Mermaid by default) or PNG image that helps AI understand
the code flow without reading thousands of lines of assembly.

Input parameters:

- `file_path` (string, required): Path to the binary file (must be in workspace)
- `format` (string): Output format ('mermaid', 'json', 'dot', or 'png'). Default is 'mermaid'.
- `function_address` (string, required): Function address (e.g., 'main', '0x140001000', 'sym.foo')
- `timeout` (integer): Execution timeout in seconds

Output parameters:

- `result`

### `analyze_xrefs` (~235 tokens)

Analyze cross-references (xrefs) for a specific address using radare2.

Cross-references show the relationships between code blocks - who calls this
function (callers) and what it calls (callees). This is essential for:
\- Understanding program flow
\- Tracing data dependencies
\- Identifying attack surfaces
\- Reverse engineering malware C&C

\**xref_type Options:**
\- **"to"**: Show who references this address (callers/jumps TO here)
\- **"from"**: Show what this address references (calls/jumps FROM here)
\- **"all"**: Show both directions (complete relationship map)

Input parameters:

- `address` (string, required): Function or address to analyze (e.g., 'main', '0x401000', 'sym.decrypt')
- `file_path` (string, required): Path to the binary file (must be in workspace)
- `timeout` (integer): Execution timeout in seconds (default: 300)
- `xref_type` (string): Type of cross-references to show: 'all', 'to', 'from' (default: 'all')

Output parameters:

- `result`

### `r2_decompile` (~125 tokens)

Decompile a binary function to pseudo-C using the r2ghidra plugin.

Uses the ``pdg`` command which invokes the embedded Ghidra decompiler
engine inside radare2 — no separate Ghidra or JDK installation required.

Input parameters:

- `file_path` (string, required): Path to the binary (must be inside the workspace).
- `function_address` (string, required): Function to decompile — name (``main``) or hex address (``0x401000``).
- `timeout` (integer): Maximum execution time in seconds (default 300).

Output parameters:

- `result`

### `r2_recover_structures` (~109 tokens)

Recover C struct layouts from a function's memory access patterns.

Analyses local variables (``afvf``), function arguments (``afvj``), and
cross-references (``axtj``) to infer struct field offsets and types.

Input parameters:

- `file_path` (string, required): Path to the binary (must be inside the workspace).
- `function_address` (string, required): Function whose local variables / struct usage to analyse.
- `timeout` (integer): Maximum execution time in seconds.

Output parameters:

- `result`

### `r2_analyze_function` (~96 tokens)

Return full metadata for a binary function via radare2.

Retrieves name, size, cyclomatic complexity, arguments, local variables,
call targets, and cross-references using radare2's JSON APIs.

Input parameters:

- `file_path` (string, required): Path to the binary (must be inside the workspace).
- `function_address` (string, required): Function name or hex address.
- `timeout` (integer): Maximum execution time in seconds.

Output parameters:

- `result`

### `r2_get_call_graph` (~115 tokens)

Generate a caller/callee call graph for a function.

Uses radare2's ``agCd`` (call-graph dot) and ``axtj`` (cross-reference JSON)
commands to build a structured graph.

Input parameters:

- `depth` (integer): Maximum call depth to traverse (default 2).
- `file_path` (string, required): Path to the binary (must be inside the workspace).
- `function_address` (string, required): Root function name or hex address.
- `timeout` (integer): Maximum execution time in seconds.

Output parameters:

- `result`

### `r2_simulate_patch` (~171 tokens)

Simulate a byte-level patch at an address and re-decompile.

Opens the binary in write mode, applies ``patch_bytes`` (hex string) at
\``address``, then runs r2ghidra's ``pdg`` to show the patched pseudo-C.
\**The original file is not modified** — radare2's ``-w`` flag patches
a memory copy only.

Input parameters:

- `address` (string, required): Target address (e.g. ``0x401020``).
- `file_path` (string, required): Path to the binary (must be inside the workspace).
- `patch_bytes` (string, required): Hex string of bytes to write (e.g. ``"9090"`` for 2 NOPs).
- `timeout` (integer): Maximum execution time in seconds.

Output parameters:

- `result`

### `r2_list_structures` (~43 tokens)

List all saved C struct definitions for a binary.

Input parameters:

- `file_path` (string, required)
- `limit` (integer)
- `offset` (integer)

Output parameters:

- `result`

### `r2_get_structure` (~34 tokens)

Retrieve a single saved struct definition by name.

Input parameters:

- `file_path` (string, required)
- `name` (string, required)

Output parameters:

- `result`

### `r2_create_structure` (~46 tokens)

Save (or replace) a C struct definition in the annotation DB.

Input parameters:

- `fields` (array, required)
- `file_path` (string, required)
- `name` (string, required)

Output parameters:

- `result`

### `r2_list_types` (~42 tokens)

List all custom type definitions saved for a binary.

Input parameters:

- `file_path` (string, required)
- `limit` (integer)
- `offset` (integer)

Output parameters:

- `result`

### `r2_list_bookmarks` (~49 tokens)

List all saved bookmarks / address annotations for a binary.

Input parameters:

- `category`
- `file_path` (string, required)
- `limit` (integer)
- `offset` (integer)

Output parameters:

- `result`

### `r2_add_bookmark` (~53 tokens)

Add (or update) an annotated bookmark at a binary address.

Input parameters:

- `address` (string, required)
- `category` (string)
- `comment` (string, required)
- `file_path` (string, required)

Output parameters:

- `result`

### `r2_read_memory` (~44 tokens)

Read raw bytes from a binary at a given virtual address.

Input parameters:

- `address` (string, required)
- `file_path` (string, required)
- `size` (integer)

Output parameters:

- `result`

### `emulate_machine_code` (~142 tokens)

Emulate machine code execution using radare2 ESIL (Evaluable Strings Intermediate Language).

This tool provides safe, sandboxed emulation of binary code without actual execution.
Perfect for analyzing obfuscated code, understanding register states, and predicting
execution outcomes without security risks.

Input parameters:

- `file_path` (string, required): Path to the binary file (must be in workspace)
- `instructions` (integer): Number of instructions to execute (default 50, max 1000)
- `start_address` (string, required): Address to start emulation (e.g., 'main', '0x401000', 'sym.decrypt')
- `timeout` (integer): Execution timeout in seconds

Output parameters:

- `result`

### `get_job_result` (~39 tokens)

Retrieve the status and result of a background job from the task queue.

Input parameters:

- `job_id` (string, required): The ID of the queued job to check.

Output parameters:

- `result`

## Diagnostics

Captured diagnostic sections: Provenance. The full working is on the page: https://verifymcp.io/servers/sjkim1127-reversecore-mcp/ghcr-io-sjkim1127-reversecore-mcp-3-0-3#diagnostics

## Score history

- 2026-08-22: 45
- 2026-08-21: 41
- 2026-08-20: 41
- 2026-08-19: 41
- 2026-08-18: 41
- 2026-08-17: 41
- 2026-08-16: 41
- 2026-08-15: 41
- 2026-08-14: 41
- 2026-08-13: 41

## Links

- Repository: https://github.com/sjkim1127/Reversecore_MCP
- Changelog RSS feed: https://verifymcp.io/servers/sjkim1127-reversecore-mcp/ghcr-io-sjkim1127-reversecore-mcp-3-0-3.xml
- Changelog JSON feed: https://verifymcp.io/servers/sjkim1127-reversecore-mcp/ghcr-io-sjkim1127-reversecore-mcp-3-0-3.json
- HTML version of this page: https://verifymcp.io/servers/sjkim1127-reversecore-mcp/ghcr-io-sjkim1127-reversecore-mcp-3-0-3