How can I know if an "assembly" really did change?

Question

I created a simple "Hello World" application in VS2005. It's a straight-forward console application; it only contains the following lines:

Console.WriteLine("Hello World");
Console.ReadLine();

When I tried to rebuild the same console application WITHOUT performing any changes (just press the rebuild button), I get a subtly different executable. (I generated a SHA-1 hash from both the 1st and 2nd generated executable, and it's different!)

Why is it different when there are no code changes? What actually changed? I used a hex editor to compare and only saw a couple different bytes.

I guess my ultimate question is, how can I know if an "assembly" really did change? (Of course without looking at File versions, file size, etc)

EDIT

So far, we've established that the difference lies in the PE header (timestamp and some debug data). Before I re-invent the wheel, is there an "assembly comparison" tool that ignores the PE header?

Thanks, Ian

Taite

Answer 1

The differences will be

• the timestamp in the PE header
• the GUID of the debug data, if present

(and maybe something more, as per the other output you've posted?) To see these, run dumpbin /all /rawdata:none on both assemblies in a VS command prompt.

To do this properly you'd have to write a comparison tool that understood this and ignored those bytes - or took copies of the executables, cleared the timestamp and GUID and then compared those versions. Or, at a pinch, you could use something like fc /b as controlfreak suggests and assume that if there are < 20 bytes different (4 for the timestamp, 16 for the GUID) then it's probably the same.

You may well get away with using an assembly with the timestamp cleared - AFAIK it's only used to cache exported symbol offsets in other DLLs if you hook that up - but it's probably safer to leave as is. If you actually need binary-identical assemblies I suggest you change your processes so you never clean-build unless you really need it.

Unreadable

In order to properly ignore those bytes, I need to know the location and range of those bytes right? Is there a documentation of some sort that I can read? – Taite

Here's the PE format documentation link from MSDN: microsoft.com/whdc/system/platform/firmware/PECOFF.mspx I meant the timestamp in the COFF header and the contents of the Debug Directory. However I'd be very surprised if tools to do this don't already exist - but I don't know of one, sorry. – Unreadable

Wow, you nailed it. It is the timestamp and some debug data! 4C4953A4 time date stamp Fri Jul 23 16:32:36 2010 4C4953A4 cv 6D 000026E4 8E4 Format: RSDS, {F421268D-98D4-4D76-B70D-9C3E398E5426}, 1, C:\HelloWorld\HelloWorld\obj\x86\Debug\HelloWorld.pdb *using dumpbin /all /rawdata:none – Taite

Answer 2

From a Visual Studio command prompt you can do a more elaborate comparison:

• You could compare the PE header using the output of dumpbin:

  dumpbin /HEADERS assembly.dll
  

• Or you could compare PE headers and the IL code embedded in the assembly using ildasm:

  ildasm /ALL /TEXT assembly1.dll > dump1.txt
  ildasm /ALL /TEXT assembly2.dll > dump2.txt
  fc dump1.txt dump2.txt        
  

  The /ALL option will dump the DOS and PE headers, the CLR header, assembly metadata and disassembled IL. However, it will not contain embedded resources. If your assmembly contains embedded resources you can use the /OUT option. This will create a separate file for each embedded resource that you can the compare using your favourite diff tool, e.g. WinMerge:

  ildasm /ALL /TEXT /OUT:folder1\dump.txt folder1\assembly.dll
  ildasm /ALL /TEXT /OUT:folder2\dump.txt folder2\assembly.dll
  

Delvecchio

Answer 3

On the command line fc /b < oldfile > < newfile >

Amphitryon

Is this supposed to be an answer? At least provide some context. – Illstarred

haha sorry. I put some things in brackets and it thought they were html tags – Amphitryon

Comparing files a.exe and B.EXE 00000088: 92 A4 00000770: F4 DD 00000771: 62 20 00000772: 7F CF 00000773: A1 24 00000774: 0B AA 00000775: 5A 16 00000776: 7A 9A 00000777: 43 41 00000778: B7 9D 00000779: F3 39 0000077A: 22 C0 0000077B: 8D BF 0000077C: 50 82 0000077D: 17 1D 0000077E: 52 27 0000077F: D6 4A 000008CC: 92 A4 000008E8: 2A 8D 000008E9: 6D 26 000008EA: C2 21 000008EB: F0 F4 000008EC: 70 D4 000008ED: 1E 98 000008EE: 3F 76 000008EF: 4B 4D 000008F0: AC B7 000008F1: 5A 0D 000008F2: 75 9C 000008F3: E0 3E 000008F4: 4D 39 000008F5: 83 8E 000008F6: 6E 54 000008F7: 1E 26 000008F8: 02 01 – Taite

Hmm, that's more than I was expecting. To see what's actually changed, in a VS command prompt (or run vsvars32), run dumpbin /all /rawdata:none on both files and then windiff the output. The first one will be the timestamp and I'd guess one of the others will be the debug GUID but can't think what the third will be. – Unreadable