Qu1cksc0pe: Static Analysis for a Dozen File Types Behind One Python CLI

The gap Qu1cksc0pe fills: one triage entry point instead of six tools

A suspicious file arrives. Before anyone decides whether it deserves a sandbox, someone has to answer basic questions: what is this, what does it import, what strings and URLs does it carry, is it packed, what language was it written in. On a normal workstation that means a chain of small utilities, one per format, each with its own output shape. Qu1cksc0pe compresses that chain into a single Python CLI and a single report format. The README lists what a user gets: DLL files used, functions and APIs, sections and segments, URLs, IP addresses and emails, Android permissions classified as Dangerous, Special or Info, MITRE ATT&CK mappings for Windows and Linux static analysis, file extensions and names, and embedded executables or exploits. The stated audience is anyone who needs to know what a suspicious file is capable of, which in practice means incident responders, malware analysts doing first-pass triage, and CTF or lab work where standing up a full analysis environment is overkill. The supported formats span Windows executables (.exe, .dll, .msi, .bin), Linux executables (.elf, .bin), macOS Mach-O, Android (.apk, .jar, .dex), Golang binaries on Linux, Office-style documents, VBScript and VBA family files, AppleScript source, HTML, JavaScript, HTA, Windows batch, .lnk shortcuts, archives (.zip, .rar, .ace), PCAP, PowerShell scripts and .eml email files. That list is the product. If your work stays inside one format, a dedicated tool will usually go deeper; the value here is not having to remember which tool covers which extension at 2 a.m.

Static first, emulation second: how the analyzers are layered

The core of the tool is static. It parses a file, extracts structural facts and indicators, and writes them into a report. Around that core the README describes a second layer: sandboxed behavior emulation for document files when macros are present, for VBScript and VBA family files under --docs, and isolated emulation for inline JavaScript in HTML, for .js files and for JScript in .hta files under --analyze. The word isolated matters. This is not a virtual machine with a network stack; it is emulation of script behavior inside the tool, which is why the same flag family also covers purely static formats like AppleScript, Windows batch and .lnk. The MCP server sits on top of all of it. Modules/mcp_server.py shells out to qu1cksc0pe.py the same way the Web UI does, so the tool surface stays in sync with the CLI without a second code path. At startup it imports only the mcp package; the individual analyzers' own dependencies are needed only when a tool actually runs. That design decision has a practical consequence: a client can connect and list tools even on a machine where half the optional dependencies are missing, and failures surface at call time rather than at launch.

Running it: the CLI flags, the MCP transport and the config files that matter

Everything goes through one entry point, qu1cksc0pe.py. The MCP server is launched with python3 qu1cksc0pe.py --mcp, and the extra dependency is installed with pip install "mcp>=2.0.0", which the README notes is already in requirements.txt. Transport defaults to streamable-http, binding 127.0.0.1:8765/mcp, so you run the server once in its own terminal and point clients at http://127.0.0.1:8765/mcp. To switch to the traditional one-client-per-process model, set SC0PE_MCP_TRANSPORT=stdio. Four environment variables control the server: SC0PE_MCP_TRANSPORT (streamable-http, stdio or sse), SC0PE_MCP_HOST (default 127.0.0.1), SC0PE_MCP_PORT (default 8765) and SC0PE_MCP_HTTP_PATH (default /mcp). A project-level .mcp.json ships with the repo so Claude Code discovers the server automatically; it pins stdio explicitly through env, because Claude Code spawns and owns a fresh process per session instead of attaching to one you started. The README warns that if python3 on your PATH is not the interpreter holding Qu1cksc0pe's dependencies, which it calls common on Windows or with multiple Python installs, you should change command to the full path of the right interpreter. Logging goes to stderr and to sc0pe_reports/mcp/mcp_server.log, with SC0PE_MCP_LOG_LEVEL=DEBUG for full stderr output and SC0PE_MCP_LOG_FILE=0 to disable the file sink. AI summaries run through --ai, and keys are stored via python qu1cksc0pe.py --key_init, an interactive menu covering VirusTotal, Claude, OpenAI, DeepSeek, Kimi and GLM, or non-interactively with --key_init --key_provider <name>. Ollama is the default provider and needs no key; its model is selected through the [Ollama] model key in Systems/Multiple/multiple.conf.

The MCP tool list and the 50MB ceiling baked into it

