Determinar qué compilador creó un Win32 PE

Question

¿Cómo se puede determinar qué compilador de C o C++ se utilizó para compilar un archivo ejecutable o DLL de Windows en particular? Algunos compiladores dejan cadenas de versión en el ejecutable final, pero esto parece ser más raro en Windows que en Linux.

Específicamente, estoy interesado en distinguir entre Visual C++ y los diversos compiladores MinGW (generalmente bastante fácil de las firmas de funciones), y luego entre versiones de Visual C++ (6, 2002/2003, 2005, 2008; más difícil de hacer). ¿Existe alguna herramienta que pueda hacer la distinción de manera semi confiable?

Answer 1

parte del análisis que IDA-Pro realiza contiene algún reconocimiento del compilador. Después de abrir el PE para su análisis, observe el registro de salida. por lo general está enterrado en algún lugar allí.

Answer 2

Una fuente de una pista para distinguir entre las versiones de VC es la biblioteca de tiempo de ejecución de C específica vinculada. Dado que el caso predeterminado es (al menos en las versiones modernas) para vincular a la DLL, esto es bastante fácil de hacer. La utilidad Dependency Walker es casi indispensable para verificar que usted sabe qué DLL realmente se están cargando, y le dirá qué C runtime DLL está en uso. Aunque Dependency Walker está incluido en el Microsoft Platform SDK, se ha extendido de forma independiente y el sitio que he vinculado es el hogar de su desarrollo actual.

VC6 y MinGW ambos se vinculan a MSVCRT.DLL de forma predeterminada, por lo que no se distinguirá entre ellos. Con un poco de esfuerzo, también se puede hacer que MinGW se vincule con las últimas versiones de tiempo de ejecución de C, por lo que tendrá que descartar de manera independiente MinGW.

Runtime  VC Version 
---------- ------------- 
MSVCRT.DLL VC6 
MSCVR80.DLL VC8 (VS 2005) 
MSCVR90.DLL VC9 (VS 2008) 

Otras DLL de tiempo de ejecución serían buenas pistas también, p. las referencias al tiempo de ejecución de Delphi probablemente indiquen que el EXE en realidad fue construido a partir de Delphi, y no una cadena de herramientas de C en absoluto.

Si los símbolos no se han eliminado del archivo .EXE, entonces es posible que encuentre algunas pistas de los símbolos internos que están presentes. Por ejemplo, una referencia a algo como _sjlj_init probablemente indica que un MinGW GCC 3.x configurado para el manejo de excepciones setjmp/longjmp estuvo involucrado en algún momento.

Answer 3

Otra opción es comprobar qué biblioteca de CRT enlaza el dll con depends.exe
MinGW y Cygwin tienen sus propias DLL que son bastante obvias de reconocer.
VC6 utiliza generalmente msvcrt.dll
cualquier versión más reciente de VS tiene su versión al lado del nombre de archivo del archivo DLL:
Msvcr90.dll - VS2008
MSVCR80.dll - VS2005
MSVCR71.dll - VS2003
MSVCR70. dll - VS2002

No tome esta lista como la guía definitiva ya que estos nombres tienden a tener variaciones extrañas, especialmente en el área de VS2002-2003. También hay otros dlls como los dlls MFC y ATL que tienen un esquema de control de versiones similar.

Esto funcionará siempre que el PE realmente dependa del CRT y no se vincule a él estáticamente.

Creo que Delphi también tiene algunos DLL a los que enlaza pero no estoy muy seguro de qué se trata.