Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

More Info on Driver Writing and Debugging


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/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

The Solution for PnP Driver Updates on Windows 7 & 8.1

zx2c4zx2c4 Member Posts: 14

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

Comments

  • Gabe_JonesGabe_Jones Member Posts: 91
    edited August 2

    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?

  • zx2c4zx2c4 Member Posts: 14
    edited August 2

    .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.

  • Gabe_JonesGabe_Jones Member Posts: 91

    @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.

  • zx2c4zx2c4 Member Posts: 14

    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:

  • Xiaofan_ChenXiaofan_Chen Member - All Emails Posts: 223

    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

  • 0xrepnz0xrepnz Member Posts: 86
    edited August 6

    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 ;) Anyway interesting writeup, thanks for sharing

    - Ori Damari
  • brad_Hbrad_H Member Posts: 86
    edited August 8

    @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?

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,663

    because the author took the blog down

    You know... there's a REASON for that.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • brad_Hbrad_H Member Posts: 86
    edited August 9

    @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?

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,663

    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
    @OSRDrivers

  • brad_Hbrad_H Member Posts: 86

    @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..

  • zx2c4zx2c4 Member Posts: 14

    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.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,093

    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,663

    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

    Peter Viscarola
    OSR
    @OSRDrivers

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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!
Internals & Software Drivers 15 November 2021 Live, Online
Writing WDF Drivers TBD Live, Online
Developing Minifilters 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online