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.

Question regarding Deprecation of Software Publisher Certificates?

Richard_MRichard_M Member Posts: 36

Hello everyone,

As you all know, Microsoft is going to soon end the support for root certificates that have kernel mode signing capabilities in 2-3 months :

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/deprecation-of-software-publisher-certificates-and-commercial-release-certificates

But i found another article that seems to suggest that some CAs will continue to work, some up to 2025 :

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing

To add to the confusion, companies like DigiCert are still selling code signing EV and non EV certificates that based on their claim, will work for up to 3 years, even tho Microsoft says they will no longer support it in 2 months? https://www.digicert.com/order/order-1.php

Can someone clarify this? Basically if i want to purchase a code signing EV or non EV certificate right now for signing kernel drivers that works for at least 1 year or more, without going through Microsoft Hardware Dev Center program, what are my options right now? will all of them stop working in 2-3 months or..?

«1

Comments

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

    It's all such a mystery; And MSFT has -- once again -- managed to make a complete and total mess of things due to lack of clear, concise, and technically accurate communications to the 3rd party driver developer community.

    It's so frustrating. I've been working on this, with some time spent on it every week, since OCTOBER.

    OK, OK, OK... I'll calm down.

    As you've noted, I see that some cross-certs have been issued that (as you noted) don't expire until 2025. That's super interesting, and it'll be interesting to know whether the EV Certs that (for example) Entrust issues today are issued by the "Entrust Root Certification Authority – G2" (with a 2025 expiring cross-cert). Here at OSR we, coincidentally, JUST got a new EV Cert from Entrust... I'll check to see what the specific CA is, and if the new cross-cert works on down-level machines. After all, there's a separate issue as to whether the "new" Trust Root CA gets updated in the Trust Root Cert Store on Win7 the down-level machines.

    companies like DigiCert are still selling code signing EV and non EV certificates that based on their claim, will work for up to 3 years

    I think it's important not to confuse the cert "working" (that is, you can use it to sign your code, and you can use it for Dashboard submissions) with the cert having an available cross-certificate that allows cross-signed drivers to load on down-level versions of the OS. The EV Cert we got from Entrust two weeks ago indeed "works"... we can sign with it.

    And, of course, cross-signing does not "work" on any flavor of Windows 10, regardless of the cross-cert.

    I'm confused too. I'll send some email to my friends in Redmond today, and see if I can gain some clarity. No promises that I'll get a coherent response... so don't hold your breath.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

    And, of course, cross-signing does not "work" on any flavor of Windows 10, regardless of the cross-cert.

    It does if you turn off "secure boot" in the BIOS. At least, I don't THINK they're removed that.

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

  • anton_bassovanton_bassov Member MODERATED Posts: 5,245

    It does if you turn off "secure boot" in the BIOS

    I heard (in context of "defenestration process" discussion,of course) that this part may be "rather problematic" on some machines.....

    Anton Bassov

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 430
    via Email
    >
    > And, of course, cross-signing does not "work" on any flavor of Windows 10,
    > regardless of the cross-cert.
    >

    Wait, what??
    It does not work NOW?
    EV cert, SHA2?
  • Richard_MRichard_M Member Posts: 36

    @Peter_Viscarola_(OSR) said:
    It's all such a mystery; And MSFT has -- once again -- managed to make a complete and total mess of things due to lack of clear, concise, and technically accurate communications to the 3rd party driver developer community.

    It's so frustrating. I've been working on this, with some time spent on it every week, since OCTOBER.

    OK, OK, OK... I'll calm down.

    As you've noted, I see that some cross-certs have been issued that (as you noted) don't expire until 2025. That's super interesting, and it'll be interesting to know whether the EV Certs that (for example) Entrust issues today are issued by the "Entrust Root Certification Authority – G2" (with a 2025 expiring cross-cert). Here at OSR we, coincidentally, JUST got a new EV Cert from Entrust... I'll check to see what the specific CA is, and if the new cross-cert works on down-level machines. After all, there's a separate issue as to whether the "new" Trust Root CA gets updated in the Trust Root Cert Store on Win7 the down-level machines.

    Glad to know I'm not the only one confused by all this mess that Microsoft has caused.. please do update us about that Entrust EV Cert.

    I think it's important not to confuse the cert "working" (that is, you can use it to sign your code, and you can use it for Dashboard submissions) with the cert having an available cross-certificate that allows cross-signed drivers to load on down-level versions of the OS. The EV Cert we got from Entrust two weeks ago indeed "works"... we can sign with it.

    But based on digicert's website, it seems like the 3 year EV cert that they are offering will work on any version of windows for 3 years, isn't it?

    And, of course, cross-signing does not "work" on any flavor of Windows 10, regardless of the cross-cert.

    Are you talking about the fact that EV cert is required for drivers to get loaded in windows 10 computers that have secure boot on, or ..?

    I'm confused too. I'll send some email to my friends in Redmond today, and see if I can gain some clarity. No promises that I'll get a coherent response... so don't hold your breath.

    Thank you Peter, please do update us.

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

    it seems like the 3 year EV cert that they are offering will work on any version of windows for 3 years

    I think you might be missing the point that the definition of "work" might not be what you think it is?

    "Work" means you can sign executables, thereby unambiguously attesting to their authenticity and origin, for anybody who cares to check.

    "Work" does NOT necessarily mean that you can use the cert to cross-sign drivers and make them load on any given operating system.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

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

    It does not work NOW?

    Cross-signing hasn't "worked" on Windows 10 since sometime in 2016.

    Now... having SAID that, there are (a ridiculously large number of) unique cases. If the system was updated, if the system has Secure Boot enabled, if the driver isn't PnP or installed with an INF.

    In general: Cross-signing is only "supposed" to work on pre-Win 10 versions of the OS. In Win10, you need to attestation sign.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 430
    via Email
    Heck, no, I can confirm crosssigned drivers still work on Win10 2004 and
    Server 2019. We use .inf files to install most of them.
    As long as the client cert is a SHA2 EV cert, and has the corresponding
    cross and root certs.
    I can tell you uf a DigiCert cert us such, but not others. DG has EV string
    in their corresponding root and cross certs' names.


    The only thing I never tested myself is Secure Boot.

    Cross-signing hasn't "worked" on Windows 10 since sometime in 2016.
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

    The only thing I never tested myself is Secure Boot.

    That's the key. Turn on "secure boot" and it all falls apart.

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

  • Richard_MRichard_M Member Posts: 36

    @Peter_Viscarola_(OSR) said:

    It does not work NOW?

    Cross-signing hasn't "worked" on Windows 10 since sometime in 2016.

    Now... having SAID that, there are (a ridiculously large number of) unique cases. If the system was updated, if the system has Secure Boot enabled, if the driver isn't PnP or installed with an INF.

    In general: Cross-signing is only "supposed" to work on pre-Win 10 versions of the OS. In Win10, you need to attestation sign.

    Peter

    So what is our best option right now for purchasing an EV certificate for signing our drivers such that they successfully load in all versions of windows (regardless of secure boot), without going through Microsoft Hardware Dev Center program? We actually contacted Digicert, and they said "You can still purchase a code signing certificate with Digicert but you can no longer order certificates with Kernal-mode driver signing capabilities"..

  • CaptainFlintCaptainFlint Member Posts: 44

    @Richard_M said:
    So what is our best option right now for purchasing an EV certificate for signing our drivers such that they successfully load in all versions of windows (regardless of secure boot), without going through Microsoft Hardware Dev Center program? We actually contacted Digicert, and they said "You can still purchase a code signing certificate with Digicert but you can no longer order certificates with Kernal-mode driver signing capabilities"..

    Right now the best choice seems to be getting a certificate from a CA, that has cross-certificate expiration date beyond Apr 2021. Entrust is the most looked at, since their life term is the longest (Jul 2025). However, I'm not sure if anybody confirmed yet, that they indeed provide a certificate able to sign the drivers with that cross-certificate...

    But if you aim for "all versions of windows (regardless of secure boot)", then you already have no choice, but to use Microsoft's services. Because Windows 10/2016 with Secure Boot enabled require the drivers to be at least Attestation signed by Microsoft, and do not accept drivers signed by anybody else (bar a few special situations), not even with an EV certificate. The EV in this case is required for signing the package that you're sending to Microsoft, but not the drivers themselves, and cross-certificate is not needed for it.

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

    @Richard_M Get any EV Cert. Sign up for a Microsoft Dashboard account. Sign your driver using Attestation Signing for Win 10. No tests to pass. Problem solved for Win 10, at least,

    But, as I said before, Cross Signing will not reliably work on Win10. Hasn’t worked for years.

    In terms of Cross Signing for down-level OS versions, that’s what we’ve all been talking about here. We here at OSR are working on getting answers (as described above), and also trying to get the community some reasonable alternatives.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Richard_MRichard_M Member Posts: 36

    Thank you everyone for giving me help on this,

    One other question : i just checked the expiration dates for some CAs in some of my signed files, and their expiration date do not correspond to what MSDN says.. for example digicerts root CA in my signed files will expire after 2030! but Microsoft says it will expire in 2-3 months.. how does that work? isn't the expiration date part of the embedded signature in the driver file? how are they going to change this?

  • CaptainFlintCaptainFlint Member Posts: 44

    @Richard_M said:
    Thank you everyone for giving me help on this,

    One other question : i just checked the expiration dates for some CAs in some of my signed files, and their expiration date do not correspond to what MSDN says.. for example digicerts root CA in my signed files will expire after 2030! but Microsoft says it will expire in 2-3 months.. how does that work? isn't the expiration date part of the embedded signature in the driver file? how are they going to change this?

    CAs are not expiring yet. It's the cross-certificates that are in the center of attention. The ones that you specify with /ac when signing with signtool. You can check their expiration dates, using the "signtool verify /kp /v" command, under the "Cross Certificate Chain" title.

  • WinCPPWinCPP Member Posts: 1

    I am seeking clarification about the question and answer at this link: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/deprecation-of-software-publisher-certificates-and-commercial-release-certificates#will-i-be-able-to-continue-using-my-ev-certificate-for-signing-submissions-to-hardware-dev-center

    Will I be able to continue using my EV certificate for signing submissions to Hardware Dev Center?
    Yes, EV certificates will continue to work until they expire. If you sign a kernel-mode driver with an EV certificate after the expiration of the cross-certificate that issued that EV certificate, the resulting driver will not load, run, or install.


    So some questions that I had,
    1. If we want the drivers to be signed for authenticity then we should use some other certificate than EV certificate?
    2. Does it mean that we need to replace the existing EV certificate in the hardware center account with non-EV certificate?
    3. Or does it mean that MSFT will itself put an authenticity signature for my corporation based on the account details?

    Hope I am asking the right questions in the first place!

    Thanks in advance!

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

    No, you're going in the wrong direction here. There is no downside to an EV cert except the extra cost, and nothing at all will be changing in the Hardware Dev Center. The procedures are exactly the same. The only thing this policy affects is drivers that you self-sign with a cross-certificate, without going through the Hardware Dev Center. That will no longer be possible.

    1. No. If you want drivers signed, then you use the Hardware Dev Center. You won't be able to sign them yourself.
    2. No. You're reading between the lines here. The Hardware Center will still require an EV cert.
    3. The whole point of the Hardware Dev Center is that Microsoft signs your package. That's always been true, and it will continue to be true. No change.

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

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

    One more comment, if I may.

    1. Or does it mean that MSFT will itself put an authenticity signature for my corporation based on the account details?

    This actually describes the OLD process. Your certificate from your certificate authority is the CA saying "I trust these people." The cross-certificate is Microsoft saying "I trust this CA". The Microsoft signature says "I trust this cross-certificate", and that's what the system looks for.

    With the WHQL process, Microsoft just puts their own certificate on your driver. They are authenticating the driver, NOT your certificate. Indeed, you don't actually need to sign a driver package before you submit it to the Hardware Dev Center. They'll put their own on it.

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

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 430
    via Email
    You do have to sign the package before submission, just not the drivers.
    You have to sign it with a cert already associated with the HwDash account,
    and not just any cert.

    This does not have to be an EV cert, but at least one still valid, EV cert
    must be aasociated with HwDash account.
    Indeed, most companies get one EV cert, as a basic requirement, but use a
    non EV cert to sign submission packages, because EV certs require a
    physical device during signature (a USB HSM stick), or an HSM servef. But
    non EV ones do not, and multiple users can sign with them at the same time.

    With the WHQL process, Microsoft just puts their own certificate on your
  • henrik_meidahenrik_meida Member Posts: 41
    edited March 1

    @Peter_Viscarola_(OSR) said:
    As you've noted, I see that some cross-certs have been issued that (as you noted) don't expire until 2025. That's super interesting, and it'll be interesting to know whether the EV Certs that (for example) Entrust issues today are issued by the "Entrust Root Certification Authority – G2" (with a 2025 expiring cross-cert). Here at OSR we, coincidentally, JUST got a new EV Cert from Entrust... I'll check to see what the specific CA is, and if the new cross-cert works on down-level machines. After all, there's a separate issue as to whether the "new" Trust Root CA gets updated in the Trust Root Cert Store on Win7 the down-level machines.

    So does that mean that if we purchase an EV certificate from entrust right now, we can use that certificate and cross sign kernel drivers for years, even after most of the cross-signed root certificates expire in 4 months?

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

    That appears to be the case, yes.

    I’m working feverishly to pull-together a post on the state of cross signing for down-level OS support (such as Win 7) to follow up what I wrote back in October.

    Of course this doesn’t help you on Win 10.

    Stay tuned,

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 430
    via Email
    Anyone know how this affects AMSI and similar?
    Are rhey user mode DLLs? If so, how would that even be submitted for
    signing?
  • henrik_meidahenrik_meida Member Posts: 41

    @Peter_Viscarola_(OSR) said:
    That appears to be the case, yes.

    I’m working feverishly to pull-together a post on the state of cross signing for down-level OS support (such as Win 7) to follow up what I wrote back in October.

    Of course this doesn’t help you on Win 10.

    Stay tuned,

    Peter

    Thank you peter, will be looking forward to reading that post.
    Also did you find the time for checking the CA on that new Entrust EV cert that you got? was it in fact the one that expires in 2025? If thats the case This is SO confusing.. why the expiration date for almost all CAs are in 2-3 months, but entrust doesn't get expired until 2025? and why doesn't Microsoft mention the 2025 expiration in their Deprecation of Software Publisher Certificates article.. this is more confusing than it should be..

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 430
    via Email
    I would first check if that cross cert is for SHA2 EV certs. If not, it is
    not useful even if it cross signs after April.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,411

    Also did you find the time for checking the CA on that new Entrust EV cert that you got?

    I need to get the actual, physical, EV token from the person who has it. With COVID we're all working at home... I'm trying to get this done today or tomorrow.

    this is more confusing than it should be.

    Welcome to Microsoft Driver Signing. Read some of our blog posts from the past 5 years about this topic. You'll see that we're just as annoyed as you are, if not more so.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

    Anyone know how this affects AMSI and similar?

    Authenticode signing is entirely different.

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

  • john_smith1978john_smith1978 Member Posts: 21
    edited March 2

    @Peter_Viscarola_(OSR) said:
    That appears to be the case, yes.

    I’m working feverishly to pull-together a post on the state of cross signing for down-level OS support (such as Win 7) to follow up what I wrote back in October.

    Of course this doesn’t help you on Win 10.

    Stay tuned,

    Peter

    Hi Peter

    I came upon this thread, and it got me really confused, so i contacted Entrust, and it seems like this in fact is not True, and Entrust just like other CAs will not be able to give code signing EV certificates that can be used to cross sign drivers until 2025, and no matter what it seems like everyone will have to go through Microsoft Hardware Dev center to get their drivers signed, but please correct me if I'm wrong. This is the answer that i got :

    """""
    I believe this all started with this post from Microsoft, https://docs.microsoft.com/en-us/windows-hardware/drivers/install/deprecation-of-software-publisher-certificates-and-commercial-release-certificates. This post calls out a cross-certificate to root Entrust.net Certification Authority (2048) which expires 15 April 2021. The issuing CA was L1D, which stopped issuing certificates at the end of 2016 due to SHA-1 issues. Those certificates did have a kernel-mode EKU. All of those certificates have expired, so kernel-mode code signing has already stopped.

    Since mid-2015 all SHA-2 code signing certificates are issued from our OVCS or EVCS issuing CAs. These issuing CAs are subordinate to Our G2 CA cert. G2 was also cross-certified by Microsoft. If a customer wants to have kernel-mode code signing, then the code must be signed by both Microsoft and the customer using an EV Code Signing certificate, see https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#f-windows-10-kernel-mode-code-signing-kmcs-requirements. More details are found here, https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/.

    All of this is not new, but I assume that Microsoft put out the notice to kill the old kernel-mode code signing. This did not impact Entrust, since we had already stopped issuing the certificates and they should have been expired at the notice time.

    Note, we only started issuing EV Code Signing certificates in 2015 to allow our customers to submit code to Microsoft for kernel-mode signing.

    """""

    So it seems like all EV certificates that CAs issue will only be useful for submitting drivers in Microsoft Hardware dev center, and nothing more ( in terms of kernel driver loading), but if anyone knows anything else, please let me know.

  • Alan_AdamsAlan_Adams Member - All Emails Posts: 11
    edited March 2

    @john_smith1978 said:

    I believe this all started with this post from Microsoft...

    Lots of interesting information there, and appreciate it being shared. At least to my reading, Entrust's info there ultimately leaves the main question unanswered, though. Since our "big confusion" was not regarding the "Entrust.net Certification Authority (2048)" cross-certificate and the Entrust certificates it applied to.

    The response confirms all Entrust SHA-256 code signing certificates after 2015 are issued from CAs subordinate to the G2 CA. And we know the G2 CA does have a Microsoft cross-certificate that doesn't expire until 2025, which this response from Entrust also acknowledges "G2 was also cross-certified by Microsoft".

    Which continues to beg the question: If I have an extended-validation SHA-2 code signing certificate issued by Entrust in 2016 or later, does this work today with the Microsoft cross-certificate for Entrust G2? Which in turn would imply that it would continue to work beyond 2021?

    It seems like after the "G2 was also cross-certified by Microsoft" statement, the Entrust response switched to "the Microsoft party line" in which Dev Center is the only answer; without addressing the fact that G2 still has a valid cross-certificate.

    Maybe someone else reads that differently, as you also apparently did. Is there anything except Entrust's statement of "If a customer wants to have kernel-mode code signing, then the code must be signed by both Microsoft and the customer..." that led to your conclusion of "all EV certificates that CAs issue will only be useful for submitting drivers in Microsoft Hardware dev center"?

    Because that's what seems to be currently missing from my reading of it. The "why" this would be true.

    edit: Removed reference to organization-validation certificate, since Entrust.com confirms those do not support kernel-mode code signing.

  • john_smith1978john_smith1978 Member Posts: 21

    @Alan_Adams said:

    @john_smith1978 said:

    I believe this all started with this post from Microsoft...

    Lots of interesting information there, and appreciate it being shared. At least to my reading, Entrust's info there ultimately leaves the main question unanswered, though. Since our "big confusion" was not regarding the "Entrust.net Certification Authority (2048)" cross-certificate and the Entrust certificates it applied to.

    The response confirms all Entrust SHA-256 code signing certificates after 2015 are issued from CAs subordinate to the G2 CA. And we know the G2 CA does have a Microsoft cross-certificate that doesn't expire until 2025, which this response from Entrust also acknowledges "G2 was also cross-certified by Microsoft".

    Which continues to beg the question: If I have an extended-validation SHA-2 code signing certificate issued by Entrust in 2016 or later, does this work today with the Microsoft cross-certificate for Entrust G2? Which in turn would imply that it would continue to work beyond 2021?

    It seems like after the "G2 was also cross-certified by Microsoft" statement, the Entrust response switched to "the Microsoft party line" in which Dev Center is the only answer; without addressing the fact that G2 still has a valid cross-certificate.

    Maybe someone else reads that differently, as you also apparently did. Is there anything except Entrust's statement of "If a customer wants to have kernel-mode code signing, then the code must be signed by both Microsoft and the customer..." that led to your conclusion of "all EV certificates that CAs issue will only be useful for submitting drivers in Microsoft Hardware dev center"?

    Because that's what seems to be currently missing from my reading of it. The "why" this would be true.

    edit: Removed reference to organization-validation certificate, since Entrust.com confirms those do not support kernel-mode code signing.

    Hi Alan,

    Yeah their answer confused me as well and i am still not really sure if i got my answer or not. although they did emphasize that we have to go through Microsoft hardware lab to sign drivers from now on, so again, very confusing.
    I suggest other people start contacting them as well, maybe if enough people started to ask them questions they clarify things ones and for all..

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 430
    via Email
    Technically, I see only three possibilities:
    - It will work for cross signing until ~2025
    - It will not load, and Entrust is actually aware that MS might
    intentionally break that functionality via a Windows Update or
    something
    - The cross cert is NOT used for EV SHA2 certificates, in which case,
    yeah, cross signing might work, but will be useless (Windows 10
    requires cross signing via SHA2 EV certs than chain to the issuer's
    SHA2 EV root)
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

    Since the cross-certificates have to be issued by Microsoft, I'm confused as to how these long term cross-certs came to be.

    (Windows 10 requires cross signing via SHA EV2 certs than chain to the issuer's SHA2 EV root)

    We know that's not true, right? EV vs non-EV is irrelevant to the cross-signing mechanism. EV is only a requirement for creating a Hardware Dashboard account.

    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 2 August 2021 Live, Online
Kernel Debugging 27 Sept 2021 Live, Online