It's looking like I'm going to be getting an EV cert to sign WinDivert for my own purposes within the next month or so. It's not 100% but I'll contact you when I'm at that point.

That'd be great. Please let me know one way or the other.

@basil00 any suggestions or advice on which cert to buy and where? I find lots of ev certs but some of them make different claims about code signing.

I find lots of ev certs but some of them make different claims about code signing.

Usually you just want the cheapest that will do the job. I found this page that has a list of EV certificate authorities that should work (given they are directly linked to by Microsoft).

@basil00 I remember some info you had about special rights for sponsors. Can you link to that info? I'm also curious if it's possible to add in some sort of mechanism to prevent tampering. For example, a content filter or AV scanner that uses WinDivert to capture all data, if there's something at the driver level where you can prevent a forced shut down of the driver. This way you could open a capture all handle that drops all by default, and someone can't just run sc.exe stop WinDivert1.XX to get by it. Thoughts?

Thanks for your time.

@TechnikEmpire, I am not sure what info you are referring to. Perhaps contact me via email and we can discuss.

For example, a content filter or AV scanner that uses WinDivert to capture all data, if there's something at the driver level where you can prevent a forced shut down of the driver. This way you could open a capture all handle that drops all by default, and someone can't just run sc.exe stop WinDivert1.XX to get by it. Thoughts?

This might not be a good idea as part of a general WinDivert release that can also be used by malicious applications, e.g. AdWare. In such cases it is important that the user/Administrator be able to disable WinDivert as a last resort.

It might be okay for a specialized WinDivert that is locked down to a specific application (e.g. AV). I am not sure how it can be implemented though.

@TechnikEmpire Do you know if you need an INF file to submit to the new driver signing standards?

@thalomatt I'm not sure. I've never gone through the process myself.

I'm in touch with an EV cert supplier. It's going to take some time because as a sole proprietor I need to jump through more hoops (signing oaths basically) but when I manage to get an EV I'll sign new releases.

Thanks, there really should be a new release that includes #92. Also I have some other minor driver improvements on my todo list. One thing I want to change is not having WinDivertSend() block on injection complete, which may be a performance bug.

Yeah I know there's a few things emerging, plus I'd like to see if I can fork it and make some additions you may be interested in. That aside, I'm pretty heavily relying on your work here for my own open source project so I'd like to contribute back somehow if I can. It may be a bit but I am getting one and will definitely sign once I do.

@TechnikEmpire ,
When you've got your cert, let me know if I can help - it wasn't a trivial matter packaging it up for Microsoft to sign the driver. At least not trivial to this non-Windows developer. But seems to work for all of our users - a few Windows 7 users said it didn't work for them, but after asking if they had all the updates, they didn't reply, so I'm guessing they updated and it started working.

@thalomatt I'd guess the Windows 7 problem is because you built WinDivert with a newer version of WDK. I assume this is a requirement from Microsoft? The newer driver will work under Windows 7 only after the user has installed the latest updates.

I believe the group I'm working with has an EV cert inbound. We had troubles with initial orders, the company ended up reneging on their offer to issue to an individual after the fact. Will update when it comes in.

@TechnikEmpire, that sounds promising. I am also in contact with another company that has recently expressed interest in helping out. The driver signing process is not as simple as before (now has hardware tokens, SHA1 versus SHA256, dev portal step), so I don't know how long it will take.

Also, it seems that Windows Server 2016 has even stricter driver signing requirements, requiring HLK testing.

@thalomatt writes...

But seems to work for all of our users - a few Windows 7 users said it didn't work for them, but after asking if they had all the updates, they didn't reply, so I'm guessing they updated and it started working.

Actually, I now think the problem is that you have signed the driver using the newer SHA2 algorithm, which is not supported by non-updated versions of Windows 7. To fix this problem, you are supposed to "rekey" your EV code signing certificate to allow duel SHA1/SHA2 signing. To rekey you need to contact your certificate provider. Otherwise, you can not bother and just not support non-updated Windows 7.

There is a new release which contains EV certificate signed drivers: https://github.com/basil00/Divert/releases/tag/v1.3.0

It has also been signed by the Microsoft dev portal, so should work for Windows 10 with secureboot enabled. I have not had the time to verify this since my virtualization environment doesn't support secureboot.

