VulnFanatic-NG

LLM-gestützte Schwachstellenanalyse für Binary Ninja.

VulnFanatic-NG fügt ein Seitenpanel hinzu, das die aktuelle Binärdatei scannt und ein LLM — standardmäßig ein lokal gehostetes OpenAI-kompatibles Modell, alternativ Anthropic Claude, Google Gemini oder Azure OpenAI (siehe LLM-Backends) — bewerten lässt, ob verdächtiger Code tatsächlich verwundbar ist. Es arbeitet hauptsächlich mit der Decompiler-Ausgabe (HLIL) von Binary Ninja, greift bei Bedarf auf Assembler zurück und meldet nur bestätigte Probleme mit klickbaren Verweisen zurück zum Code.

---

So funktioniert es

Ein Scan läuft in bis zu drei Phasen ab (Phase 3 ist optional und nur online):

Phase 1 – Gefährliche Funktionsaufrufe

Findet Aufrufstellen gefährlicher Funktionen, die in rules/phase1_rules.json definiert sind — strcpy, memcpy, sprintf/Formatstrings, system, alloca, scanf, Command/Exec- APIs, schwache Zufallszahlen, die free/delete-Familie (Use-after-Free / Double-Free), Einlesen nicht vertrauenswürdiger Eingaben in feste Puffer (recv/read/fread/ReadFile), SQL-Injection (sqlite3_exec/mysql_query/PQexec), deaktivierte TLS- Zertifikatsprüfung (SSL_CTX_set_verify/curl), SSRF und fehlerhaftes Rechte-Management (setuid/setresgid), die memset/bzero-Familie und Vergleiche mit einer angreiferkontrollierten Länge (memcmp/strncmp → Authentifizierungs-Bypass), über C/C++, Win32 und (best effort) Rust FFI hinweg. Abgedeckt sind auch gehärtete _chk- (FORTIFY) und Annex-K-_s-Varianten. Gebundene formatierte Ausgabefunktionen (snprintf und Varianten) haben ihre eigene standardmäßig sichere Regel, sodass ein korrektes Größenargument nicht als Überlauf gemeldet wird. Aufrufstellen werden auf drei Arten gefunden: direkte Aufrufe der benannten Symbole; Aufrufe über Forwarding-Thunks / PLT-Stubs (die tatsächlichen Aufrufer werden wiederhergestellt, damit ein Import, der nur über einen Stub erreicht wird, nicht übersehen wird); und — sofern vulnfanatic.scanIndirectCalls nicht deaktiviert ist — indirekte Aufrufe, die über einen Funktionszeiger oder eine Vtable dispatched werden und von Binary Ninja einer gefährlichen Funktion zugeordnet wurden. Für jede Aufrufstelle wird ein interprozeduraler, decompiler-zentrierter Kontext aufgebaut, der auf ein Token-Limit begrenzt ist (Standard 100k):

