3

So I'm trying to figure out how to get my exe to have the same hash code/checksum when it's recompiled. I'm using FastSum to generate the checksum. Currently, no code changes are made, I'm just rebuilding the project in VS and the checksum comes out different. The code is written in c++.

I'm not familiar with using hash codes and/or checksums in this manner, but I did some research and read something about needing a consistent GUID. But I have no idea how that would tie into the checksum generation program...

Well, I'll leave it at that, thanks in advance.

lsalamon
  • 7,998
  • 6
  • 50
  • 63
Ramon Johannessen
  • 173
  • 5
  • 14

3 Answers3

4

Have you examined the differences between the exes? I suspect the compiler/linker is inserting the date or time into the binary and as a result each binary will be different from another. Or it could be worse, sometimes compilers/linkers build static tables in their own system memory then copy that into the binary, say you have 9 bytes of something and for alignment reasons the compiler chooses to use 12 bytes in the binary, I have seen compilers/linkers take whatever 3 bytes are in system memory of that computer and copy that into the file. Ideally you would want the tools to zero out memory they are using for such a thing so you get repeatable results.

Basically do a binary diff between the files you should then find out why they dont match.

old_timer
  • 69,149
  • 8
  • 89
  • 168
  • Also, even if the compiler/linker were not inserting date/time information, any reference in the code to `__DATE__` would have the same effect. – Clifford Apr 26 '11 at 18:53
  • Man, I hope it doesn't have anything to do with compiler/linker decisions! I know in the code we've written there's no reference to [code]__DATE__[/code], but that doesn't mean it's not used I guess. I'll do a binary diff and see what comes up, thanks guys. – Ramon Johannessen Apr 26 '11 at 19:05
  • I did a binary difference, and there's two sections that are different. One is right at the beginning, I assume it's some part of the header, but I don't know how to determine exactly what it is. There's a line "This program cannot be run in DOS mode." newline, then "$00000000000000", and the next chunk is where the first difference is. The second, which consists of mostly text, is about halfway through the data and must have something to do with the compiler moving stuff around just because it feels like it... – Ramon Johannessen Apr 26 '11 at 19:56
  • use a hexdump -C or something like that to examine that area, if it is ascii date and time it should jump out at you and be obvious. – old_timer Apr 26 '11 at 20:06
  • Well, it doesn't appear to be date/time, the only thing that stands out in that section is PE, which I assume is portable executable, whether that's important or not I don't know. But I figure if other portions of the data midway through are changing, there's not much I can do. – Ramon Johannessen Apr 26 '11 at 20:35
0

From what I recall, the EXE format includes a build timestamp so a hash of the exe, including that timestamp, would change on each recompile.

Paul Alexander
  • 31,970
  • 14
  • 96
  • 151
0

Is this a managed binary? Managed binaries have a GUID section that changes from build to build and there's not much you can do to stop that.

You can get a better look at the changes in your binary by running "link /dump /all [filename]" or "link /dump /disasm [filename]". The /all option will show you all the hex values as well as their ascii equivalent, while the /disasm option will disassemble the code and show it to you in assembly, which can be easier to read but might ignore some trivial differences which might have caused the hash to change.

Zain Rizvi
  • 23,586
  • 22
  • 91
  • 133