inVtero.net
inVteroCore.0.1
https://github.com/ShaneK2/inVtero.net/blob/master/quickdumps/publish.zip
Linux usa servidores de símbolos para la resolución de tipos, simplemente funciona;)
Consulte la versión inVteroCore para proporcionar integridad para XEN y VMWare en Linux (o en cualquier lugar donde se ejecute CORECLR, OSX y FBSD)
##$ IMPORTANTE (usuarios de Windows en .NET) => Es necesario tener registrado msdia140.dll "cmd /c regsvr32 msdia140.dll" (ver zip)
No se necesita configuración, escritura completamente dinámica / pato
Nueva interfaz de usuario para formatos compatibles con edición de memoria (desmontaje/ensamblaje y parcheo). Utilice "Loader()" en una instancia de vtero como;
Loader(test(MemList))
Cambie la cadena MemoryDump para que apunte a un volcado de memoria. Ejemplo de recorrido de volcado de memoria y explicación del sistema de tipos en analyse.py, consulte WalkProcListExample()
quickdumps
>>> MemList = [ "c:\temp\win10.64.xendump" ]
>>> test(MemList)
++++++++++++++++++++++++++++++ ANALYZING INPUT [c:tempwin10.64.xendump] ++++++++++++++++++++++++++++++
PART RUNTIME: 00:00:08.5211677 (seconds), INPUT DUMP SIZE: 4,303,692,448.00 bytes.
SPEED: 466,980 KB / second (all phases aggregate time)
++++++++++++++++++++++++++++++ DONE WITH INPUT [c:tempwin10.64.xendump] ++++++++++++++++++++++++++++++
>>> Loader(vtero)
Buscar/Extraer procesos, hipervisores (incluidos los anidados) en volcados de memoria utilizando técnicas de introspección de máquinas virtuales independientes de la microarquitectura. Herramientas de análisis de memoria física de alto rendimiento, multiplataforma y multiarquitectura.
| Lanzamiento x64 |
|---|
Quickdumps es un ejemplo del uso de la API de inVtero.net para extraer y validar la memoria física.
La forma en que inicializamos nuestra traducción de direcciones virtuales a físicas no depende del formato del archivo de entrada. Cualquier .DMP, .RAW, .DD debería estar bien. Desafortunadamente, existe un gran problema: si el formato de captura subyacente utiliza algún tipo de almacenamiento de extensiones (es decir, no consume almacenamiento físico para páginas NULL o NO PRESENTES), su kilometraje puede variar. Hay muchas herramientas para convertir volcados de memoria y volatilidad; rekal son algunos buenos lugares para comenzar. MAPA DE BITS. Los archivos DMP están en proceso para facilitar el análisis de los liveumps (actualmente, las cosas funcionan mejor si realiza una pantalla azul iniciada manualmente con un volcado completo configurado o utiliza una herramienta de tipo dd sin formato de terceros).
Se utilizan varios conceptos para garantizar que interactuemos con el usuario solo cuando sea necesario. De manera similar, para el proyecto Actaeon github @eurecom-s3/actaeon, un objetivo principal es ubicar y aprovechar la página VMCS para ubicar el EPTP (puntero de tabla de páginas extendida) configurado que se necesita para ubicar las páginas físicas que pertenecen a un instancia del sistema operativo invitado. Posteriormente, Google @google/rekall rekal implementó una implementación más amplia que requiere que el usuario ejecute un módulo del kernel de Linux en el sistema que origina un volcado de memoria determinado y que está destinado a construir un perfil especializado que se puede usar para luego importar a un rekal local. perfil que le permitirá aislar/extraer la memoria del huésped de un volcado de host físico.
Durante CanSecWest/DC22 presenté una técnica de alta calidad (basada en la interacción de capa más baja entre las capas de CPU y SO mm) para identificar cualquier proceso que se ejecuta en un sistema mediante la inspección de instantáneas de memoria física. Este mecanismo se basa en lo que se llama el puntero automático (Windows) o puntero de directorio de página recursivo (*BSD) que siempre se espera que se encuentre (a menos que su sistema Windows tenga un mm muy modificado/parcheado, o simplemente un kernel personalizado para * BSD). El resultado neto de esto es que conocemos todos los valores de registro CR3 dados. Dado que el VMCS contiene al menos 1 valor CR3 conocido (se puede emular o reasignar dinámicamente un segundo), tenemos confianza en que se puede realizar un volcado de memoria completo sin saber nada sobre la versión del sistema operativo subyacente (por ejemplo, XP(64 bits)->Win2016 son consistente) o microarquitectura.
¡La fuerza bruta siempre gana al final del día! O eso escuché... En cualquier caso, si se encuentra un mapeo VMCS desconocido (índice EPTP), los volcados rápidos emitirán un conjunto de valores/índices posibles. La lista suele ser pequeña, de 10 a 20 como máximo. Una próxima característica es automatizar los intentos para cada valor posible hasta que se encuentre uno que "funcione". Esto debería garantizar que trabajemos para las próximas microarquitecturas de CPU sin ningún cambio de código (o probablemente configuraré algunas clases que las especifiquen para hacer la vida más fácil). De cualquier manera, la fuerza bruta debería ser bastante rápida. Intento aprovechar al máximo las CPU de múltiples núcleos, por lo que si tienes núcleos adicionales, es probable que se ejerciten si analizas un volcado enorme con muchas máquinas virtuales.
Ejemplo ejecutado desde una computadora portátil:
Process CR3 [00000002DD41F000] File Offset [0000000293A12000] Diff [FFFFFFFFB65F3000] Type [Windows]
159 candiate process page tables. Time so far: 00:01:01.4826693, second pass starting. rate: 32588.149 MB/s
Hypervisor: VMCS revision field: 16384 [00004000] abort indicator: NO_ABORT [00000000]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
Hypervisor: Windows CR3 found [00000000016A0000)] byte-swapped: [00006A0100000000] @ PAGE/File Offset = [00000001262DA000]
[435][00000000006F0054]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [00000001308D3000]
[14][000000007433301E]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [0000000130AD1000]
[14][000000007433301E]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [00000001314CF000]
[14][000000007433301E]
Hypervisor: VMCS revision field: 0 [00000000] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000016A0000)] byte-swapped: [00006A0100000000] @ PAGE/File Offset = [0000000160643000]
[106][00000000001E001C]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [0000000195922000]
[14][000000007433301E]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [00000001959A3000]
[14][000000007433301E]
159 candiate VMCS pages. Time to process: 00:02:51.8973861
Data scanned: 34,171,150,654.00Second pass done. rate: 1277.967 MB/s▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
grouping and joinging all memory
Scanning for group correlations
MemberProces: Groupt 1 Type [Windows] Group Correlation [100.000 %] PID [1AB000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [16A0000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [1FCA000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [62AB000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [34CE8000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [37300000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [7DCC6000]
Finished Group 1 collected size 48 next group
Scanning for group correlations
MemberProces: Groupt 2 Type [FreeBSD] Group Correlation [100.000 %] PID [65C8000]
MemberProces: Groupt 2 Type [FreeBSD] Group Correlation [100.000 %] PID [6B51000]
MemberProces: Groupt 2 Type [FreeBSD] Group Correlation [100.000 %] PID [6CC9000]
En el ejemplo anterior, el EPTP de VMWARE está en el índice 14 en su VMCS.
* Veremos si elimino este, pero en este momento solo está volcando la memoria del kernel de cada capa. Trabajando en el espacio de usuario desde las máquinas virtuales del sistema operativo invitado.
Muchos TODOS, pero los agregaré lo antes posible. El problema principal en este momento es que dudo mucho en agregar cualquier cosa que incluya el sistema operativo, incluso si fuera de gran ayuda. Creo que hay suficiente contexto disponible para evitar agregar dependencias lógicas del sistema operativo. Me gusta cómo Rekal promete esto, pero parece que su archivo de perfil también es muy grande, así que un poco de ambos.
Aún queda un poco de limpieza por hacer. Esto todavía es alfa, pero se desarrollará activamente.
Amplíe a tipos de EPTP más conocidos para que no se requiera fuerza bruta
Vamos a crear un índice de mapa de bits PFN para determinar automáticamente las ejecuciones (actualmente, si intentas volcar/consultar algo después de una ejecución, causará problemas o se perderá, etc. Agregaremos esto a continuación para garantizar que obtengamos volcados 100 % completos). .
Abstenerse de utilizar estructuras lógicas del sistema operativo para soportar el análisis de la memoria. Es probable que un atacante pueda manipular la mayoría de las estructuras, datos, códigos y objetos de las capas del sistema operativo para desviar los esfuerzos de un analista.
Próxima funcionalidad para representar un mapa de integridad para páginas de códigos que se pueden asignar nuevamente a valores hash de bloque/página criptográficamente seguros (es decir, SHA256 o TIGER192). Nuestros resultados indican tasas de verificación anteriores a Win10 superiores al 99 %, mientras que la memoria volátil posterior a Win10 es prácticamente 100 % comprobable. Esto elimina las conjeturas sustanciales y las incógnitas debido al manejo/revisión/desmontaje manual tradicional de la memoria al intentar detectar/analizar varios gigabytes de entrada.
Documentación
Implementación de GUI
