{"id":816,"date":"2014-02-23T10:30:34","date_gmt":"2014-02-23T13:30:34","guid":{"rendered":"http:\/\/www.maurom.com\/blog\/?p=816"},"modified":"2017-07-05T19:32:30","modified_gmt":"2017-07-05T22:32:30","slug":"analizando-ejecutables-de-windows-con-software-libre","status":"publish","type":"post","link":"https:\/\/maurom.com\/blog\/2014\/02\/23\/analizando-ejecutables-de-windows-con-software-libre\/","title":{"rendered":"Analizando ejecutables de Windows con software libre"},"content":{"rendered":"

Tras haber repasado durante la creaci\u00f3n de\u00a0gpefile.py<\/a>\u00a0las estructuras internas del formato Portable Executable (PE)<\/a>\u00a0que describe a los ejecutables de Windows, otro de los pet projects<\/em> en los que he picado c\u00f3digo es un sencillo generador de gr\u00e1ficos de flujo de control (control flow graphs<\/a>) para comprender el flujo de ejecuci\u00f3n de los binarios de dicha plataforma.<\/p>\n

Haciendo uso de\u00a0pefile<\/a>, pygraphviz<\/a>\u00a0y principalmente\u00a0pymsasid<\/a>, con unas 400 l\u00edneas de python es posible partir de un ejecutable cualquiera y obtener un gr\u00e1fico como el siguiente.<\/p>\n

\"autochk-fragment2\"<\/a>autochk –\u00a0full image<\/a>\u00a0(big!) – dot file<\/a>
\n<\/em><\/div>\n


\nDesde luego este es un ejemplo extremadamente sencillo y trivial, analizando el binario <\/span>autochk.exe<\/span><\/em>\u00a0de <\/span>ReactOS 0.3.16<\/a>, un sistema operativo binary-compatible con Windows. El gr\u00e1fico de flujo de control para un ejecutable moderno crece r\u00e1pidamente a ra\u00edz de los distintos caminos que el compilador debe generar para representar las instrucciones presentes en el c\u00f3digo fuente original de la utilidad (<\/span>autochk.c<\/a>).<\/span><\/p>\n

El diagrama siguiente fue construido a partir del ejecutable hideflag.exe<\/a><\/em>, que es un c\u00f3digo hist\u00f3rico en este blog<\/a>. He marcado en amarillo el bucle principal que se puede apreciar en el c\u00f3digo fuente de la aplicaci\u00f3n (en pascal, esta vez).<\/p>\n

\"hideflag-fragment2\"<\/a>hideflag –\u00a0full image<\/a>\u00a0(big!) –\u00a0dot file<\/a>
\n<\/em><\/div>\n


\nPara el despliegue de los gr\u00e1ficos, dado que los visores en Debian se mambean con imagenes de varios megap\u00edxeles (bugs <\/span>581891<\/a> y <\/span>163090<\/a> ya reportados en varios lugares), les recomiendo descargar los archivos <\/span>.dot<\/em> originales\u00a0y visualizarlos directamente con la excelente utilidad <\/span>xdot<\/a><\/em>\u00a0(tambi\u00e9n hecha en python, de paso).<\/span><\/p>\n

En el diagrama, cada bloque b\u00e1sico<\/a>\u00a0inicia con un punto de entrada (primera instrucci\u00f3n a ejecutar, EIP, o destino de un salto) y finaliza con otro salto, una instrucci\u00f3n de retorno (ret<\/em>), o bien abruptamente como resultado de un l\u00edmite impuesto arbitrariamente por m\u00ed (esto \u00faltimo para evitar generar gr\u00e1ficos grandes con los cuales dot<\/em> se marea, y cr\u00e9anme que algunos tardan m\u00e1s de diez minutos en desplegarse).<\/p>\n

El bloque marcado en verde<\/span> es com\u00fanmente el primero en ejecutarse. Las flechas de colores indican, obviamente, el flujo de ejecuci\u00f3n posible. Los c\u00f3digos son los siguientes:<\/p>\n