peafl64

Instrumentando un binario en modo usuario con NOPs

Instrumentando un binario en modo kernel con filtrado por ID de proceso

Instrumentando un binario en modo kernel con filtrado por ID de hilo y salida detallada

Cómo reemplazar controladores de Windows

Primero tendrás que comprobar si tu máquina arranca con BIOS o UEFI.
Para máquinas Hyper-V: las máquinas de Gen 1 están basadas en BIOS y las de Gen 2 en UEFI.
Si tu máquina está basada en BIOS, necesitas parchear winload.exe:

• Obtén una copia de winload.exe de tu máquina virtual y localiza la función ImgpValidateImageHash en ella
• Parchea el valor de retorno para que siempre devuelva 0 en rax. Por ejemplo, reemplaza mov eax, edi por xor eax, eax en el último bloque de código de la función
• Copia el winload parcheado a la carpeta system32 y ejecuta bcdedit /set path \Windows\system32\winload2.exe

Si tu máquina arranca con UEFI, usa la utilidad EfiGuard para parchear winload.efi.
Hoja de referencia de comandos si usas Hyper-V Manager:

1. Crea un nuevo disco duro para la máquina virtual
2. Usa el FAT.vhdx suministrado en la carpeta Tools (o crea uno tú mismo) que contenga el módulo UefiShell+EfiGuard junto con el nuevo disco duro
3. Cambia el orden de arranque de la máquina para que el nuevo disco duro sea el primero en el orden
4. Tras el arranque, estando en la UefiShell ejecuta los siguientes comandos:

A continuación, instrumenta el controlador que elijas. Para cargar un controlador instrumentado en una máquina Windows debe estar firmado, y un certificado de autofirma es suficiente para cumplir los requisitos del sistema operativo:

Si el controlador que instrumentaste ya es utilizado por el sistema, usa estos comandos (como administrador) para reemplazar el archivo del controlador:

Después ejecuta:

Fuzzing con WinAFL

La integración con WinAFL se realiza compilando un harness con las cabeceras proporcionadas.
Junto a las cabeceras se incluye example.c, un programa de ejemplo que muestra cómo usarlas.
Las cabeceras proporcionadas son una ligera modificación de las que ya incluye WinAFL para integrarse con otra herramienta de instrumentación estática de binarios llamada Syzygy.

Fuzzing con kAFL

La forma en que nos integramos con kAFL es bastante sencilla.
Normalmente, un harness de kAFL se ejecuta en una máquina virtual y se comunica con el frontend del fuzzer mediante "hypercalls" especiales.
Estas hypercalls le indican al fuzzer que haga muchas cosas, entre ellas cargar los datos de cobertura de IntelPT y parsearlos como un bitmap de AFL.
Debido a que peafl64 hace obsoleto el rastreo con IntelPT, debemos preparar una forma de transmitir los datos de cobertura al fuzzer.
Por lo tanto, ampliamos qemu y kvm con "hypercalls" que permiten que el harness (en modo usuario) que se ejecuta en una VM envíe los datos de cobertura que recopiló mediante el controlador auxiliar.

Configuración en ESXi

Esto se refiere específicamente a la configuración en ESXi, pero debería ser relevante para otras plataformas de virtualización como AWS.
La configuración es bastante sencilla:

• Crea una máquina Ubuntu
• Asegúrate de que "Expose hardware assisted virtualization to the guest OS" esté habilitado en la configuración de CPU de la máquina
• Clona el repositorio sbi_kAFL
• Instala kAFL normalmente como se indica en el repositorio de kAFL, pero en lugar del paso install.sh qemu, ejecuta install.sh qemu_sbi

Para hacer fuzzing con kAFL y peafl64, necesitamos preparar una máquina de fuzzing:

• Compila el controlador auxiliar y fírmalo
• Compila un harness usando las cabeceras proporcionadas con nuestro fork de kAFL
• En la VM, carga el controlador auxiliar
• Ejecuta el loader de kAFL

