3 ms·
The disassembly for both versions of the file was a 100% match, though, which is a pretty good indicator that the binary difference must be something unimportan
by 0x0 13y ago
The disassembly for both versions of the file was a 100% match, though, which is a pretty good indicator that the binary difference must be something unimportant and not related to the actual code.
- edwintorok 13y agoYes that is a good step towards fully deterministic build. There are ways to manipulate the PE file though to achieve slightly different behaviour. If you want to be thorough and make sure that your binary was not infected by malware for example then comparing the binaries makes sense.
- ynik 13y agoIt's possible that the difference is in the actual code: x86 machine code sometimes has multiple different encodings for the same assembler instruction. These would show up as single-byte differences in the binary. See http://www.strchr.com/machine_code_redundancy http://www.strchr.com/machine_code_redundancy for some examples. Compilers might use this to stenographically hide additional data in the binary. Printer manufacturers already do something similar (https://en.wikipedia.org/wiki/Printer_steganography https://en.wikipedia.org/wiki/Printer_steganography). I wouldn't be surprised if MS compilers embedded a hidden data in binaries -- it could be useful to track down malware authors; or identify software created with pirated MS tooling.
- oakwhiz 13y agoPerhaps this could even be used by an organization to differentiate official binaries of closed-source software from leaked binaries.
- 0x0 13y agoIf you read the whole article, you'd see that every single bit difference is accounted for; none of the bit differences occur in the actual code.