openbin-ai / binny

BINNY 
 An open source agent harness for reverse engineering. Plug in any model, point it at a binary, and it works through the code with real tools and hands you a report to review. 
BINNY is the harness, not the model. It brings the tools (decompiled functions, strings, imports, data, a sealed sandbox, local Ghidra), the playbooks, the triage, investigate, draft loop, the budgets, the checkpoints and the report format. The model is whatever you plug in: Claude, GPT, DeepSeek, Qwen, Kimi, Gemini, Bedrock, or a local model through Ollama or LM Studio. BINNY opens one of your OpenBin or OpenAPK projects, or decompiles a file on your disk, and runs that loop against the decompiled code. Every step is a tool call you can watch: it lists functions, reads decompilations, pulls strings, imports and data, runs scripts in a sealed sandbox, and records findings as it goes. The draft lands on the project report for you to check before anything is published.
It runs on your own model key, or on a local model. Nothing about your sample goes to us unless you put it in a project.
## Install
macOS and Linux:
 [code] 
Windows (PowerShell):
 [code] 
Then:
 [code] 
Prebuilt binaries for every platform are on the releases page. Docker is needed only for `/decompile` (local Ghidra) and the sandbox tools.
## What it does
**Investigate.** `/investigate` starts the full loop. Triage classifies the sample against the STIX 2.1 malware vocabulary, picks the matching playbooks, then investigates function by function until the budget or the evidence runs out, and writes the draft. `/mode malware` and `/mode vuln` switch the lens between a malware analysis report and a vulnerability research report.
**Three ways to run it.** `/autonomy autonomous` runs to a finished draft with no stops. `supervised` pauses at phase boundaries and whenever BINNY is unsure, and asks you. `collaborative` adds a short interview before the write-up: audience, depth, framing.
**Ask.** `/ask` skips the pipeline. Pick up a project at its current state and question it: verify a claim in an existing report, inspect one function, or build a defensive proof of concept such as a config decryptor. An existing report is treated as claims to check, not facts.
**Tools, not vibes.** Read tools work on the project's analysis: metadata, function list, decompiled function, strings, imports, exports, data symbols, raw data reads, and for Android projects file listing and file reads. `/sample ` attaches the raw binary and unlocks extraction. The sandbox `run` tool executes scripts in a Docker container with no network, a read-only root, a read-only sample mount, dropped capabilities and CPU, memory and pid limits. `/work` is a persistent workspace that survives between sessions.
**Local decompile.** `/decompile [processor]` runs Ghidra on your machine and keeps the result on disk. Nothing is uploaded. Raw firmware takes a Ghidra processor ID such as `ARM:LE:32:v7`. Multi-sample projects (dropper plus payloads, fir