Algunas dudas sobre Drivers...

[Vaagish]

Hola amigos! Bueno, no quiero quedar pesado, ni aparentar que no he leído nada sobre el tema, pero por mas que busque diferentes fuentes ninguna me despoja de la duda sobre algunos asuntos de los drivers, creo, en parte por no manejar el ingles fluidamente. Si alguien me da una mano sobre algunos conceptos, se lo agradecería mucho. Voy a poner una serie de nombres, algunas con lo que yo entiendo y otras para que si alguien quiere/puede me las "traduzca" al "entendible" 

IRP: The IRP structure is a partial opaque structure that represents an I/O request packet.

IRP es una estructura que se utiliza para la comunicacion de los drivers

IO_STACK_LOCATION: The IO_STACK_LOCATION structure defines an I/O stack location, which is an entry in the I/O stack that is associated with each IRP.

Alguien me puede aclarar esto??

IRP Major Function: Each driver-specific I/O stack location (IO_STACK_LOCATION) for every IRP contains a major function code (IRP_MJ_XXX)

IRP Major Function es un vector de punteros de funciones que necesita nuestro driver, entiendo que eso es asi, pero no porque.

IoCreateDevice: WDM drivers, other than bus drivers, call IoCreateDevice to create their device objects. Most WDM drivers create their device objects from within their AddDevice routines. Some drivers, such as disk drivers that must respond to drive layout IOCTLs, call IoCreateDevice from a dispatch routine.

Por lo que entiendo aca,, los drivers en windows llaman a IoCreateDevice para crear sus device objects, pero entonces, un driver en windows siempre es considerado como un dispositivo, o "representante" de uno? Aunque sea un driver que no interactue con un dispositivo siempre sera considerado un dispositivo? ( Esta parte me interesa, porque tengo un error de concepto me parece )

Bueno, tengo mas dudas, pero creo que se pueden ir aclarando si puedo despejar un poco estas primero..
Muchas gracias de antemano! Saludos!

[x64core]

Citar
IRP: The IRP structure is a partial opaque structure that represents an I/O request packet.
IRP es una estructura que se utiliza para la comunicacion de los drivers
Citar

Estructura que es creada por el IO manager el cual lo pasa por todos lo drivers cargados en el kernel,
por ahi en esos libros que supongo que estas leyendo recuerdo que hay una imagen que muestra un diagrama sobre esta estructura y como se relaciona
del IO manager y los drivers.

IO_STACK_LOCATION: The IO_STACK_LOCATION structure defines an I/O stack location, which is an entry in the I/O stack that is associated with each IRP.
Alguien me puede aclarar esto??
Citar

Es la definicion de la estructura que estamos hablando en la pregunta 1.

IRP Major Function: Each driver-specific I/O stack location (IO_STACK_LOCATION) for every IRP contains a major function code (IRP_MJ_XXX)
IRP Major Function es un vector de punteros de funciones que necesita nuestro driver, entiendo que eso es asi, pero no porque.
Citar

Es la funcion que sera llamada a los drivers, todo driver tiene un array de punteros que corresponde a cada codigo de funcion para cada proposito.

IoCreateDevice: WDM drivers, other than bus drivers, call IoCreateDevice to create their device objects. Most WDM drivers create their device objects from within their AddDevice routines. Some drivers, such as disk drivers that must respond to drive layout IOCTLs, call IoCreateDevice from a dispatch routine.
Por lo que entiendo aca,, los drivers en windows llaman a IoCreateDevice para crear sus device objects, pero entonces, un driver en windows siempre es considerado como un dispositivo, o "representante" de uno? Aunque sea un driver que no interactue con un dispositivo siempre sera considerado un dispositivo? ( Esta parte me interesa, porque tengo un error de concepto me parece )

Driver son los controladores de los dispositivos, si un driver es cargado para un proposito legitimo es porque controlara un dispositivo en general, mirar
algunos dispositivos como video camaras instalan driver(s) para controlar y manipular el dispositivo ( camara de video en este caso ). ademas sirve para comunicarse
de modo usuario a modo kernel.

[Vaagish]

Primero que nada, muchas gracias x64Core! Pensé que ya nadie me iba a responder, hoy ya no tenia ni ganas de leer el libro, esto me anima 

Estructura que es creada por el IO manager el cual lo pasa por todos lo drivers cargados en el kernel

Entonces todos los irps son enviados a todos los drivers.. por eso había leido en el tuto "Principios básicos de desarrollo de drivers en Windows"

Es decir, cuando una aplicación en modo usuario llame a algunas de estas funciones:

CreateFile
CloseHandle
WriteFile
ReadFile
DeviceIoControl

