El rootkit TDL3 contiene una peculiaridad en su código que se aprecia rápidamente al ser visualizado en un desensamblador: el uso masivo de direcciones de memoria absoluta, sin relocalización, que referencian diferentes offsets de una misma página. La dirección de memoria absoluta es una dirección de memoria virtual válida de kernel, 0xFFDF0000, y el offset al que más veces se hace referencia es +0×308, 0xFFDF0308.
Tras un breve análisis se puede determinar que estas direcciones de memoria son utilizadas como una única variable global en la que el rootkit almacena unos cuantos datos y a los que accede constantemente durante su ejecución.
Ejemplos de uso en el código:
Usando windbg se puede obtener la siguiente información:
En el mapa de direcciones virtuales de Windows x86 32bits esta “misteriosa” dirección virtual pertenece al espacio asignado para uso de HAL:
Aunque en principio es posible continuar el análisis del rootkit sin saber lo que significa esta dirección de memoria y el contenido de la página que referencia, al final, es necesario tener toda la información posible para no perder ningún detalle.
Una búsqueda en Google de la dirección virtual 0xFFDF0000 nos muestra varios documentos y rápidamente damos con la pista definitiva. De todos los resultados destaca un artículo muy interesante publicado hace unos pocos años, de sobra conocido, “Remote Windows Kernel Exploitation Step into the Ring0” de Barnaby Jack. En este documento se muestra detalladamente como construir una shellcode que debe funcionar en kernel y los trucos que podemos utilizar para localizar APIs, zonas de memoria, etc. En una de las secciones del artículo se comenta lo siguiente:
”
… we can store our code within kernel-user-shared memory, officially known as SharedUserData. At 0xFFDF0000 is a writable memory area where we may store our shell code. This memory address is mapped from user land at 0×7FFE0000 and marked read only; these mapped locations are the same on all platforms, so it is a good choice for keeping everything generic. As the data at this memory location is readable from all processes, we are not required to switch into the address space of our target process.
…
“
… we can store our code within kernel-user-shared memory, officially known as SharedUserData. At 0xFFDF0000 is a writable memory area where we may store our shell code. This memory address is mapped from user land at 0×7FFE0000 and marked read only; these mapped locations are the same on all platforms, so it is a good choice for keeping everything generic. As the data at this memory location is readable from all processes, we are not required to switch into the address space of our target process.
…
“
Con esta aclaración todas las dudas quedan despejadas, la “misteriosa” dirección virtual dentro del espacio de kernel se corresponde con la famosa estructura de datos global SharedUserData:
nt!_KUSER_SHARED_DATA.
nt!_KUSER_SHARED_DATA.
Esta página tan peculiar es mapeada en ring0 y ring3 durante la inicialización del sistema (ntoskrnl) en la rutina nt!MiInitSystem():
Utilizando windbg de nuevo se puede comprobar que el doble mapeo es válido y se accede al mismo contenido a través de las dos direcciones de memoria virtual, una de kernel y otra de un proceso de usuario:
Hay que tener en cuenta que SharedUserData es una estructura bastante grande y al ser usada por el sistema y por los procesos de usuario no se puede cambiar el valor de cualquier campo. Los autores del rootkit han tenido esto muy en cuenta y los datos almacenados son “camuflados” en determinados campos o en el espacio restante de la página, evitando así cualquier mal funcionamiento del sistema.
El tipo de datos que guarda el rootkit y para que los usa es otra historia :)
@s21sec
** 
