Partager via

Preparando un entorno de depuración para Windows

  • Article

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.

Dicho esto, vamos al grano. Necesitaremos algunas herramientas, algunos accesorios y un poquito de configuración:

Las herramientas

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:

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:

image

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:

image

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:

   image imageimage

Venga, ¿quién me dice que antivirus tengo instalado en el equipo?

Pronto más.

Saludos.

David Cervigón

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    El hecho de que una máquina sea virtual no implica que un gran número de las operaciones que

  • Anonymous
    January 01, 2003
    Si, y a NT, 2000, 2003 y 2008

  • Anonymous
    January 01, 2003
    Lo cierto es que no son muy comunicativos que se diga. Pero dadas las circunstancias en las que se producen

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Nose para que me meti a leer esto. No entendi nada.

  • Anonymous
    May 28, 2008
    Hola David del antivirus no se pero del fabricante de tu portatil es IBM, Espero ansioso La continuacion de este post. Un Saludo

  • Anonymous
    May 28, 2008
    Es un Lenovo, con reconocimiento de huellas ¿quizá un Lenovo Thinkcentre A60 Athlon 64 X2 3800+ 2000 Mhz?. El antivirus me aventuro a decir que es CA Anti-virus (antes conocido como eTrust EZ Antivirus) Un saludete.

  • Anonymous
    May 28, 2008
    Hola David. El ino_fltr.sys es típico de los antivirus de CA.

  • Anonymous
    May 30, 2008
    ¡La ruta en el registro aplica también para Windows XP Sp3 o es sólo para Vista?