所以我试图弄清楚如何让我的 exe 在重新编译时具有相同的哈希码/校验和。我正在使用 FastSum 生成校验和。目前,没有进行任何代码更改,我只是在 VS 中重建项目,校验和结果不同。代码是用 C++ 编写的。
我不熟悉以这种方式使用哈希码和/或校验和,但我做了一些研究并阅读了一些关于需要一致 GUID 的内容。但我不知道这将如何与校验和生成程序联系起来......
好吧,我先把它留在那里,先谢谢了。
所以我试图弄清楚如何让我的 exe 在重新编译时具有相同的哈希码/校验和。我正在使用 FastSum 生成校验和。目前,没有进行任何代码更改,我只是在 VS 中重建项目,校验和结果不同。代码是用 C++ 编写的。
我不熟悉以这种方式使用哈希码和/或校验和,但我做了一些研究并阅读了一些关于需要一致 GUID 的内容。但我不知道这将如何与校验和生成程序联系起来......
好吧,我先把它留在那里,先谢谢了。
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.
据我回忆,EXE 格式包含一个构建时间戳,因此 exe 的哈希值(包括该时间戳)会在每次重新编译时发生变化。
这是托管二进制文件吗?托管二进制文件有一个 GUID 部分,该部分会随着构建的变化而变化,您无能为力来阻止它。
您可以通过运行“link /dump /all [filename]”或“link /dump /disasm [filename]”来更好地查看二进制文件中的更改。/all 选项将向您显示所有十六进制值以及它们的 ascii 等效项,而 /disasm 选项将反汇编代码并以汇编形式显示给您,这样更易于阅读,但可能会忽略一些可能存在的细微差异导致哈希发生变化。