Reversecore MCP
OCI · GHCR.IO/SJKIM1127/REVERSECORE_MCP:3.0.3 · 2 COMPONENTS · SCANNED AUG 22
Security-first MCP server for reverse engineering, malware analysis, forensics, and SAST.
Available components
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. How we score →
Supply Chain Security0
- Malware scan not yet available for this package.Unverified
- 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.Unverified
- Install-script risk not yet assessed.Unverified
- 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.Unverified
Provenance & Transparency48
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 8 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability82
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (good).Pass
- 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. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management30
- Stability observed for 9 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage97
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 88% of tool parameters carry a description.Partial
- Structured output schemas are declared (97% of tools); any adoption earns full credit.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
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.
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
oci · ghcr.io/sjkim1127/reversecore_mcp:3.0.3
claude mcp add sjkim1127-reversecore-mcp -- docker run --rm -i ghcr.io/sjkim1127/reversecore_mcp:3.0.3
codex mcp add sjkim1127-reversecore-mcp -- docker run --rm -i ghcr.io/sjkim1127/reversecore_mcp:3.0.3
{
"$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
}
}
} mcp_servers:
sjkim1127-reversecore-mcp:
command: "docker"
args: ["run", "--rm", "-i", "ghcr.io/sjkim1127/reversecore_mcp:3.0.3"] {
"mcpServers": {
"sjkim1127-reversecore-mcp": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"ghcr.io/sjkim1127/reversecore_mcp:3.0.3"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 22 Aug 26 +4
- Stability: unverified → 0.30 ▲ functional
- 13 Aug 26 41
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 22 Aug 2026 · Analysed oci/ghcr.io/sjkim1127/reversecore_mcp:3.0.3
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | oci |
| Reason | No attestation published |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability.
adaptive_vaccine ~184
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
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | Threat information from Ghost Trace or Trinity Defense Format: { "function": "func_name", "address": "0x401000", "instruction": "cmp eax, 0xDEADBEE… |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
analyze_heap_exploit ~491
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.
| Name | Type | Req | Description |
|---|---|---|---|
| crash_file | – | – | Optional path to an AFL++ crash input file. If provided, ``triage_crash`` is run to extract crash context automatically. |
| file_path | string | yes | 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``. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
analyze_patch_diff_auto ~326
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | Path to the **post-patch** binary. |
| file_path_old | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
analyze_variant_changes ~181
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?"
| Name | Type | Req | Description |
|---|---|---|---|
| file_path_a | string | yes | Path to the original binary |
| file_path_b | string | yes | 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) |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
analyze_xrefs ~235
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)
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | yes | Function or address to analyze (e.g., 'main', '0x401000', 'sym.decrypt') |
| file_path | string | yes | 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') |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
artifact_collect ~146
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``.
| Name | Type | Req | Description |
|---|---|---|---|
| artifact_type | string | – | Type of artifact (see ARTIFACT_TYPES for valid values). |
| artifacts | array | yes | 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'). |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
artifact_correlate_ioc ~136
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.
| Name | Type | Req | Description |
|---|---|---|---|
| artifacts | array | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
artifact_generate_yara ~125
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.
| Name | Type | Req | Description |
|---|---|---|---|
| artifacts | array | yes | 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'). |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
artifact_report ~127
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.
| Name | Type | Req | Description |
|---|---|---|---|
| analyst | string | – | Analyst name to include in the report header. |
| artifacts | array | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
artifact_timeline ~112
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.
| Name | Type | Req | Description |
|---|---|---|---|
| artifacts | array | yes | 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). |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
assemble_instructions ~144
Assemble assembly instruction strings into raw machine byte values using Keystone.
| Name | Type | Req | Description |
|---|---|---|---|
| arch | string | – | Target architecture (e.g., 'x86', 'arm', 'arm64', 'mips', 'sparc', 'ppc', 'systemz'). |
| assembly_code | string | yes | 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). |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
audit_source_code ~144
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.
| Name | Type | Req | Description |
|---|---|---|---|
| file_path | string | yes | Path to the source code file. |
| language | – | – | Optional language hint (e.g., 'c', 'python'). If None, inferred from extension. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
autonomous_vuln_hunt ~708
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
build_rop_chain ~288
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.
| Name | Type | Req | Description |
|---|---|---|---|
| file_path | string | yes | 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:… |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
complete_memory_session ~60
Mark an analysis session as completed with a summary. Use this when finishing an analysis to save a summary for future reference.
| Name | Type | Req | Description |
|---|---|---|---|
| session_id | string | yes | Session ID to complete |
| summary | string | yes | AI-generated summary of the analysis findings |
Structured output declared, but exposes no named fields.
No examples provided.
copy_to_workspace ~111
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
| Name | Type | Req | Description |
|---|---|---|---|
| destination_name | – | – | Optional custom filename in workspace (defaults to original name) |
| source_path | string | yes | Absolute or relative path to the source file |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
create_directory ~61
Create a new sub-directory within the workspace. This tool allows AI agents to dynamically create isolated sub-workspaces for different tasks or sessions.
| Name | Type | Req | Description |
|---|---|---|---|
| directory_path | string | yes | Relative or absolute path of the directory to create. Must be within the workspace boundary. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
create_memory_session ~109
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'.
| Name | Type | Req | Description |
|---|---|---|---|
| binary_name | – | – | Name of the binary being analyzed (optional) |
| binary_path | – | – | Path to binary for automatic hash calculation (optional) |
| name | string | yes | Template name for the session (e.g., 'malware_sample_001') |
Structured output declared, but exposes no named fields.
No examples provided.
detect_packer ~48
Detect packer, compiler, and protector using LIEF and Strings heuristics. (Replaces legacy Detect It Easy tool)
| Name | Type | Req | Description |
|---|---|---|---|
| file_path | string | yes | Path to the binary file to analyze |
No output schema declared.
No examples provided.
detect_packer_deep ~50
Deep scan for packer/compiler/protector detection. Combines LIEF section entropy analysis with full strings heuristic scanning.
| Name | Type | Req | Description |
|---|---|---|---|
| file_path | string | yes | Path to the binary file to analyze |
No output schema declared.
No examples provided.
diff_binaries ~273
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
| Name | Type | Req | Description |
|---|---|---|---|
| file_path_a | string | yes | Path to the first binary file (e.g., pre-patch version) |
| file_path_b | string | yes | 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) |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
disk_analyze_mft ~100
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.
| Name | Type | Req | Description |
|---|---|---|---|
| image_path | string | yes | 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). |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
disk_extract_file ~82
Extract a live (non-deleted) file from a disk image by inode number.
| Name | Type | Req | Description |
|---|---|---|---|
| image_path | string | yes | Path to the disk or filesystem image file. |
| inode | string | yes | Inode number of the file to extract. |
| offset | – | – | Partition start offset in sectors. |
| output_path | string | yes | Destination path to write the extracted file. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
disk_hash_verify ~102
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.
| Name | Type | Req | Description |
|---|---|---|---|
| algorithm | string | – | Hash algorithm to use ('sha256', 'sha1', 'md5'). Default: 'sha256'. |
| expected_hash | – | – | Optional expected hash value to verify against. |
| image_path | string | yes | Path to the disk image or file to hash. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
disk_list_files ~143
List all files and directories in a disk/filesystem image.
| Name | Type | Req | Description |
|---|---|---|---|
| directory | string | – | Directory path within the image to list (default: root '/'). |
| image_path | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
disk_list_partition ~50
List partition layout of a disk image using Sleuth Kit mmls.
| Name | Type | Req | Description |
|---|---|---|---|
| image_path | string | yes | Path to the raw disk image file (.img, .dd, .raw, .iso). |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
disk_recover_deleted ~122
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.
| Name | Type | Req | Description |
|---|---|---|---|
| image_path | string | yes | Path to the disk or filesystem image file. |
| inode | string | yes | 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 | yes | Destination path to write the recovered file. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
dormant_detector ~227
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()?").
| Name | Type | Req | Description |
|---|---|---|---|
| file_path | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
emulate_binary ~189
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.
| Name | Type | Req | Description |
|---|---|---|---|
| end_address | – | – | Hexadecimal or decimal address to stop emulation at (optional). |
| file_path | string | yes | 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). |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
emulate_machine_code ~142
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.
| Name | Type | Req | Description |
|---|---|---|---|
| file_path | string | yes | Path to the binary file (must be in workspace) |
| instructions | integer | – | Number of instructions to execute (default 50, max 1000) |
| start_address | string | yes | Address to start emulation (e.g., 'main', '0x401000', 'sym.decrypt') |
| timeout | integer | – | Execution timeout in seconds |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
explain_patch ~131
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").
| Name | Type | Req | Description |
|---|---|---|---|
| file_path_a | string | yes | Path to the original binary (e.g., vulnerable version). |
| file_path_b | string | yes | Path to the modified binary (e.g., patched version). |
| function_name | – | – | Optional specific function to analyze. If None, analyzes top changes. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
extract_iocs ~240
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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) |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
extract_rtti_info ~75
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.
| Name | Type | Req | Description |
|---|---|---|---|
| file_path | string | yes | Path to the binary file |
| timeout | integer | – | Execution timeout in seconds |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
find_similar_patterns ~83
Find similar patterns from previous analyses. Use this to check if current findings match anything from past analyses. Enables knowledge transfer across projects.
| Name | Type | Req | Description |
|---|---|---|---|
| current_session_id | – | – | Exclude current session from results |
| limit | integer | – | Maximum results |
| pattern_signature | string | yes | Pattern to search for |
| pattern_type | – | – | Limit to specific type (optional) |
Structured output declared, but exposes no named fields.
No examples provided.
generate_advanced_yara_rule ~116
Generate an advanced YARA rule based on radare2 disassembly opcodes. This masks offsets in CALL/JMP instructions to reduce false positives.
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | yes | Start address |
| file_path | string | yes | 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 |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
generate_function_graph ~148
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.
| Name | Type | Req | Description |
|---|---|---|---|
| file_path | string | yes | Path to the binary file (must be in workspace) |
| format | string | – | Output format ('mermaid', 'json', 'dot', or 'png'). Default is 'mermaid'. |
| function_address | string | yes | Function address (e.g., 'main', '0x140001000', 'sym.foo') |
| timeout | integer | – | Execution timeout in seconds |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
generate_fuzzing_harness ~147
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.
| Name | Type | Req | Description |
|---|---|---|---|
| file_path | string | yes | 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 | yes | The function name or hex address to fuzz (e.g. 0x401234). |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
generate_poc_exploit ~238
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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"``. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
generate_signature ~227
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
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | yes | Start address for signature extraction (e.g., 'main', '0x401000') |
| file_path | string | yes | 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) |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
generate_yara_rule ~144
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.
| Name | Type | Req | Description |
|---|---|---|---|
| byte_length | integer | – | Number of bytes to extract (default 64, max 1024) |
| file_path | string | yes | Path to the binary file (must be in workspace) |
| function_address | string | yes | 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) |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
get_job_result ~39
Retrieve the status and result of a background job from the task queue.
| Name | Type | Req | Description |
|---|---|---|---|
| job_id | string | yes | The ID of the queued job to check. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
get_memory_session_detail ~54
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.
| Name | Type | Req | Description |
|---|---|---|---|
| session_id | string | yes | Session ID to retrieve |
Structured output declared, but exposes no named fields.
No examples provided.
get_relevant_context ~72
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.
| Name | Type | Req | Description |
|---|---|---|---|
| current_session_id | – | – | Current session to exclude |
| description | string | yes | Description of what you're currently analyzing |
| limit | integer | – | Maximum relevant items |
Structured output declared, but exposes no named fields.
No examples provided.
get_server_health ~91
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
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
get_tool_metrics ~31
Get detailed execution metrics for specific or all tools.
| Name | Type | Req | Description |
|---|---|---|---|
| tool_name | – | – | Optional tool name to filter results |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
list_memory_sessions ~67
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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | Maximum number of sessions to return |
| status | – | – | Filter by status ('in_progress', 'completed', 'paused') |
Structured output declared, but exposes no named fields.
No examples provided.
list_workspace ~28
List all files in the workspace directory. Returns: ToolResult with list of files in workspace
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
match_libraries ~279
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.
| Name | Type | Req | Description |
|---|---|---|---|
| file_path | string | yes | 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) |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
memory_analyze ~182
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.
| Name | Type | Req | Description |
|---|---|---|---|
| _bypass_queue | boolean | – | Internal — set True to skip ARQ queueing. |
| dump_path | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
memory_detect_injections ~86
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).
| Name | Type | Req | Description |
|---|---|---|---|
| _bypass_queue | boolean | – | Internal — set True to skip ARQ queueing. |
| dump_path | string | yes | Path to the memory dump file. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.