How can a .exe be modified and still keep a valid digital signature?

Question

When a Windows .exe installer is code-signed, I thought that modifying a single byte (thus changing its SHA256 hash) would make the digital signature invalid, but surprisingly, this is not true.

Indeed, as reported two days ago in Each Firefox download has a unique identifier, a few bytes differ in each download, with a unique ID. If you compare two downloaded .exe installers, you can notice the digital signature is the same, but only a few bytes are different: the ID.

Is this Windows-executable-file-format's feature documented somewhere? Which bytes can be modified in a .exe without invalidating a digital signature?

Reference:

https://docs.fileformat.com/executable/exe/

https://en.wikipedia.org/wiki/.exe

In the case of the Firefox installer, it is a Portable Executable (dumpbin gives: PE signature found, File Type: EXECUTABLE IMAGE).

Answer 1

From https://docs.microsoft.com/en-us/windows/win32/debug/pe-format, emphasis mine:

When included in a certificate, the image digest must exclude certain fields in the PE Image, such as the Checksum and Certificate Table entry in Optional Header Data Directories. This is because the act of adding a Certificate changes these fields and would cause a different hash value to be calculated.

The Win32 ImageGetDigestStream function provides a data stream from a target PE file with which to hash functions. This data stream remains consistent when certificates are added to or removed from a PE file. Based on the parameters that are passed to ImageGetDigestStream, other data from the PE image can be omitted from the hash computation.

The ImageGetDigestStream function is documented at https://docs.microsoft.com/en-us/windows/win32/api/imagehlp/nf-imagehlp-imagegetdigeststream, which shows that it accepts a bitfield indicating optional file sections to include: the import data, the debug symbols, and the resource section (which is used for things like embedded image files and other large binary blobs). The executable image (code and static data) are always included.

Beyond all of that, there's some padding between sections of file, and at the end of the file, that is not used in the digest. It's conventionally zero (NULL) bytes, but can be changed as long as the total file length doesn't change. I've verified that changing the padding at the end, at least, doesn't invalidate the signature.

---

Based on that, some (non-exclusive) candidates for explaining the different Firefox downloads (without even looking at actual examples):

• Unique certificates in the Checksum and Certificate Table, either actually used for code signing or just there to uniquely identify the binary.
• Resource data that just isn't included in the signature (I don't know if there is any; it's certainly quite common for installers to include lots of resource data but I'd hope it would be signed).
• Padding, especially padding at the end of the file.