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).
- validity period 2015-10-07 18:17:29 to 2017-01-07 18:17:29 UTC and
Using a hex editor, I see in particular these differences
- at offset 0x148..0x14A (sole difference until after 92% of the file, where signature and countersignature seem to live)
06 33 02
for one33 DF 01
for the other
- a date string with initial length byte, mostly matching date of signature as shown in user interface
20151030033209.248Z
for one20151030033209.24Z
for the other
- date strings with initial length byte matching countersignature validity period as shown
151007181729Z
and170107181729Z
for one151007181740Z
and170107181740Z
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?