Binary Ninja reverse engineering

Use Binary Ninja when the user explicitly selects it, when its ILs materially help data-flow analysis, or when IDA/Ghidra/radare2 results need an independent cross-check.

Start safely

1. Confirm the repository case scope is ready before acting on a target.
2. Check skills/tool-index.md for binaryninja; Binary Ninja is commercial software and must be installed manually with a valid Vector 35 license.
3. Work on a copy when applying patches or saving database changes.
4. Record imports/exports, entry points, architecture, and file hash before promoting findings.

Choose the integration

• GUI or Python API: preferred when Binary Ninja is already open or the user wants direct interactive analysis.
• Community MCP bridge: use only when explicitly requested and after reviewing the third-party plugin boundary. Keep the Binary Ninja HTTP listener on 127.0.0.1:9009; do not enable network exposure by default.
• Fallback: use ghidra-reverse, ida-reverse, or radare2 when Binary Ninja is unavailable or its license/API cannot open the target.

The reviewed community integration is fosdickio/binary_ninja_mcp, GPL-3.0, plugin metadata version 1.1.0, minimum Binary Ninja build 4000. The repository is not an official Vector 35 component. This skill was checked against commit 8c5134ee46e2bf44f9a4d846bd971c3e39b3e306 on 2026-09-03.

Install the Binary Ninja side through its Plugin Manager or from the reviewed source. For the MCP stdio bridge, pin the published bridge version rather than using an unbounded package:

npx -y binary-ninja-mcp@1.0.0 --host 127.0.0.1 --port 9009

Register that command only in the MCP client the user selected. The bridge is not ready until Binary Ninja is running, a binary is open, and the localhost plugin endpoint responds.

Analysis workflow

1. Enumerate open binaries and select the intended view.
2. Capture binary status, entry points, segments, imports, exports, and representative strings.
3. Follow call sites and cross-references before interpreting a function in isolation.
4. Use HLIL for readable logic, MLIL SSA for data flow, and LLIL/disassembly when lifting loses instruction-level behavior.
5. Apply names, comments, and types incrementally; keep the original addresses in evidence.
6. Treat byte patches, prototype changes, and saved-file writes as mutations. Perform them only when requested and preserve the original artifact.
7. Cross-check high-impact conclusions with a second evidence source or another disassembler.

Useful MCP capability families include binary/view selection, list_imports, list_exports, list_strings, decompile_function, get_il, callers/callees, cross-references, types, comments, renames, and byte patching. Discover the live tool list instead of assuming every upstream function is present.

Output

Report concrete addresses, function names, IL level, supporting strings/imports, confidence, and reproduction steps. Keep the Evidence → Finding → Path chain used by the rest of the repository.