Indeed, that part itches me a little as well. I share the author's belief it's p...

acqq · on Oct 24, 2013

One possible explanation is that the compiler and linker don't produce 100.00% same output because they have somewhere uninitialized space which gets written to the disk. That's why disassembly can still match 100.00%: the bytes that differ don't contribute to any observable functionality. If you know C, you can imagine how it happens:

You have somewhere char buff[ 32 ] which you don't set all to zeros, then you do strcpy( buff, "something" ) then you write all 32 bytes of buff to the file. What's behind "something"? It can be different in every run.

Now look at the picture: https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binarie...

See the "RSDS"? It's some initial value, just like c:\truec... that follows some bytes later. And what's behind? Some small sequence of random bytes. I've just checked and confirmed that it appears in the ".rdata" (read only data) section of the executable.

Now the fact that this doesn't happen on much more places also means that somebody in Microsoft obviously from time to time does fully clean the code, that is, somebody worries about such effects too, but it seems that from time to time some "late" fix then slips through, misbehaving.

Another explanation would be that there is something in the building code or script that produces some different values in the initialization area. That can be then observed by source inspection.

The third explanation would be some kind of "unique id" generated by the compiler or linker. Then this effect should be observed in all binaries even when the source is fully different (e.g. compile some program which generates Vogon poetry, observe the same effect). This hypothesis doesn't match the observations, according to the pictures presented.

So I believe the highest possibility is the first assumption being true.

moyix · on Oct 25, 2013

RSDS is part of the debug information section. The structure looks like (using the construct library's syntax):

  CV_RSDS_HEADER = Struct("CV_RSDS",
      Const(Bytes("Signature", 4), "RSDS"),
      GUID("GUID"),
      ULInt32("Age"),
      CString("Filename"),
  )

So it's a GUID, and one property of GUIDs is that they're "Globally unique", hence regenerated each time. Mystery solved.

Edit: Here's a source [1] so you don't have to take my word for it.

[1] http://www.godevtool.com/Other/pdb.htm