recurse

Agentische Reverse-Engineering-IDE mit einem reinen Rust-Multi-Architektur-Disassembler, nativem Decompiler, Debugger und LLM-Agenten für Binäranalyse und CTF-Arbeit.

recurse-agent ist nur der Agent; die statische Analyse lebt in recurse-static und der Debugger in recurse-debug, sodass der Agent weder Systemcode einbindet, den er nicht verwendet. Kein Crate hängt von Tauri ab, und jedes lässt sich eigenständig bauen/testen; recurse-eval steuert den Agent headless. Alle sind Workspace-Mitglieder, sodass ein Cargo.lock und ein target/ das gesamte Repo abdecken.

Funktionen

• Cursor-artiger Workspace: Funktionsliste, Disassembly/Strings/Imports-Tabs, CFG-Graph, und eine Chat-Agent-Sidebar (umschalten mit dem Chat-Button oder Ctrl+L)
• Recon-Seite: Binärinfo, MD5/SHA1/SHA256/CRC32-Hashes, Entropie, verlinkte Bibliotheken, ein eigenständiger Hardening-Report (RELRO / PIE / NX / Canary / FORTIFY / RPATH — kein externes checksec), und Analyse-Zähler
• Funktionen aus der Liste umbenennen (Doppelklick oder der ✎-Button); Namen bleiben in SQLite erhalten und erscheinen in der Funktionsliste, den Disassembly-Annotationen und für den Agent
• Grounded Agent: jede Adresse ist ein klickbares Objekt (Funktionsliste, Graph-Knoten, Xrefs, Decompiler-Annotationen) — kein eingefügter Text, den das Modell halluzinieren kann
• Live-Analyse-Session auf jeder Binärdatei — auch auf Dateien ohne Erweiterung
• Persistentes Projektgedächtnis in SQLite mit FTS5/BM25-Retrieval — Umbenennungen, Findings und Notizen überleben /clear und erneutes Öffnen und befüllen die nächste Session
• Headless-Kern (recurse-agent) mit Debug-Tracing pro Turn; dieselbe Agent-Schleife läuft in der UI und im Eval-Harness
• LLM-Agent auf Basis eines OpenAI-kompatiblen Endpunkts (standardmäßig OpenRouter) mit Modell-Auswahl; steuert die Session direkt (Disasm, Xrefs, Strings, Imports, Decompile)
• Dark-First-UI gebaut mit Tailwind CSS v4 + shadcn/ui
• lift-Op: hebt eine Funktion in eine VTIL-artige De-Obfuskierungs-IL und führt Propagation/Folding/Dead-Code-Elimination/Branch-Resolution-Pässe über die gesamte Routine aus — nützlich, wenn die Disassembly wie ein VM-Dispatcher oder eine Opaque-Predicate-Kette aussieht (siehe docs/vtil-lift.md)
• Nativer Decompiler: decompile rendert C-ähnlichen Pseudocode (if/while- Strukturierung, vollständige Instruktionsabdeckung) aus derselben recurse-vtil- Pipeline — kein externes Tool, kein r2 erforderlich
• Eigenständiger recurse-mcp-Server: dieselbe Engine über MCP stdio für jeden MCP-fähigen Agent (Claude Code, Cursor, Claude Desktop, …) — kein Tauri, kein IDA-Seat, keine Python-Bridge (siehe docs/recurse-mcp.md)

Analyse-Backends

Die Analyse läuft über ein einziges Engine-Trait (crates/recurse-static/src/engine.rs), sodass die Engine eine Wahl ist, keine harte Abhängigkeit:

• native (Standard) — reines Rust-Parsing von ELF/PE/Mach-O und Multi-Architektur-Disassembly (object + capstone): x86/x86-64, ARM, AArch64, MIPS, PowerPC, RISC-V, SPARC, SystemZ, M68K, BPF. Kein Kindprozess, kein externes Tool, kein LGPL im Build. Enthält einen Decompiler (die Lift → Optimize → Structure-Pipeline von recurse-vtil — siehe docs/vtil-lift.md) und eine lift-Op für VTIL-artige De-Obfuskierung.
• r2 (radare2) — unterstützt als Opt-in-Alternative für Installationen, die dessen eigenen, vollständigeren Decompiler oder eine rohe Konsole wünschen. Installiere r2 und wähle es als Engine; es läuft als separater Prozess und wird niemals mit Recurse gelinkt oder gebündelt.

Auswählbar über das Einstellungsmenü, die Umgebungsvariable RECURSE_BACKEND oder die gespeicherte Konfiguration. Der Agent erhält ein backend-neutrales analyze-Tool (functions, disasm, graph, lift, decompile, xrefs, strings, imports, info, plus raw für die Engine-Konsole) — gefiltert auf die Ops, die die aktive Engine tatsächlich unterstützt, sodass raw (native hat keine Konsole) nur angeboten wird, wenn verfügbar. Die UI konsumiert kanonische Ergebnistypen, nicht das JSON irgendeiner Engine. Siehe docs/backends.md für das Trait, die Crate-Entscheidungen und die Lizenz- Begründung. Das Öffnen einer großen Binärdatei ist schnell, weil die Analyse lazy ist — die Discovery indexiert Funktionen kostengünstig und Basic Blocks werden erst dekodiert, wenn eine Funktion angezeigt wird; siehe docs/lazy-analysis.md.

Warum nicht einfach MCP-to-IDA / es in Claude Code yolo-en?

Einen MCP-Server an IDA/Ghidra zu kleben oder Disassembly in einen CLI-Agent einzufügen, funktioniert für 5-Funktions-CTFs und scheitert bei echten Binärdateien. Recurse ist eine zweckgebaute Umgebung, kein Chatbot-Wrapper:

