3.5 KiB
Binary Ninja MCP Provider
REA adapts an existing Binary Ninja MCP server into its native analysis tools. Install and configure your selected Binary Ninja engine and upstream MCP server following their instructions. REA does not install, license, activate, or bundle Binary Ninja.
Configure an upstream MCP JSON registration and set REA_BINJA_MCP_CONFIG (or REA_BINARYNINJA_MCP_CONFIG) to that file, then select binaryninja through REA_ANALYSIS_PROVIDER, the CLI's --provider binaryninja, or MCP's open_binary.provider_id.
No provider startup occurs during discovery.
1. Registration Configuration
REA accepts either a standard command/args/env stdio configuration or a local Streamable HTTP URL endpoint (http://127.0.0.1:... or http://localhost:...).
Option A: Direct stdio registration
{
"command": "python",
"args": ["/path/to/binaryninja_mcp/server.py"],
"mode": "attached"
}
Option B: Wrapped in mcpServers
An existing mcpServers object with a binaryninja-mcp (or binja-mcp, binaryninja) entry is also accepted:
{
"mcpServers": {
"binaryninja-mcp": {
"command": "binaryninja-mcp",
"args": []
}
}
}
Option C: Local HTTP endpoint
{
"url": "http://127.0.0.1:9000/mcp",
"mode": "attached",
"headers": {
"Authorization": "Bearer local-token"
}
}
Security Guardrail: Remote HTTP endpoints and URL embedded credentials (
http://user:pass@...) are strictly prohibited and rejected by schema validation. All authorization credentials in headers are redacted from diagnostics and traces.
2. Using Binary Ninja in REA
Set the environment variable pointing to your registration JSON:
export REA_BINJA_MCP_CONFIG=/absolute/path/to/binja-mcp.json
export REA_ANALYSIS_PROVIDER=binaryninja
Then run analysis operations via CLI or MCP:
# Verify registration via doctor
rea doctor --provider binaryninja
# List procedures
rea procedures /path/to/binary --json
# Decompile a procedure (HLIL / pseudo-C)
rea decompile /path/to/binary main --json
# Analyze function dossier
rea function /path/to/binary main --json
3. Supported Operations
The Binary Ninja adapter is read-only and supports:
list_procedures: Enumerates discovered functions and coordinatessearch_procedures: Searches functions by regex or literal name matchinglist_strings: Lists extracted strings across the binarysearch_strings: Searches strings by regex or literal matchingprocedure_address: Resolves procedure entry coordinatesprocedure_pseudo_code: Recovers High-Level IL (HLIL) or decompiled pseudo-Cprocedure_assembly: Retrieves architecture disassembly instructionsprocedure_callers: Inspects incoming direct call relationshipsprocedure_callees: Inspects outgoing call referencesread_function_instructions: Provides bounded raw instruction windowsxrefs: Inspects cross-references to code and data addressesanalyze_function: Aggregates assembly, decompilation, callers, callees, and metadata into a completeFunctionDossier
Mutating operations (such as set_comment, set_address_name, or binary modification) are fail-closed and rejected by the adapter.
4. Diagnostics & Verification
Run rea doctor --provider binaryninja to verify that the registration file is valid without launching the disassembler engine:
rea doctor --provider binaryninja
Expected output confirms the registration is syntactically valid and reports readiness.