How to install unsigned drivers

How to install unsigned drivers

  • Comments 4

Most device drivers these days have signatures which allow the operating system to validate that the driver files have not been tampered with since the author sent them out into the world.

It is still possible to run into an unsigned driver. If you try to install an unsigned driver, Windows will warn you at install time:

IMPORTANT: if you see this warning, ask yourself this question - DO I TRUST THE SOURCE OF THIS DRIVER? If the answer is anything but a resounding YES, you should click "Don't install this software."

Windows XP was, by and large, a 32-bit operating system. A 64-bit version of Windows XP was developed but it was not broadly released. At that time it was still fairly common to have unsigned drivers.

Windows Vista was the first client release of Windows to have a widely deployed 64-bit release. This gave an opportunity to be more strict about enforcing driver signatures. For backwards compatibility, it was still possible to run unsigned drivers on the 32-bit version of Windows Vista (so the XP drivers would still work) but there was no such burden on Windows Vista 64-bit; so Windows Vista 64-bit was the first time that there was really a strong incentive to run with only signed drivers.

Even so, there are still workarounds provided:

  • If you want to run an unsigned driver for one particular boot, you can hit F8 during boot1 and choose "Disable Driver Signature Enforcement". This allows unsigned drivers to load for this boot only.
  • If you're a device driver developer, it is expected that you will want to iterate on your particular driver; it is also expected that you will probably also have a kernel debugger attached. So driver signature enforcement is disabled if you have a kernel debugger attached.

The most reliable method, however, and the one with the fewest side effects, is to... well... sign the driver!

To sign a driver:

  1. Download the Windows Driver Kit.
  2. Make sure the driver .inf has a CatalogFile=MyCatalogFile.cat line (specify your own value for MyCatalogFile.cat). If one is missing you can add it to the [Version] section.
  3. Point inf2cat to the driver .inf file and it will make a .cat file for you. This .cat file will have an entry for every file pulled in by the .inf.
  4. Use SignTool to sign the .cat file.

At this point you can see who says this driver is OK. Double-click the .cat file | View Signature | View Certificate | Certification Path and note the highest certificate in the chain:

If you're a professional driver developer and you want your driver to ship on Windows systems, your next step would very likely be to use the Windows Logo Kit to run the Microsoft logo tests, and get an official "Microsoft says this driver has passed the logo tests" signature for your .cat file. (The difference is that the top certificate in the chain will be "Microsoft Root Authority" rather than "Microsoft Test Root Authority.") A full description of this process lies outside the scope of this blog post.

But if you're just developing a driver for your personal use, you would probably skip this step. Instead of getting a "Microsoft says this driver is OK" signature, you can add the root certificate for your signing certificate to the "trusted root certificates" certificate store on the machine you want to load the driver on.

If the root certificate in question is the "Microsoft Test Root Authority", you can run "bcdedit -set testsigning on" and reboot.

If it's some other certificate (for example, if you generated a self-signed certificate) then you need to add it to the trusted certificate store by using certmgr.exe or by going to Internet Explorer | Internet Options | Content | Certificates.

If you have everything right, then installing the driver should not pop up the "driver is unsigned" warning. If you still get the warning, looking at C:\windows\inf \setupapi.dev.log can give some clues as to what is wrong... whether there is a driver file that is not listed in the catalog file, or the catalog file's signature does not lead back to a trusted root certificate, or something else.

1 In Windows 8 Developer Preview, the F8 experience has been reworked. Hit Shift-F8 instead.2
2 Some BIOSes have an issue where Shift is not sent to Windows this early. If you have Windows 8 Developer Preview installed one of these machines there's another way - hit F10 during boot to get to the "Edit Boot Options" screen. Add /DISABLE_INTEGRITY_CHECKS to the boot flags.

Leave a Comment
  • Please add 1 and 3 and type the answer here:
  • Post
  • F8 worked with the Vista/Windows 7 bootloader, but it didn't work reliably in cases where the boot delay was set to 0 seconds. (blogs.msdn.com/.../the-space-bar-is-the-new-f8-when-it-comes-to-vista-and-server-2008-boot-options.aspx). The official key to show the boot screen/F8 options was Space bar which worked properly for all cases. Now not only is pressing Shift+F8 together at just the right time before the OS begins to boot not easy but Space or Shift+Space no longer works. Can't it be a single keystroke that works reliably even if the boot delay is set to 0 seconds?

  • Don't forget the cross-certificates:

    msdn.microsoft.com/.../gg487315

  • Do I understand right, that, to run the driver without "testsigning on" or "F8 trick", it must be signed with commercial code signing certificate?

    I've looked a bit, such certificates cost about $200 per year... Not bad business, hehe.

  • If I read that article correctly...

    > Digitally signing kernel-mode software is similar to code-signing any software that is published for Windows

    ... would imply that there are four ways to run code:

    1. unsigned. This is enabled by default, for all x86 code; for user-mode 64-bit code; and for no ARM code.

    2. self-signed. This requires generating your own root certificate (once), adding it to the Trusted Certificate Store when installing the code.

    3. signed by Microsoft. Microsoft will sign your driver, or your Windows Store app, if the code passes certain tests. Some of the stricter forms of audio DRM allow apps to require that the audio driver be signed this way.

    4. signed by someone else, whose root certificate is already in the Trusted Certificate Store.

    I haven't tried installing a driver with a trusted self-signed certificate myself, though.

Page 1 of 1 (4 items)