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.

What We Know About Cross-Signing for Down-Level Windows Versions As of Today (2 March 2021)

Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,560
edited March 2 in NTDEV

OK, let's see if I can help clear SOME things up -- Though I'm not going to be able to clear up nearly as much as I had hoped earlier.
 
I got our eToken today, and it seems OSR's new code signing cert is issued by Digicert, not Entrust. My bad. But, I'm not sure that'd help anything no matter what.
 
I'm going to post this here, then I'm going to clean it up and make it into a blog post and try to get the word out across the industry. Comments/thoughts appreciated.
 
Before I even start, let me acknowledge that this is an unholy mess.
 
This is what I know as of this afternoon.
 
The problem:
 

  • This discussion is about driver signing on down-level versions of Windows, such as Windows 7, Windows 8, and Windows 8.1 -- This discussion has nothing at all to do with driver signing for Windows 10.
  • To enable a driver to be installed on down-level versions of Windows, the driver package needs to be signed either by a Microsoft certificate or using a third-party kernel-mode code signing certificate that has been cross-signed by the CA. Both certificates need to be valid when the driver is signed.
  • This discussion results from MSFT's policy to discontinue support for cross-signing drivers to enable them to be installed on down-level version of Windows. This isn't an arbitrary decision, but rather is driven by technical issues around the way the existing certs work.
  • According to the MSFT Trusted Root Program (TRP) policy, after 1 July 2021CAs cannot issue kernel-mode code signing certificates. Certificates in violation of Microsoft TRP policies are subject to revocation.
  • Despite repeated pleas to provide an alternate way to sign drivers, as of today (2 March 2021) the only way MSFT says that you'll be able to install drivers on down-level versions of Windows is to make your drivers pass the WHQL tests.
  • Here's where the Community gets screwed: It is technically impossible for many drivers to pass the WHQL tests (consider, for example, drivers that load/run on certain embedded systems that can't work as clients for the HCKs).

 
Cross-Signing Certs Valid After 1 July 2021?
 

  • Folks in the community have noticed that new cross-signing certificates have been issued, with expiration dates that run BEYOND 1 July 2021.
  • There are exactly 5 such certificates that I can find as of today (2 March 2021). They are from "Entrust Root Certification Authority – G2", "AddTrust External CA Root", "GoDaddy Class 2 Certification Authority", "Starfield Class 2 Certification Authority", and "UTN-USERFirst-Object"
  • It seems logical that if you had a kernel-mode code signing cert that chains up to one of these specific CAs, you could continue to use it along with one of the cross-certs above to sign kernel-mode drivers until either your code signing cert expires or the cross-cert expires, whichever comes first.
  • The catch: I can't find a way to purchase a relevant code-signing cert from any of these CAs (AddTrust and UTN-USERFirst-Object are both part of Sectigo now). If you can, let us know!

 
A Work-Around:
 

  • Remember: The goal here is to be able to install drivers on down-level versions of Windows, without having to pass WHQL.
  • One solution that we know works on Windows 7: Attestation Sign your driver package and binary for Windows 10. The resulting driver package will install on Windows 7 (with KB4474419, which enabled SHA-256 signing installed). Note that this works as long as you DO NOT sign the driver binary with your own signature before you submit it to MSFT for Attestation Signing.
  • Attestation Signing your driver package for Windows 10 will also allow non-PnP drivers drivers to be installed on Windows 8.1(including right-click install using an INF) -- This does not, however, work for PnP drivers.

 
That's what I know as of this afternoon, and I sincerely hope it's helpful.
 
I am in (almost) daily communication with MSFT on this issue. I've been told that we should see something more from them, in terms of a policy clarification or something soon. Yes... we've heard that before.
 
Peter

Peter Viscarola
OSR
@OSRDrivers

«1

