Unsigned Driver Problem

Well its been a while since I wrote in this thing. Had a problem earlier this week that I was working on with the rest of the team. Drivers were being preinstalled on a workstation for use by devices that would be plugged in at a later point by a locked-down user. These drivers weren't being used and the user is then being prompted for an Admin account to finish the install.

So we started looking into it. I eventually made my way to the SetupAPI log file @ C:\Windows\SetupApi.log. In it I noticed that where it was showing the driver fail to install it gave in parenthesis about a server side installation. I thought that was odd until I found this Microsoft Article. I noticed that the log had entries stating that the driver wasn't signed.

I went into VB.NET and modified a hash compute program I had. Instead of using an MD5 Hash, I chose Sha1. I then used it to compute the hash on the files and compared them to the tag of the inf file. Sure enough the hash was different. Additionally the hash on the system files was different as well. I then noticed that other drivers that worked had hashes that matched for the inf and ini files, but failed for the sys and dll files. More on that later.

Our team decided that we should just sign them ourself. None of us are certain on how kosher this is, but none the less we proceeded. We found a Microsoft Doc that walked through the basics of signing a driver. What we found was that we needed the Windows Driver Kit. It just so happens that Microsoft has the RTM version of the Vista WDK @ Microsoft Connect.

To summarize how it is done:

1. Use MakeCert to make a certificate
2. Import that cert into the Trusted Root and Trusted Publishers sections using CertMgr
3. Use Signability to create an unsigned Catalog file.
4. Use Signtool to sign the Catalog file.

Note: all these tools we in the %WDK Directory%\bin\SelfSign\ Your results may differ.


Now all we have to do is import that cert that we created and then pre-install the drivers.


Everything sailed smoothly after that. One thing I couldn't understand was why the sys and dll files came up with different Sha1 hashes then what I would compute them out to be, but they would still be considered valid by the Install process.

I cleared up my confusion by finding this Microsoft Article. It stated the following

"A flat file hash is not used for files, such as drivers, that use the portable executable (PE) file format. Instead, relevant sections such as the PE header, executable data, and authenticated attributes are selectively hashed."

I next found a useful API Call, CryptCatAdminCalcHashFromFileHandle. I used this to make another VB.NET app and verified that the hash was correct for the PE file formats.

Cool Stuff