Por lo demás, hacer fuzzing con nuestro fork de kAFL es igual que con el kAFL normal.

Flujo de ejecución

Resumen de pasos:

1. Determinar los puntos de inserción para el código de instrumentación
2. Localizar las instrucciones y estructuras que necesitarán ajustes
3. Insertar el código de instrumentación en las funciones solicitadas
4. Ajustar:
   • Instrucciones relativas
   • Tablas de salto
   • Manejadores de excepciones
   • Cabeceras PE
   • Varias configuraciones de PE (load config)
5. Reconstruir el PE con las secciones instrumentadas

Primero, usamos IDA para encontrar y analizar las instrucciones y ubicaciones de interés.
El análisis crea un archivo dump.json que contiene toda esa información en formato json.
instrument.py contiene la lógica de instrumentación, y el flujo en sí está descrito en la función process_pe.
Para instrumentar el binario, duplicamos sus secciones ejecutables, donde se encontrará todo el código instrumentado.
A continuación, procesamos todas las instrucciones relativas y determinamos cómo y si necesitamos gestionarlas. Supongamos que tenemos un jmp corto de la dirección X a la dirección Y. Insertamos código de instrumentación entre X e Y, y ahora el destino está en la dirección Z (Z = Y + len(instrumentation)).
Eso significa que tenemos que modificar el salto. Si la dirección Z queda ahora fuera del rango de los jmp cortos, necesitamos transformar el salto de short a far. (instrument.py:expand_relative_instructions)
Por ejemplo:

• short jmp 0x57 (eb 55) -> near jmp 0x604 (e9 ff 05 00 00)

Ese también es el caso de instrucciones como call, loop y saltos condicionales.
Otro caso común que requiere tratamiento son las instrucciones relativas a rip introducidas en ensamblador x64:

• call [rip+0x1000]

Actualizamos los siguientes elementos para que apunten al código instrumentado: tabla de reubicaciones, tabla de exportaciones, configuración de carga, el directorio TLS y los registros de excepciones.
Las actualizaciones se realizan reasignando todas las direcciones de las secciones originales a sus contrapartidas instrumentadas. (instrument.py:update_addr)
Las cabeceras se actualizan para reflejar los cambios en la estructura del PE: secciones añadidas, punto de entrada modificado y tamaño del PE. (instrument.py:update_pe_headers)

Además, peafl64 es capaz de instrumentar el kernel de Windows. Para lograrlo, parsea y actualiza la tabla de reubicación de valores dinámicos (DVRT) y la SSDT, y maneja las particularidades de PatchGuard.

La DVRT es una tabla generada por el compilador que describe las ubicaciones de las direcciones que deben cambiarse al cargar el PE.
Se utiliza para mejorar KASLR y ayuda a mitigar la vulnerabilidad Spectre (1, 2, 3).
La DVRT se parsea mediante un conjunto de clases que imitan la estructura de la tabla (drt.py; instrument.py:get_updated_dynamic_relocs)

Gestionar y actualizar la SSDT no fue tan sencillo.
Su dirección no está exportada, así que tuvimos que depender de símbolos o de heurísticas para localizarla.
Nuestra solución utiliza un enfoque heurístico, usando NtWaitForSingleObject como marcador constante para todas las versiones de Windows 10 y encontrando la dirección de la SSDT de forma relativa a él. (instrument.py:ntoskrnl_update_KiServiceTable)
Este enfoque funciona para todos los kernels de Windows 10, pero deberá ajustarse para otras versiones de kernel.

TODO

• soporte para x64
• Nuevos manejadores de excepciones (cxx4)
• Mejorar el rendimiento del dumper de IDA
• Parsear completamente la estructura LOAD_CONFIG
• Añadir pruebas
• Compatibilidad con más versiones del kernel de Windows de serie
• Integración con Nyx (el nuevo kAFL)