There are caveats:

• The signature uses the SHA2 algorithm which is not supported by Windows 7 unless a patch is installed. If your Windows 7 system is up-to-date the patch should already be installed.
• The drivers will not work for Windows Server 2016 unless you disable secure boot. This is because even stricter driver signing requirements including passing the HLK tests. This is on the TODO list.

Note also that version 1.3.0 is essentially the same as version 1.2.0-rc but with bug fixes. The latest performance patches have not been included in this release.

@basil00 Just curious, will we lose Vista compat with the new driver signing requirements?

Vista and unpatched Windows 7 support should be possible by "rekeying" the EV certificate to SHA1, then dual signing with SHA1/SHA2. That said, Vista is no longer officially supported by Microsoft, so I do not intend to "officially" support it anymore either.

Heya @basil00 I'd like to hop in on the driver signing train 😄

Great, if you want to help then contact me via email.

Status on this?

The project currently has two sponsors who have expressed willingness to sign the driver. There has not been a new version for a while, but this may change in Q2 2018.

That's one of the many caveats; a cross-signed driver will not load on Secure Boot enabled systems due to more restrictive Code Integrity Policies.

Thanks for the hint about Secure Boot. To clarify: the driver is signed directly by Microsoft and then also by me. The driver then has two distinct signatures.
I will investigate further and check if the driver is accepted if signed that way.

That's another pitfall: since Secure Boot is available since Windows 8 the Windows 10 signature won't work there and your cross-signed cert will also be denied.

@dhaavi you can use Hyper-V to emulate Windows 2016 with Secure Boot.
@nefarius According to this comment: https://github.com/MicrosoftDocs/windows-driver-docs/issues/1068#issue-382747909 it might actually work

Sorry, forgot to update you guys with the most recent findings:
I had my colleague test the signatures on his Secure Boot enabled Windows 10 machine - the signatures, both only from Microsoft and with mine added to it, worked fine. I don't have access to a machine with Win8.1 and Secure Boot at the moment.

So, to sum it up - I have two versions of the driver: one is only signed by Microsoft, the other has my EV signature added to it for transparency. Both work on:

• Windows 7
• Windows 8.1
• Windows 10 (also with Secure Boot)
• Windows Server 2016
• Windows Server 2019

Thanks for the hint about Hyper-V, I may take that route for future testing.

Windows Server 2016

It'd be interesting to also try this one with Secure Boot.

@basil00 It seems none of the drivers are dual signed with sha1 anymore. Is this intended? I assume that attempting to support non-updated Windows 7 is simply not a thing anymore.

Yes pretty much. Also because the SHA1 signature seemed to cause more problems than it solved, such as mysterious revocation errors.

I have KB3033929 patch installed on Win7 but run WinDivert-2.2.0-A/B/C with an error: failed to open the WinDivert device (577). WinDivert-1.4.3-A is running well without any problem. Any suggestions? Thanks.

@helloray Try this version: https://reqrypt.org/download/WinDivert-2.2.0-D.zip

@basil00 Same result. error: failed to open WinDivert handle (err = 577)

I forgot to mention that you should reboot before trying the new version. If not, then Windows will attempt to reuse the previous driver with the signature it did not like.

Hi @basil00 , I have already rebooted before try WinDivert-2.2.0-D. Any other possible reasons?

I am not sure. As a last resort, you can try manually deleting any WinDivert entry in the registry. That seemed to have worked for other people.

I am not sure. As a last resort, you can try manually deleting any WinDivert entry in the registry. That seemed to have worked for other people.

The Version 2.2 A/B/C/D is double sha-256 signature. You should set a sha-1 and sha-256 signature. This can support Windows 7/ Windows 2008.

I usually ask the sponsors (who sign the driver) if they also want to support SHA1, but most do not bother. It is still possible to run SHA256 drivers by using an up-to-date version of Windows 7, or at least by installing a patch: https://support.microsoft.com/en-us/help/3033929/microsoft-security-advisory-availability-of-sha-2-code-signing-support