• Binäres Weltmodell, kein Text-Scraping. Funktionen, Xrefs, Strings und der CFG sind erstklassiger Zustand, den Agent und UI teilen. Kein erneutes Parsen von pdF-Dumps in den Kontext bei jedem Turn, keine erfundenen 0x401023s.
• Verifikation > Generierung. Im RE gibt es kein npm test — Verifikation ist visuell. Agent-Umbenennungen propagieren sofort in Funktionsliste, Graph und Decompile, sodass ein Mensch mit einem Klick bestätigt oder ablehnt.
• Für Skalierung gebaut. Echte Malware hat 10k Funktionen. Bedarfsgesteuerte Tools + persistentes Gedächtnis schlagen das Dumpen vollständiger Decompiles, bis der Kontext OOMt.
• Agentable Engine. Eine skriptbare, pipebare Engine bedeutet, dass Agents 100 Turns laufen, forken, zurücksetzen und diffen können — und du kannst es tatsächlich ausliefern. Die standardmäßige native Engine benötigt überhaupt kein externes Tool.
• Standardmäßig malware-sicher. Local-first, BYO-Key/OpenRouter-Routing und ein Weg zu Offline-Modellen — kein erzwungener Exfil von Samples an einen Cloud-Chatbot.

Voraussetzungen

1. Kern-Toolchains

Überprüfen:

2. Analyse-Engine

Die standardmäßige native Engine ist reines Rust — nichts zu installieren. Um stattdessen r2 (radare2) als Analyse-Engine zu verwenden, installiere es und wähle es aus (das Einstellungsmenü oder RECURSE_BACKEND=r2); Recurse steuert die r2-Binärdatei in deinem PATH. r2 ist optional, wird vom Build niemals benötigt und niemals mit Recurse verteilt — bring deine eigene Installation mit.

3. Tauri-Linux-Systemabhängigkeiten

Debian/Ubuntu/Pop!_OS:

Andere Distributionen: folge den offiziellen Tauri-Voraussetzungen.

4. Decompiler

Beide Engines bieten einen: native rendert Pseudocode über recurse-vtil (Lift → Optimize → Structure — siehe docs/vtil-lift.md), nichts zu installieren; r2 kann seinen eigenen, vollständigeren Decompiler bereitstellen, wenn sein Plugin installiert ist.

Build

App-Abhängigkeiten liegen in tauri/; Rust kommt aus dem Workspace-Root. just umschließt beide (siehe just --list), oder steuere sie direkt.

Entwicklung

Dies startet den Vite-Dev-Server und öffnet das Tauri-Fenster. Die erste Kompilierung dauert eine Weile (Rust-Build); nachfolgende sind schnell.

Produktions-Binärdatei

Das Bundle landet in target/release/bundle/ (Workspace-Target):

• .deb / .rpm / .AppImage für Linux
• eigenständige Binärdatei unter target/release/recurse

Auf Arch und anderen Rolling-Distributionen benötigt der AppImage-Schritt einen einmaligen lokalen Fix (upstream linuxdeploy hinkt der Distro-Toolchain hinterher) — siehe docs/linux-appimage-build.md.

Nur das Frontend (ohne Desktop-Shell)

Qualitätsprüfungen

Äquivalente direkte Befehle: cargo clippy --workspace --all-targets, cargo test --workspace im Root; npm run lint / npm run format / npm run build innerhalb von tauri/.

Evals

Der Agent wird headless gegen Crackme-Tiers evaluiert (siehe crates/recurse-eval/README.md). Tiers sind YAML: Auswahlfilter über das Dataset oder eine eingefrorene Hexid-Liste, plus Run-Knobs.

eval-run ist eine Binärdatei, kein Test, sodass cargo test niemals Geld oder Zeit für den Agent ausgibt. Endpunkt + Key gehören in crates/recurse-eval/.env (kopiere .env.example). Jeder Lauf schreibt target/eval-traces/<tier>/<backend>/run.log (die vollständige Narration) plus eine <hexid>.json pro Task mit der vollständigen Konversation pro Turn. Das Backend (native oder r2) ist pro Lauf auswählbar — siehe das Eval-README.

Agent-LLM

Das Agent-Chat-Panel läuft auf jedem OpenAI-kompatiblen Endpunkt. Konfiguriere den API-Key, die Base-URL und das Modell über den In-App-Dialog Model & Provider (persistiert in ~/.recurse/recurse.db) oder über Env:

Lokale Modelle / benutzerdefinierte Base-URL

Richte den Agent auf jeden lokalen oder selbst gehosteten OpenAI-kompatiblen Server — Ollama, LM Studio, llama.cpps llama-server, vLLM, text-generation-webui oder ein Remote-Gateway. Setze die Base URL im Dialog (eine bloße Base-URL oder eine vollständige /chat/completions- Route funktionieren beide) und wähle ein Modell aus dem Katalog dieses Servers oder gib eine Modell-ID (llama3.1:8b, qwen2.5-coder, …) direkt ein:

Lokale Endpunkte benötigen keinen API-Key: wenn der Key leer ist, wird die Anfrage ohne Authorization-Header gesendet, und die Modellliste wird aus dem eigenen {base}/models des Endpunkts gelesen. Ein benutzerdefinierter Endpunkt gilt als ohne Key konfiguriert, sodass der Chat gegen einen lokalen Server sofort funktioniert.

Ohne Credentials fällt es auf einen Echo-Client zurück, damit die Verdrahtung weiterhin testbar bleibt.

Der Agent sieht Live-Binärkontext (Arch, Bits, Typ) und kann die vollständige Analyse- Oberfläche (Disassembly, Xrefs, Strings, Imports, Decompilation) durch die Session steuern.

Lizenz

Apache-2.0 — © 2026 Aayush Khanna