Signing a Windows Kernel driver without using Microsoft

[Stingered]

I've been doing some reading and reviewed the lengthy process of using MS to get your .CAB file digitally signed and approved (VERY not worth it). Not to mention going through the expensive process of obtaining a code signing cert (not worth it). I know there are "tools" out there to create your own code-signing cert, and/or you can use a leaked cert. My question is how do you do this once you have created/obtained said cert. Can I just use signtool.exe or some other similar tool to do this? I've looked online for a how-to, but it seems my search strings are not doing the job. I hope this enough detail on what I'm asking...

P.S. I'd rather not us a test cert.

-Thx

EDIT:

Well, After doing even more research, I do not think this is possible. There are methods, such as KDMAPPER, but even that has been patched as of Windows 11 22H2.

<sigh>

[Elisa3167]

After you get a WHQL certificate, you have to add SHA-256 /fd 256, /td 256 and external timestamp to the command-line.

If you don't add an external timestamp, the codesign is considered "no-good" so you must add /tr.

Example:
signtool.exe sign /v /n "YourDrivername" /fd sha256 /td sha256 /tr http://timestamp.example.com/rfc3161 DriverFile.sys

Assuming you have a smartcard and smartcard reader, you have to sign-in to the smartcard device, then sign the EXE.

If you have a laptop, you need carry a mobile smartcard reader.

Advice.
Carry the smartcard around with you... Don't leave it for someone to take it...

[Kerlingen]

Microsoft defined one point in time (I think it was June 1st, 2016) and starting with Windows 10 version 1607, the following restrictions apply to kernel mode drivers without a signature from "Microsoft Windows Hardware Compatibility Publisher":

• If the signing certificate expired before June 1st, 2016, the driver is allowed to load.
• If the signing certificate became valid before June 1st, 2016 and expired after June 1st, 2016, the timestamp of the signature is checked to decide if the driver is allowed to load.
• If the signing certificate became valid after June 1st, 2016, the driver is always denied to load.

For obvious reasons you cannot get any new certificate which expires before June 1st, 2016, so you are required to have a signature from Microsoft for any drivers you want to distribute.

