Introducción a la programación de drivers en Windows

1. Nociones básicas

En este documentos voy a intentar hacer una introducción a la programación de drivers en Windows. Cabe decir que los temas que se van a exponer aquí son una minúscula parte de lo que realmente se puede hacer con drivers. Antes de empezar nada, primer tenemos que saber realmente que es lo que hace un driver (en este caso, seran módulos del Kernel, aunque lo llame driver), por esto este primer artículo sobre nociones básicas.

Antes de empezar este documento, quiero dar las gracias públicamente a Mek (®®) ya que se tomó la molestia de enseñarnos a programar drivers por un proyecto que teníamos en mente.

1.1 Herramientas necesarias

Para programar drivers no se usa el compilador del Dev ni del MVC++ ni de ningun otro, vamos a usar la DDK (Driver Development Kit), aunque se pueden configurar tanto el MVC++ cono el Dev para usar el compilador del DDK, aunque yo prefiero programarlo directamente con el compilador del DDK.

Una vez tengan el DDK, tenemos que instalarlo, una vez echo esto, se van a Inicio / Todos los programas y buscan el DDK que se instaló, una vez hay tienen que ir a Build Environments, desde hay pueden seleccionar el que quieran, aunque yo recomiendo usar Win XP Free Build Environment (Pueden moverlo al escritorio ya que lo van a usar siempre para compilar, mas info sobre el Build Environment aqui). Para compilar, lo que tienen que hacer es crear una carpeta y dentro meter el codigo (main.c, por ejemplo) y un archivo SOURCES y un MAKEFILE.

El SORCES tiene que se así:

Citar

TARGETNAME=prueba
TARGETPATH=.
TARGETTYPE=DRIVER

SOURCES=main.c

Donde prueba es el nombre del driver que se generará y main.c es el archivo con el código fuente, no tienen que modificar nada más.

El MAKEFILE es siempre el mismo:

Citar

!INCLUDE $(NTMAKEENV)\makefile.def

Una vez tengamos esto, ejecutamos el Win XP Free Build Environment y se nos abrirá una consola, cambiamos el directorio actual con el comando CD, una vez situados dentro de la carpeta donde estan los 3 archivos (como mínimo), tenemos que escribir:

build -cZ

Esto se encarga de compilar y enlazar (linkear) el archivo, si ha habido errores nos lo va a marcar. Si no ha habido errores, nos va a generar el driver dentro de \i386 (se genera una carpeta dentro de la del proyecto). Una vez echo esto, el trabajo de la DDK se puede dar por concluido.

El tema de las herramientas no a terminado, ahora nos falta, como mínimo, una herramienta para cargar el driver y otra para ver los mensajes que el driver nos envía. Ya que un driver no se ejecuta con una consola como los archivos de C/C++ o con una ventana, para poder ver los mensajes que nos envía debemos tener una herramienta adicional.

DebugView: Como su nombre indica, esta herramienta sirve para ver los mensajes que se enviar a través de debug (con el comando DbgPrint). Aunque no solo esta orientada a modo kernel, también sirve para aplicaciones de modo usuario.

OSRLoader: Aunque hay otras, esta es la que uso para cargar los drivers, utiliza el método de cargar lo drivers como servicios, primero seleccionan el driver, registran el servicio y lo ejecutan, una vez terminado, lo pueden parar y para no dejar rastro en el registro pueden eliminar el servicio, aunque esto es opcional.

WinDbg: (Opcional) Sirve para poder analizar la memoria del kernel, es una herramienta que recomiendo aprender su uso, ya que se puede sacar muchísima información (Por ejemplo, la información sobre la Eprocess se saca con esta herramienta).

IceSword: (opcional) Esta herramienta te permite ver los hooks en la SSDT entre otras cosas, aunque ya se que no es la mejor herramienta anti-rootkit, la recomiendo ya que te muestra la dirección original de la API hookeada, el Rootkit Unhooker no lo hace.

1.2 Modo kernel y modo Usuario

Los Ring's (Anillos) de la imagen, son privilege rings (anillos de privilegios), y como ven, los que tienen mas privilegios están en el corazón (Ring0) y los que menos, al exterior (Ring3). Las aplicaciones que ejecutamos en nuestro PC, estan todas en Ring3, hay algunas que tienen una parte en Ring3 y otra en Ring0 (Anti-Virus, Firewalls). Esta mezcla entre modo usuario y modo kernel es que en modo usuario esta muy limitado en cuanto a privilegios.

El kernel de Windows incorpora dentro del modo usuario un Subsistemas de Ambiente Protegido, esto significa que controla los errores en los procesos, lo que a su vez implica, que si se produce un error en algún programa, este puede ser descargado de memoria sin provocar en el sistema operativo ningún tipo de error (dependiendo de que aplicación tenga el error, evidentemente). En modo Kernel no existe esta protección, lo que provoca que si un driver tiene un error, el sistema operativo se ve obligado a reiniciar el PC.

Los procesos que se ejecutan dentro de modo usuario, poseen memoria virtual, eso significa que la posición de memoria 0x00457ab no es la misma posición físicamente, esto lo maneja el Kernel de windows, para impedir que otros procesos escriban o modifiquen datos de otro procesos. Los drivers en cambio se ejecutan dentro de la memoria física, esto equivale a que es posible escribir en la memoria de otro drivers y en el mismo kernel, aunque alguna paginas de memoria tengan protección de escritura (que se puede eliminar).

Los programas en modo usuario, hacen función de las API's, estas, en sus rutinas llaman a las API's nativas, que son las que ejecuta el kernel. Esto implica, que si se hookea una API, se puede cambiar la información que van a recibir todos los procesos que llamen a esa API.

1.3 Documentación interesante

Esta breve introducción al modo kernel y al modo usuario es muy corta, para una mayor información, pueden buscar en internet o comprarse algunos libros que voy a menciona ahora, donde se explica perfectamente.

- Microsoft Windows Internals (4th Edition)
- Rootkits: Subverting the Windows Kernel

Para temas sobre rootkits pueden visitar la pagina : www.rootkit.com
Para charlar sobre modo kernel, pueden visitar el foro de SysInternals: http://forum.sysinternals.com