VulnFanatic-NG

Investigación de vulnerabilidades asistida por LLM para Binary Ninja.

VulnFanatic-NG añade un panel lateral que escanea el binario actual y pregunta a un LLM — un modelo alojado localmente compatible con OpenAI por defecto, o Anthropic Claude, Google Gemini, o Azure OpenAI (ver Backends de LLM) — para juzgar si el código sospechoso es realmente vulnerable. Funciona principalmente a partir de la salida del descompilador (HLIL) de Binary Ninja, recurriendo al ensamblador cuando es necesario, e informa solo problemas confirmados con referencias en las que se puede hacer clic hacia el código.

---

Cómo funciona

Un análisis se ejecuta en hasta tres fases (La Fase 3 es opcional y solo en línea):

Fase 1 — llamadas a funciones peligrosas

Encuentra sitios de llamada de funciones peligrosas definidas en rules/phase1_rules.json — strcpy, memcpy, sprintf/cadenas de formato, system, alloca, scanf, APIs de comando/ejecución, RNG débil, la familia free/delete (uso después de liberación / doble liberación), lecturas de entrada no confiable en buffers fijos (recv/read/fread/ReadFile), inyección SQL (sqlite3_exec/mysql_query/PQexec), verificación de certificado TLS deshabilitada (SSL_CTX_set_verify/curl), SSRF, y gestión de privilegios inadecuada (setuid/setresgid), la familia memset/bzero, y comparaciones con una longitud controlada por el atacante (memcmp/strncmp → bypass de autenticación), en C/C++, Win32, y (con el mejor esfuerzo) Rust FFI. Cobertura incluye variantes fortificadas _chk (FORTIFY) y con verificación de límites _s (Anexo-K). Las funciones de salida con formato acotado (snprintf y variantes) tienen su propia regla segura por defecto, por lo que un argumento de tamaño correcto no se reporta como desbordamiento. Los sitios de llamada se encuentran de tres maneras: llamadas directas a los símbolos nombrados; llamadas enrutadas a través de stubs de reenvío / PLT (se recuperan los llamadores reales, de modo que no se pierde una importación alcanzada solo a través de un stub); y — a menos que vulnfanatic.scanIndirectCalls esté desactivado — llamadas indirectas despachadas a través de un puntero a función o vtable que Binary Ninja resolvió a una función peligrosa. Para cada sitio de llamada, construye un contexto interprocedimental centrado en el descompilador, limitado a un presupuesto de tokens (por defecto 100k):

• la expresión de la llamada y sus argumentos,
• el prototipo declarado de la función llamada (de la información de tipos de Binary Ninja, o de una tabla incorporada) para que el modelo asigne argumentos a parámetros correctamente — las variantes fortificadas __*_chk y con verificación de límites *_s toman argumentos iniciales adicionales, desplazando la posición del formato/tamaño/destino,
• el tipo y tamaño en bytes de cada argumento de llamada (capacidades de los buffers), derivado del tipo de la expresión HLIL del argumento, de modo que un campo de estructura como s->buf se resuelva al tamaño real del array del campo en lugar del tamaño del puntero de s; las definiciones de estructuras en la sección de tipos también llevan tamaños en bytes por campo,
• el valor concreto / rango de cada argumento resuelto por el análisis de propagación de constantes y de conjuntos de valores de Binary Ninja (por ejemplo, una longitud probada constante 0x40 o acotada a [0, 0xff]), que el modelo usa como verdad fundamental al comparar un tamaño con la capacidad de un buffer en lugar de adivinar,
• el diseño del marco de pila de la función llamadora (desplazamientos de variables y tamaños en bytes) cuando contiene un buffer de tamaño fijo, de modo que un desbordamiento de pila pueda juzgarse frente a las variables adyacentes y la dirección de retorno guardada (vulnfanatic.includeStackLayout),
• las restricciones de ruta (las condiciones if/bucle/switch que protegen la llamada),
• un resumen del flujo de datos de los argumentos — dónde se define y utiliza cada argumento de la llamada dentro de la función,
• resolución de parámetros a través de los llamadores — cuando un argumento peligroso es un parámetro de la función llamadora, el contexto informa lo que cada llamador realmente pasa por él (por ejemplo, "todos los llamadores pasan un literal de cadena"), de modo que un parámetro de formato/tamaño que siempre es constante no se confunda con controlado por el atacante,
• el cuerpo descompilado completo de la función llamadora,
• definiciones de tipos de datos (struct/union/enum) para los tipos referenciados a lo largo de la cadena de llamadas y las variables de los argumentos, para que el modelo conozca los tamaños reales de los buffers/campos y las anchuras enteras,
• los cuerpos descompilados de las funciones que producen o consumen las variables de los argumentos de la llamada (rastreadas mediante uso/definición HLIL), que es lo que hace posible el razonamiento sobre uso después de liberación / doble liberación y tamaño contaminado,
• rutas de llamada desde los puntos de entrada / funciones exportadas hasta la llamada,
• el cuerpo descompilado de cada función a lo largo de esas rutas de llamada (la más cercana a la llamada peligrosa primero), cada una anotada con el sitio de llamada y las condiciones que protegen el siguiente salto,
• los cuerpos de otras funciones que esas funciones de la ruta llaman (por ejemplo, para MAIN→ABCD→strcpy, también las funciones que MAIN y ABCD llaman en otros lugares), ya que pueden contener las comprobaciones de límites/validación que protegen el valor peligroso (vulnfanatic.includeCallPathSiblings, completado mientras el presupuesto lo permita), y
• pistas de fuentes contaminadas (funciones de entrada como recv/read/getenv llamadas en la misma función).

Ese contexto, junto con un prompt específico de la regla, se envía al modelo, que devuelve un veredicto estructurado. Los no-problemas se descartan. Los prompts están ajustados para un modelo de código local potente (por ejemplo, Qwen2.5-Coder) y le indican que analice todo el flujo y emita solo JSON.

Razonamiento, borrador y confianza

Se le indica al modelo que favorezca el recuerdo — reporte problemas plausibles y relevantes para la seguridad y exprese incertidumbre a través de una Confianza en lugar de descartar cualquier cosa que no pueda probar completamente. Muestra su trabajo en un borrador que cita los fragmentos de código literales en los que se basó (la fuente de entrada, cada protección, el tamaño/longitud, el tipo relevante, y el sumidero), que se almacena en el hallazgo para que puedas auditar el razonamiento.

Cada hallazgo lleva una Confianza (alta/media/baja): alta = toda la cadena se muestra en el contexto; media = probable, con uno o dos enlaces inferidos; baja = una pista que merece revisión manual. Esta es la métrica principal (la estimación de severidad del modelo es un campo secundario). Establece vulnfanatic.minConfidence para descartar cualquier cosa por debajo de un umbral.

Ajustando precisión vs. recuerdo

Por defecto VulnFanatic-NG favorece el recuerdo (detectar problemas reales). Si obtienes demasiados falsos positivos, ajústalo con cualquiera de: