Todo el proceso de ejecución de la función CreateFile

La función CreateFile ejecuta todo el proceso

Proceso Ring3 de CreateFile

HANDLE CreateFileA(
  LPCSTR                lpFileName,
  DWORD                 dwDesiredAccess,
  DWORD                 dwShareMode,
  LPSECURITY_ATTRIBUTES lpSecurityAttributes,
  DWORD                 dwCreationDisposition,
  DWORD                 dwFlagsAndAttributes,
  HANDLE                hTemplateFile
);

CreateFile es una función muy común y común. Al escribir código en VS, o F8 durante la depuración, a nadie le importa qué proceso atraviesa un CreateFile y qué tipo de mecanismo operativo para abrir el archivo. Interesado en investigarlo hoy. La investigación debe estudiarse a fondo, de modo que sienta un poco de placer cuando llame a cada API en el futuro.
Inserte la descripción de la imagen aquí
CreateFile en Kernel32.dll. Solo una oración de jmp, esta instrucción de salto dinámico indirecto. A través de X64dbg, puede ver que saltó a Kernelbase32.dll.
Inserte la descripción de la imagen aquí
Agregue el símbolo "/ ?? /" a la ruta del archivo abierto en Kernelbase32.dll y ejecute el código __GSHandlerCheck en la figura siguiente después de la función CreateFileInternal.
Inserte la descripción de la imagen aquí
Este código GSHandlerCheck no es muy claro y se siente menos importante. Debería ser un trabajo preparatorio para ingresar a Ring0. Estudie más cuando tenga tiempo.
Inserte la descripción de la imagen aquí
Finalmente, se llama a la función NtCreateFile. El siguiente paso irá a ntdll.dll para ejecutar NtCreateFile. Para algunas API bajo Ring3, eventualmente corresponderá a una función Ntxxx (es decir, API nativa) en Ntdll.dll. Por ejemplo, este CreateFile finalmente llama a la función NtCreateFile en Ntdll.dll. NtCreateFile finalmente pone el número de servicio del sistema en EAX, y luego una dirección almacenada en 7FFE0300 del sistema CALL (más sobre eso más adelante), ingresa al kernel, desde Ring3- > Ring0, y finalmente obtenga la dirección del kernel del servicio del sistema correspondiente con el mismo nombre a través del EAX entrante en Ring0.
Inserte la descripción de la imagen aquí
Para NtCreateFile, es lo mismo que ZwCreateFile. El programa entrará en la llamada al sistema en la capa ntdll y entrará en la capa Ring0.
La imagen de arriba 0x55 es el número de llamada SSDT de la función NtCreateFile en este sistema. Este sistema admite la instrucción syscall, por lo que la versión anterior de int 0x2E no se ejecutará para ingresar al kernel del sistema. La tabla SSDT es un almacenamientoPuntero de funciónLas tablas y estos indicadores de función apuntan a rutinas de servicio importantes del sistema. La importancia de esta tabla es muy alta, si un programa malicioso engancha esta tabla y modifica la rutina de servicio falsa proporcionada por la dirección de la rutina de servicio, entonces puede hacer algunas cosas malas.
Inserte la descripción de la imagen aquí
Como se muestra en la figura anterior, después de ingresar a Ring0, muchos registros han cambiado. Hasta ahora, nuestro X64dbg ya no se puede depurar y no podemos profundizar. Cambiar la herramienta Windbg, OD para depurar programas de 32 bits es lo mismo, no se puede profundizar en la capa del kernel syscall para continuar el seguimiento.

Continuar rastreando el proceso Ring0

El siguiente proceso es: KiFastSystemCall-> sysenter-> KiFastCallEntry-> Buscar SSDT y llamar en el pasado.Los estudiantes interesados ​​pueden buscar funciones relacionadas en WRK para recorrer el proceso.
Bienvenido al espacio de direcciones del kernel de 0x80000000-0xFFFFFFFF, el depurador está obsoleto, pero podemos usarloConductor BTSContinúe capturando el proceso de ejecución y rastrearlo.
Hay demasiados GANCHOS y contramedidas en Ring3, especialmente SSDT HOOK, que es el más común y fácil de detectar (compare directamente la copia codificada en el kernel con la dirección del kernel en la memoria). Pero una vez que el adversario (si es un rootkit de nivel de kernel) instala el controlador en la máquina, la confrontación de CreateFile es una confrontación de nivel Ring0.
Desde Pchunter, puede ver que la ubicación del archivo SSDT está en ntoskr.exe (si no ha sido conectado). También puede encontrar el número de llamada SSDT de NtCreateFile.
Inserte la descripción de la imagen aquí
Busque la implementación de NtCreateFile en ntoskrnl.exe. Tenga en cuenta que este NtCreateFile no tiene nada que ver con NtCreateFile de Ring3. Aunque tienen el mismo nombre, están en dos mundos diferentes, por lo que no hay ningún error (como usted y su antimateria) ... ). La función IopCreateFile se vuelve a llamar en la función Obviamente, la historia de CreateFile es todavía muy larga.
Inserte la descripción de la imagen aquí
No más tonterías, la figura anterior es el resto del flujo de llamadas. La figura anterior utiliza la función IopCreateFile del administrador IO. Función Inline Hook IopCreateFile ver ver foro de nieve: Función Inline Hook IopCreateFile . La función de realización común de IoCreateFile en el desarrollo de controladores es IopCreateFile (iosubs.c).

Después de esto, está la función del controlador de administración de archivos. El administrador de E / S actúa como interfaz entre el código de modo de usuario y el controlador. El controlador procesará o reenviará el IRP enviado por el administrador de E / S de manera segura y estable, y finalmente completará la interacción con la capa de abstracción de hardware hal.dll, completará y retroalimentará la solicitud de operación CreateFile.

para resumir

Inserte la descripción de la imagen aquí
Se puede ver que todo el proceso de llamar a la función CreateFile implica demasiado conocimiento de la plataforma Windows. La interfaz de la API de Win32, el principio y la estructura del kernel, el desarrollo de controladores, etc. están involucrados. A primera vista, parece que el proceso de abrir un archivo en CreateFile es muy complicado, y la E / S del dispositivo de archivo se puede operar directamente con la instrucción de ensamblaje IN OUT. ¿Por qué se requiere un proceso tan complicado en Windows? La respuesta es dos palabras:La seguridad. Puede verse que cuanto más maduros y unificados son los productos, mayor es el precio que se paga por la seguridad.
El programa de virus Rootkit puede ENGANCHAR una de las funciones durante cualquiera de los procesos anteriores para llegar a la lectura y apertura del archivo de control (dispositivo). Por eso, desde hace mucho tiempo, el enfrentamiento técnico entre el software de seguridad y el desarrollo de virus no dejará este frente necesario, se ha estado haciendo GANCHO y anti-GANCHO, y acabando con la pugna con que se acabe. La solución tradicional aún permanece en este tipo de confrontación a nivel de funciones.
El aprendizaje no tiene fin y todavía queda un largo camino por recorrer para el estudio y la investigación de Windows.

Supongo que te gusta

Origin blog.csdn.net/qq_43312649/article/details/107796994
Recomendado
Clasificación