Different Microsoft-signed excecutables have apparently the same signature!

Question

On Windows 10 systems, I found two versions of bootsect.exe (a Microsoft-supplied utility that writes disk boot sector) with different hashes (SHA-1 9b7463c79460a55a36b53bee0889f894b2379ec3 for one 67ea7b4a6d73831600a141f053139b33fe90f1d8 for the other), but on the surface of it the same valid Microsoft signature dated 2015-10-30.

Closer analysis of the property / digital signature tab reveals

• same date of signature shown (2015-10-30 03:32:09 UTC after translation from my locale)
• same signature shown (serial number, hash, dates..)
• different countersignatures:
  • validity period 2015-10-07 18:17:29 to 2017-01-07 18:17:29 UTC and OU = nCipher DSE ESN:98FD-C61E-E641 for one
  • validity period 2015-10-07 18:17:40 to 2017-01-07 18:17:40 UTC and OU = nCipher DSE ESN:7D2E-3782-B0F7 for the other (likely related to the timestamping HSM used).

Using a hex editor, I see in particular these differences

1. at offset 0x148..0x14A (sole difference until after 92% of the file, where signature and countersignature seem to live)
   • 06 33 02 for one
   • 33 DF 01 for the other
2. a date string with initial length byte, mostly matching date of signature as shown in user interface
   • 20151030033209.248Z for one
   • 20151030033209.24Z for the other
3. date strings with initial length byte matching countersignature validity period as shown
   • 151007181729Z and 170107181729Z for one
   • 151007181740Z and 170107181740Z for the other

Questions:

• Why are they two versions of this utility ?
• What are the operational differences between these?
• What's the likely reason of difference (1.)?
• Would not it be trivial for the signed program to act differently based on that (or the different countersignatures), defeating one of the purpose of the digital signature?
• What can be the exact role of the date strings in (2.), and why do they differ in size? Are they supposed to be related to software build, signature date, or countersignature date?
• Why do the validity periods in (3.) differ by 11 seconds, when the date strings in (2.) differ only by 8/1000 seconds?
• Why is there no century in the internal definition of the validity period? Is that allowed by X.509 or whatever standard defines the (counter)signatures? Is not that a risk that a (counter)signature becomes valid again in year 2116?

Answer 1

Some questions can be answered, other are speculative.

• X.509 relies on ASN.1. ASN.1 defines two data types for dates, UTCTime and GeneralizedTime. UTCTime has only two digits for the year, so it is not Y2K-clean; it was defined in the late 1980s out of what can only be described as a consummate lack of foresight. It was temporarily fixed by defining that UTCTime really covers years 1950 to 2049, making the interpretation unambiguous. Dates beyond 2049 shall use GeneralizedTime, which has four year digits and is thus fine until December 31st, 9999.

  Therefore, the two-digit years are a symbol of incompetence, but not a security issue stricto sensu.

• The GeneralizedTime format (with four digits for the year) can contain fractional seconds, indicated by a dot followed by extra digits. The number of extra digits is theoretically unbounded; however, upon encoding, trailing zeros are supposed to be removed. If you see "20151030033209.248Z" and "20151030033209.24Z", then these dates were measured with (at least) millisecond precision, but in the latter, the number of milliseconds was "240" and the trailing zero has been removed.

• Usually, signature and time stamping are done by distinct machines; the time stamping is performed by a dedicated Time Stamping Authority whose job is to maintain an accurate clock. Time stamping is often delayed. In your case, you see that the time stamping occurred four days after the signature.

• I find some reports that the two versions of bootsect.exe correspond to two different builds of Windows, called "10.0.10586.0 (th2_release.151029-1700)" and "10.0.10135.0 (winmain_prs.150531-1700)", respectively. According to this site, the latter is an internal Microsoft build that was leaked on June 6th, 2015, but was not meant for release and is thus relatively rare in the wild.

From these information, I infer the following: within the Microsoft build process (which is probably quite intricate), two versions of bootsect.exe were compiled at the same time, differing probably only in the "build number" (I suppose your bytes at offset 0x148 are part of the build number) and signed in short succession (8 milliseconds between the two signatures). The two builds might correspond to a "stable" and a "development" versions with different building options, but integrated within the same compilation process. These two versions were then scheduled for time stamping, which occurs elsewhere, on another machine, with its own queueing. The two time stamps were performed a few days later, with an 11-second delay between the two files -- one has to imagine that the queueing is not fully "in order" and files which where queued in short succession may be handled at different times.

It is improbable that the two files behave differently. The signature uses Authenticode, which covers the complete file except the few fields that cannot be logically part of it, i.e. those for the signature and certificates, and the header checksum. It is possible for a signed executable to inspect its own binary and leverage a one-byte difference in the header to change its behaviour, but this is quite artificial: the code has to do it on purpose. Signatures are supposed to protect against malicious alterations of honest files, not against shifty executables that try to perform underhanded trickeries.

My conclusion is thus that your two bootsect.exe correspond to two distinct builds that happened to be done concurrently within the Microsoft compilation process, and for two versions of the source code that are, in fact, identical, thus leading to the same behaviour. The two files were signed in short succession, time stamped a few days later independently of each other, and one was part of an official release while the other was an internal build that got leaked.