Comments

  • CaptainFlintCaptainFlint Member Posts: 51

    As an additional argument against the whole "just go and do WHQL" claim, you could add that drivers distributed under GPL are legally forbidden from being WHQL signed. So even if you manage to pass all the tests, it does not mean you can get the signature.

  • Francis_LitterioFrancis_Litterio Member Posts: 8
    edited March 2

    Peter wrote:

    This isn't an arbitrary decision, but rather is driven by technical issues around the way the existing certs work.

    Do we have any info from MSFT on what these technical issues are? If they relate to enabling malware, I understand that details must be omitted, but it would still be nice to have some general info.

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,440
    via Email
    What law prohibits GPL drivers fro, being WHQL signed?

    Mark Roddy
  • CaptainFlintCaptainFlint Member Posts: 51

    @Mark_Roddy said:
    What law prohibits GPL drivers fro, being WHQL signed?

    It's not a law, it's Microsoft's policy. The agreements you have to sign and then comply with; they define what you are allowed to send for submission.

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

    The agreements you have to sign and then comply with; they define what you are allowed to send for submission.

    @CaptainFlint
    Can you give us a citation, please? I been doing this (drivers for Windows) for a while now, and I've never heard that before. I'm not saying you're wrong... I'm just saying I'm really, really, surprised.

    Do we have any info from MSFT on what these technical issues are?

    @Francis_Litterio
    Ugh. The info I have was given to me under NDA. So, while it's not very interesting, it's also not something I can share. I apologize for that.

    I only mentioned it to make the point that MSFT isn't discontinuing support for cross-signing arbitrarily, for absolutely NO reason. And they're not doing it purely to push people off Win 7 or to purely to promote driver devs using WHQL (though, I'm sure those two things definitely influence the overall decision as well).

    I don't know why they haven't made the reason widely known, but the PM who "owns" the decision to discontinue support for cross-signing apparently has some reason, as he has not made it widely public.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • CaptainFlintCaptainFlint Member Posts: 51

    @Peter_Viscarola_(OSR) said:
    Can you give us a citation, please? I been doing this (drivers for Windows) for a while now, and I've never heard that before. I'm not saying you're wrong... I'm just saying I'm really, really, surprised.

    it's governed by the section 7.g of the Windows Compatibility Program and Driver Quality Attestment Testing Agreement:

    (g) Drivers and BIOSes are not, and when delivered to Microsoft will not be, in whole or in part, governed by an Excluded License. An "Excluded License" is any license that requires, as a condition of use, modification and/or distribution of software subject to the Excluded License, that such software and/or other software combined and/or distributed with such software be (i) disclosed or distributed in source code form; (ii) licensed for the purpose of making derivative works; or (iii) redistributable at no charge.

    When I first heard about such restriction, I went googling, and among others found the following discussion about this matter:
    https://libusb-win32-devel.narkive.com/0CaoKh07/whql-testing-agreement-and-gplv3-conflicts
    It contains also information from a user who contacted Microsoft directly, and their legal department confirmed that GPL is indeed not accepted. Even though the thread starts with GPLv3, the same is applicable to GPLv2 (which is also confirmed by a quote from Microsoft).

  • john_smith1978john_smith1978 Member Posts: 21

    @Peter_Viscarola_(OSR) said:

    • The catch: I can't find a way to purchase a relevant code-signing cert from any of these CAs (AddTrust and UTN-USERFirst-Object are both part of Sectigo now). If you can, let us know!

    Hi Peter

    Purchasing from Entrust is only possible from the following link :

    https://www.entrust.com/digital-security/certificate-solutions/products/digital-signing/code-signing-certificates

    Which then redirects you to filling up a form so they can contact you. I guess you can specify the specific CA in the request form.

    Sectigo is also the following :

    https://sectigo.com/ssl-certificates-tls/code-signing

    But i couldn't find anything for code signing in GoDaddy or Starfield, i guess the best way is to contact them.

    We contacted Entrust and as you know got a vague answer, but we suggest other folks to also contact Entrust and the other 4 companies so maybe we can get a clear answer.

  • Alan_AdamsAlan_Adams Member - All Emails Posts: 15

    @Peter_Viscarola_(OSR) said:

    • One solution that we know works on Windows 7: Attestation Sign your driver package and binary for Windows 10. The resulting driver package will install on Windows 7 (with KB4474419, which enabled SHA-256 signing installed). Note that this works as long as you DO NOT sign the driver binary with your own signature before you submit it to MSFT for Attestation Signing.

    Well now, there's something I'll want to go test. What I recall is that the attestation signing process generated a .CAT containing only the platform IDs selected during submission, which are all Windows 10 variants. And that attested installation set was rejected as a signed driver during installation on the Windows 7 platform or any other platforms, because there was effectively "no .CAT file" (valid for those platforms).

    But indeed we are signing the binaries prior to attested submission, specifically because our intention is to run on both Windows 10 and pre-Windows 10. Once the dual-signed binaries are received back from Microsoft, we are able to generate a second .INF and .CAT, and sign that .CAT ourselves. In order to have a working "pre-Windows 10" .INF to install with on such platforms, while using the Microsoft-generated .CAT for installing Windows 10 platforms. i.e. Same binaries, two different .INFs and .CATs.

    If Microsoft is now including a Windows 7-compatible platform ID in the .CAT created for attested signing -- if you didn't sign the driver binaries ahead of time -- indeed that opens up an additional useful option. An option that Microsoft could withdraw at any moment, of course, but how many aspects of this aren't exactly like that anyway.

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

    If Microsoft is now including a Windows 7-compatible platform ID in the .CAT created for attested signing

    There's no chance that's happening, so I don't know how it works. I only know that it does work, and this has been verified and repro'ed by multiple folks.

    I suspect the CAT isn't used on Win7, however, because on Win7 I can edit the INF file on the target install system, and the driver still installs without error.

    Ugly, huh?

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

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

    Purchasing from Entrust is only possible from the following link

    I have an enquiry in to Entrust as of this morning to purchase one of their certs. I'll post back what I hear.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Alan_AdamsAlan_Adams Member - All Emails Posts: 15

    @Peter_Viscarola_(OSR) said:
    I suspect the CAT isn't used on Win7, however, because on Win7 I can edit the INF file on the target install system, and the driver still installs without error.

    That certainly would seem unusual, since neither actual WHQL signed packages nor cross-signed packages have worked that way on Windows 7 platform previously. Meaning you do get the angry red "installation set has been tampered with" warning when modifying the .INF away from the content it was signed with, which confirms both the .CAT and the contained hash for the .INF file were being verified.

    I modified our signing process to no longer pre-sign the binaries with our company code signing certificate, such that only the Attested signing signatures would be present on the binaries. For what it's worth, neither the ".CAT isn't used on Win7" assertion, nor the "Attested package installs without error if you didn't pre-sign the binaries" assertion held true in testing here.

    Your expectation regarding the OS attribute list in the .CAT was correct, and by selecting all non-ARM64 platforms during attested signing, the .CAT we received only contains the Windows 10 platforms. Which was the same as what we receive when we do pre-sign the binaries:

    _v100,_v100_X64,_v100_RS1,_v100_X64_RS1,_v100_RS2,_v100_X64_RS2,_v100_RS3,_v100_X64_RS3,_v100_RS4,_v100_X64_RS4,_v100_RS5,_v100_X64_RS5,_v100_19H1,_v100_X64_19H1,_v100_Vb,_v100_X64_Vb

    But on a Windows 7 Professional x64 machine up to date with SHA-2 support, with this Microsoft Attestation-only signed package I get the "Windows can't verify the publisher of this driver software" as the interactive angry red publisher verification message. The setupapi.dev.log confirms during _VERIFY_FILE_SIGNATURE that its attempt to verify the .INF file is what failed:

    Verifying file against specific (valid) catalog failed! (0xe0000244)
    "Error 0xe0000244: This software was tested for compliance with Windows Logon requirements on a different version of Windows, and may not be compatible with this version" as the reason the publisher verification failure was presented.

    I'm not a hardware driver, though. This is for a NetClient-class component being installed through INetCfg/NetSetup. So maybe that's enough to explain the split in the observations. But "signing of driver package for hardware drivers is ignored" still seems like a highly unusual proposition to accept. Maybe knowing what setupapi.dev.log revealed during these multiple successful verifications of the behavior might work toward explaining it, too.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,028

    Windows 7 does not actually require a CAT file. That didn't start until Windows 8.

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

  • Alan_AdamsAlan_Adams Member - All Emails Posts: 15

    @Tim_Roberts said:
    Windows 7 does not actually require a CAT file. That didn't start until Windows 8.

    This list knows better than I do, so I'll assume for now this is also a "when installing hardware drivers" scenario that I don't get to experience with my component. What I can say is that during my component's .INF-based driver installation on Windows 7 x64, the setupapi.dev.log is clearly citing both the .INF file being executed and the .CAT file it's using in it's attempt to verify the signed status of this .INF. And this verification fails when the .CAT file is not valid for the Windows 7 platform.

    That certainly sounds like a good and fortunate scenario for hardware drivers though, if the same doesn't apply to hardware drivers. Allowing them to employ Attested signing to work around the inability to cross-sign, and then rely on the absence of .CAT-based verification when that same valid-for-Windows-10 .INF is invoked on Windows 7 platform.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,560
    edited March 3

    Just got notified of this lovely little addition to the page on cross-signing:

    Will I be able to continue signing drivers if my certificate chains to a cross-cert that expires after 2021?
    No, using any code signing certificate to sign a kernel-mode driver without a WHQL signature after July 1st, 2021 is a violation of Microsoft Trusted Root Program (TRP) policy. Certificates in violation of Microsoft TRP policies will be revoked.

    So, yeah... there's that.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

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

    @Alan_Adams

    on a Windows 7 Professional x64 machine up to date with SHA-2 support, with this Microsoft Attestation-only signed package I get the "Windows can't verify the publisher of this driver software" as the interactive angry red publisher verification message.

    Yes... you get the angry red pop-up. BUT... in our case, the driver installed successfully, even after that.

    Looking at setupapi.dev.log, we see:

    sig:                          Verifying file against specific (valid) catalog failed! (0xe0000244)
    

    ! sig: Error 0xe0000244: The software was tested for compliance with Windows Logo requirements on a different version of Windows, and may not be compatible with this version.
    sig: {_VERIFY_FILE_SIGNATURE exit(0xe0000244)} 14:44:36.474
    !!! sto: An unexpected error occurred while validating driver package. Assuming that driver package is unsigned. Catalog = Nothing_KMDF.cat, Error = 0xE0000244
    ! sto: Driver package is considered unsigned, but user wants to install driver package anyway.

    Now... on Windows 8.1, trying to install the same PnP driver, the process fails with the usual error:

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

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

    @CaptainFlint ...

    Because you are in the process of getting an Entrust cert, I wanted to be sure you saw the post above about MSFT threatening to revoke the cert of anybody who cross-signs after 1 July 2020.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • CaptainFlintCaptainFlint Member Posts: 51
    edited March 3

    @Peter_Viscarola_(OSR) said:
    Because you are in the process of getting an Entrust cert, I wanted to be sure you saw the post above about MSFT threatening to revoke the cert of anybody who cross-signs after 1 July 2020.

    Yes, thank you for your concern, I appreciate it! I have already noticed that remark earlier, and it is indeed highly unsettling. But we need a new EV certificate in any case; our current one is close to expiring. It doesn't matter if we get the new certificate from Entrust or any other CA, as long as MS recognizes it for the Dashboard company account. Therefore, we are continuing the process of purchasing. If we're unable to also use the certificate for cross-signing, like we did before — well, there's nothing we can do about it...

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 442
    via Email
    In that case, I'd go with the cheapest supported EV cert, whixh should be
    ANY?
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,560

    it is indeed highly unsettling

    That is nicely said. Yes, exactly.

    If we're unable to also use the certificate for cross-signing, like we did before — well, there's nothing we can do about it...

    Sad, but true.

    Well... MSFT new policy saved OSR US$1K (the cost of a 3-year Entrust OV code signing cert). So, that's something I guess.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • john_smith1978john_smith1978 Member Posts: 21

    @Peter_Viscarola_(OSR) said:
    Just got notified of this lovely little addition to the page on cross-signing:

    Will I be able to continue signing drivers if my certificate chains to a cross-cert that expires after 2021?
    No, using any code signing certificate to sign a kernel-mode driver without a WHQL signature after July 1st, 2021 is a violation of Microsoft Trusted Root Program (TRP) policy. Certificates in violation of Microsoft TRP policies will be revoked.

    So, yeah... there's that.

    Peter

    Well there's that i guess, not a good news.

    So what's next? Has Microsoft made its final decision and not backing down?

  • henrik_meidahenrik_meida Member Posts: 46

    @Peter_Viscarola_(OSR) said:
    Just got notified of this lovely little addition to the page on cross-signing:

    Will I be able to continue signing drivers if my certificate chains to a cross-cert that expires after 2021?
    No, using any code signing certificate to sign a kernel-mode driver without a WHQL signature after July 1st, 2021 is a violation of Microsoft Trusted Root Program (TRP) policy. Certificates in violation of Microsoft TRP policies will be revoked.

    So, yeah... there's that.

    Peter

    So lets say we buy a 3 year cert from Entrust, then if the cert expires in 3 years, how can Microsoft even know when did we cross sign it? considering its not expired yet, we don't even need to timestamp the certificate, therefore we can cross sign it locally without network connection, and load it successfully. Am i missing something here?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,028

    The cross-certificates are issued BY MICROSOFT. They can certainly interfere in the trust chain. I don't think they could make any currently signed packages go invalid, but they can certainly prevent any new packages from being signed.

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

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 442
    via Email
    They can.
    If the excerpt from the license is true (that cross signing after
    April 1st is against the license), they can revoke your cert, thus
    making it invalid for all machines that update to thee new CRL.

    If you do it locally, I doubt anything will happen, but if the driver
    goes into the wild, they can catch it easily.
    Whether they wish to revoke certs that were not abused to make havoc
    is a different thing.

    But they are making us leave Windows :(
    > The cross-certificates are issued BY MICROSOFT. They can certainly
    > interfere in the trust chain. I don't think they could make any currently
    > signed packages go invalid, but they can certainly prevent any new packages
    > from being signed.
    >
    > --
    > Reply to this email directly or follow the link below to check it out:
    > https://community.osr.com/discussion/comment/300634#Comment_300634
    >
    > Check it out:
    > https://community.osr.com/discussion/comment/300634#Comment_300634
    >
  • henrik_meidahenrik_meida Member Posts: 46
    edited March 11

    @Dejan_Maksimovic said:
    If you do it locally, I doubt anything will happen, but if the driver
    goes into the wild, they can catch it easily.
    Whether they wish to revoke certs that were not abused to make havoc
    is a different thing.

    @Tim_Roberts said:
    The cross-certificates are issued BY MICROSOFT. They can certainly interfere in the trust chain. I don't think they could make any currently signed packages go invalid, but they can certainly prevent any new packages from being signed.

    But how can they even know when i signed the driver if i do it locally without even using a timestamp?!! i can literally revert the date of my signing machine to 2020/early-2021, sign it locally without internet connection, and then its done. how on earth can they stop this?

    And we are not even using our drivers in the wild, we want this in our local company for less than 40 computers, ranging from windows 7 to 10. and we HAVE TO support old windows 7 machines and cannot upgrade them.

    But our main question is, if we purchase a 3 year code signing EV certificate from Entrust right now, does this mean that we can cross sign our drivers locally without using a timestamp server for 3 years? again i have to emphasize that we want this for our company's computers, its not a commercial driver.. (and NO, we do not want to use test signing mode..)

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,028

    I don't think anyone knows the answer to that.

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

  • CaptainFlintCaptainFlint Member Posts: 51

    @henrik_meida said:
    But our main question is, if we purchase a 3 year code signing EV certificate from Entrust right now, does this mean that we can cross sign our drivers locally without using a timestamp server for 3 years? again i have to emphasize that we want this for our company's computers, its not a commercial driver.. (and NO, we do not want to use test signing mode..)

    Not using timestamps means, that in 3 years all the drivers' signatures will become invalid with the expiration of the main certificate. Because timestamping prevents exactly that: it identifies, that you signed the driver at the moment in time, when all the involved certificates were valid.

    Technically, if MS wants to push it real hard, they can simply revoke the non-expired cross-certificates, and signing will become... not really impossible, but problematic at best. And, at a guess, just to use drivers signed with a revoked cross-certificate, you'd have to prevent all your machines from updating the CRLs (which in itself is a bit dangerous: certificates may be revoked due to them being used maliciously).

    As Tim said, nobody knows for sure, we can only guess what will happen after July 1. I personally am inclined to think, that MS will not go to such drastic measures, and that internal-only use should be safe, even with timestamping (I don't think timestamp CAs report to Microsoft; even more, I'm not even sure CAs themselves know what certificate you are using; most probably, they receive just a hash of the file). But, on the other hand, I would never have believed, that one day MS would blow up the whole cross-certificate system, and yet here we are...

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,028

    And, at a guess, just to use drivers signed with a revoked cross-certificate, you'd have to prevent all your machines from updating the CRLs (which in itself is a bit dangerous:

    That's an interesting side point in itself. It is my (potentially flawed) understanding that the KMCS check, which happens on the 64-bit systems every time the driver loads, doesn't actually validate the whole chain. That takes too much time. It only looks for that "Microsoft Code Verification Root" at the end. If so, revoking would prevent new signings, but would not block existing drivers.

    It WOULD prevent new installs -- the installation process does check the whole chain.

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

  • CaptainFlintCaptainFlint Member Posts: 51

    Well, to be fair, the kernel-mode check is indeed somewhat simplified. I deliberately tried not to touch that subject, since it may be sensitive, and if discussed and misused too widely, it may cause Microsoft to patch it (like they added UAC, even though they had perfectly working permissions system; but very few people used it properly, and the most common reply to "why this program does not work?" was "just run from Admin"). Even with new installs, it will not prevent it completely, but make it harder...

  • henrik_meidahenrik_meida Member Posts: 46

    @CaptainFlint said:
    Technically, if MS wants to push it real hard, they can simply revoke the non-expired cross-certificates, and signing will become... not really impossible, but problematic at best. And, at a guess, just to use drivers signed with a revoked cross-certificate, you'd have to prevent all your machines from updating the CRLs (which in itself is a bit dangerous: certificates may be revoked due to them being used maliciously).

    What is the easiest way to stop computers in our company from updating the CLRs? is there any group policy for it? again our computers range from windows 7 to latest version of 10, and we use 2012 windows servers.

    @Tim_Roberts said:
    That's an interesting side point in itself. It is my (potentially flawed) understanding that the KMCS check, which happens on the 64-bit systems every time the driver loads, doesn't actually validate the whole chain. That takes too much time. It only looks for that "Microsoft Code Verification Root" at the end. If so, revoking would prevent new signings, but would not block existing drivers.

    @CaptainFlint said:
    Even with new installs, it will not prevent it completely, but make it harder...

    Interesting! I didn't know this, which windows kernel module is responsible for this check? Is there any article regarding this?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,028

    Is there any article regarding this?

    I don't think they have made this public. Security through obscurity. It has to be somewhere in the kernel module loader.

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

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

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!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 27 September 2021 Live, Online
Kernel Debugging 15 November 2021 Live, Online