se llamara a tu driver.

Lo que esta pasando es que cuando se llama a una API Nativa, la IRP pasa por nuestro driver, entonces ahi podemos modificar el resultado, justo como un hook, no?

por ahi en esos libros que supongo que estas leyendo recuerdo que hay una imagen que muestra un diagrama sobre esta estructura y como se relaciona

Si que lo estoy leyendo, pero no recuerdo haber visto el diagrama, y si lo vi no lo abre entendido, ahora lo voy a repasar..

Driver son los controladores de los dispositivos, si un driver es cargado para un proposito legitimo es porque controlara un dispositivo en general

Ok! Eso me aclara bastante, porque había leído que hay diferentes tipos de drivers, pero entonces siempre debería ser esa la función de un driver..

Muchas Gracias! Saludos!!

[x64core]

Citar
Es decir, cuando una aplicación en modo usuario llame a algunas de estas funciones:

CreateFile
CloseHandle
WriteFile
ReadFile
DeviceIoControl

se llamara a tu driver.
Lo que esta pasando es que cuando se llama a una API Nativa, la IRP pasa por nuestro driver, entonces ahi podemos modificar el resultado, justo como un hook, no?

Lo que los rootkits hacen es reemplazar el puntero del IRP Handler, por ejemplo para ocultar archivos reemplazan el puntero correspondiente en el driver responsable del NTFS/FAT.

[Vaagish]

Ok,, voy a estudiar eso, suena interesante.. Entonces, cuando se envía un IRP, se envía a todos los drivers, no? (Me quede con esa idea)

EDIT: O sea, si mi driver tiene un Major Function que pueda recibir ese IRP, no?

[x64core]

Ok,, voy a estudiar eso, suena interesante.. Entonces, cuando se envía un IRP, se envía a todos los drivers, no? (Me quede con esa idea)

EDIT: O sea, si mi driver tiene un Major Function que pueda recibir ese IRP, no?

Si tu driver esta añadido a la cadena de drivers, sí (ya veras como va).
De lo contrario capturara solo los de tu device.

[Vaagish]

Hola! Yo molestanto otra vez..

Loading the Windows NT kernel[edit]
The operating system starts when certain basic drivers flagged as "Boot" are loaded into memory. The appropriate file system driver for the partition type (NTFS, FAT, or FAT32) which the Windows installation resides are amongst them. At this point in the boot process, the boot loader clears the screen and displays a textual progress bar, (which is often not seen due to the initialization speed); Windows 2000 also displays the text "Starting Windows..." underneath. If the user presses F8 during this phase, the advanced boot menu is displayed, containing various special boot modes including Safe mode, with the Last Known Good Configuration, with debugging enabled, and (in the case of Server editions) Directory Services Restore Mode. Once a boot mode has been selected (or if F8 was never pressed) booting continues.
Next, the Windows NT kernel (Ntoskrnl.exe) and the Hardware Abstraction Layer (hal.dll) are loaded into memory. If multiple hardware configurations are defined in the Windows Registry, the user is prompted at this point to choose one.

Ntoskrnl.exe

This system binary is not a native application (in that it is not linked against ntdll.dll), instead containing a standard main entry point, a stub that calls the kernel initialization function but is unused as the OS loader (internal symbol OSLOADER) calls KiSystemStartup directly. While ntoskrnl.exe is not linked against ntdll.dll, it is linked against bootvid.dll, hal.dll and kdcom.dll. Because it requires a static copy of C Runtime objects it depends on, the executable is usually about 2MB in size.

Bueno, estos dos archivos no se cargan de forma "Normal", no? (Ntoskrnl.exe y hal.dll) Porque el loader de windows aun no esta cargado en memoria, aparte, el Ntoskrnl.exe, muchas veces esta definido como "el mismo kernel" (Aunque esto no es del todo cierto, o sea, no es solo ese archivo el núcleo de windows), lo que me da a pensar esto, es que gran parte del núcleo de windows es un exe, como todo programa de windows,, es esto así?

Saludos!!

[Eternal Idol]

Si, es un PE, algo que podes comprobar de varias maneras.

[Vaagish]

Ajam.. interesante... lo voy a ver con el Pe Explorer.. por ende, supongo que puedo ver que funciones exporta..
En realidad, estaba por poner que mas que una duda, una confirmación.. por tener extensión .exe, esperaba que fuera un PE, pero no se carga como los demas PE's.. otra cosa es que ese .exe no se muestra en la lista de procesos, (por ser el mismo kernel, calculo..)
Se podra inyectar? 

[Eternal Idol]

¿Inyectar? ¿Que? ¿Codigo? Si, aunque en versiones modernas esta el PatchGuard.