The MCP surface is fourteen tools: analyze_file, analyze_document, analyze_archive, detect_packer, detect_language, extract_iocs, check_resources, check_signatures, scan_hash, scan_virustotal, configure_virustotal_api_key, configure_ai_api_key, update_hash_database and list_supported_file_types. Two details in the README are more revealing than the list itself. First, each tool validates its input file or folder locally and rejects files of 50MB or larger, because the CLI would otherwise prompt interactively. That is a real ceiling: a large installer or a fat archive will not go through the MCP path at all, and the rejection happens before any analysis, not as a warning. Second, interactive-only features are deliberately excluded: --watch dynamic analysis, --ui and --install are not exposed as tools. The five analysis tools that accept ai=True also take an ai_provider argument with values auto, ollama (the default, local), claude, openai, deepseek, kimi or glm, and a cloud key must be configured first with configure_ai_api_key(provider="claude", api_key="...") or the equivalent. The reasoning behind the exclusion list is sound: an agent should not be able to trigger an install or attach a watcher. The consequence is that an MCP client sees a strictly read-and-report subset of the tool, and dynamic Windows or Linux analysis remains a human-driven terminal activity.

Where Qu1cksc0pe stops: dynamic coverage, size limits and verdict quality

The support matrix is more uneven than the headline suggests. Windows executables get static and dynamic analysis, Linux executables get both, but macOS Mach-O is static only, Golang binaries on Linux are static only, and Android dynamic analysis is limited to .apk for now, in the README's own words. So the dynamic column exists for two platforms and a single Android container format. Anything else is a static report. The 50MB rejection on the MCP side is a second boundary, and it applies to folders as well as files. A third limitation is conceptual rather than technical: the output is indicators and structure, not a verdict. MITRE ATT&CK mappings and permission classifications tell you what a sample could do, and the README's own framing is that the tool helps the user realize what a file is capable of. If you need a definitive malicious or benign call, you are still the one making it, and scan_virustotal or scan_hash are lookups rather than adjudication. The AI summarization layer inherits the same property: it summarizes a report the tool already produced, so a thin report yields a thin summary. None of this is a defect for triage work, but it disqualifies the tool as an automated gate in a pipeline that expects a clean signal.

Against a dedicated sandbox: different inputs, different outputs

The obvious alternative for anyone reaching for a dynamic-capable analyzer is a full sandbox such as Cuckoo-derived systems or a commercial detonation service. The difference is in what each one consumes. A sandbox runs the sample and records what it does: process trees, file writes, registry changes, network callbacks. Qu1cksc0pe mostly reads the sample and reports what is inside it, with emulation reserved for macro-bearing documents and script families. That means Qu1cksc0pe works on a sample that will not execute on your platform, will not run at all because it is a .lnk or an .eml, or would be dangerous to detonate. It also means it cannot tell you that a binary phoned home to a specific host during execution; it can only tell you that a URL string is present in the file. The two approaches answer different questions and the README does not present them as substitutes. If your workflow already has detonation capacity, Qu1cksc0pe slots in before it as a cheap pre-filter. If you have no detonation capacity and no intention of building one, it is one of the few tools that will still produce structured output for a Mach-O binary, a PCAP, a PowerShell script and an .eml file through the same interface.

Licence and maintenance: GPL-3.0, no tagged releases, and what that costs you

Qu1cksc0pe is GPL-3.0. That matters if you plan to embed it in a product or ship a modified copy, because the licence carries copyleft obligations; this is a description of the licence identifier, not legal advice, and anyone integrating it commercially should read the full text. The repository is not archived and the last push recorded is 2026-09-01, but no releases were retrieved, so there is no tagged version to pin against. In practice that means upgrades are a git pull against master, and the MCP server's own design softens the cost of that: because it shells out to qu1cksc0pe.py rather than reimplementing analyzers, CLI changes propagate to MCP clients without a separate integration step. The same cannot be said for the tool list, which is hand-written, so a new analyzer added to the CLI will not appear as an MCP tool until the server is updated. Dependency cost is variable by design: the mcp package is imported at startup, but each analyzer's dependencies load only when its tool runs, so a partial install degrades specific tools rather than the whole server. The AI layer adds an ongoing cost only if you choose a cloud provider; Ollama keeps it local. There is no migration guide and no release notes to consult, which is the real maintenance tax here.

Editorial conclusion

Adopt Qu1cksc0pe if you are a responder, CTF player or analyst who needs one command to pull strings, imports, sections, URLs, Android permissions and MITRE ATT&CK mappings out of an unknown sample, and you accept Python, GPL-3.0 and a report you still have to read. Do not adopt it as a sandbox replacement or as an automated verdict engine; the README itself limits dynamic Android analysis to .apk and dynamic Windows/Linux analysis is interactive-only. Before relying on it, verify that python3 on your PATH is the interpreter holding the dependencies (python3 -c "import mcp" is the check the README suggests), run --key_init to confirm which providers you actually have keys for, and read Systems/Multiple/multiple.conf to see which Ollama model is selected by default.

Official sources

1. CYB3RMX/Qu1cksc0pe on GitHub
2. Issues
3. License: GPL-3.0
4. README