recurse

IDE d'ingénierie inverse agentique avec un désassembleur multi-architecture en pur Rust, un décompilateur natif, un débogueur et un agent LLM pour l'analyse binaire et le travail CTF.

recurse-agent n'est que l'agent ; l'analyse statique réside dans recurse-static et le débogueur dans recurse-debug, de sorte que l'agent n'embarque aucun code système qu'il n'utilise pas. Aucun crate ne dépend de Tauri, et chacun se compile/se teste de manière autonome ; recurse-eval pilote l'agent sans interface. Tous sont membres de l'espace de travail, donc un seul Cargo.lock et un seul target/ couvrent tout le dépôt.

Fonctionnalités

• Espace de travail de style Cursor : liste de fonctions, onglets désassemblage/chaînes/imports, graphe CFG, et une barre latérale d'agent conversationnel (basculez avec le bouton Chat ou Ctrl+L)
• Page Recon : informations sur le binaire, hachages MD5/SHA1/SHA256/CRC32, entropie, bibliothèques liées, un rapport de durcissement autonome (RELRO / PIE / NX / canary / FORTIFY / RPATH — sans checksec externe), et compteurs d'analyse
• Renommer les fonctions depuis la liste (double-clic ou le bouton ✎) ; les noms persistent dans SQLite et apparaissent dans la liste de fonctions, les annotations de désassemblage, et pour l'agent
• Agent ancré : chaque adresse est un objet cliquable (liste de fonctions, nœuds du graphe, xrefs, annotations du décompilateur) — pas du texte collé que le modèle peut halluciner
• Session d'analyse en direct sur n'importe quel binaire — y compris les fichiers sans extension
• Mémoire de projet persistante dans SQLite avec récupération FTS5/BM25 — renommages, découvertes et notes survivent à /clear et à la réouverture, et amorcent la session suivante
• Cœur sans interface (recurse-agent) avec traçage de débogage par tour ; la même boucle d'agent s'exécute dans l'interface et dans le harnais d'évaluation
• Agent LLM adossé à un point de terminaison compatible OpenAI (OpenRouter par défaut) avec un sélecteur de modèle ; pilote directement la session (disasm, xrefs, chaînes, imports, décompilation)
• Interface à thème sombre par défaut construite avec Tailwind CSS v4 + shadcn/ui
• Opération lift : élève une fonction vers un IL de désobfuscation de style VTIL et exécute sur toute la routine des passes de propagation/repliement/élimination de code mort/résolution de branchement — utile lorsque le désassemblage ressemble à un dispatcheur de VM ou à une chaîne de prédicats opaques (voir docs/vtil-lift.md)
• Décompilateur natif : decompile produit du pseudocode de type C (if/while structurés, couverture totale des instructions) à partir du même pipeline recurse-vtil — aucun outil externe, r2 non requis
• Serveur recurse-mcp autonome : le même Engine via MCP stdio pour tout agent compatible MCP (Claude Code, Cursor, Claude Desktop, …) — pas de Tauri, pas de licence IDA, pas de pont Python (voir docs/recurse-mcp.md)

Backends d'analyse

L'analyse passe par un unique trait Engine (crates/recurse-static/src/engine.rs), donc le moteur est un choix, pas une dépendance dure :

• native (par défaut) — analyse ELF/PE/Mach-O en pur Rust et désassemblage multi-architecture (object + capstone) : x86/x86-64, ARM, AArch64, MIPS, PowerPC, RISC-V, SPARC, SystemZ, M68K, BPF. Aucun processus enfant, aucun outil externe, aucun LGPL dans la compilation. Inclut un décompilateur (pipeline lift → optimize → structure de recurse-vtil — voir docs/vtil-lift.md) et une opération lift pour la désobfuscation de style VTIL.
• r2 (radare2) — pris en charge comme alternative opt-in pour les installations qui veulent son propre décompilateur plus complet ou une console brute. Installez r2 et sélectionnez-le comme moteur ; il s'exécute comme processus séparé et n'est jamais lié ni fourni avec Recurse.

Choisissez via le menu des paramètres, la variable d'environnement RECURSE_BACKEND, ou la configuration stockée. L'agent dispose d'un unique outil analyze neutre vis-à-vis du backend (functions, disasm, graph, lift, decompile, xrefs, strings, imports, info, plus raw pour la console du moteur) — filtré selon les opérations réellement prises en charge par le moteur actif, donc raw (le natif n'a pas de console) n'est annoncé que lorsqu'il est disponible. L'interface consomme des types de résultats canoniques, pas le JSON d'un moteur. Voir docs/backends.md pour le trait, les choix de crates, et la justification de licence. L'ouverture d'un gros binaire est rapide car l'analyse est paresseuse — la découverte indexe les fonctions à moindre coût et les blocs de base ne sont décodés que lorsqu'une fonction est consultée ; voir docs/lazy-analysis.md.

Pourquoi ne pas simplement faire du MCP-vers-IDA / tout tenter dans Claude Code ?

Greffer un serveur MCP sur IDA/Ghidra, ou coller du désassemblage dans un agent CLI, fonctionne pour des CTF de 5 fonctions et s'effondre sur de vrais binaires. Recurse est un environnement conçu sur mesure, pas un habillage de chatbot :

