I've been learning about the Windows Driver Signing/Validation Process, including the installation process on Windows 7.
I understand that as part of the installation process, Windows requires a .inf file and a .cat file alongside the .sys files that consist of the actual drivers. However, I'm a little confused as to how the hash validation process works. I've looked at a number of examples where, when opening the .cat files and looking at the sha1 fingerprints stored within, the sha1 fingerprints for the .cat file consistently match the .inf files correctly, but never for the .sys files or other associated files such as the WDF coinstallers. Despite this, if the driver is added to the driver store via pnputil, Windows accepts them without a hitch.
Is it the case that the sys files are somehow modified before/after the sha1 fingerprint generation/comparison (and if so, how are they restored for verification?), or does windows only care about hashes for the .inf files at installation time ( msdn seems to suggest it applies to all files).
Many thanks for your time.
The files themselves are not modified at all by making a security catalog. The catalog file is a set of digest records with attached attributes that itself can be digitally signed to allow for checking files that cannot contain their own digital signature.
The stored digest is not just the digest of the given file but can also include catalog attributes if the right flag is set. See the documentation for the CRYPTCATATTRIBUTE structure. If an attribute includes CRYPTCAT_ATTR_AUTHENTICATED then this is included in the digest calculation. I don't know exactly how as it is not just the attribute value added into the digest data. It is also not clear why these are not being included for the .INF files in my example as this flag is set for the OSAttr and File attributes in the sample I have.