• der Aufrufausdruck und seine Argumente,
• das deklarierte Prototyp der aufgerufenen Funktion (aus den Typinformationen von Binary Ninja, andernfalls aus einer eingebauten Tabelle), damit das Modell Argumente korrekt auf Parameter abbildet — gehärtete __*_chk- und grenzgeprüfte *_s-Varianten haben zusätzliche führende Argumente, wodurch sich die Position von Format/Größe/Ziel verschiebt,
• der Typ und die Bytgröße jedes Aufrufarguments (Pufferkapazitäten), abgeleitet aus dem HLIL-Ausdruckstyp des Arguments, sodass ein Strukturfeld wie s->buf auf die tatsächliche Arraygröße des Felds auflöst statt auf die Zeigergröße von s; Strukturdefinitionen im Typbereich tragen ebenfalls Bygrößen pro Feld,
• der konkrete Wert / Wertebereich jedes Arguments, aufgelöst durch Binary Ninjas Konstantenpropagation und Value-Set-Analyse (z. B. eine nachweislich konstante Länge 0x40 oder begrenzt auf [0, 0xff]), die das Modell als Ground Truth verwendet, wenn es eine Größe mit einer Pufferkapazität vergleicht, statt zu raten,
• das Stackframe-Layout der aufrufenden Funktion (Variablenoffsets und Bygrößen), wenn sie einen Puffer fester Größe enthält, sodass ein Stack-Overflow anhand der benachbarten Variablen und der gespeicherten Rücksprungadresse beurteilt werden kann (vulnfanatic.includeStackLayout),
• die Pfadbedingungen (die if/Schleifen-/switch-Bedingungen, die den Aufruf absichern),
• eine Argument-Datenfluss-Zusammenfassung — wo jedes Aufrufargument innerhalb der Funktion definiert und verwendet wird,
• Parameterauflösung über Aufrufer hinweg — wenn ein gefährliches Argument ein Parameter der aufrufenden Funktion ist, berichtet der Kontext, was jeder Aufrufer tatsächlich übergibt (z. B. „alle Aufrufer übergeben ein String-Literal"), damit ein Format-/ Größenparameter, der immer konstant ist, nicht fälschlich als angreiferkontrolliert eingestuft wird,
• den vollständig decompilierten Rumpf der aufrufenden Funktion,
• Datentypdefinitionen (struct/union/enum) für die Typen, auf die in der Aufrufkette und in den Argumentvariablen verwiesen wird, damit das Modell echte Puffer-/Feldgrößen und Integer-Breiten kennt,
• die decompilierten Rümpfe der Funktionen, die die Argumentvariablen des Aufrufs erzeugen oder konsumieren (verfolgt über HLIL-Def/Use), was Use-after-Free / Double-Free- und Tainted-Size-Überlegungen überhaupt erst möglich macht,
• Aufrufpfade von Einstiegspunkten / exportierten Funktionen hinunter zum Aufruf,
• den decompilierten Rumpf jeder Funktion entlang dieser Aufrufpfade (am nächsten zum gefährlichen Aufruf zuerst), jeweils annotiert mit der Aufrufstelle und den Bedingungen, die den nächsten Hop absichern,
• die Rümpfe anderer Funktionen, die diese Pfadfunktionen aufrufen (z. B. für MAIN→ABCD→strcpy auch die Funktionen, die MAIN und ABCD sonst noch aufrufen), da sie die Grenz-/Validierungsprüfungen enthalten können, die den gefährlichen Wert absichern (vulnfanatic.includeCallPathSiblings, solange das Budget reicht), und
• Tainted-Source-Hinweise (Eingabefunktionen wie recv/read/getenv, die in derselben Funktion aufgerufen werden).

Dieser Kontext plus ein regelspezifischer Prompt wird an das Modell gesendet, das eine strukturierte Bewertung zurückgibt. Nicht-Probleme werden verworfen. Die Prompts sind auf ein starkes lokales Code-Modell (z. B. Qwen2.5-Coder) abgestimmt und weisen es an, den gesamten Fluss zu analysieren und nur JSON auszugeben.

Reasoning, Scratchpad und Konfidenz

Das Modell wird angewiesen, Recall zu bevorzugen — plausible, sicherheitsrelevante Probleme zu melden und Unsicherheit über eine Confidence auszudrücken, anstatt etwas zu verwerfen, das es nicht vollständig beweisen kann. Es zeigt seine Arbeit in einem Scratchpad, das die wörtlichen Code-Snippets zitiert, auf die es sich gestützt hat (die Eingabequelle, jede Absicherung, die Größe/Länge, den relevanten Typ und die Senke), das beim Befund gespeichert wird, damit du die Argumentation prüfen kannst.

Jeder Befund trägt eine Confidence (hoch/mittel/niedrig): hoch = die gesamte Kette ist im Kontext sichtbar; mittel = wahrscheinlich, mit ein oder zwei abgeleiteten Verbindungen; niedrig = ein Anhaltspunkt, der eine manuelle Prüfung wert ist. Das ist die zentrale Kennzahl (die Schweregradschätzung des Modells ist ein sekundäres Feld). Setze vulnfanatic.minConfidence, um alles unterhalb einer Schwelle zu verwerfen.

Präzision vs. Recall abstimmen

Standardmäßig bevorzugt VulnFanatic-NG Recall (echte Probleme finden). Wenn du zu viele False Positives bekommst, verschärfe die Einstellung mit einer der folgenden Optionen: