VulnFanatic-NG

Recherche de vulnérabilités assistée par LLM pour Binary Ninja.

VulnFanatic-NG ajoute un panneau latéral qui analyse le binaire actuel et demande à un LLM — un modèle compatible OpenAI hébergé localement par défaut, ou Anthropic Claude, Google Gemini, ou Azure OpenAI (voir Backends LLM) — de juger si un code suspect est réellement vulnérable. Il fonctionne principalement à partir de la sortie du décompilateur (HLIL) de Binary Ninja, en utilisant l'assembleur si nécessaire, et ne rapporte que les problèmes confirmés avec des références cliquables vers le code.

---

Comment ça fonctionne

Une analyse s'exécute en jusqu'à trois phases (la phase 3 est optionnelle et en ligne uniquement) :

Phase 1 — appels de fonctions dangereuses

Trouve les sites d'appel des fonctions dangereuses définies dans rules/phase1_rules.json — strcpy, memcpy, sprintf/chaînes de format, system, alloca, scanf, API de commande/exécution, RNG faible, la famille free/delete (use-after-free / double-free), lectures d'entrées non fiables dans des tampons fixes (recv/read/fread/ReadFile), injection SQL (sqlite3_exec/mysql_query/PQexec), vérification de certificat TLS désactivée (SSL_CTX_set_verify/curl), SSRF, et gestion inappropriée des privilèges (setuid/setresgid), la famille memset/bzero, et comparaisons avec une longueur contrôlée par l'attaquant (memcmp/strncmp → contournement d'authentification), à travers C/C++, Win32, et (au mieux) Rust FFI. La couverture inclut les variantes fortifiées _chk (FORTIFY) et Annex-K _s. Les fonctions de sortie formatée bornées (snprintf et variantes) ont leur propre règle par défaut sécurisée afin qu'un argument de taille correct ne soit pas signalé comme un débordement. Les sites d'appel sont trouvés de trois manières : appels directs aux symboles nommés ; appels acheminés via des thunks de redirection / stubs PLT (les appelants réels sont récupérés, donc une importation atteinte uniquement via un stub n'est pas manquée) ; et — sauf si vulnfanatic.scanIndirectCalls est désactivé — appels indirects envoyés via un pointeur de fonction ou une vtable que Binary Ninja a résolu en une fonction dangereuse. Pour chaque site d'appel, il construit un contexte interprocédural, centré sur le décompilateur, avec un budget de jetons (100k par défaut) :

• l'expression d'appel et ses arguments,
• le prototype déclaré de la fonction appelée (à partir des informations de type de Binary Ninja, sinon une table intégrée) afin que le modèle associe correctement les arguments aux paramètres — les variantes fortifiées __*_chk et les variantes vérifiées des limites *_s prennent des arguments supplémentaires en tête, décalant la position du format/taille/destination,
• le type et la taille en octets de chaque argument d'appel (capacités des tampons), dérivés du type d'expression HLIL de l'argument afin qu'un champ de structure comme s->buf se résolve en la taille réelle du tableau du champ plutôt qu'en la taille du pointeur de s ; les définitions de structure dans la section des types portent également des tailles en octets par champ,
• la valeur concrète / plage de chaque argument résolue par la propagation de constantes et l'analyse d'ensemble de valeurs de Binary Ninja (par exemple, une longueur prouvée constante 0x40 ou bornée à [0, 0xff]), que le modèle utilise comme vérité terrain lorsqu'il compare une taille à une capacité de tampon au lieu de deviner,
• la disposition de la pile d'appel de la fonction appelante (décalages des variables et tailles en octets) lorsqu'elle contient un tampon de taille fixe, afin qu'un débordement de pile puisse être jugé par rapport aux variables adjacentes et à l'adresse de retour sauvegardée (vulnfanatic.includeStackLayout),
• les contraintes de chemin (les conditions if/boucle/switch qui protègent l'appel),
• un résumé du flux de données des arguments — où chaque argument d'appel est défini et utilisé dans la fonction,
• résolution des paramètres à travers les appelants — lorsqu'un argument dangereux est un paramètre de la fonction appelante, le contexte rapporte ce que chaque appelant passe réellement pour celui-ci (par exemple, "tous les appelants passent une chaîne littérale"), afin qu'un paramètre de format/taille toujours constant ne soit pas confondu avec un paramètre contrôlé par l'attaquant,
• le corps décompilé complet de la fonction appelante,
• les définitions de types de données (struct/union/enum) pour les types référencés dans la chaîne d'appel et les variables d'argument, afin que le modèle connaisse les vraies tailles de tampons/champs et les largeurs d'entiers,
• les corps décompilés des fonctions qui produisent ou consomment les variables d'argument de l'appel (tracées via la définition/utilisation HLIL), ce qui rend possible le raisonnement sur l'utilisation après libération / double libération et la taille contaminée,
• les chemins d'appel depuis les points d'entrée / fonctions exportées jusqu'à l'appel,
• le corps décompilé de chaque fonction le long de ces chemins d'appel (le plus proche de l'appel dangereux en premier), chacun annoté avec le site d'appel et les conditions protégeant le saut suivant,
• les corps des autres fonctions que ces fonctions de chemin appellent (par exemple, pour MAIN→ABCD→strcpy, également les fonctions que MAIN et ABCD appellent ailleurs), car elles peuvent contenir les vérifications de limites/validation qui contrôlent la valeur dangereuse (vulnfanatic.includeCallPathSiblings, rempli tant que le budget le permet), et
• indices de source contaminée (fonctions d'entrée comme recv/read/getenv appelées dans la même fonction).

Ce contexte, ainsi qu'une invite spécifique à la règle, est envoyé au modèle, qui renvoie un verdict structuré. Les non-problèmes sont ignorés. Les invites sont optimisées pour un modèle de code local puissant (par exemple Qwen2.5-Coder) et lui demandent d'analyser l'ensemble du flux et d'émettre uniquement du JSON.

Raisonnement, bloc-notes et confiance

Le modèle reçoit l'instruction de favoriser le rappel — signaler les problèmes plausibles et pertinents pour la sécurité et exprimer l'incertitude via une Confiance plutôt que d'abandonner tout ce qu'il ne peut pas prouver complètement. Il montre son travail dans un bloc-notes qui cite les extraits de code textuels sur lesquels il s'est appuyé (la source d'entrée, chaque garde, la taille/longueur, le type pertinent, et le puits), qui est stocké sur la constatation afin que vous puissiez auditer le raisonnement.

Chaque constatation porte une Confiance (haute/moyenne/basse) : haute = toute la chaîne est montrée dans le contexte ; moyenne = probable, avec un ou deux liens inférés ; basse = une piste méritant un examen manuel. C'est la métrique principale (l'estimation de sévérité du modèle est un champ secondaire). Définissez vulnfanatic.minConfidence pour ignorer tout ce qui est en dessous d'un seuil.

Réglage de la précision vs. rappel

Par défaut, VulnFanatic-NG favorise le rappel (détection des vrais problèmes). Si vous obtenez trop de faux positifs, resserrez avec l'un des éléments suivants :