Preparando un entorno de depuración para Windows
Hola
Para contrarrestar un poco el post anterior, y sobre todo teniendo en cuenta que este blog aparece en las Home de TechNet y MSDN, vamos a ver cómo montar un entorno para depurar Windows y sus aplicaciones.
Le llevo dando vueltas a contar este tipo de cosas desde que Juan Garrido empezó a poner algo de información en su blog sobre análisis forense mediante análisis de memoria RAM, y más desde que le vi hacer las demos en vivo y en directo. Sin embargo, las mismas herramientas y similares técnicas se han aplicado tradicionalmente al análisis y resolución de problemas "rebeldes", y es en el entorno en el que yo tradicionalmente me he movido. Así es que este post va dedicado a Silverhack, que seguro que le sabrá sacar provecho.
Antes de nada, advertir que el dominio de este tipo de habilidades no está al alcance de cualquiera, y para eliminar cualquier sospecha de pedantería he de dejar claro que me aparté de este camino hace algunos años, aunque he intentado en lo posible no perderlo de vista. Hay un montón de excelentes profesionales que nunca han necesitado ni necesitarán de este tipo de conocimientos, mas que nada porque cada vez más los propios productos implementan capacidades de autodiagnóstico bastante potentes. No obstante, hay dos lecturas indispensables para, además de adentrarse en el camino, evitar decir tonterías más a menudo de lo deseable, y ser capaces de calcular la profundidad de las aguas sobre las que nos encontramos cuando hablamos de arquitectura de sistemas operativos.
- Windows Internals, Fifth Edition, como no, de los señores Mark Russinovich y David Solomon (me cachis, yo tengo sólo la cuarta edición, voy a tener que hablar seriamente con mi jefe)
- Advanced Windows Debugging, de Mario Hewardt y Daniel Pravat (The Addison-Wesley Microsoft Technology Series; ISBN-10: 0321374460)
Dicho esto, vamos al grano. Necesitaremos algunas herramientas, algunos accesorios y un poquito de configuración:
Las herramientas
- Las Windows Debugging Tools: Como su nombre indica, agrupan a un buen numero de utilidades y depuradores tanto gráficos como por línea de comandos. Su fichero de ayuda es simplemente apabullante en cantidad de información, y da una idea rápida de lo amplio que es este campo.
- Process Explorer, de Sysinternals: de nuevo, un buen regalo del amigo Mark, y la herramienta que todo el mundo debería usar antes de lanzarse a repetir como un loro "Windows Vista va lento", o al menos hacerlo con un poco de criterio.
Lo cierto es que en lugar de descargar únicamente el Process Explorer, lo mejor es bajarse toda la Sysinternals Suite y pasarse un rato echándolas un vistazo para conocer su utilidad. Tarde o temprano nos pueden acabar haciendo falta.
Los Símbolos de Depuración:
Los símbolos (symbols) son ficheros que almacenan información acerca de los nombres de las funciones y variables que se utilizan en un cierto binario. Los produce el linker como un fichero aparte ya que para el propio fichero binario esta información no es necesaria a la hora de funcionar correctamente. Microsoft, muchos otros fabricantes de software, producen dos tipos de símbolos, los privados para uso interno, y los públicos que contienen un subconjunto de la información. También se pueden encontrar (por ejemplo en las suscripciones a MSDN) "Checked builds" de Windows, que son compilaciones especiales del sistema operativo que incluyen código adicional para trazado y depuración. Para estas versiones existen también los paquetes de símbolos "checked" correspondiente, pero por lo general estos no serán necesarios para analizar los sistemas desplegados en el mundo real.
Cierto es es que la información completa de lo que hace el software está en su código fuente. Sin embargo, cuando hablamos de millones de líneas de código, es falso pensar que vamos a encontrar lo que buscamos leyéndolo en un editor de texto. En un sistema operativo moderno en funcionamiento, hay en todo momento infinidad de interdependencias y llamadas entre múltiples de sus componentes que hacen que no sepamos dónde ir a buscar. En esos caso, se depura. Y ciertamente esto te llega a dar una idea muy exacta de qué esta haciendo el sistema, y te dice en que parte del código tienes que ir a mirar exactamente, si es que tienes acceso a el.
Microsoft pone al alcance de todo el mundo los símbolos de depuración de Windows principalmente de dos maneras:
- Mediante un servicio web que consumirá directamente el depurador: https://msdl.microsoft.com/download/symbols
- Paquetes de descarga individuales. Deberemos elegir aquellos que correspondan exactamente con la versión y plataforma del sistema operativo que se pretende depurar. Están disponibles aquí: https://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx.
Configuración mínima:
Podemos especificarle explícitamente al depurados dónde debe ir a buscar los símbolos, pero es mucho más sencillo definirlo mediante la creación de la variable de entorno _NT_SYMBOL_PATH.
Lo que queremos es que cuando el depurador busque un símbolo lo haga en las carpetas donde tenemos almacenado los que hemos descargado de la web. Si no lo encuentra, que busque en una carpeta de cache, y si no hay suerte, que vaya a la librería online a descargarlo y lo almacene en dicha cache para posteriores consultas.
Por ejemplo: En mi caso trabajo con Windows XP SP2 y SP3, Windows 2003 SP2, Windows Vista SP1 y Windows Server 2008. Hay que tener en cuenta que el mismo paquete de símbolos vale tanto pata Vista SP1 y Windows Server 2008, y lo mismo para Windows XP SP2 x64 y Windows Server 2003 x64.
Mi carpeta C:\Symbols se podría parecer a esto:
- C:\Symbols\Symbols (la carpeta que hará de Cache)
- C:\Symbols\W2K3SP2-x86
- C:\Symbols\W2K3SP2-x64
- C:\Symbols\XPSP2
- C:\Symbols\XPSP3
- C:\Symbols\W2K8-VistaSP1-x86
- C:\Symbols\W2K8-VistaSP1-x64
Con lo que defino:
set _NT_SYMBOL_PATH = C:\Symbols\W2K3SP2-x86;C:\Symbols\W2K3SP2-x64;C:\Symbols\XPSP2;C:\Symbols\XPSP3;C:\Symbols\W2K8-VistaSP1-x86;C:\Symbols\W2K8-VistaSP1-x64;srv*C:\Symbols\Symbols*https://msdl.microsoft.com/download/symbols
o también:
La carpeta C:\Symbols podría una ser perfectamente carpeta compartida de la red. Bastaría sustituir C:\Symbols por \\Server\Symbols. Otra opción podría haber sido combinar todas esas carpetas en un almacén de símbolos (SymStore), que además puedo compartir a su vez en la red. Combinaciones muchas, y cada maestrillo con su librillo. Consultad "Symbol path" en la "Debugging Help" (la ayuda de las "debugging tools")
En el caso de Process Explorer, NO se consume esta variable de entorno, por lo que tenemos que hacer la configuración a mano dentro de la herramienta. En el menú "options", opción "Configure Symbols" cambiaremos el path a Dbghelp.dll que viene por defecto para apuntar a la que se incluye en las Debugging Tools y escribiremos el mismo path que hemos puesto para _NT_SYMBOL_PATH:
Por último, puede ser interesante conectar Process Explorer con uno de los depuradores incluidos en las Debugging Tools, de manera que podamos usar la opción "Debug" que aparece al hacer clic con el botón derecho del ratón sobre cualquiera de los procesos que aparecen en la lista. Para ello configuramos el Depurador por defecto del sistema, mediante una entrada del registro (ojo, con UAC activado, ejecutadlo explícitamente como administrador):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger = "C:\Program Files\Debugging Tools for Windows (x64)\WinDbg.exe" -p %ld -e %ld
Comprobando el entorno:
Para ello, vamos a utilizar Process Explorer, comparando la información que ofrece en un sistema normal con la de otro configurado tal y como hemos explicado hasta ahora. A la izquierda, las propiedades del proceso System sin haber definido el path de los símbolos. A la derecha, la información que se muestra si se están utilizando los símbolos:
Venga, ¿quién me dice que antivirus tengo instalado en el equipo?
Pronto más.
Saludos.