• Modèle du monde binaire, pas du scraping de texte. Fonctions, xrefs, chaînes et le CFG sont un état de première classe partagé par l'agent et l'interface. Pas de re-parsing des dumps pdF dans le contexte à chaque tour, pas de 0x401023 inventés.
• Vérification > génération. En RE il n'y a pas de npm test — la vérification est visuelle. Les renommages de l'agent se propagent à la liste de fonctions, au graphe et à la décompilation instantanément, donc un humain confirme ou rejette en un clic.
• Conçu pour l'échelle. Un vrai malware fait 10k fonctions. Outils à la demande + mémoire persistante battent le vidage de décompilations complètes jusqu'à saturation du contexte.
• Moteur agentifiable. Un moteur scriptable et pipable signifie que les agents peuvent exécuter 100 tours, forker, réinitialiser et différencier — et vous pouvez réellement le livrer. Le moteur natif par défaut ne nécessite aucun outil externe.
• Sûr pour le malware par défaut. Local-first, routage BYO-key/OpenRouter, et une voie vers des modèles hors ligne — aucune exfiltration forcée d'échantillons vers un chatbot cloud.

Prérequis

1. Chaînes d'outils de base

Vérifier :

2. Moteur d'analyse

Le moteur native par défaut est du pur Rust — rien à installer. Pour utiliser r2 (radare2) comme moteur d'analyse à la place, installez-le et sélectionnez-le (le menu des paramètres, ou RECURSE_BACKEND=r2) ; Recurse pilote le binaire r2 présent dans votre PATH. r2 est optionnel, n'est jamais requis par la compilation, et n'est jamais distribué avec Recurse — apportez votre propre installation.

3. Dépendances système Tauri Linux

Debian/Ubuntu/Pop!_OS :

Autres distributions : suivez les prérequis Tauri officiels.

4. Décompilateur

Les deux moteurs en fournissent un : native produit du pseudocode via recurse-vtil (lift → optimize → structure — voir docs/vtil-lift.md), rien à installer ; r2 peut fournir son propre décompilateur plus complet lorsque son plugin est installé.

Compilation

Les dépendances de l'application résident dans tauri/ ; Rust vient de la racine de l'espace de travail. just encapsule les deux (voir just --list), ou pilotez-les directement.

Développement

Cela démarre le serveur de développement Vite et lance la fenêtre Tauri. La première compilation prend un certain temps (build Rust) ; les suivantes sont rapides.

Binaire de production

Le paquet atterrit dans target/release/bundle/ (cible de l'espace de travail) :

• .deb / .rpm / .AppImage pour Linux
• binaire autonome à target/release/recurse

Sur Arch et autres distributions rolling, l'étape AppImage nécessite une correction locale unique (le linuxdeploy amont est en retard sur la chaîne d'outils de la distribution) — voir docs/linux-appimage-build.md.

Juste le frontend (sans shell de bureau)

Contrôles de qualité

Commandes directes équivalentes : cargo clippy --workspace --all-targets, cargo test --workspace à la racine ; npm run lint / npm run format / npm run build dans tauri/.

Évaluations

L'agent est évalué sans interface contre des niveaux de crackme (voir crates/recurse-eval/README.md). Les niveaux sont en YAML : filtres de sélection sur le jeu de données, ou une liste d'hexid figée, plus des réglages d'exécution.

eval-run est un binaire, pas un test, donc cargo test ne dépense jamais d'argent ni de temps sur l'agent. Le point de terminaison + la clé vont dans crates/recurse-eval/.env (copiez .env.example). Chaque exécution écrit target/eval-traces/<tier>/<backend>/run.log (le récit complet) plus un <hexid>.json par tâche avec la conversation complète par tour. Le backend (native ou r2) est sélectionnable par exécution — voir le README d'évaluation.

LLM de l'agent

Le panneau de chat de l'agent fonctionne sur tout point de terminaison compatible OpenAI. Configurez la clé API, l'URL de base, et le modèle depuis la boîte de dialogue Model & Provider dans l'application (persistée dans ~/.recurse/recurse.db), ou via l'environnement :

Modèles locaux / URL de base personnalisée

Pointez l'agent vers n'importe quel serveur compatible OpenAI local ou auto-hébergé — Ollama, LM Studio, llama-server de llama.cpp, vLLM, text-generation-webui, ou une passerelle distante. Définissez l'URL de base dans la boîte de dialogue (une URL de base nue ou une route complète /chat/completions fonctionnent toutes les deux) et choisissez un modèle dans le catalogue de ce serveur, ou saisissez un identifiant de modèle (llama3.1:8b, qwen2.5-coder, …) directement :

Les points de terminaison locaux ne nécessitent aucune clé API : lorsque la clé est vide, la requête est envoyée sans en-tête Authorization, et la liste des modèles est lue depuis le {base}/models du point de terminaison lui-même. Un point de terminaison personnalisé est considéré comme configuré sans clé, donc le chat fonctionne immédiatement contre un serveur local.

Sans identifiants, il retombe sur un client echo pour que le câblage reste exerçable.

L'agent voit le contexte binaire en direct (arch, bits, type) et peut piloter toute la surface d'analyse (désassemblage, xrefs, chaînes, imports, décompilation) à travers la session.

Licence

Apache-2.0 — © 2026 Aayush Khanna