确定哪个编译器构建了 Win32 PE
如何确定使用哪个 C 或 C++ 编译器来构建特定的 Windows 可执行文件或 DLL？ 一些编译器会在最终的可执行文件中留下版本字符串，但这在 Windows 上似乎比在 Linux 上更罕见。
具体来说，我感兴趣的是区分 Visual C++ 和各种 MinGW 编译器（通常从函数签名来看相当容易），然后区分 Visual C++ 版本（6、2002/2003、2005、2008；更难做到）。 有没有一种工具可以以半可靠的方式进行区分？
How can one determine which C or C++ compiler was used to build a particular Windows executable or DLL? Some compilers leave behind version strings in the final executable, but this seems to be rarer on Windows than on Linux.
Specifically, I'm interested in distinguishing between Visual C++ and the various MinGW compilers (usually fairly easy from the function signatures), and then between Visual C++ versions (6, 2002/2003, 2005, 2008; more difficult to do). Is there a tool out there that can make the distinction in a semi-reliable way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
区分 VC 版本的提示来源之一是链接的特定 C 运行时库。 由于默认情况是（至少在现代版本中）链接到 DLL，因此这相当容易做到。 实用程序 Dependency Walker 对于验证您是否知道真正加载的 DLL 几乎是必不可少的，它会告诉您正在使用哪个 C 运行时 DLL。 尽管 Dependency Walker 包含在 Microsoft Platform SDK 中，但它已独立扩展，我链接的站点是其当前开发的主页。
VC6 和 MinGW 默认情况下都链接到 MSVCRT.DLL，因此不会区分它们。 经过一些努力，MinGW 也可以链接到更高的 C 运行时版本，因此您需要独立排除 MinGW。
其他运行时 DLL 也是很好的线索，例如对 Delphi 运行时的引用可能表明 EXE 实际上是从 Delphi 构建的，而不是 C 工具链。
如果符号尚未从 .EXE 文件中删除，那么您可能会发现一些存在内部符号的线索。 例如，对
_sjlj_init之类的引用可能表明在某个时刻涉及为 setjmp/longjmp 异常处理配置的 MinGW GCC 3.x。One source of a hint to distinguish among VC versions is the specific C runtime library linked. Since the default case is (at least in the modern versions) to link to the DLL, this is fairly easy to do. The utility Dependency Walker is almost indispensible for verifying that you know what DLLs are really being loaded, and it will tell you which C runtime DLL is in use. Although Dependency Walker is included in the Microsoft Platform SDK, it has been extended independently and the site I linked is the home of its current development.
VC6 and MinGW both link to MSVCRT.DLL by default, so this won't distinguish between them. With some effort, MinGW can be made to link to the later C runtime versions as well, so you will need to independently rule out MinGW.
Other runtime DLLs would be good clues too, e.g. references to Delphi's runtime probably indicate the EXE was actually built from Delphi, and not a C toolchain at all.
If symbols haven't been stripped from the .EXE file, then you might find some clues from which internal symbols are present. For instance, a reference to something like
_sjlj_initprobably indicates that a MinGW GCC 3.x configured for setjmp/longjmp exception handling was involved at some point.另一种选择是使用 depends.exe 检查 dll 链接到的 CRT 库
MinGW 和 Cygwin 有自己的 dll，很容易识别。
VC6通常使用MSVCRT.dll
任何较新版本的 VS 在 dll 文件名旁边都有其版本号：
MSVCR90.dll - VS2008
MSVCR80.dll - VS2005
MSVCR71.dll - VS2003
MSVCR70.dll - VS2002
不要将此列表作为最终指南，因为这些名称往往有奇怪的变化，特别是在 VS2002-2003 领域。 还有其他 dll（例如 MFC 和 ATL dll）也具有类似的版本控制方案。
只要 PE 实际上依赖于 CRT 并且它没有静态链接到它，这就会起作用。
我认为 Delphi 也有一些它链接到的 DLL，但我不太确定它是什么。
Another option is to check what CRT library the dll links to using depends.exe
MinGW and Cygwin have their own dlls which are quite obvious to recognize.
VC6 uses MSVCRT.dll usually
any newer version of VS has its version next to the dll's file name:
MSVCR90.dll - VS2008
MSVCR80.dll - VS2005
MSVCR71.dll - VS2003
MSVCR70.dll - VS2002
Don't take this list as the definitive guide since these names tend to have strange variations, especially in the area of VS2002-2003. There are also other dlls like the MFC and ATL dlls that have similar versioning scheme.
This will work as long as the PE actually depends on the CRT and it didn't link to it statically.
I think Delphi also has some DLL it links to but I'm not really sure what it is.
IDA-Pro 执行的部分分析包含一些编译器识别。 打开PE进行分析后，查看输出日志。 它通常被埋在那里的某个地方。
part of the analysis that IDA-Pro performs contains some compiler recognition. After you open the PE for analysis, look at the output log. it's usually buried somewhere there.