Определение, какой компилятор построил Win32 PE

Question

Как определить, какой компилятор C или C ++ использовался для создания конкретного исполняемого файла Windows или DLL? Некоторые компиляторы оставляют после себя строки версий в конечном исполняемом файле, но в Windows это выглядит реже, чем в Linux.

В частности, меня интересует различие между Visual C ++ и различными компиляторами MinGW (как правило, довольно просто из сигнатур функций), а затем между версиями Visual C ++ (6, 2002/2003, 2005, 2008; более трудное для выполнения ). Есть ли какой-нибудь инструмент, который может сделать различие в полу-надежном способе?

Answer 1

Одним из источников подсказки для различия между версиями VC является связанная библиотека времени выполнения C. Так как по умолчанию (по крайней мере в современных версиях) используется ссылка на DLL, это довольно легко сделать. Утилита Dependency Walker практически необходима для проверки того, что вы знаете, какие библиотеки действительно загружаются, и подскажет, какая DLL-библиотека времени выполнения C используется. Несмотря на то, что Dependency Walker включен в пакет Microsoft Platform SDK, он был расширен независимо, и сайт, на который я ссылаюсь, является домом для его текущей разработки.

VC6 и MinGW по умолчанию ссылаются на MSVCRT.DLL, поэтому они не различаются. С некоторыми усилиями можно сделать MinGW для связи с более поздними версиями среды выполнения C, поэтому вам нужно будет самостоятельно исключить MinGW.

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

Другие библиотеки DLL времени выполнения также были бы хорошими подсказками, например, ссылки на среду выполнения Delphi, вероятно, указывают на то, что EXE-файл на самом деле был построен из Delphi, а вовсе не C-цепочкой инструментов.

Если символы не были извлечены из .EXE-файла, вы можете найти некоторые подсказки, из которых присутствуют внутренние символы. Например, ссылка на что-то вроде _sjlj_init, вероятно, указывает, что в какой-то момент был задействован MinGW GCC 3.x, настроенный для обработки исключений setjmp / longjmp.

Answer 2

Другой вариант - проверить, на какую библиотеку CRT ссылается dll, используя зависимость.exe
У MinGW и Cygwin есть свои собственные dll, которые довольно очевидно распознавать.
VC6 использует MSVCRT.dll обычно
любая новая версия VS имеет свою версию рядом с именем файла DLL:
MSVCR90.dll - VS2008
MSVCR80.dll - VS2005
MSVCR71.dll - VS2003
MSVCR70.dll - VS2002

Не принимайте этот список за полное руководство, поскольку эти названия, как правило, имеют странные различия, особенно в области VS2002-2003. Есть также другие библиотеки, такие как библиотеки MFC и ATL, которые имеют похожую схему управления версиями.

Это будет работать до тех пор, пока PE фактически зависит от CRT и не имеет статической связи с ним.

Я думаю, что в Delphi также есть какая-то DLL, на которую он ссылается, но я не совсем уверен, что это такое.

Answer 3

часть анализа, который выполняет IDA-Pro , содержит некоторое распознавание компилятором. После того, как вы откроете PE для анализа, посмотрите журнал вывода. обычно он где-то там похоронен.