Divert

Divert copied to clipboard

I am looking for a new sponsor for driver signing. The high-level requirements are:

• Willing to sign new releases of the WinDivert32.sys and WinDivert64.sys driver (probably about 1-2 releases per year).
• Have an Extended Validation (“EV”) Code Signing Certificate as required by Windows 10.

Note that there is no immediate problem as the current release is already signed. This is for anticipated future releases or bug fixes.

If you can help then please contact basil at reqrypt.org.

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.

@basil00 What is the status on this? I'd like to help as a sponsor and/or explore possibilities to fast track this work.

@arifulhuq If you'd like to help sign the driver then please contact me via email (see email here). I'd certainly welcome more sponsors.

Currently the project has two sponsors but I've yet to contact them regarding WinDivert2.0, but probably will do soon.

I spent the last weeks/months working on a driver that is somewhat similar to WinDivert - it's geared more towards firewall applications and will be open sourced on Github soon. I am now trying to figure out how to sign this thing (got the EV cert!).

If anyone here would be willing to give a quick overview how to go about this, that would be great. Would also be nice to have this documented better for WinDivert. (We used the build environment of WinDivert.) How have WinDivert signers done this in the past?

Anyway, as soon as I get the hang of this, I'd also be happy sign WinDivert releases.

(PM via Twitter or Email)

You'll need to go through all the Microsoft documentation on how to do it. I've never done it personally.

The gist of it is that you need to create and sign (with your EV certificate) a driver package (sys + inf) and upload it do the dev portal for attestation signing. Microsoft will then sign the driver and it is ready for use.

Yes, I have gone through the Microsoft documentation until my head hurt. 😏

I almost wanted to start with the attestation signing, but then I read here that An attestation signed driver will only work for Windows 10. It will not work for other versions of Windows, such as Windows 8.1, Windows 7, or any Windows Server versions.

After checking with Statcounter and realizing that Win10 still only has a Windows market share of 55%, I though that it would be really great to at least also sign it for Win7.

Going further down that road, the docs also explain here how to sign for all Windows versions: Use the Hardware Lab Kit (HLK) to test your submission against Windows 10 and use the Hardware Certification Kit (HCK) to test against earlier versions of Windows. [...] This is the only way to make a submission apply to all Windows versions.

So the two questions that arose, were:

• Does attestation signing really only work for Win10? I mean, this is an internal network filter driver. There are compatibility guarantees across Windows versions, and there is no interaction with custom hardware.
• How much work is HLK/HCK testing? Is there any way to automate this? A DevOps pipeline maybe?

I should have been more clear in my first comment.

Also, the docs say that attestation signing is more complicated, but still a valid option. I have the feeling that HLK/HCK testing is way more complicated.

If this is going to much off topic for this issue, I'll happily move this somewhere else. I didn't think of this becoming a huge thread and hoped to ping the right people by commenting here.

That's odd cause those docs are from 2017 yet I've gone through attestation signing and AFAIK this is how releases here are done. You zip it, upload it in the dashboard and Microsoft spits out a signed version. Its fast and easy. Just make sure you zip it right. 32 and 64 bit need to be in folders in the zip named the same way windivert names them. (Amd64 or whatever etc).

Thanks @TechnikEmpire, you are right. This actually worked, contrary to the official docs. I suspect that it works because Microsoft certifies the driver as Universal, because it only uses internal APIs.

The repo is now online, here is the description of the semi-automated signing process: https://github.com/Safing/portmaster-windows-kext/tree/master/release

To be explicit: I verified that the signature works on Windows 7, 8.1 and 10. I had to first install updates on the Win7 VM, as it was from 2015 or so.

I guess this means I am available for WinDivert signing now! 😉