|
#1
|
|||
|
|||
Signing a Windows Kernel driver without using Microsoft
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> Last edited by Stingered; 01-26-2023 at 10:22. |
#2
|
|||
|
|||
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... |
#3
|
|||
|
|||
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":
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) |
#4
|
|||
|
|||
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. Last edited by Stingered; 01-27-2023 at 00:10. |
#5
|
|||
|
|||
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. |
#6
|
|||
|
|||
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.
|
#7
|
|||
|
|||
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. |
#8
|
|||
|
|||
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. |
The Following 3 Users Say Thank You to DavidXanatos For This Useful Post: | ||
#9
|
|||
|
|||
Quote:
Great info!!! |
#10
|
||||
|
||||
Quote:
__________________
Best Wishes, Fyyre -- https://github.com/Fyyre |
The Following User Says Thank You to Fyyre For This Useful Post: | ||
chants (01-28-2023) |
#11
|
|||
|
|||
Quote:
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 |
#12
|
|||
|
|||
Quote:
Original repo hxxps://github.com/vyvojar/slshim His other repos are also about spp. I worked with him as a tester while he was developing it. Somewhere I will have the latest version of his patch. If requested I can search it. |
#13
|
|||
|
|||
#14
|
|||
|
|||
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 |
#15
|
|||
|
|||
Quote:
Quote:
And why would Windows trust your fake timeserver's signature? Also, as explained above, the timestamp doesn't really matter for kernel driver signatures. |
Thread Tools | |
Display Modes | |
|
|