VulnFanatic-NG

Ricerca di vulnerabilità assistita da LLM per Binary Ninja.

VulnFanatic-NG aggiunge un pannello laterale che analizza il binario corrente e chiede a un LLM — un modello compatibile con OpenAI ospitato localmente per impostazione predefinita, oppure Anthropic Claude, Google Gemini o Azure OpenAI (vedi Backend LLM) — di stabilire se il codice sospetto è davvero vulnerabile. Funziona principalmente dall'output del decompilatore (HLIL) di Binary Ninja, ripiegando sull'assembly quando necessario, e segnala solo problemi confermati con riferimenti cliccabili al codice.

---

Come funziona

Una scansione viene eseguita in un massimo di tre fasi (la Fase 3 è opzionale e solo online):

Fase 1 — chiamate a funzioni pericolose

Trova i punti di chiamata delle funzioni pericolose definite in rules/phase1_rules.json — strcpy, memcpy, sprintf/stringhe di formato, system, alloca, scanf, API di comandi/exec, RNG debole, la famiglia free/delete (use-after-free / double-free), letture di input non attendibile in buffer a dimensione fissa (recv/read/fread/ReadFile), iniezione SQL (sqlite3_exec/mysql_query/PQexec), verifica dei certificati TLS disabilitata (SSL_CTX_set_verify/curl), SSRF e gestione impropria dei privilegi (setuid/setresgid), la famiglia memset/bzero e confronti con una lunghezza controllata dall'attaccante (memcmp/strncmp → bypass dell'autenticazione), in C/C++, Win32 e (per quanto possibile) Rust FFI. La copertura include le varianti fortificate _chk (FORTIFY) e quelle _s dell'Annex K. Le funzioni di output formattato limitato (snprintf e varianti) hanno una propria regola sicura di default, così un argomento di dimensione corretto non viene segnalato come overflow. I punti di chiamata vengono trovati in tre modi: chiamate dirette ai simboli nominati; chiamate instradate attraverso thunk di forwarding / stub PLT (i chiamanti reali vengono recuperati, quindi un import raggiunto solo tramite stub non viene perso); e — a meno che vulnfanatic.scanIndirectCalls sia disattivata — chiamate indirette inviate attraverso un puntatore a funzione o vtable che Binary Ninja ha risolto a una funzione pericolosa. Per ogni punto di chiamata costruisce un contesto interprocedurale, incentrato sul decompilatore, limitato a un budget di token (default 100k):

• l'espressione di chiamata e i suoi argomenti,
• il prototipo dichiarato della funzione chiamata (dalle informazioni sui tipi di Binary Ninja, altrimenti da una tabella integrata) così il modello mappa correttamente gli argomenti ai parametri — le varianti fortificate __*_chk e quelle con controllo dei limiti *_s hanno argomenti iniziali aggiuntivi, spostando la posizione di formato/dimensione/destinazione,
• il tipo e la dimensione in byte di ogni argomento di chiamata (capacità dei buffer), derivati dal tipo dell'espressione HLIL dell'argomento, così un campo di struct come s->buf si risolve nella dimensione reale dell'array del campo piuttosto che nella dimensione del puntatore di s; anche le definizioni di struct nella sezione dei tipi riportano le dimensioni in byte per campo,
• il valore concreto / intervallo di ogni argomento risolto dall'analisi di propagazione delle costanti e value-set di Binary Ninja (ad es. una lunghezza dimostrata costante 0x40 o limitata a [0, 0xff]), che il modello usa come riferimento reale quando confronta una dimensione con la capacità di un buffer invece di fare supposizioni,
• il layout dello stack frame della funzione chiamante (offset delle variabili e dimensioni in byte) quando contiene un buffer a dimensione fissa, così un overflow dello stack può essere valutato rispetto alle variabili adiacenti e all'indirizzo di ritorno salvato (vulnfanatic.includeStackLayout),
• i vincoli di percorso (le condizioni if/loop/switch che proteggono la chiamata),
• un riepilogo del data-flow degli argomenti — dove ogni argomento di chiamata viene definito e usato all'interno della funzione,
• risoluzione dei parametri attraverso i chiamanti — quando un argomento pericoloso è un parametro della funzione chiamante, il contesto riporta ciò che ogni chiamante passa effettivamente (ad es. "tutti i chiamanti passano una stringa letterale"), così un parametro di formato/dimensione sempre costante non viene scambiato per controllato dall'attaccante,
• il corpo decompilato completo della funzione chiamante,
• definizioni dei tipi di dati (struct/union/enum) per i tipi referenziati attraverso la catena di chiamate e le variabili degli argomenti, così il modello conosce le dimensioni reali di buffer/campi e le larghezze degli interi,
• i corpi decompilati delle funzioni che producono o consumano le variabili degli argomenti della chiamata (tracciati tramite def/use HLIL), ciò che rende possibile il ragionamento su use-after-free / double-free e dimensioni contaminate,
• percorsi di chiamata dai punti di ingresso / funzioni esportate fino alla chiamata,
• il corpo decompilato di ogni funzione lungo questi percorsi di chiamata (prima quelle più vicine alla chiamata pericolosa), ciascuna annotata con il punto di chiamata e le condizioni che proteggono il passo successivo,
• i corpi delle altre funzioni chiamate da quelle sul percorso (ad es. per MAIN→ABCD→strcpy, anche le funzioni che MAIN e ABCD chiamano altrove), poiché potrebbero contenere i controlli di limiti/validazione che condizionano il valore pericoloso (vulnfanatic.includeCallPathSiblings, riempito finché il budget lo consente), e
• suggerimenti di sorgenti contaminate (funzioni di input come recv/read/getenv chiamate nella stessa funzione).

Questo contesto, insieme a un prompt specifico per la regola, viene inviato al modello, che restituisce un verdetto strutturato. I non-problemi vengono scartati. I prompt sono ottimizzati per un modello di codice locale potente (ad es. Qwen2.5-Coder) e gli chiedono di analizzare l'intero flusso e di emettere solo JSON.

Ragionamento, scratchpad e confidenza

Al modello viene chiesto di privilegiare il recall — segnalare problemi plausibili e rilevanti per la sicurezza ed esprimere l'incertezza attraverso una Confidence piuttosto che scartare ciò che non può dimostrare completamente. Mostra il suo lavoro in uno scratchpad che cita i frammenti di codice verbatim su cui si è basato (la sorgente di input, ogni guardia, la dimensione/lunghezza, il tipo rilevante e il sink), che viene salvato sulla segnalazione così puoi verificare il ragionamento.

Ogni segnalazione ha una Confidence (alta/media/bassa): alta = l'intera catena è mostrata nel contesto; media = probabile, con uno o due collegamenti dedotti; bassa = una pista che merita una revisione manuale. Questa è la metrica principale (la stima della severità del modello è un campo secondario). Imposta vulnfanatic.minConfidence per scartare tutto ciò che è sotto una soglia.

Ottimizzare precisione vs. recall

Per impostazione predefinita VulnFanatic-NG privilegia il recall (trovare i problemi reali). Se ricevi troppi falsi positivi, puoi stringere con una delle seguenti opzioni: