x64dbg MCP Server
The x64dbg MCP Server exposes x64dbg reverse-engineering and debugging capabilities to AI assistants, enabling automated binary analysis, debugging, and security triage of Windows PE executables.
Debugging Session Management
Load PE executables (auto-detecting 32/64-bit), attach to running processes, terminate sessions, query debugger status, list active sessions, and close the debugger process.
Execution Control
Resume execution, step into/over/out of functions, run to a specific address, and execute raw x64dbg command strings.
Breakpoints
Set software, hardware, or memory breakpoints with optional conditions and log text; remove or list breakpoints; collect values at breakpoint hits in a loop (
collect_bp_args).
Memory & Registers
Read/write debuggee memory, search for byte patterns or strings, get the full virtual memory map, read/set CPU registers, get the call stack, list/switch threads.
Code & Binary Analysis
Disassemble instructions, analyze function boundaries and call graphs, find cross-references, list recognized functions, get loaded modules, inspect imports/exports, find strings in memory, parse PE headers, and record execution traces.
Security Triage
Detect packing/obfuscation (entropy, EP location, packer signatures), cross-reference imports against a malware API database (injection, network, crypto, anti-debug, etc.), scan for anti-debugging techniques, check PE sections for anomalies (W+X, high entropy, etc.), and generate a consolidated security triage report.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@x64dbg MCP Server load executable sample.exe and set breakpoint at main"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
x64dbg MCP Server
A production-level Model Context Protocol server that exposes x64dbg reverse-engineering and debugging capabilities to AI assistants over STDIO or Streamable HTTP.
It is designed for practical debugger automation, not just toy examples:
Auto-detects PE architecture and launches
x32dbgorx64dbgas neededSupports both
load_executableandattach_to_processExposes debugging, memory, analysis, and security triage tools through MCP
Uses a lightweight bridge plugin and talks to
x64bridge.dlldirectly viactypesDoes not depend on
x64dbgpy
Quick Start
Recommended path
npm install -g x64dbg-mcp
x64dbg-mcp setup
x64dbg-mcp doctorAfter that, choose one transport:
STDIO: let your MCP host launch
x64dbg-mcpdirectlyStreamable HTTP: start a long-running server with:
x64dbg-mcp --transport streamable-http --host localhost --port 3000The HTTP endpoint is fixed at http://localhost:3000/mcp.
stdio and streamable-http are the supported startup transports. The SDK still ships a standalone SSE server transport, but it is deprecated and this project does not expose it as a separate mode.
Related MCP server: Binary MCP Server
Requirements
Windows only, because x64dbg is Windows-only
Node.js 20+
Python 3.10+
CMake 3.15+ plus MSVC or MinGW only if you need to build the C loader from source
npm install downloads x64dbg automatically if it is not already available. The iced_x86 Python package is also installed automatically into detected Python environments; if that installation fails, the bridge falls back to x64dbg's own disassembly APIs.
Installation
Global npm install
npm install -g x64dbg-mcpThe global install path is the simplest one. Its postinstall step handles the usual setup work:
Step | What happens |
x64dbg | Downloads the latest snapshot if not found locally |
Plugin files | Deploys the loader and Python bridge files into the x64dbg plugins directories |
Bridge auth | Generates |
Python | Detects Python install paths and records |
| Installs it into detected Python environments if needed |
| Creates a config file with detected values and defaults |
Before continuing, review the configuration values in the next section if your x64dbg install path, Python install path, or HTTP port should differ from the detected defaults.
Then run:
x64dbg-mcp setup
x64dbg-mcp doctor
x64dbg-mcpIf you need to rebuild and redeploy the loader manually, use:
x64dbg-mcp install-pluginSource checkout
Use this path if you are developing on the project itself:
git clone https://github.com/ouonet/x64dbg-mcp.git
cd x64dbg-mcp
npm install
npm run buildThen review the configuration section below, especially if X64DBG_PATH, Python paths, or the default HTTP port need to change.
npm run setup
npm run install-plugin
npm run doctor
npm startTo run HTTP mode from a source checkout:
node .\dist\server.js --transport streamable-http --host localhost --port 3000If you want the x64dbg-mcp command in a source checkout too, run npm link after npm run build.
If x64dbg already exists in a non-default location, set X64DBG_PATH in .env before npm run install-plugin.
Manual plugin installation
Most users should not need this. Use it only if you want to build and copy the loader manually instead of running install-plugin.
cd plugin\loader
# 64-bit
cmake -B build64 -A x64
cmake --build build64 --config Release
$p64 = "C:\x64dbg\release\x64\plugins"
Copy-Item build64\Release\x64dbg_mcp_loader.dp64 $p64
Copy-Item ..\x64dbg_mcp_bridge.py $p64
Copy-Item ..\x64dbg_bridge_sdk.py $p64
# 32-bit
cmake -B build32 -A Win32 -DBUILD_32BIT=ON
cmake --build build32 --config Release
$p32 = "C:\x64dbg\release\x32\plugins"
Copy-Item build32\Release\x64dbg_mcp_loader.dp32 $p32
Copy-Item ..\x64dbg_mcp_bridge.py $p32
Copy-Item ..\x64dbg_bridge_sdk.py $p32npm run install-plugin performs the same work for both architectures by default. Pass -No32 if you want to skip the 32-bit build.
Configuration
npm install creates .env automatically. Edit that file directly, or run setup again if you want the interactive flow.
# x64dbg path (auto-detected)
X64DBG_PATH=C:\x64dbg
# Python install directories used by the C loader
PYTHON_HOME_X64=C:\Python314
PYTHON_HOME_X86=C:\Python312-32
# Bridge
BRIDGE_HOST=127.0.0.1
BRIDGE_PORT=27042
BRIDGE_AUTH_TOKEN=<auto-generated>
# MCP transport defaults
MCP_TRANSPORT=stdio
MCP_HTTP_HOST=127.0.0.1
MCP_HTTP_PORT=3000
# Logging / limits
LOG_LEVEL=info
MAX_SESSIONS=1
SESSION_TIMEOUT_MS=3600000Variable | Default | Description |
| auto-detected | x64dbg installation directory |
| auto-detected | Preferred Python 64-bit install directory |
| auto-detected | Preferred Python 32-bit install directory |
|
| TCP host for the local bridge |
|
| TCP port for the local bridge |
| auto-generated | Shared secret for MCP to bridge requests |
|
| Default startup transport: |
|
| Default HTTP bind host |
|
| Default HTTP listen port |
|
|
|
|
| Active session limit for the current bridge architecture |
|
| Idle session timeout in milliseconds |
If you manually start x64dbg outside the MCP flow, keep the deployed x64dbg_mcp_bridge.token file in the plugins directory so the bridge enforces the same token as the MCP server.
Use With Your MCP Host
Note: You do not need to pre-launch x64dbg manually. The MCP server auto-launches the correct debugger when you call
load_executableorattach_to_process.
STDIO host configuration
Use STDIO when your MCP host can spawn a local process.
Claude Desktop
If you installed the package globally:
{
"mcpServers": {
"x64dbg-mcp": {
"command": "x64dbg-mcp"
}
}
}If you are using a source checkout instead:
{
"mcpServers": {
"x64dbg-mcp": {
"command": "node",
"args": ["C:\\path\\to\\x64dbg-mcp\\dist\\server.js"]
}
}
}Windsurf / Cascade
{
"mcpServers": {
"x64dbg-mcp": {
"command": "node",
"args": ["C:\\path\\to\\x64dbg-mcp\\dist\\server.js"],
"env": { "BRIDGE_PORT": "27042" }
}
}
}Streamable HTTP
Use Streamable HTTP when you want to start x64dbg-mcp once and let an AI tool connect to it through a fixed local URL.
Start the server first.
If you installed the package globally:
x64dbg-mcp --transport streamable-http --host localhost --port 3000If you are running from a source checkout:
node .\dist\server.js --transport streamable-http --host localhost --port 3000Then connect your AI tool to this MCP endpoint:
http://localhost:3000/mcpBelow are direct configuration examples for common AI tools.
Claude Code
Create a .mcp.json file in the project root:
{
"mcpServers": {
"x64dbg-mcp": {
"type": "http",
"url": "http://localhost:3000/mcp"
}
}
}Or add the same server to Claude Code with its CLI:
claude mcp add --transport http x64dbg-mcp http://localhost:3000/mcpWindsurf / Cascade
Edit ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"x64dbg-mcp": {
"serverUrl": "http://localhost:3000/mcp"
}
}
}If you already have other MCP servers configured in that file, just add the x64dbg-mcp entry under mcpServers.
If your AI tool does not support remote HTTP MCP servers and only knows how to launch a local command, use the STDIO setup above instead.
CLI flags override MCP_TRANSPORT, MCP_HTTP_HOST, and MCP_HTTP_PORT from the environment. The legacy MCP_TRANSPORT=http alias is still accepted for compatibility.
Typical Prompts
These are good examples of the kinds of requests the MCP server is built to support:
"Load
C:\samples\target.exeand analyze it for suspicious behavior""Attach to PID 1234 and inspect the current thread"
"Find the license check function"
"Generate a first-pass malware triage report"
Typical tool flows behind those prompts look like this:
Goal | Typical tools |
Load and debug a binary |
|
Attach to a live process |
|
Malware triage |
|
Reverse engineering |
|
Capabilities
The server exposes 38 tools across four practical groups.
Group | Scope |
Core debugging | load or attach, control execution, manage breakpoints, inspect session state |
Memory and registers | read and write memory, inspect registers, switch threads, walk call stacks |
Analysis | disassembly, function analysis, cross references, modules, imports, exports, strings, traces |
Security triage | packing checks, suspicious APIs, anti-debug detection, section anomalies, consolidated reports |
Representative tools include load_executable, attach_to_process, get_status, read_memory, disassemble, analyze_function, and generate_security_report.
Architecture
┌─────────────────┐ STDIO / HTTP ┌──────────────────┐ TCP (JSON) ┌──────────────┐
│ AI Assistant │ ◄───────────────► │ MCP Server │ ◄──────────► │ x64dbg │
│ (Claude, etc.) │ │ (Node.js / TS) │ port 27042 │ + Bridge │
└─────────────────┘ └──────────────────┘ │ Plugin │
└──────────────┘At a high level, the MCP server in src/ speaks STDIO or Streamable HTTP to an AI client, then forwards requests over a local TCP bridge to the plugin running inside x64dbg. The plugin side is a lightweight C loader plus Python bridge that translates those requests into x64dbg Bridge SDK calls.
Development And Testing
Development commands:
npm run ci
npm run ci -- --no-loader
npm run dev
npm run sync-plugin
npm run setup-x64dbg
npm run setup-x64dbg -- --force
npm run build
npm run lint
npm run cleanTesting commands:
npm test
python plugin/tests/test_bridge.py
npm run test:e2e
npm run test:http-smoke
npm run doctornpm run dev automatically syncs Python files into the bundled x64dbg checkout before starting the server.
npm run inspector launches MCP Inspector. On first run it downloads @modelcontextprotocol/inspector via npx, so restricted environments may need HTTP_PROXY / HTTPS_PROXY or a global install.
Reusable verifier scripts live under test/e2e/. They require an explicit target:
TARGET_EXE=C:\path\to\sample.exefor load-based verificationTARGET_PID=1234orTARGET_PROCESS_NAME=notepadfor attach-based verification
Examples:
$env:TARGET_EXE = "C:\Windows\System32\notepad.exe"
node test/e2e/verify_breakpoint_chain.mjs
$env:TARGET_PROCESS_NAME = "notepad"
node test/e2e/verify_attach_chain.mjsCI in .github/workflows/ci.yml runs TypeScript, Python, and loader-build jobs on every push. On tagged releases (v*), it also publishes the npm package with the prebuilt loader binaries included.
Project Structure
x64dbg-mcp/
├── src/
│ ├── server.ts # Entry point and transport bootstrap
│ ├── cli.ts # CLI parsing for transport/host/port
│ ├── httpServer.ts # Streamable HTTP server and MCP session handling
│ ├── mcpServer.ts # Shared MCP server factory and tool registration
│ ├── bridge.ts # TCP client for the x64dbg bridge
│ ├── launcher.ts # PE detection and debugger startup
│ ├── session.ts # Session lifecycle and garbage collection
│ ├── config.ts # Env-backed configuration loading
│ ├── errors.ts # Shared error helpers
│ ├── logger.ts # Winston logger
│ ├── types.ts # Shared TypeScript types
│ └── tools/
│ ├── debug.ts
│ ├── memory.ts
│ ├── analysis.ts
│ ├── security.ts
│ └── index.ts
├── plugin/
│ ├── x64dbg_mcp_bridge.py # Python bridge running inside x64dbg
│ ├── x64dbg_bridge_sdk.py # ctypes wrapper for x64bridge.dll
│ ├── loader/
│ │ ├── x64dbg_mcp_loader.c
│ │ ├── CMakeLists.txt
│ │ └── prebuilt/
│ ├── tests/
│ │ └── test_bridge.py
│ └── README.md
├── scripts/
│ ├── setup.mjs
│ ├── doctor.mjs
│ ├── install-plugin.mjs
│ ├── install-plugin.ps1
│ ├── postinstall.mjs
│ ├── prepack.mjs
│ ├── setup-x64dbg.mjs
│ ├── sync-plugin.mjs
│ ├── ci.mjs
│ └── manual/
├── test/
│ ├── basic.test.ts
│ └── e2e/
├── x64dbg/ # Bundled x64dbg snapshot used in development/tests
├── package.json
├── .env.example
└── README.mdLicense
MIT
Community
Contribution guide: see CONTRIBUTING.md
Security policy: see SECURITY.md
Code of conduct: see CODE_OF_CONDUCT.md
Bug reports and feature requests: use the GitHub templates under
.github/ISSUE_TEMPLATE/
For non-sensitive questions or usage issues, open a GitHub issue. For vulnerabilities, follow the private reporting process in SECURITY.md instead of opening a public issue.
Available Tools
39 toolsanalyze_functionA
Analyse the function that contains the given address. Returns boundaries, size, call graph (callers + callees), and whether the function is a leaf.
Inputs: sessionId (required), address (required).
analyze_suspicious_apisA
Cross-reference the executable's import table against a database of Windows APIs commonly used by malware, grouped by category (process injection, network, crypto, anti-debug, etc.). Returns per-category findings and an overall risk level.
Inputs: sessionId (required), module, includeAll.
check_section_anomaliesA
Check PE sections for anomalies that may indicate packing, code injection, or tampering: writable+executable sections, unusual names, zero raw-size with non-zero virtual-size, high entropy.
Inputs: sessionId (required), module.
close_debuggerA
Kill the x64dbg or x32dbg process. Works even if the bridge is not connected. Use this to cleanly shut down the debugger before deploying updated plugins or when you need to restart the debugger.
Inputs: force.
collect_bp_argsA
Continue execution in a loop, collecting a memory expression at each breakpoint hit. Use this to trace repeated calls (e.g. AddMoudle, GetClassObject). The default expr 'ptr_utf16@[esp+4]' reads a wchar_t* arg from the x86 stack.
Inputs: sessionId (required), expr, maxHits, timeoutSec.
continue_executionA
Resume execution of a paused debuggee. Runs until the next breakpoint, exception, or program exit. REQUIRES: session state must be 'paused' (check with get_status). Returns stopReason ('breakpoint', 'paused', or 'exited') and the address where execution stopped. If stopReason is 'exited', the process has terminated.
Inputs: sessionId (required).
detect_anti_debugB
Scan the loaded executable for common anti-debugging techniques: API checks (IsDebuggerPresent, NtQueryInformationProcess), timing checks, PEB flags, int 2d / int 3, TLS callbacks, etc.
Inputs: sessionId (required), module.
detect_packingA
Analyse the loaded executable for signs of packing or obfuscation. Checks section entropy, section name anomalies, import table size, entry-point location, and known packer signatures. Returns a confidence score and list of indicators.
Inputs: sessionId (required), module.
disassembleA
Disassemble instructions starting at a given address in the loaded module. Returns address, raw bytes, mnemonic, operands, and metadata (is_call, is_jump, reference target) for each instruction. Safe to call while paused. Address may be a hex value ('0x401000') or a symbol name ('main', 'kernel32.CreateFileW'). Tip: after load_executable with breakOnEntry=true, disassemble the entry point returned in the load result to see where execution begins.
Inputs: sessionId (required), address (required), count.
execute_commandA
Execute a raw x64dbg command string. Use this for advanced operations not covered by other tools. Returns the command output.
Inputs: sessionId (required), command (required).
find_stringsB
Search for ASCII and Unicode strings in the debuggee's memory. Optionally filter by content substring or module.
Inputs: sessionId (required), module, filter, minLength, +1 more.
generate_security_reportA
Run all security analysis tools and produce a consolidated report: packing detection, suspicious API analysis, anti-debug detection, and section anomaly checks. Useful as a first-pass triage.
Inputs: sessionId (required), module.
get_call_stackA
Get the call stack (backtrace) of the current thread. Shows return addresses, module names, and function names where available.
Inputs: sessionId (required), maxFrames.
get_cross_referencesA
Find all cross-references (xrefs) to or from the given address. Returns code references (calls/jumps) and data references (reads/writes).
Inputs: sessionId (required), address (required), direction.
get_exportsB
List all exported functions/symbols for a specific module.
Inputs: sessionId (required), module (required), nameFilter.
get_importsB
List all imported functions for a specific module. Shows DLL name, function name, ordinal, and IAT address.
Inputs: sessionId (required), module, dllFilter, functionFilter.
get_memory_mapA
Return the virtual memory map of the debuggee process: all regions with base address, size, protection, type, and associated module.
Inputs: sessionId (required), filterModule, filterProtection.
get_modulesA
List all modules (DLLs and the main EXE) loaded in the debuggee with base address, size, entry point, and file path.
Inputs: sessionId (required).
get_pe_headerA
Parse and return the PE header information for a module: DOS header, NT headers, section table, data directories, timestamp, subsystem, characteristics, etc.
Inputs: sessionId (required), module.
get_registersA
Read the current CPU register values of the active thread. Includes general-purpose registers, instruction pointer (RIP/EIP), flags, and optionally segment and debug registers. REQUIRES: session must be paused (call get_status to check). On x64: returns RAX, RBX, RCX, RDX, RSI, RDI, RSP, RBP, RIP, R8-R15. On x86: returns EAX, EBX, ECX, EDX, ESI, EDI, ESP, EBP, EIP.
Inputs: sessionId (required), includeSegment, includeDebug, includeFpu.
get_statusA
Query the current state of the debugger and active session. Returns bridge connectivity, session state (idle/paused/running/stepping/terminated), current instruction pointer, active thread, and a next-step hint. Call this whenever you are unsure what state the debugger is in before issuing step/continue/breakpoint operations. This is always safe to call — it does not change any debugger state.
Inputs: sessionId.
get_threadsB
List all threads in the debuggee process with their current state.
Inputs: sessionId (required).
list_breakpointsA
List all breakpoints in the session, including hit counts and conditions.
Inputs: sessionId (required).
list_functionsA
List recognised functions in the debuggee. Can filter by module name and/or name substring.
Inputs: sessionId (required), module, nameFilter, offset, +1 more.
list_sessionsA
List all active debugging sessions with their state and metadata.
Inputs: no named parameters.
load_executableA
START HERE — load a PE executable into x64dbg and create a debugging session. Returns a sessionId that ALL other tools require as their first parameter. Auto-detects 32-bit vs 64-bit PE and launches x32dbg or x64dbg accordingly. With breakOnEntry=true (default): execution stops at the entry point and the session state becomes 'paused' — you can immediately call step_into, get_registers, or disassemble. With breakOnEntry=false: the debuggee starts running; use set_breakpoint then continue_execution to pause it later. Only one session can be active at a time. Call terminate_session first if one exists.
Inputs: executablePath (required), commandLineArgs, breakOnEntry, autoAnalyze.
read_memoryA
Read raw bytes from the debuggee's virtual address space. Returns a hex+ASCII dump. Address must be in the debuggee's mapped memory (see get_memory_map for valid ranges). REQUIRES: session must be paused.
Inputs: sessionId (required), address (required), size.
remove_breakpointB
Remove a previously set breakpoint at the given address.
Inputs: sessionId (required), address (required).
run_to_addressA
Set a one-shot breakpoint at the given address and continue execution. Stops when the address is reached or another breakpoint/exception fires first.
Inputs: sessionId (required), address (required).
search_memoryA
Search the debuggee's memory for a byte pattern or string. Supports hex patterns with wildcards (e.g. '4D 5A ?? ??') and text strings.
Inputs: sessionId (required), pattern (required), searchType, startAddress, +2 more.
set_breakpointB
Set a breakpoint. Supports software BPs, hardware BPs (execute/read/write), and memory BPs. Optionally supply a condition expression or log text.
Inputs: sessionId (required), address (required), type, condition, +2 more.
set_registerC
Set the value of a single CPU register.
Inputs: sessionId (required), register (required), value (required).
step_intoA
Execute one or more instructions, stepping INTO function calls. REQUIRES: session state must be 'paused'. Returns the new address, disassembly, module, and key register values after stepping. Use step_over instead if you want to skip over CALL instructions.
Inputs: sessionId (required), count.
step_outA
Run until the current function returns (execute until RET). REQUIRES: session state must be 'paused'. Useful for quickly leaving a called function and returning to the caller without stepping through every instruction.
Inputs: sessionId (required).
step_overA
Execute one or more instructions, stepping OVER function calls. REQUIRES: session state must be 'paused'. If the current instruction is a CALL, the entire called function executes and control returns to the instruction after the CALL. Use step_into if you want to trace inside the called function.
Inputs: sessionId (required), count.
switch_threadA
Switch the active thread. Subsequent register/stack/step operations will apply to this thread.
Inputs: sessionId (required), threadId (required).
terminate_sessionA
Stop the debuggee process and close the debugging session. x64dbg itself stays open and ready for the next load_executable call. Call this before loading a new executable, or when analysis is complete.
Inputs: sessionId (required).
trace_executionB
Record an execution trace from the current position. Steps through instructions and records address + disassembly at each step. Stops after maxInstructions or a breakpoint.
Inputs: sessionId (required), maxInstructions, traceInto, recordRegisters, +1 more.
write_memoryA
Write bytes to the debuggee's virtual memory. Use with caution — writing to wrong addresses can crash the debuggee.
Inputs: sessionId (required), address (required), hexBytes (required).
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 39 tools
Most tools have distinct, well-defined purposes (e.g., step_into vs step_over, disassemble vs read_memory). However, tools like analyze_function and analyze_suspicious_apis could be confused if descriptions are not read carefully, and execute_command overlaps with other tools' capabilities.
All tool names use a consistent verb_noun pattern in snake_case (e.g., analyze_function, load_executable, continue_execution). No mixed conventions or vague verbs.
39 tools is on the higher end but justified by the breadth of debugger functionality. The tool set covers execution control, memory inspection, analysis, and session management without being excessive.
The tool set provides comprehensive coverage for a debugger/analysis server: loading, stepping, breakpoints, memory, registers, modules, security analysis, session management. No obvious gaps for typical reverse engineering tasks.
Maintenance
Related MCP Connectors
Hunt zero-days by talking to binaries. 40+ tools. Hosted, OAuth + SSO, invite: hi@byteray.ai
Evidence-oriented REA + Ghidra static-analysis workflows, read-only PE32 and Delphi VMT tools.
34 security tools for AI agents: phishing links, exposure maps, DNS, SSL, PQC, history, pivots.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceEnables AI-assisted reverse engineering and debugging through x64dbg integration. Provides 40+ tools for breakpoint management, memory operations, register manipulation, code analysis, process control, and advanced debugging features.22-
- AlicenseNot gradedqualityBmaintenanceEnables AI assistants to analyze binaries, debug processes, and inspect kernel state using Ghidra, x64dbg, WinDbg, and ILSpyCmd.12Apache 2.0
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to control the x64dbg debugger through natural language, providing tools for breakpoints, memory, disassembly, tracing, PE dumping, and anti-debug bypass, all locally via stdio.139MIT
- AlicenseNot gradedqualityFmaintenanceEnables AI-driven reverse engineering with x64dbg via 71+ MCP tools for breakpoints, memory, disassembly, tracing, debug control, PE analysis, and anti-anti-debugging, supporting HTTP, SSE, and stdio transports.2MIT