A Guide to Signing Un-signed Drivers (Part 2)

This post continues from part 1 of the driver signing series which can be found here.  Part 3 of the series can be found here.

It’s been a while since I looked at signing un-signed drivers I must admit. In fact, I’ve probably not signed one since my original post on AppDeploy (now ITNinja) back in 2010!  I’ve been caught up in ‘other worlds’ since then, but I’m finally back to write a second part to this original post (which incidentally I’ve modified and re-written here and you may need to reference this throughout this post).

Anyway, this second part is a small piece on how driving signing works (high level) and an issue that I’ve stumbled upon and resolved recently.

WHY SIGN A DRIVER?

It’s a way of ensuring that a driver package has not been tampered with since it was tested and approved.  In our self-signing example, you are testing and approving it!  It also means that non-administrative users will not get any security prompts when installing drivers for Plug and Play devices (depending upon your driver signing policy).

WHAT IS A CATALOG USED FOR?

A catalog file contains digital signatures that reference each file in your driver’s INF file (referenced by the CopyFiles directive…..read on), allowing the operating system to verify the integrity of every file.  If any files referenced by the driver INF file are changed after digitally signing the catalog file (including the INF itself!), the signature will be broken.

HOW IS THE CATALOG USED WHEN WE INSTALL A DRIVER?

The inf file looks for the catalog file that it is referencing and verifies the digital signature.  It also verifies the cryptographic checksum of every file that is recorded in the signed catalog file.  If any of this does not comply, the driver install will fail.

DEBUGGING A DRIVER INSTALL (WITH AN EXAMPLE)

I’m working on an un-signed Smart Card printer by IDP called Smart 50s.  Here is the original INF file content:

Since we’ve already generated a corporate certificate using my guide, all we really need to do here is sign the catalog file.  Occasionally we need to delete the vendor’s cat file and generate our own cat file.  I sometimes do this for peace of mind, to ensure that the cat file is up to date and contains all the correct file checksums referenced by the INF file.

So next I imported my certificate into the Trusted Root store (i need to do this before I can verify the digital signature), and verified the digital signature of my catalog file using SignTool.exe.  Everything reported a success.

Next (and as a quick test) I lumped a copy of DPInst.exe into the driver folder on my dev machine, and ran it interactively by double clicking it.  And then I gasped:

Unsigned driverHow can this be?  Signtool.exe verified the digital signature successfully?  So I delved into the driver log file which is located here:

C:\Windows\inf\setupapi.dev.log

And when I scrolled down to the bottom (incidentally deleting this file will regenerate a new one, which may be handy when debugging) I found this line:

This was interesting.  Take note of the exclamation marks at the very start – a single exclamation is a warning, and a triple exclamation mark is an error/failure   So I did a little Googling and stumbled upon this.  Specifically, it says:

PnP device installation considers the digital signature of a driver package to be invalid if any file in the driver package is altered after the driver package was signed. Such files include the INF file, the catalog file, and all files that are copied by INF CopyFiles directives.

I knew the INF and Catalog files hadn’t been modified since signing them, so it led me to the bit in bold.   Was UNIDRVUI.DLL being copied to the driver store by a CopyFiles directive?  It turns out it wasn’t!!  So this meant fixing a vendor’s INF file which I can assure you, isn’t much fun!  What’s important to note here is that even though Signtool.exe verified the digital signature of my catalog file, that does not mean to say that the catalog file contains all the required file checksums!

Here are the changes I made – unfortunately I won’t go in to how we modify INF files since it’s not a trivial task to explain.  Anyway:
1. Added a CopyFiles directive, pointing to a section called UNIFILES.INF difference 12. Created the UNIFILES section, and added all the files that we missing (it wasn’t just UNIDRVUI.DLL)INF difference 2

3. Added the files to the SourceDisksFiles.x86 section, so that they could be located on disk (they were in a sub folder called i386)
INF difference 3

I then deleted the cat file so I could re-generate it with all the new file checksums.  And I re-signed it with my certificate.  I then ran DPInst.exe and successfully got the following prompt!

Signed successfullyAt this point I thought it was good to go.  As you all probably know, Windows 7 and above come with some handy VBScript printing utilities located here:

C:\Windows\System32\Printing_Admin_Scripts\en-US

The scripts basically use WMI classes under the hood to add/configure printers and ports etc.  I wanted to run  quick test using the WMI approach instead of the PrintUI.dll approach since we can return exit codes, and I think there are issues returning exit codes via Rundll32 and PrintUI.dll (it tends to just print the error out to a dialog window as opposed to returning an exit code).

When we tried to install our driver, it returned an 2148467266 exit code.  So I checked inside setupapi.dev.log and found the following:

Assuming an untrusted signer?  That’s strange.  So I MOVED the certificate to the Trusted Publishers store.  And then I got this:

Fair enough.  I kind of expected that.  So i decided to put my certificate in BOTH the Trusted Publisher AND the Trusted Root stores.  And voila.  No error messages and a return code of 0!

I’ll probably end up using C:\Windows\System32\PnPutil.exe to install my driver above.  It has a handy command line switch (/i) that installs the driver on matching devices that are connected to the system (the WMI approach doesn’t seem to do this – although perhaps a little more research is needed surrounding this!).  In other words, when a user plugs in this device (without the drivers installed – they need to plug it in first to mount the Virtual Printer port) it will create an entry under Devices and Printers in the ‘Unspecified’ section.  Installing the driver and adding a printer via WMI works, but also leaves the ‘Unspecified’ device until the user logs off and logs back in (even after a print spooler stop and start).  PnPutil.exe seems to install the driver and then match it up to this unspecified device and moves it to the Printers and Faxes section.  That’s all….for now.

One thought on “A Guide to Signing Un-signed Drivers (Part 2)

  1. Pingback: Guide to Signing Un-signed Drivers (Part 1)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.