Even if you had an old certificate, it would be a SHA1 certificate, but since 2022 all drivers are required to have a SHA256 signature on Windows 10/11/2019/2022. (and that old certificate would probably be "leaked" and any file signed with it would get instantly deleted by anti-virus, so you couldn't even use in on 32-bit Windows 7/8/8.1)

[Stingered]

This is explains a lot (why hxxps://github.com/utoni/PastDSE doesn't work anymore, for example).

I don't know if this is possible, but if there was a "tool" (not from Digicert or similar companies) that generated a x509 SHA256 self-signed cert, then this could technically work?

Thanks again for the explanation.

[Kerlingen]

There are a lot of tools available which generate self-signed certificates, but Windows will never trust them, since they are not signed by Microsoft. Technically, even the old "kernel driver signing" certificates you bought at some certificate authority were signed by Microsoft. They were not signed directly, but Microsoft cross-signed the authority's intermediate certificate and you had to include this certificate with your signature.

This way, the certificate tree received a second "root". While the primary root certificate would be accepted by normal application software (for example, verifying the signature in Windows Explorer), it would fail the certificate check in the Windows kernel driver loader. After that, the second root certificate would be checked, traced back to a trusted Microsoft certificate (hardcoded in the loader) and permit the driver to load.

[Stingered]

So at some point in the chain, the check will result in failure. Very good explanation. I suppose I'll just have to live with using a test cert after all.

[chants]

There is always hacking the private key of a trusted signing authority. Also you could crack Windows to not check, although if on EFI, might have to hack that private key as well. Or fallback to MBR.

Sure these are the most impractical options. But worth a mention.

[DavidXanatos]

Ah yes... driver signing, a terrible mess really...
I was lucky with my projects that I fell with it into the time where leaked certs, aside of anti malware fools getting upset were working just fine. And by the time the restrictions were tied down I became able to get my drivers properly signed.


There are a few noteworthy things that I ran across which haven't yet been mentioned:
https://github.com/Mattiwatti/EfiGuard it is a bootkit that works with modern versions of windows, as long as you don't use the microsoft hypervisor, and allows you to toggle DSE on or off.
In combination with the https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk you can even have "secure boot" and load your own drivers at will. muhahahahah.....

here is a quite verbose write down of windows driver signign policy:
https://www.geoffchappell.com/notes/security/whqlsettings/index.htm?tx=40

As well as a semi supported way of using secure boot to sign your own drivers on your own pc:
https://www.geoffchappell.com/notes/windows/license/customkernelsigners.htm
only catch this is enabled only on Chinese governmental editions of windows 10
but that said there are hacks to get it working on any windows 10:
https://github.com/HyperSine/Windows10-CustomKernelSigners

Now the method of using a custom driver to keep the
HKEY_LOCAL_MACHINE\system\ControlSet001\Control\CI\Protected
"Licensed" value set to 1 is quite hacky and every time it fails you will need to manually hack the value from win PE, a custom loader which can parse and change the value in the SYSTEM hive on disk on each boot would be the best solution, but I haven't seen one yet.

Using a custom kernel signer really gives you the best combination of security and freedom, to bad MSFT want's only the Chinese government to have this.

[Elisa3167]

Another thing you could do... Fake the timestamp-server response.

The /tr http://timestamp.example.com/ and use DNS redirect to your private time-stamp server.

https://github.com/Jemmy1228/TimeStampResponder-CSharp

[Kerlingen]

Originally Posted by chants

There is always hacking the private key of a trusted signing authority.

No, there is not. The only trusted authority which has ever existed is Microsoft itself and all intermediate cross-certificates signed by Microsoft have expired at least two years ago.

Originally Posted by chants

Also you could crack Windows to not check, although if on EFI, might have to hack that private key as well. Or fallback to MBR.

If you don't want Windows to check driver signatures on your own computer, then you can just turn it off. Windows provides several official ways to load drivers without proper signatures, but they are all limited to your computer and will not work when trying to distribute the driver to regular Windows systems without modifications. Microsoft is not like Apple, so Windows still allows you to switch off security features.

Originally Posted by Elisa3167

Another thing you could do... Fake the timestamp-server response.

And why would Windows trust your fake timeserver's signature? Also, as explained above, the timestamp doesn't really matter for kernel driver signatures.

[Stingered]

Originally Posted by DavidXanatos

Ah yes... driver signing, a terrible mess really...
I was lucky with my projects that I fell with it into the time where leaked certs, aside of anti malware fools getting upset were working just fine. And by the time the restrictions were tied down I became able to get my drivers properly signed.


There are a few noteworthy things that I ran across which haven't yet been mentioned:
https://github.com/Mattiwatti/EfiGuard it is a bootkit that works with modern versions of windows, as long as you don't use the microsoft hypervisor, and allows you to toggle DSE on or off.
In combination with the https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk you can even have "secure boot" and load your own drivers at will. muhahahahah.....

here is a quite verbose write down of windows driver signign policy:
https://www.geoffchappell.com/notes/security/whqlsettings/index.htm?tx=40

As well as a semi supported way of using secure boot to sign your own drivers on your own pc:
https://www.geoffchappell.com/notes/windows/license/customkernelsigners.htm
only catch this is enabled only on Chinese governmental editions of windows 10
but that said there are hacks to get it working on any windows 10:
https://github.com/HyperSine/Windows10-CustomKernelSigners

Now the method of using a custom driver to keep the
HKEY_LOCAL_MACHINE\system\ControlSet001\Control\CI\Protected
"Licensed" value set to 1 is quite hacky and every time it fails you will need to manually hack the value from win PE, a custom loader which can parse and change the value in the SYSTEM hive on disk on each boot would be the best solution, but I haven't seen one yet.

Using a custom kernel signer really gives you the best combination of security and freedom, to bad MSFT want's only the Chinese government to have this.

Yes, I've just read up on ElfGuard and Super-UEFIinSecureBoot-Disk, but the rest I can certainly spend some time.

Great info!!!

[chants]

Originally Posted by Kerlingen

No, there is not. The only trusted authority which has ever existed is Microsoft itself and all intermediate cross-certificates signed by Microsoft have expired at least two years ago.

But your earlier post said if you are signed by an old cross certificate it loads, so hacking the private key to these expired certificates should allow arbitrary driver loading.

I agree cracking the OS isn't necessary but seems a lot of research is known in that area with enough details to easily do it. But more than just driver signing policy changes is needed to justify the troublem

[Fyyre]

Originally Posted by DavidXanatos

Using a custom kernel signer really gives you the best combination of security and freedom, to bad MSFT want's only the Chinese government to have this.

I assume the CCP edition of Windows 10 x64 has such a custom signer? I'm curious if anyone has performed a deep dive comparison between Windows 10 1809 CCP and version for other countries.

[user1]

But your earlier post said if you are signed by an old cross certificate it loads, so hacking the private key to these expired certificates should allow arbitrary driver loading.

still possible. google it.

[DavidXanatos]

Originally Posted by Fyyre

I assume the CCP edition of Windows 10 x64 has such a custom signer? I'm curious if anyone has performed a deep dive comparison between Windows 10 1809 CCP and version for other countries.

Well as described here: https://www.geoffchappell.com/notes/windows/license/customkernelsigners.htm
Its not like the CCP edition is different, its just a licensing restriction, you can trick any non CCP windows into enabling this, but the licensing service will disable it for the next reboot. So you need a driver to block that from happening. As described here: https://github.com/HyperSine/Windows10-CustomKernelSigners