Tutoriales y Manuales
Entradas Mensuales
-
►
2024
(Total:
1110
)
- ► septiembre (Total: 50 )
-
►
2023
(Total:
710
)
- ► septiembre (Total: 65 )
-
►
2022
(Total:
967
)
- ► septiembre (Total: 72 )
-
►
2021
(Total:
730
)
- ► septiembre (Total: 56 )
-
►
2020
(Total:
212
)
- ► septiembre (Total: 21 )
-
►
2019
(Total:
102
)
- ► septiembre (Total: 14 )
-
►
2017
(Total:
231
)
- ► septiembre (Total: 16 )
-
►
2016
(Total:
266
)
- ► septiembre (Total: 38 )
-
►
2015
(Total:
445
)
- ► septiembre (Total: 47 )
-
►
2014
(Total:
185
)
- ► septiembre (Total: 18 )
-
►
2013
(Total:
100
)
- ► septiembre (Total: 3 )
-
►
2011
(Total:
7
)
- ► septiembre (Total: 1 )
Blogroll
Etiquetas
seguridad
(
396
)
privacidad
(
364
)
google
(
355
)
ransomware
(
341
)
vulnerabilidad
(
308
)
Malware
(
267
)
Windows
(
246
)
android
(
246
)
tutorial
(
244
)
cve
(
240
)
manual
(
229
)
software
(
206
)
hardware
(
197
)
linux
(
128
)
twitter
(
117
)
ddos
(
95
)
WhatsApp
(
92
)
Wifi
(
85
)
cifrado
(
77
)
herramientas
(
76
)
hacking
(
74
)
sysadmin
(
68
)
app
(
65
)
Networking
(
58
)
nvidia
(
53
)
ssd
(
51
)
youtube
(
51
)
firmware
(
44
)
adobe
(
43
)
office
(
41
)
hack
(
40
)
firefox
(
36
)
contraseñas
(
32
)
eventos
(
32
)
antivirus
(
31
)
juegos
(
31
)
cms
(
30
)
flash
(
28
)
anonymous
(
27
)
apache
(
27
)
MAC
(
25
)
programación
(
25
)
exploit
(
23
)
multimedia
(
23
)
javascript
(
22
)
Kernel
(
20
)
ssl
(
19
)
SeguridadWireless
(
17
)
documental
(
16
)
Forense
(
15
)
conferencia
(
15
)
Debugger
(
14
)
lizard squad
(
14
)
técnicas hacking
(
13
)
auditoría
(
12
)
delitos
(
11
)
metasploit
(
11
)
Virtualización
(
10
)
adamo
(
9
)
reversing
(
9
)
Rootkit
(
8
)
Ehn-Dev
(
7
)
MAC Adress
(
6
)
antimalware
(
6
)
oclHashcat
(
5
)
Entradas populares
-
Después de ver qué es una vCPU y la diferencia entre núcleos (cores) e hilos en los procesadores, pasamos a explicar toda la nomenclatura d...
-
Arm Holdings Plc es una empresa británica dedicada al diseño de software y semiconductores . Con sede en Cambridge, Reino Unido, tiene una ...
-
Dado que Unbound DNS en OPNsense no soporta DNS sobre HTTPS (DoH) directamente, fue necesario utilizar el plugin DNSCrypt-Proxy. El plugin t...
Detectando hooks en procesos desde un módulo de Kernel
lunes, 8 de marzo de 2010
|
Publicado por
Mateu Llull
|
Editar entrada
En el presente artículo se va a tratar la detección de API Hooking en procesos mediante un módulo de Kernel. Un breve índice sobre los puntos que voy a tratar:
Diferencia entre manejo de direcciones en modo Kernel y modo Usuario:
-->
Como ya saben, no es lo mismo trabajar con memorias en un módulo de Kernel que en un proceso corriendo en modo usuario. La principal diferencia es que un módulo Kernel trabaja con direcciones físicas y los procesos con memoria virtual. Vamos a ver mas detalladamente que es cada cosa.
Al querer trabajar con procesos desde un driver, se nos presenta la siguiente pregunta: ¿Como trabajamos con memoria virtual desde la memoria física? En el siguiente punto responderemos a esta pregunta.
Trabajando sobre el proceso en Modo kernel
-->
Para manipular la memoria virtual de los procesos, existen varias API's que nos permiten trabajar con ellos, nosotros nos centraremos concretamente en dos de ellas, ObReferenceObjectByHandle y KeStackAttachProcess.
Lo que hacen estas dos API's, a grandes rasgos, es dejarnos trabajar dentro del espacio de memoria virtual del proceso, una vez terminemos de trabajar, tenemos que salir de dicho espacio, para ello usaremos las API's KeUnstackDetachProcess y ObfDereferenceObject.
Este método nos permite tocar lo que queramos dentro del proceso y, aunque sea más peligroso (si hay algún error, nos tira BSOD), podemos tocar lo que queramos sobre cualquier proceso.
Una vez sabemos las API's a usar y lo que nos permiten hacer, pasemos a la parte importante.
-->
-->
La primera columna es la dirección en donde se carga, la segunda, lo que nos interesa, los bytes de la API. Y como estamos en una arquitectura Little Endian, el patrón de bytes es el siguiente: 0x8B55FF8B.
Ahora que ya tenemos la dirección de la API y el patrón, podemos empezar a codear. Lo que tenemos que hacer es lo siguiente:
-->
Una vez hemos obtenido el Handle, la siguiente función que he programado es la que propiamente verifica si hay Hook o no. Pego el código y luego lo explico.
-->
Lo primero que hacemos es referenciar el Handle, una vez hecho esto, nos metemos en el espacio de memoria del proceso con KeStackAttachProcess y una vez estamos dentro del espacio de memoria virtual del proceso, lo único que tengo que hacer es leer la memoria y guardarlo en un Buffer y luego comparar este con los bytes originales que antes habíamos obtenido.
Si quisiéramos reparar el hook, con usar la API RtlMoveMemory podríamos sobrescribir la parte hookeada con sus bytes originales.
El cuerpo del módulo restante es el siguiente:
-->
-->Con esto ya tenemos una pequeña base para programar un programa sencillo para detectar hooks en modo usuario y poderlos reparar desde Kernel, aunque el objetivo de este artículo es el de trabajar en el espacio de procesos desde un módulo de Kernel.
Aquí les dejo la versión en PDF de este artículo: Descarga
Un Saludo
Hendrix.
- Diferencia entre manejo de direcciones en modo Kernel y modo Usuario
- Trabajando sobre el proceso en modo Kernel
- Leyendo memoria y código final
Diferencia entre manejo de direcciones en modo Kernel y modo Usuario:
Como ya saben, no es lo mismo trabajar con memorias en un módulo de Kernel que en un proceso corriendo en modo usuario. La principal diferencia es que un módulo Kernel trabaja con direcciones físicas y los procesos con memoria virtual. Vamos a ver mas detalladamente que es cada cosa.
- Memoria Virtual: La memoria virtual es la memoria que otorga el Sistema Operativo a un proceso para que este pueda trabajar. Se le llama virtual, ya que las direcciones de memoria son asignadas por el SO, con esto, entre muchas otras cosas, se bloquea el acceso en memoria a otros procesos, ya que la memoria que puede alcanzar el proceso solamente pertenece a el mismo (ningún otro proceso es cargado en el espacio de memoria virtual). Muchas veces, al depurar varios programas a la vez, se puede observar que comparten direcciones de memoria (por ejemplo, la dirección 0x0040C8B3) sin embargo, contienen diferentes instrucciones. Esto es debido a la memoria virtual, cada proceso esta encapsulado para que trabaja con sus propias direcciones sin interferir en la ejecución de los demás.
- Memoria física: La memoria física, en términos de Sistemas Operativos y su kernel, es aquella en la cual reside el Kernel del SistemaOperativo una vez el PC es cargado. A diferencia de la Memoria Virtual, el código ejecutado en la memoria física no esta encapsulado, lo que permite que los módulos lean/escriban sobre la memoria que no les corresponde (aunque para ello, se ideó el Registro de Control en los procesadores i386 que, entre otras cosas, protege ciertas páginas de memoria, aunque bien es sabido que esta medida de protección se puede saltar con unas cuantas lineas en ensamblador).
Al querer trabajar con procesos desde un driver, se nos presenta la siguiente pregunta: ¿Como trabajamos con memoria virtual desde la memoria física? En el siguiente punto responderemos a esta pregunta.
Para manipular la memoria virtual de los procesos, existen varias API's que nos permiten trabajar con ellos, nosotros nos centraremos concretamente en dos de ellas, ObReferenceObjectByHandle y KeStackAttachProcess.
Lo que hacen estas dos API's, a grandes rasgos, es dejarnos trabajar dentro del espacio de memoria virtual del proceso, una vez terminemos de trabajar, tenemos que salir de dicho espacio, para ello usaremos las API's KeUnstackDetachProcess y ObfDereferenceObject.
Este método nos permite tocar lo que queramos dentro del proceso y, aunque sea más peligroso (si hay algún error, nos tira BSOD), podemos tocar lo que queramos sobre cualquier proceso.
Una vez sabemos las API's a usar y lo que nos permiten hacer, pasemos a la parte importante.
Leyendo memoria y código final
Lo que he echo yo para mi módulo de Kernel, es crearme una función, la cual se le pasa por parámetro el Handle del proceso con el que trabajaremos, la dirección donde leer y el valor con el que se va a comparar y nos dice si existe hook o no.
En mi aplicación, e “harcodeado” los valores del inicio de la API, ya que el tema principal era el de mirar si hay hook o no, lo ideal sería que desde una aplicación en modo usuario, coger estos valores (cargar la Dll, ir a la dirección donde esta la API y coger los valores requeridos). Para evitar problemas, la longitud del buffer es de 1 int (por ejemplo, un patrón válido sería: 0x8AAAAAAA).
El siguiente paso es obtener el patrón (los primeros bytes de la API original) de la API a verificar, en el ejemplo, hookearé la API MessageBoxExA. Para ello, abrimos el WinDbg, abrimos un ejecutable cualquiera y escribimos lo siguiente:
u MessageBoxA
Lo que nos da el siguiente resultado:
En mi aplicación, e “harcodeado” los valores del inicio de la API, ya que el tema principal era el de mirar si hay hook o no, lo ideal sería que desde una aplicación en modo usuario, coger estos valores (cargar la Dll, ir a la dirección donde esta la API y coger los valores requeridos). Para evitar problemas, la longitud del buffer es de 1 int (por ejemplo, un patrón válido sería: 0x8AAAAAAA).
El siguiente paso es obtener el patrón (los primeros bytes de la API original) de la API a verificar, en el ejemplo, hookearé la API MessageBoxExA. Para ello, abrimos el WinDbg, abrimos un ejecutable cualquiera y escribimos lo siguiente:
u MessageBoxA
Lo que nos da el siguiente resultado:
USER32!MessageBoxExA:
7e3d085c 8bff mov edi,edi
7e3d085e 55 push ebp
7e3d085f 8bec mov ebp,esp
7e3d0861 6aff push 0FFFFFFFFh
7e3d0863 ff7518 push dword ptr [ebp+18h]
7e3d0866 ff7514 push dword ptr [ebp+14h]
7e3d0869 ff7510 push dword ptr [ebp+10h]
7e3d086c ff750c push dword ptr [ebp+0Ch]
7e3d085c 8bff mov edi,edi
7e3d085e 55 push ebp
7e3d085f 8bec mov ebp,esp
7e3d0861 6aff push 0FFFFFFFFh
7e3d0863 ff7518 push dword ptr [ebp+18h]
7e3d0866 ff7514 push dword ptr [ebp+14h]
7e3d0869 ff7510 push dword ptr [ebp+10h]
7e3d086c ff750c push dword ptr [ebp+0Ch]
La primera columna es la dirección en donde se carga, la segunda, lo que nos interesa, los bytes de la API. Y como estamos en una arquitectura Little Endian, el patrón de bytes es el siguiente: 0x8B55FF8B.
Ahora que ya tenemos la dirección de la API y el patrón, podemos empezar a codear. Lo que tenemos que hacer es lo siguiente:
- Entrar en el espacio del proceso con el que trabajar
- Copiar los primeros bytes dentro de un buffer
- Salir del espacio del proceso
- Comparar para ver si hay hook
-->
HANDLE GetHandlByPid(int pid) { HANDLE phandle; OBJECT_ATTRIBUTES oa; CLIENT_ID cid; NTSTATUS ret = 0; __try { InitializeObjectAttributes(&oa,NULL,0,NULL,NULL); cid.UniqueProcess=(HANDLE)pid; cid.UniqueThread=NULL; ret=ZwOpenProcess(&phandle,GENERIC_READ,&oa,&cid); if(!NT_SUCCESS(ret)) { return 0; } } __except(EXCEPTION_EXECUTE_HANDLER) { DbgPrint("Error en el procesamiento de GetHandlByPid"); } return phandle; }
Una vez hemos obtenido el Handle, la siguiente función que he programado es la que propiamente verifica si hay Hook o no. Pego el código y luego lo explico.
-->
NTSTATUS VerificaHook(HANDLE ProcHandle, PVOID Direccion, int CorrectBytes) { PVOID ProcObj=NULL; KAPC_STATE ApcState; POBJECT_TYPE PsProcType = 0; int i=0; int Buff; int Hook = 0; __try { ObReferenceObjectByHandle(ProcHandle, 0x10, PsProcType, KernelMode, &ProcObj, NULL); KeStackAttachProcess(ProcObj, &ApcState); RtlCopyMemory(&Buff, Direccion, sizeof(int)); KeUnstackDetachProcess(&ApcState); ObfDereferenceObject(ProcObj); if(Buff == CorrectBytes) { //DbgPrint("No hay hook"); Hook = 0; } else { //DbgPrint("Hay Hook"); DbgPrint("Buff: %x",Buff); DbgPrint("CrBt: %x", CorrectBytes); Hook = 1; } } __except(EXCEPTION_EXECUTE_HANDLER) { DbgPrint("Error en el procesamiento de VerificaHook"); return -1; } return Hook; }
Lo primero que hacemos es referenciar el Handle, una vez hecho esto, nos metemos en el espacio de memoria del proceso con KeStackAttachProcess y una vez estamos dentro del espacio de memoria virtual del proceso, lo único que tengo que hacer es leer la memoria y guardarlo en un Buffer y luego comparar este con los bytes originales que antes habíamos obtenido.
Si quisiéramos reparar el hook, con usar la API RtlMoveMemory podríamos sobrescribir la parte hookeada con sus bytes originales.
El cuerpo del módulo restante es el siguiente:
-->
#include <ntddk.h> #include "ntifs.h" #include <string.h> #include <stdio.h> void Salir(PDRIVER_OBJECT DriverObject) { DbgPrint("Saliendo"); } NTSTATUS DriverEntry( PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) { HANDLE myHand; int Ret = 0; PVOID Dir = (PVOID)0x7E3D0774; //Direccion de MessageBoxExA int BitesOriginales = 0x8B55FF8B; //Bytes originales de la API DriverObject->DriverUnload=Salir; DbgPrint("Cargado"); myHand = GetHandlByPid(2016); //Obtenemos el Handle if(myHand == 0) { DbgPrint("Error al sacar el Handle"); return STATUS_SUCCESS; } else { DbgPrint("Handle: 0x%x",myHand); } Ret = (int)VerificaHook(myHand,Dir,BitesOriginales); //Verificamos Hooks switch(Ret) { case 0: DbgPrint("No hay hook"); break; case 1: DbgPrint("Hay hook"); break; case -1: DbgPrint("Error en la función"); break; } ZwClose(myHand); return STATUS_SUCCESS;
-->Con esto ya tenemos una pequeña base para programar un programa sencillo para detectar hooks en modo usuario y poderlos reparar desde Kernel, aunque el objetivo de este artículo es el de trabajar en el espacio de procesos desde un módulo de Kernel.
Aquí les dejo la versión en PDF de este artículo: Descarga
Un Saludo
Hendrix.
Enviar por correo electrónico
Escribe un blog
Compartir en X
Compartir con Facebook
Compartir en Pinterest