I signed the driver with our company's certificate, and then submitted it to Microsoft for signature. The choice is:
Windows 10 Client versions 1506 and 1511 (TH2)
Windows 10 Client versions 1506 and 1511 x64 (TH2)
Windows 10 Client version 1607 (RS1)
Windows 10 Client version 1607 x64 (RS1)
Windows 10 Client version 1703 Client (RS2)
Windows 10 Client version 1703 Client x64 (RS2)
Windows 10 Client version 1709 Client (RS3)
Windows 10 Client version 1709 Client x64 (RS3)
  I've been stuck in the Scanning stage, I don't know why

IIRC just select a single target with the lowest version of windows 10. The portal scans the ini files and figures out itself what architectures you've included and such.

IIRC just select a single target with the lowest version of windows 10. The portal scans the ini files and figures out itself what architectures you've included and such.

Does IIRC mean RS2? I now choose this way:
Windows 10 Client versions 1506 and 1511 (TH2)
Windows 10 Client versions 1506 and 1511 x64 (TH2)
Windows 10 Client version 1607 (RS1)
Windows 10 Client version 1607 x64 (RS1)
Give it a try

Now the scan fails：
Scanning Notes
{"code":"4001","details":{"errorInfo":"ConfirmedMalware"},"innerError":null}

No sorry, its just short for "if I recall correctly". The portal is finicky and will get stuck without explanation sometimes. Pick the simplest/base option. In this case, the lowest version of windows. Also make sure that you're only choosing attestation signing. Theres another type of signing where the portal runs a myriad of tests against the driver. You don't want that. Simply attestation signing.

@basil00 that MS portal output needs your attention.
@wumn290 that doesn't look good. I've tagged the author, he will have to follow up.

{"code":"4001","details":{"errorInfo":"ConfirmedMalware"},"innerError":null}

That is quite concerning. If Microsoft decides to shadowbans the driver then that is pretty much the end of the project.

Some questions:

• What version of WinDivert did you attempt to sign?
• Did you make any modifications to the driver before signing?

Can anyone else with an EV certificate verify this for me?

If confirmed, the next step would be to contact Microsoft support to complain about a false positive. WinDivert is not malware and should not be classified as such.

{"code":"4001","details":{"errorInfo":"ConfirmedMalware"},"innerError":null}

That is quite concerning. If Microsoft decides to shadowbans the driver then that is pretty much the end of the project.

Some questions:

• What version of WinDivert did you attempt to sign?
• Did you make any modifications to the driver before signing?

Can anyone else with an EV certificate verify this for me?

If confirmed, the next step would be to contact Microsoft support to complain about a false positive. WinDivert is not malware and should not be classified as such.

I am using WinDivert64.sys and WinDivert32.sys under WinDivert-1.4.3-A \ x86, which are not compiled from the source code, the driver is not changed before signing, but the inf is written by myself, other driver files of our company can The signature passed, but windivert failed

One of the sponsors resigned version 2.2.0 of the driver and had no problems. So this might just be a false positive in Microsoft's malware detection that affects version 1.4.3 of the driver binary.

There are are few things you could try, such as upgrading to newer versions of the driver, recompiling the driver, or contacting Microsoft support to complain about the false positive.

I have KB3033929 patch installed on Win7 but run WinDivert-2.2.0-A/B/C with an error: failed to open the WinDivert device (577). WinDivert-1.4.3-A is running well without any problem. Any suggestions? Thanks.

@helloray Try this version: https://reqrypt.org/download/WinDivert-2.2.0-D.zip

@basil00 I had the same issue with A/B/C where they wouldn't load on a fully updated W7. The D version worked for me. Could you upload it to the project site or add it to releases? Thanks!

@SizzlingCalamari Your D version worked for me. Thanks

Looking for a new sponsor for driver signing

WinDivert 2.2.1 is available but is currently unsigned. If anyone can help with driver signing, please contact basil at reqrypt.org.

Looking for a new sponsor for driver signing

WinDivert 2.2.1 is available but is currently unsigned. If anyone can help with driver signing, please contact basil at reqrypt.org.

We can help to sign driver. Contacted by email.

@Fplyth0ner-Combie Thanks very much for your help.

A WinDivert 2.2.1 release (with signed drivers) is now available here: https://github.com/basil00/Divert/releases/tag/v2.2.1