Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Ref: https://github.com/pbatard/libwdi/issues/155#issuecomment-918883668
It is mentioned by libwdi developer that "Microsoft is no longer trusting certificates that are installed in Trusted Publishers for the signing of driver packages" for Windows 11. Just want to know if this is really true or not.
Background: libwdi used to work up until latest version of Windows 10.
Quick explanation of how libwdi works by Tim Roberts
Ref: https://community.osr.com/discussion/271918/libwdi-and-windows-10
libwdi is an open source installer for USB drivers, designed specifically as a companion for the libusb generic USB library, which requires a kernel driver (either WinUSB or one of the alternatives that were created before WinUSB existed). They generate a new certificate for each run, then install that certificate in the "Trusted Certificate Store". By generating a new certificate each time, rather than using some common certificate, they are trying to maintain a semblance of security and accountability.
The scheme satisfies KMCS prior to Windows 8, and for the time being even works on Windows 10.
Upcoming OSR Seminars | ||
---|---|---|
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
Kernel Debugging | 13-17 May 2024 | Live, Online |
Developing Minifilters | 1-5 Apr 2024 | Live, Online |
Internals & Software Drivers | 11-15 Mar 2024 | Live, Online |
Writing WDF Drivers | 26 Feb - 1 Mar 2024 | Live, Online |
Comments
Tim's assertion is that the method was supposed not to work under Windows 10 if Secure Boot is ON, however, that is not true. It works under Windows 10 even if Secure Boot is ON.
Ref: https://community.osr.com/discussion/293016/alternative-driver-signing-method-for-windows-10-using-libwdi-without-ev-certificate
For what is worth, this is an excerpt from
setupapidev.log
from trying to install a driver package on Windows 11 where the.cat
signing certificate has been added to Trusted Publishers:(NB: I had to replace the
>>>
at the beginning of the first two lines because it looks like OSR's markdown chokes on those in a code block).This is pretty much the same error you'd see on Windows 10 if the certificate that was used to sign the
.cat
was missing from Trusted Publishers, so it certainly looks like Windows 11 is no longer using a trust chain with certificates that users have access to, for driver package installation.Of course I validated that the relevant certificate was present in Trusted Publishers, and I also tried to copy it in virtually every other store, including Trusted Root, with no success.
I suspect that one of driver isolation or device guard is being formally enforced on Windows 11, and that this is what is preventing the method, where you could just self sign a driver package and add the cert to Trusted Publishers, from working.
And I also confirm that this method works just fine on a Windows 10 platform with Secure Boot enabled.
Note that this method is not libwdi specific. You should easily be able to replicate these findings by generating self-signed credentials, signing a driver package with them, and installing the public cert into Trusted Publisher before trying to proceed to the driver installation.
Just going to add that I have also tested driver package installation using a
.cat
that was signed with an actual Authenticode certificate (of course with that certificate added to Trusted Publishers) and I got the same error as if one tries to install a driver package signed using a self signed cert:So Windows 11 has now rendered https://docs.microsoft.com/en-us/windows-hardware/drivers/install/trusted-publishers-certificate-store wrong, since the following is no longer valid:
As a matter of fact, it is not even possible to install a driver package at all in this manner, let alone silently...
Another thing worth mentioning is that, in Windows 10, you also did get
in
setupapi.dev.log
when installing a driver package signed with credentials whose certificate has been installed in Trusted Publishers. But this was treated as a silent warning rather than an error.So I guess the difference in Windows 11 is that they are now treating this warning as a full blown error, per:
In other words, the culprit appears to be the Code Integrity feature, but according to this, Code Integrity should be on when Secure Boot is enabled... Or maybe what Microsoft is referring to is HVCI, a.k.a. Device Guard, in which case it should be possible to replicate the issue with Windows 10 when HVCI is on.
I'll try to test this to confirm.
Well, even with HVCI enabled, Windows 10 seems to be fine installing driver packages with self signed certs, even as we get the
Error 0x800b0109
code:Just a side note (I have no experience to add about Win 11 and self-signed certs).
It’s easy for a lot of us to ignore this method of signing as a bad work-around for avoiding getting a “real” signature. But there are a significant number of Enterprise-level ISVs and (particularly) IHVs who use this method of driver signing. So, if a self-signed certs placed in the trusted publisher store no longer work, there a “a lot” of folks who are gonna be surprised come release time.
Peter
Peter Viscarola
OSR
@OSRDrivers
Agreed.
I was still hoping that I had missed something (such as the properties of the autogenerated cert installed by libwdi not matching the properties of a real Authenticode cert, thus leading to the validation failure), but seeing that the test with an Authenticode signed package also failed means that, unless I screwed up something during that test, a lot of people are going to have a bad surprise indeed.
I am however puzzled that nobody else seems to be reporting this change of behaviour, so I am planning to investigate this some more...
What you’re doing isn’t commonly done… you don’t see it much outside the enterprise setting and, aside from that, is mostly used by those who are trying to “skirt the rules”… so, we don’t see a ton of these complaints here.
Peter
Peter Viscarola
OSR
@OSRDrivers
Of course the irony of it is that we aren't trying to "skirt the rules" or do anything that can be considered even remotely dodgy.
We are following Microsoft's established rules (linked previously) exactly, with the main goal of installing a pure Microsoft driver (WinUSB), that is pretty much delivered by the system anyway.
But the sad truth is that Windows was never designed to install the generic USB driver it provides against a device that the user wishes to access in a generic manner... which forces us to jump through hoops that people who produce drivers for specific devices are unlikely to ever require, but that end users actually very much want, on account that Microsoft failed to offer a proper solution for them (outside of WCID, but WCID requires the provider of the device to already have planned for its use with a generic USB driver).
So, the plot thickens.
Further testing shows that it is actually possible to install non WinUSB drivers after singing the
.cat
with self-signed credentials and a certificate copied to Trusted Publishers (e.g.libusb0.sys
orlibusbK.sys
, carried out against the exact same device and interface, and same Windows 11 machine as before).When doing so, the double
{_VERIFY_FILE_SIGNATURE}
section becomes the same as what you'd see under Windows 10, with one initial validation failure due to the trust chain, followed with a validation success through the detection of an "Authenticode" (self-signed) cert in Trusted Publishers:In other words, for anything but the WinUSB driver on Windows 11, we get the expected:
but for WinUSB installation, we get:
And the kicker is that, once you have installed a non WinUSB driver for the device, then you can replace it with the WinUSB driver, using the exact same method as the one that failed before, as it will work just fine this time around...
And yes, I agree that the first line of inquiry is "Surely, you must be doing something different with that initial WinUSB installation compared to the subsequent non-WinUSB or working WinUSB ones", but I'm definitely not seeing anything in that vein so far though I am of course continuing to investigate the matter.
At least, this provides us with one workaround to get WinUSB installed, and this tells us that the Trusted Publishers method of installation is still functional even with Windows 11, but this driver installation behaviour sure is weird, and I still don't have an explanation for it...
I have upgraded my new Acer Swift 3 laptop to Windows 11 offical release today and Zadig works fine. So I can not reproduce the issue.
I have upgraded my new Acer Swift 3 laptop to Windows 11 offical release today and Zadig works fine. So I can not reproduce the issue.
Full debug log: https://github.com/pbatard/libwdi/issues/155
Yeah, I am also not seeing the previous behaviour on the final release that I was seeing with the Insider builds before that. In other words, unlike the Insider builds, Windows 11 release appears to behave in the same manner as Windows 10 when it comes to signing a driver package and adding its certificate to Trusted Publishers.
From what I can see, it does look like Microsoft toned down some of the "improvements" they were planning to bring to the new Windows, at least for the time being.
If this is the case, it would not be the first time.
I'll remind everyone that a Windows release isn't "complete" and "stable" until some months after the initial release. Things continue to change for "quite a while." It's not like the old days when they burned a zillion CDs, and sent them out, and THAT was the release. Now, the release changes, as critical fixes and updates are applied.
Peter
Peter Viscarola
OSR
@OSRDrivers