views:

661

answers:

4

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?

+1  A: 

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.

shoosh
Yeah, IDA Pro 5.1 is what I'm using now. Its analysis is very fuzzy, though; for something I know was compiled with VC6, it says "Using FLIRT signature: Microsoft VisualC 2-8/net runtime".
kquinn
+7  A: 

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.

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

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_init probably indicates that a MinGW GCC 3.x configured for setjmp/longjmp exception handling was involved at some point.

RBerteig
dang! beat me to it!
shoosh
Well, your list of versions *is* more complete... ;-)
RBerteig
Ah, MSVCRT.DLL with no number on it is VC6... that explains a few things. Thanks for the link to Dependency Walker, it looks very useful. I wish I could split the accepted answer points between the three of you, but I decided to give them to the guy with 1 rep.
kquinn
+2  A: 

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.

shoosh
+10  A: 

http://www.peid.info

Installs as a shell extension. Right click a binary, PeID and there you go. This is a tool created for/used by the cracker community.

This is pretty much exactly what I was looking for -- a tiny little scanner that does a nice job of sifting out and displaying the interesting bits.
kquinn
Yet it doesn't always quite work. especially for stuff compiled with newer MSVC. This tool is mostly used to check if an executable is packed. and even for that there are better ways.
shoosh