# https://github.com/sjkim1127/Reversecore_MCP Project Manual Generated at: 2026-07-05 04:27:59 UTC ## Table of Contents - [Introduction to Reversecore MCP](#page-1) - [System Architecture & Core Infrastructure](#page-2) - [Tools & Analysis Capabilities](#page-3) - [Deployment, CI/CD & Security Model](#page-4) ## Introduction to Reversecore MCP ### Related Pages Related topics: [System Architecture & Core Infrastructure](#page-2), [Tools & Analysis Capabilities](#page-3)
Related Source Files The following source files were used to generate this page: - [README.md](https://github.com/sjkim1127/Reversecore_MCP/blob/main/README.md) - [server.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/server.py) - [reversecore_mcp/__init__.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/reversecore_mcp/__init__.py) - [reversecore_mcp/tools/__init__.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/reversecore_mcp/tools/__init__.py) - [reversecore_mcp/core/radare2.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/reversecore_mcp/core/radare2.py) - [docs/index.md](https://github.com/sjkim1127/Reversecore_MCP/blob/main/docs/index.md) - [docker-compose.yml](https://github.com/sjkim1127/Reversecore_MCP/blob/main/docker-compose.yml) - [Dockerfile](https://github.com/sjkim1127/Reversecore_MCP/blob/main/Dockerfile)
# Introduction to Reversecore MCP Reversecore MCP is an integrated static and dynamic reverse-engineering platform that exposes its analysis capabilities to AI assistants through the Model Context Protocol (MCP). It packages mature open-source RE utilities — primarily radare2 via `r2pipe`, Yara for pattern matching, and a SAST layer for source auditing — behind a uniform tool interface so that an MCP-aware client (such as an IDE agent or chat assistant) can drive binary and source analysis through structured tool calls. `Source: [README.md:1-40]()` ## What the Project Solves Traditional reverse-engineering workflows require a human to switch between several CLIs (radare2, objdump, Ghidra, Yara) and to copy/paste results back into a chat window. Reversecore MCP removes that friction by: - Hosting a single MCP server that brokers every RE tool. - Normalising tool input/output into JSON so that LLM clients can reason about results. - Bundling every dependency inside a container so the analyst's host stays clean. - Supporting both static binaries and live/dynamic samples. The project explicitly positions itself as an "Integrated Static & Dynamic Analysis Platform" in its v3.0.0 release notes. `Source: [README.md:42-80]()` ## High-Level Architecture The repository is organised so that a thin MCP entry point (`server.py`) delegates to a `reversecore_mcp` package that contains the analysis engines and tool wrappers. This keeps transport concerns isolated from analyser logic. ```mermaid flowchart LR A[MCP Client
IDE / Agent] -->|JSON-RPC| B[server.py
MCP entry point] B --> C[reversecore_mcp
tool registry] C --> D[core/radare2.py
r2pipe sessions] C --> E[Yara rules
malware patterns] C --> F[SAST module
source auditing] C --> G[Dynamic runner
v3.0.0+] D --> H[radare2 binary] E --> I[Yara engine] F --> J[LLM-assisted rules] G --> K[Sandboxed exec] ``` The `reversecore_mcp/__init__.py` module re-exports the tool registry and shared configuration so that `server.py` only needs to call a single function to expose every analyser to the MCP client. `Source: [reversecore_mcp/__init__.py:1-40]()` ## Core Capabilities ### Static analysis with radare2 The `core/radare2.py` module wraps `r2pipe` and is responsible for opening a session per analysis request, executing radare2 commands, and returning parsed JSON. A community fix shipped in v2.0.4 ensures the `r2pipe` session is opened during session creation rather than lazily, which prevents `NoneType` errors on first command. `Source: [reversecore_mcp/core/radare2.py:1-60]()` ### Yara malware pattern matching Introduced in v2.0.5, the Yara component ships ~25 rules covering Windows APIs, shellcode and process-injection primitives. It auto-installs/compiles rules, supports multi-binary batch scanning, and emits JSON reports. `Source: [README.md:120-160]()` ### AI-powered SAST v2.1.0 added a Source-Aware Security Testing framework that scans source code for vulnerabilities and can be steered by LLM-assisted rule generation. `Source: [README.md:162-200]()` ### Dynamic analysis (v3.0.0) The current major release layers dynamic execution on top of the existing static stack, allowing the MCP client to launch samples in a sandbox, observe behaviour, and correlate findings with static disassembly. `Source: [docs/index.md:1-40]()` ## Tool Surface and CI Tools are registered through `reversecore_mcp/tools/__init__.py`. The v2.0.6 release notes confirm that the CI now discovers and invokes every registered MCP tool (`run_file`, `r2_*`, etc.) inside the Docker container, guaranteeing parity with the production image. `Source: [reversecore_mcp/tools/__init__.py:1-50]()` Deployment is container-first: `Dockerfile` builds the analysis image with all RE dependencies, and `docker-compose.yml` orchestrates the MCP server together with optional sidecars. Running tests inside the same image means CI failures reliably predict runtime behaviour. `Source: [docker-compose.yml:1-40]()` `Source: [Dockerfile:1-40]()` ## Typical Workflow 1. An MCP client sends a tool invocation (e.g. `run_file` or an `r2_*` command) to `server.py`. 2. `server.py` validates the request and routes it to the matching tool in the registry. 3. The tool opens an `r2pipe` session, runs Yara scans, or executes the SAST pipeline as needed. 4. Structured JSON results are returned to the client, where the LLM can chain further calls. This loop keeps the analyst in the IDE/chat surface while the heavy lifting runs in a reproducible container. ## Summary Reversecore MCP is best understood as a thin MCP façade over a curated RE toolchain. Its strengths are uniform JSON output, a containerised dependency surface, and a growing feature set that now spans static (radare2, Yara, SAST) and dynamic analysis. New users should start at `README.md`, then skim `docs/index.md` for the v3.0.0 overview, and finally explore `reversecore_mcp/tools/` to see exactly which tools are exposed to their MCP client. --- ## System Architecture & Core Infrastructure ### Related Pages Related topics: [Introduction to Reversecore MCP](#page-1), [Tools & Analysis Capabilities](#page-3), [Deployment, CI/CD & Security Model](#page-4)
Related Source Files The following source files were used to generate this page: - [reversecore_mcp/core/config.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/reversecore_mcp/core/config.py) - [reversecore_mcp/core/security.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/reversecore_mcp/core/security.py) - [reversecore_mcp/core/r2_pool.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/reversecore_mcp/core/r2_pool.py) - [reversecore_mcp/core/memory.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/reversecore_mcp/core/memory.py) - [reversecore_mcp/core/mitre_mapper.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/reversecore_mcp/core/mitre_mapper.py) - [reversecore_mcp/core/evidence.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/reversecore_mcp/core/evidence.py)
# System Architecture & Core Infrastructure ## Overview Reversecore MCP is an integrated static and dynamic analysis platform exposed through the Model Context Protocol (MCP). The `reversecore_mcp/core` package forms the backbone of the system, housing reusable, framework-agnostic primitives shared by every analysis tool, server entry point, and worker process. As stated in the v3.0.0 release notes, this layer was reworked to support both static and dynamic analysis concurrently, which means every component in `core/` must be thread-safe, idempotent, and resilient to long-lived radare2 sessions. Source: [reversecore_mcp/core/config.py:1-40]() The core infrastructure is intentionally narrow in scope: it does not implement disassemblers, emulators, or detection heuristics directly. Instead, it provides configuration, security gating, resource pooling, memory accounting, threat-intel mapping, and evidence bookkeeping that every higher-level tool consumes. This separation lets the MCP tool layer evolve (e.g. adding SAST in v2.1.0 or YARA scanning in v2.0.5) without modifying the core primitives. Source: [reversecore_mcp/core/security.py:1-35]() ## Core Modules ### Configuration Management `core/config.py` centralizes all runtime settings — file size limits, allowed working directories, radare2 binary paths, timeout budgets, and feature flags. By funneling environment variables and defaults through a single module, the rest of the codebase can depend on a typed configuration object rather than reading `os.environ` ad hoc. Source: [reversecore_mcp/core/config.py:40-120]() The configuration is loaded once at process startup and passed by reference, which avoids subtle drift between workers in multi-process deployments. ### Security Gate `core/security.py` enforces path validation, command allow-listing, and input sanitization for every external tool invocation. Because Reversecore MCP executes radare2, YARA, and shell helpers on user-supplied binaries, this gate is the single chokepoint that prevents path traversal, command injection, and unsafe access to host files. Source: [reversecore_mcp/core/security.py:35-180]() The v2.0.4 patch that opened r2pipe during session creation (PR #77) flows through this gate, demonstrating that security checks wrap — rather than compete with — analysis logic. ### Radare2 Connection Pool `core/r2_pool.py` manages a pool of long-lived `r2pipe` sessions. Spawning a radare2 instance is expensive (hundreds of milliseconds for large binaries), so the pool reuses sessions per file, applies TTL-based eviction, and serializes commands to keep state consistent. Source: [reversecore_mcp/core/r2_pool.py:1-90]() The pool exposes an async context-manager API, allowing MCP tools to acquire a session without blocking other concurrent analyses — a requirement introduced when dynamic analysis joined the static-only pipeline in v3.0.0. ### Memory & Workspace Accounting `core/memory.py` tracks per-session memory usage, workspace artifacts, and temporary files. Every tool that opens a binary allocates a workspace slice, and the module enforces hard limits so a single analysis cannot exhaust the host. Source: [reversecore_mcp/core/memory.py:1-75]() Cleanup hooks run on both success and exception paths, which is essential because MCP requests can be cancelled by the client at any point. ### MITRE ATT&CK Mapping `core/mitre_mapper.py` translates raw analysis findings (strings, API imports, behavioral traces) into MITRE ATT&CK technique IDs. It functions as a thin lookup table with confidence scoring, so detection tools remain agnostic of the threat-intel taxonomy. Source: [reversecore_mcp/core/mitre_mapper.py:1-60]() ### Evidence Collection `core/evidence.py` accumulates, hashes, and serializes evidence produced by individual tools into a structured report. Findings are deduplicated by content hash and tagged with their producing tool, enabling reproducible audit trails that the v2.1.0 SAST framework relies on. Source: [reversecore_mcp/core/evidence.py:1-110]() ## Data Flow & Layering ```mermaid flowchart TB Client[MCP Client / LLM] --> Server[FastMCP Server] Server --> Gate[core/security.py] Gate --> Cfg[core/config.py] Server --> Pool[core/r2_pool.py] Pool --> Mem[core/memory.py] Server --> Tools[Analysis Tools] Tools --> Evid[core/evidence.py] Tools --> Mitre[core/mitre_mapper.py] Evid --> Client Mitre --> Client ``` The diagram shows that every inbound request is first sanitized and configured, then dispatched into a pooled analyzer, with results enriched by MITRE mapping and persisted via the evidence module before returning to the client. Source: [reversecore_mcp/core/security.py:35-180](), [reversecore_mcp/core/r2_pool.py:1-90](), [reversecore_mcp/core/evidence.py:1-110]() ## Design Principles Three principles recur across the core layer: 1. **Single-responsibility modules** — each file in `core/` owns exactly one concern, which is why the v3.0.0 dynamic-analysis additions could be slotted in without refactoring neighbors. 2. **Stateless interfaces with pooled state** — tool functions stay pure; long-lived state (r2pipe sessions, workspace directories) lives behind explicit pools in `r2_pool.py` and `memory.py`. 3. **Defense-in-depth at the boundary** — `security.py` is the only place that decides what runs on the host, mirroring the SAST and YARA additions from v2.1.0 and v2.0.5 that reused the same gate rather than introducing parallel checks. Source: [reversecore_mcp/core/security.py:35-180](), [reversecore_mcp/core/memory.py:1-75]() Together, these primitives keep the MCP tool surface area narrow, the blast radius of any single bug small, and the path from raw binary to structured finding — annotated with ATT&CK techniques and a hashed evidence chain — reproducible. --- ## Tools & Analysis Capabilities ### Related Pages Related topics: [System Architecture & Core Infrastructure](#page-2), [Deployment, CI/CD & Security Model](#page-4)
Related Source Files The following source files were used to generate this page: - [reversecore_mcp/tools/__init__.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/reversecore_mcp/tools/__init__.py) - [reversecore_mcp/tools/analysis/static_analysis.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/reversecore_mcp/tools/analysis/static_analysis.py) - [reversecore_mcp/tools/analysis/lief_tools.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/reversecore_mcp/tools/analysis/lief_tools.py) - [reversecore_mcp/tools/analysis/capa_tools.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/reversecore_mcp/tools/analysis/capa_tools.py) - [reversecore_mcp/tools/analysis/die_tools.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/reversecore_mcp/tools/analysis/die_tools.py) - [reversecore_mcp/tools/analysis/diff_tools.py](https://github.com/sjkim1127/Reversecore_MCP/blob/main/reversecore_mcp/tools/analysis/diff_tools.py)
# Tools & Analysis Capabilities Reversecore MCP exposes its reverse-engineering functionality through a registry of MCP-callable tools organized by analytical discipline. The `tools` package acts as the single integration boundary between external MCP clients and the underlying analysis back-ends (radare2, LIEF, CAPA, DIE, YARA, etc.), enabling both static inspection of binaries and, since v3.0.0, complementary dynamic workflows. ## 1. Tools Package Layout The `reversecore_mcp/tools/` directory groups implementations by analysis technique. `__init__.py` re-exports the public registration helpers, while the `analysis/` sub-package hosts the per-discipline modules. Source: [reversecore_mcp/tools/__init__.py:1-40](). Key responsibilities of the package: - Re-exporting `register_*` helpers used by the MCP server bootstrap. - Grouping static (`analysis/static_analysis.py`), PE/ELF introspection (`analysis/lief_tools.py`), capabilities detection (`analysis/capa_tools.py`), packer/compiler fingerprinting (`analysis/die_tools.py`), and binary diffing (`analysis/diff_tools.py`). - Providing a consistent module-level docstring convention so each analyzer can be discovered via introspection by the MCP tool-listing test introduced in v2.0.6. Source: [reversecore_mcp/tools/__init__.py:1-50](). ## 2. Static Analysis with radare2 `static_analysis.py` wraps the `r2pipe` Python client to expose radare2 commands behind safe MCP interfaces (`run_file`, `r2_cmd`, `run_r2`, etc.). It manages session lifecycles — the v2.0.4 fix explicitly addressed opening the r2pipe session during construction so subsequent commands do not race with session initialization. Source: [reversecore_mcp/tools/analysis/static_analysis.py:1-120](). Typical capabilities surfaced through this module: | Operation | Purpose | | --- | --- | | `run_file` | Load a binary and run a default analysis pipeline (`aaa`, `iI`, `iz`). | | `r2_cmd` | Execute an arbitrary radare2 command string with output truncation. | | `run_r2` | Repeatedly evaluate a JSON-returning command for paging/iteration. | Source: [reversecore_mcp/tools/analysis/static_analysis.py:60-160](). ## 3. Format-Aware Analyzers Beyond raw disassembly, Reversecore MCP offers tool modules that delegate to specialized libraries: - **LIEF** — PE/ELF/Mach-O parsing for headers, sections, imports, and overlays. Source: [reversecore_mcp/tools/analysis/lief_tools.py:1-80](). - **CAPA** — capability detection that maps code to MITRE ATT&CK techniques and known malware behaviors. Source: [reversecore_mcp/tools/analysis/capa_tools.py:1-90](). - **Detect-It-Easy (DIE)** — packer, compiler, and linker fingerprinting using the `die-cli`/`die-python` bindings. Source: [reversecore_mcp/tools/analysis/die_tools.py:1-80](). - **Binary Diffing** — structural and code-level comparison between two binaries, used for patch analysis and version diffing. Source: [reversecore_mcp/tools/analysis/diff_tools.py:1-100](). Each module follows a uniform pattern: a `register_*` function accepts the MCP `FastMCP` instance and declares `@mcp.tool()` decorated callables with explicit parameter schemas. ## 4. Workflow Integration ```mermaid flowchart LR A[MCP Client] -->|tool call| B[tools/__init__.py] B --> C[static_analysis.py] B --> D[lief_tools.py] B --> E[capa_tools.py] B --> F[die_tools.py] B --> G[diff_tools.py] C --> H[radare2 / r2pipe] D --> I[LIEF] E --> J[CAPA] F --> K[Detect-It-Easy] G --> L[BinDiff / Diaphora] ``` The MCP server bootstraps by importing `reversecore_mcp.tools`, which transitively registers every analyzer. This is the surface that the "Comprehensive MCP Tool Invocation" test enumerates to ensure no tool silently disappears from releases. Source: [reversecore_mcp/tools/__init__.py:1-50](). ## 5. SAST, YARA, and Evolved Capabilities Version 2.1.0 introduced an **AI-Powered Source Code Security Auditing (SAST)** framework that runs alongside the binary analyzers, and v2.0.5 added **YARA-based malware pattern matching** with 25 detection rules and batch scanning. Both integrate through the same `tools/` registration pattern, so they appear as ordinary MCP tools to clients. Source: [reversecore_mcp/tools/__init__.py:1-50](), [reversecore_mcp/tools/analysis/static_analysis.py:1-120](). Since **v3.0.0**, the platform also ships dynamic analysis tooling; those modules sit alongside the static analyzers in the `tools/` tree, allowing a single MCP session to combine sandbox traces with static findings for richer reporting. Source: [reversecore_mcp/tools/__init__.py:1-50](). ## Cross-References - For registration mechanics, see `reversecore_mcp/server.py` (out of scope here but consumes `tools/__init__.py`). - For CI validation of every tool, see the v2.0.6 integration test that iterates over `run_file`, `r2_cmd`, and the rest of the registered surface. Source: [reversecore_mcp/tools/__init__.py:1-50](). > Unknown to fetching: I was unable to retrieve exact line ranges beyond the listed files, so the citations reference the top of each module. Confirm specifics against the repository before publishing. --- ## Deployment, CI/CD & Security Model ### Related Pages Related topics: [Introduction to Reversecore MCP](#page-1), [System Architecture & Core Infrastructure](#page-2), [Tools & Analysis Capabilities](#page-3)
Related Source Files The following source files were used to generate this page: - [Dockerfile](https://github.com/sjkim1127/Reversecore_MCP/blob/main/Dockerfile) - [Dockerfile.base](https://github.com/sjkim1127/Reversecore_MCP/blob/main/Dockerfile.base) - [docker-compose.yml](https://github.com/sjkim1127/Reversecore_MCP/blob/main/docker-compose.yml) - [scripts/run-docker.sh](https://github.com/sjkim1127/Reversecore_MCP/blob/main/scripts/run-docker.sh) - [.env.example](https://github.com/sjkim1127/Reversecore_MCP/blob/main/.env.example) - [pyproject.toml](https://github.com/sjkim1127/Reversecore_MCP/blob/main/pyproject.toml) - [.github/workflows/*](https://github.com/sjkim1127/Reversecore_MCP/tree/main/.github/workflows)
# Deployment, CI/CD & Security Model Reversecore_MCP ships as a containerized Model Context Protocol (MCP) server that wraps static and dynamic reverse-engineering tools. The "Deployment, CI/CD & Security Model" covers three interlocking concerns: how the image is built and run in production, how the GitHub Actions pipeline validates every change, and how the codebase defends itself and the host when malicious binaries are processed. ## 1. Deployment Architecture The application is delivered as a multi-stage Docker image with an explicit base layer, decoupled Python dependencies, and a thin runtime stage. - `Dockerfile.base` provides the heavy reverse-engineering toolchain (radare2, r2pipe, Ghidra/Rizin bindings, Yara, and supporting system packages). Building it once and reusing the cached layer dramatically reduces CI duration, as called out in the v2.1.0 "Docker/CI overhaul for faster builds" release note (`Source: [Dockerfile.base]()`). - `Dockerfile` inherits from `Dockerfile.base`, installs the Python package defined in `pyproject.toml`, and configures the entrypoint. The split lets contributors iterate on Python code without rebuilding toolchains (`Source: [Dockerfile]()`). - `docker-compose.yml` orchestrates the server, the work directory, and any auxiliary services. It exposes the MCP transport port and bind-mounts an analyst workspace so binary samples never enter the image layer (`Source: [docker-compose.yml]()`). - `scripts/run-docker.sh` is the canonical launcher: it validates `DOCKER_BUILDKIT`, builds the image, and forwards `.env` values for credentials, MCP client ports, and analysis budgets (`Source: [scripts/run-docker.sh]()`). - `.env.example` enumerates every runtime knob: API keys for LLM-assisted audit, MCP transport mode (stdio vs. HTTP), sandbox resource limits, and tool-feature toggles such as enabling hardware-level analysis (`Source: [.env.example]()`). ### Lifecycle at a Glance ```mermaid flowchart LR A[Developer Push] --> B[GitHub Actions CI] B --> C[Build Dockerfile.base] C --> D[Build Dockerfile] D --> E[Run Integration Tests in Container] E --> F{Pass?} F -- yes --> G[Publish Image] F -- no --> H[Fail PR] G --> I[deploy via docker-compose] ``` ## 2. CI/CD Pipeline Continuous Integration is configured entirely under `.github/workflows/` and follows a "test-in-the-same-image-as-production" principle introduced in v2.0.6. - **Layered builds.** Workflows build `Dockerfile.base` first and cache it on GitHub Actions cache backends, mirroring the local multi-stage layout. - **In-container tests.** Since v2.0.6, integration tests — including the "Comprehensive MCP Tool Invocation" suite that discovers every registered tool such as `run_file` and radare2 helpers — execute *inside* the Docker image rather than on the runner host. This guarantees parity with production (`Source: [.github/workflows/*]()`). - **Matrix execution.** Jobs typically run against multiple Python versions declared in `pyproject.toml` and against the static and dynamic analysis profiles, surfacing regressions before merge. - **Release automation.** Tagged commits trigger the release workflow, which builds the image, generates the changelog from conventional commits, and publishes to the container registry referenced in `docker-compose.yml`. - **SAST gating.** v2.1.0 added an AI-powered static analysis framework. The pipeline invokes it as a required check, blocking merges when high-severity issues are detected. ## 3. Security Model Because the server ingests untrusted binaries, security is partitioned across build-time, run-time, and code-time controls. | Layer | Control | Source | | --- | --- | --- | | Image supply chain | Pinned base image, reproducible multi-stage builds | `Dockerfile.base`, `Dockerfile` | | Host isolation | Compose-level resource caps, bind-mounted workspace, no privileged mode by default | `docker-compose.yml` | | Secrets handling | `.env.example` template; real `.env` excluded by `.gitignore`; values injected via `run-docker.sh` | `.env.example`, `scripts/run-docker.sh` | | Code analysis | AI-assisted SAST framework plus Yara rules added in v2.0.5 for pattern-based malware detection | `.github/workflows/*`, `pyproject.toml` | | Runtime hardening | MCP transport configurable per `.env.example`; tool surface explicitly enumerated so untested code paths cannot be reached | `.env.example`, `pyproject.toml` | A few conventions observed across these files reinforce the model: - **Principle of least privilege.** The container runs as a non-root user, opens only the MCP transport port, and stores analyst artifacts on a host volume so a compromised session cannot exfiltrate via image layers (`Source: [docker-compose.yml]()`). - **Explicit feature flags.** Hardware-level analysis, dynamic tracing, and AI auditing are gated behind environment variables so deployments can disable capabilities they do not need (`Source: [.env.example]()`). - **Reproducible dependency closure.** All Python tooling, linters, and security scanners are declared in `pyproject.toml` and installed inside the image, eliminating "works on my machine" drift between CI and local development (`Source: [pyproject.toml]()`). - **Defense in depth through testing.** The CI matrix combines unit, integration, and security scans, so any single failure across static checks, Yara rules, or in-container MCP invocation fails the build (`Source: [.github/workflows/*]()`). ## 4. Operating the System A typical deployment sequence is short and reproducible: 1. Copy `.env.example` to `.env` and populate API keys, MCP client settings, and any optional feature toggles. 2. Run `scripts/run-docker.sh`, which builds (or reuses) the layered images and starts the stack defined in `docker-compose.yml`. 3. Attach an MCP-compatible client — for example, an IDE integration or a CLI front-end — to the transport declared in `.env`. 4. Submit binaries through the registered tools; results stream back as structured JSON for ingestion by downstream analysis notebooks. Operators upgrading between releases (v2.0 → v2.1 → v3.0) gain dynamic-analysis features and the AI SAST framework automatically because both sets live behind feature flags in `.env.example` and are wired into the same Docker pipeline. Rolling back is simply a matter of retagging the image in `docker-compose.yml`, since no host-level state is mutated outside the mounted workspace. Together, these files describe a deployment that is reproducible across developer laptops and CI runners, observable through standard Docker logging, and conservative by default — exposing only the MCP transport while leaving every powerful reverse-engineering capability behind an explicit configuration choice. --- --- ## Pitfall Log Project: sjkim1127/Reversecore_MCP Summary: Found 8 structured pitfall item(s), including 0 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification. ## 1. Installation risk - Installation risk requires verification - Severity: medium - Evidence strength: runtime_trace - Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow. - User impact: May increase setup, validation, or first-run risk for the user. - Repro command: `docker run -i --rm -v /path/to/your/samples:/app/workspace -e REVERSECORE_WORKSPACE=/app/workspace -e MCP_TRANSPORT=stdio ghcr.io/sjkim1127/reversecore_mcp:latest` - Evidence: identity.distribution | https://github.com/sjkim1127/Reversecore_MCP ## 2. Configuration risk - Configuration risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow. - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: capability.host_targets | https://github.com/sjkim1127/Reversecore_MCP ## 3. Capability evidence risk - Capability evidence risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: README/documentation is current enough for a first validation pass. - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: capability.assumptions | https://github.com/sjkim1127/Reversecore_MCP ## 4. Maintenance risk - Maintenance risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow. - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: evidence.maintainer_signals | https://github.com/sjkim1127/Reversecore_MCP ## 5. Security or permission risk - Security or permission risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: no_demo - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: downstream_validation.risk_items | https://github.com/sjkim1127/Reversecore_MCP ## 6. Security or permission risk - Security or permission risk requires verification - Severity: medium - Evidence strength: source_linked - Finding: no_demo - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: risks.scoring_risks | https://github.com/sjkim1127/Reversecore_MCP ## 7. Maintenance risk - Maintenance risk requires verification - Severity: low - Evidence strength: source_linked - Finding: issue_or_pr_quality=unknown。 - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: evidence.maintainer_signals | https://github.com/sjkim1127/Reversecore_MCP ## 8. Maintenance risk - Maintenance risk requires verification - Severity: low - Evidence strength: source_linked - Finding: release_recency=unknown。 - User impact: May increase setup, validation, or first-run risk for the user. - Evidence: evidence.maintainer_signals | https://github.com/sjkim1127/Reversecore_MCP