In this analysis of a Portable Executable linked using Microsoft Linker (6.0), down in the Imported Objects section, the website makes some very specific claims:

3 .OBJ Files (COFF) linked with LINK.EXE 5.12 (Visual Studio 5 SP2) (build: 9049)
4 .OBJ Files (COFF) linked with LINK.EXE 6.00 (Visual Studio 6) (build: 8168)
178 .C Files compiled with CL.EXE 12.00 (Visual Studio 6) (build: 8168)
26 .CPP Files compiled with CL.EXE 12.00 (Visual Studio 6) (build: 8168)
41 .ASM Files assembled with MASM 6.13 (Visual Studio 6 SP1) (build: 7299)
12 .OBJ Files linked with ALIASOBJ.EXE 6.00 (Internal OLDNAMES.LIB Tool) (build: 7291)

As far as I know, all debug information is stripped from the executable, and there certainly aren't 178 embedded ascii strings ending in ".C".

The sections in the PE are the usual .text, .rdata, .data, .rsrc.

What type of additional information or metadata in the EXE could be used to make guesses about the original object files?


My guess is that the website is parsing the Rich Signature (see https://www.ntcore.com/files/richsign.htm for analysis and details). There is a shorter description here. Basically, Microsoft's linkers add some info that can be used to infer that information.

  • Fascinating! This also answers the question of whether boundaries or ordering of the linked objects can be inferred: they can not.
    – minexew
    Jan 2 '19 at 12:49
  • Do you have IDA Pro? I recently found an object boundary detection project from JHU APL called CodeCut. It is an IDA Python script. I have not tried it myself, so not sure how well it works, otherwise I would have added it to my answer. Jan 3 '19 at 0:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.