The Solution for PnP Driver Updates on Windows 7 & 8.1

Hey folks,

I ran into the June 1 Authenticode apocalypse today, and then caught up with the blog posts and the forum posts here to learn what had happened. Whirlwind afternoon. Yikes. It looks like in the end, Microsoft stood their ground, and things have been declared a “lost cause”. Somebody mentioned the extra dirty timestamp server hack, which really seems to violate the spirit of signing rules, and so that was dismissed as nonviable. And so in the absence of a good, clean, reliable, non-sketchy solution, we’re in a bad place.

Worry no longer: I wrote up a little summary of a very clean workaround here: https://git.zx2c4.com/downlevel-driver-enabler/about/

In short, the security barrier that Windows cares about relates to the CA used for code signing, and the information along that certification path. The kernel enforces this, and all is well. There’s an additional obsolete policy barrier, in which Windows 7 will reject drivers that have been PnP certified for Windows 10. We know this isn’t security sensitive in the least, since non-PnP drivers load. Instead, it’s just some basic userspace policy around PnP. And fortunately, Microsoft provides a facility for turning it off, and really modifying everything about how that policy is enforced. And it allows this without having to do anything naughty. By flipping a registry key, you can choose how PnP driver installation works. So the write-up simply describes turns off the OS version check. It does this, again, without having to mess with the kernel’s security-sensitive load-time check. This then allows us to load Windows 10 attestation signed drivers in Windows 7 and 8.1, both for the PnP case and the non-PnP case. In my tests so far, it works very well.

Enjoy!
Jason

The analysis of the driver signature verification process was very enlightening. Thank you for that.

What benefit does using shim.c provide over simply generating a properly targeted catalog file with inf2cat?

.cat files must contain valid signatures. Reportedly authenticode signatures are no longer valid for kernel driver code signing.

It turns out, though, that it’s possible to have a Windows 10 attested .sys file and an Authenticode signed .cat file, and the userspace PnP loader won’t mind the .cat’s path doesn’t go through a kernel signing certificate, as it’s just using the generic authenticode winverifytrust check. I just tested this briefly and it seemed to work.

@zx2c4 said:
It turns out, though, that it’s possible to have a Windows 10 attested .sys file and an Authenticode signed .cat file, and the userspace PnP loader won’t mind the .cat’s path doesn’t go through a kernel signing certificate, as it’s just using the generic authenticode winverifytrust check. I just tested this briefly and it seemed to work.

Yes, one (or maybe two?) of the myriad threads here on the topic came to that conclusion, but it’s hard to find all the relevant info. I think the most enlightening discussion began at https://community.osr.com/discussion/comment/301128/#Comment_301128. The most important part that I missed originally was that the Microsoft signature should be the first or only signature on the driver binaries themselves.

The problem is that setupapi still returns 0x800B0109 and writes this in the log. It doesn’t treat that as fatal, but I suspect (very weakly) from user reports that on some oddly configured Windows 7 machines this could block it. But that’s a weaker suspicion more than anything. I suppose I could reverse engineer a bit more to find out exactly what’s happening. In general, though, I would be more inclined to roll with the shim approach and have no errors thrown anywhere along the path, nice and clean, and as a side effect, pnputil shows Microsoft Windows Hardware Compatibility Publisher:

1 Like

Since the .sys driver is signed, the following may be a simple method for niche use cases. It works across Windows 7/8/8.1/10.
https://community.osr.com/discussion/293016/alternative-driver-signing-method-for-windows-10-using-libwdi-without-ev-certificate

And it allows this without having to do anything naughty.

This is cool and fun but not sure it’s quite as clean as you suggest… You essentially hijack an undocumented interface to spoof the return value of the signature verification function… sounds naughty to me :wink: Anyway interesting writeup, thanks for sharing

1 Like

@zx2c4 said:
Somebody mentioned the extra dirty timestamp server hack, which really seems to violate the spirit of signing rules, and so that was dismissed as nonviable. And so in the absence of a good, clean, reliable, non-sketchy solution, we’re in a bad place.

Anyone still got any backup of that blogpost of that timestamp trick or remember how that trick worked? because the author took the blog down and i cant anything regarding it?

because the author took the blog down

You know… there’s a REASON for that.

Peter

@“Peter_Viscarola_(OSR)” said:

because the author took the blog down

You know… there’s a REASON for that.

Peter

I hope you’re not gonna say “because the bad guys would use it”, because in that case they already have a sea of stolen certificates and vulnerable drivers to use to do the job…
What’s the problem with sharing knowledge?

Read the thread in which the guy posted and then deleted the hack. As I remember it, the hack was unethical, at the very least.

We’re a group of professional software engineers here, who work on Windows. We don’t condone, promote, or even publicize activities that are not in the best interest of the community. This isn’t a university where “any idea is open for discussion.” We don’t allow discussions here of hacking techniques, or writing malware, for example.

Peter

@“Peter_Viscarola_(OSR)” said:
Read the thread in which the guy posted and then deleted the hack. As I remember it, the hack was unethical, at the very least.

We’re a group of professional software engineers here, who work on Windows. We don’t condone, promote, or even publicize activities that are not in the best interest of the community. This isn’t a university where “any idea is open for discussion.” We don’t allow discussions here of hacking techniques, or writing malware, for example.

Peter

So these “hacky” techniques are unethical, but Microsoft introducing idiotic policies and leaving thousands of driver developers without any solution or proper answer is totally ethical? Notice that people that are coming up with these solutions are not doing it for malicious purposes, they are doing it because Microsoft left them no other choice…

brad_H - while I’m not too keen on people being pressured to take down blog posts, it’s Peter’s forum, and I’m generally fine following his direction on what kind of content he finds acceptable here.

However, do note that I went out of my way to find a technique for Windows 7 drivers that would not require shady things. The technique I outlined doesn’t involve removing any security checks, but just some outdated policy check that obviously makes no sense any more to have. And it seems like that’s very squarely on the side of things people don’t have any objection to, as it’s not violating any trust barrier. The forged timestamp trick, on the other hand, smells a lot worse, and I can understand that rubbing folks like Peter the wrong way.

So these “hacky” techniques are unethical, but Microsoft introducing idiotic policies and leaving thousands of driver developers
without any solution or proper answer is totally ethical?

Of course. It’s their operating system, they make the rules. I believe this policy is unwise, short-sighted, and counterproductive, but it is not unethical.

I’m not too keen on people being pressured to take down blog posts

Whoa! Let’s be clear: I did not pressure – or ask or suggest – that this guy take down the blog post from his own site. He did that after the general consensus here was that what he suggested was shady.

He’s not a Windows guy. He wasn’t sure how the community, in general, felt about such hacks… Mr. Roberts among others politely convinced him that his hack was unethical. He deleted his own blog post from his own site.

That’s the history.

Peter