Inspector PE: visor de EXE y DLL de Windows

Cómo usar

1. Suelta el archivo en el recuadro. Un .exe, una .dll, un controlador .sys, un control .ocx o un binario .efi se analizan igual: la extensión no es lo que decide.
2. Lee las tarjetas de cabecera para la arquitectura, PE32 frente a PE32+, EXE frente a DLL y el subsistema. La versión de consola y la de GUI del mismo programa solo se diferencian aquí.
3. Revisa las etiquetas de endurecimiento. ASLR, DEP y CFG son lo que activa por defecto una cadena de herramientas actual de Windows, así que una etiqueta ámbar en un binario reciente merece explicación antes de distribuirlo.
4. Busca en las importaciones la capacidad que te interesa: WS2_32 son sockets, WININET o WINHTTP significan que habla con la web, ADVAPI32 registro o servicios, CRYPT32 certificados.
5. Mira en la tabla de secciones si hay alguna escribible y ejecutable, y en los directorios de datos si hay certificado, entrada de depuración o cabecera del runtime CLR, que cambia cómo debe leerse todo lo demás.

Preguntas frecuentes

El archivo muestra la etiqueta de firma. ¿Significa que es seguro?

No, y la distinción importa. La etiqueta solo dice que el directorio de datos de certificados no está vacío, es decir, que hay un bloque Authenticode añadido después de la última sección. No dice que ese bloque corresponda a los bytes que lo preceden, que el certificado firmante encadene con una raíz en la que Windows confíe, que el certificado fuera válido al firmar ni que quien firmó sea quien el archivo afirma. Cualquiera de esas cosas puede ser falsa con el directorio igualmente lleno: se puede refirmar con un certificado autoemitido, o modificar el contenido después de firmar para que el hash ya no cuadre. Verificarlo de verdad exige la cadena completa, datos de revocación y normalmente un sello de tiempo de confianza, y eso es una operación de red, deliberadamente fuera del alcance de una herramienta que promete no subir tu archivo.

¿Qué añade el ASLR de alta entropía sobre el ASLR normal?

El ASLR normal mueve la imagen a una base aleatoria al cargarla, pero en Windows de 32 bits solo unos ocho bits de la dirección son realmente aleatorios, pocos suficientes para probarlos por fuerza bruta en un bucle. HIGH_ENTROPY_VA le dice al cargador que la imagen puede colocarse en cualquier punto del espacio de direcciones de 64 bits, lo que sube los bits aleatorios por encima de diecisiete y hace impracticable adivinar. Solo significa algo en una imagen PE32+ que además tenga DYNAMIC_BASE, y exige que el programa nunca trunque un puntero a 32 bits: por eso los enlazadores lo dejan tras /HIGHENTROPYVA y por eso un binario de 64 bits heredado de código de la época de 32 bits puede llevarlo desactivado a propósito.

¿Por qué algunas funciones importadas aparecen como #12 en vez de con nombre?

Porque el archivo las importó por ordinal. Cada entrada de un array de thunks es una palabra de máquina cuyo bit más alto es una bandera: si está puesto, los 16 bits bajos son el ordinal que hay que buscar en la tabla de direcciones de la DLL exportadora, y en el archivo importador no se guarda ningún nombre. Si está a cero, el resto de la palabra es un RVA que apunta a un par pista/nombre y el nombre está ahí mismo. Importar por ordinal se resuelve algo más rápido y era común en código antiguo; también es lo que se ve cuando alguien quiere ocultar qué API se llama. Esta herramienta muestra el ordinal en bruto en lugar de adivinar, porque la correspondencia entre ordinal y nombre vive en la DLL exportadora y depende de la versión instalada.

La tabla muestra una sección escribible y ejecutable. ¿Es grave?

Es lo bastante raro como para mirarlo, pero por sí solo no prueba nada. Un compilador y un enlazador normales emiten .text como lectura más ejecución y .data como lectura más escritura, nunca ambas a la vez, porque DEP existe justamente para que esa combinación falle. Las secciones con IMAGE_SCN_MEM_WRITE e IMAGE_SCN_MEM_EXECUTE juntas suelen venir de un empaquetador en tiempo de ejecución que descomprime el código en su propia sección antes de saltar a ella (UPX llama a la suya UPX1), o de un instalador antiguo, un esquema de protección automodificable, o un JIT que reserva dentro de la imagen. Si no esperabas nada de eso, conviene entender qué hace el binario antes de ejecutarlo.

La hora de enlazado dice 1970, o una fecha futura. ¿Está corrupto?

Casi con seguridad no. TimeDateStamp es un campo de 32 bits con segundos desde 1970 que rellena el enlazador, y las cadenas de herramientas modernas dejaron de tratarlo como una fecha. Una compilación reproducible lo pone a cero o a una constante fija para que el mismo código fuente dé siempre una salida idéntica byte a byte, y MSVC con /Brepro escribe ahí un hash de las entradas, que cae en un punto arbitrario del calendario y a menudo muy futuro. La cabecera Rich y el directorio de depuración suelen ser mejor evidencia de la cadena de herramientas que este campo, y nada de ello prueba cuándo se distribuyó realmente el archivo. Tómalo como metadato con forma de fecha.

Es un ensamblado .NET. ¿Por qué las importaciones y el punto de entrada parecen casi vacíos?

Porque en un ensamblado gestionado la parte PE es una cáscara. Cuando el directorio de datos del runtime CLR (índice 14, el descriptor COM) no está vacío, el programa real es IL guardado en metadatos de .NET, y las cabeceras nativas existen sobre todo para satisfacer al cargador de Windows. Un ejecutable de C# clásico tiene exactamente una importación, _CorExeMain de mscoree.dll, un punto de entrada que es un salto de dos instrucciones hacia ella, y una sección .text que es más metadatos que código máquina. Por eso el campo de arquitectura puede decir Intel 386 en un programa que correrá tranquilamente en 64 bits, y los tamaños de sección no dicen nada del tamaño real del programa. Leerlo bien requiere un desensamblador de IL como ildasm o ILSpy.

Herramientas relacionadas