Patching in your own kernel signing certificate

[tame_mpeg]

I need a signing certificate which is completely trusted by an up to date version of windows.
Test signing is an option for some purposes, but many applications don't like it being enabled. I’m also aware of tools to disable PatchGuard and DSE.
There are leaked certificates and timestamp spoofing tools but they don't play well with up to date versions of windows and kernel driver signing.

I came across this writeup which describes a process of patching bootmgfw.efi to replace the signature of an unimportant Microsoft Test signing certificate with your own certificate. The final result of doing this is you get your own certificate which can sign drivers without compromising the security or stability of Windows.
The writeup:
https://github.com/Avery3R/re-writeups/blob/master/windows-ci/part1_on_disk_patching.md

The writeup doesn't go into much detail and I don't know if I could figure out how to try it myself.
Has anyone else done something like this? Do you think it would still work?
Anyone have links to any other resources or tools which could help do the things in that writeup?

[Kerlingen]

I attached a kernel debugger to my VM and tried to load the driver with devcon

This is already the first mistake made in the article: As soon as a kernel debugger is attached, many of the kernel protection features are automatically disabled, including the kernel signature verification. Drivers do not even need a test signed certificate in this case, they will load even without any signature.

manually added my root certificate to the trusted roots store the normal way

This is also total nonsense. The root certificates for kernel signing are hard-coded in the executable files, they are never read from the trusted roots store. The whole article seems to focus on removing certificate warnings in the GUI, a part which has absolutely nothing to do with the decision if a kernel driver is permitted to load or not.

[KostyantynX]

Originally Posted by tame_mpeg

I
The writeup:
https://github.com/Avery3R/re-writeups/blob/master/windows-ci/part1_on_disk_patching.md

The writeup doesn't go into much detail and I don't know if I could figure out how to try it myself.
Has anyone else done something like this? Do you think it would still work?
Anyone have links to any other resources or tools which could help do the things in that writeup?

In that writeup the author ends by saying "If you have any questions or comments, feel free to get in touch with me on reddit /u/Avery3R or twitter @Avery3R."
Did you try to contact him directly?
You may get better answers directly from the author?

[tame_mpeg]

Originally Posted by Kerlingen

This is already the first mistake made in the article: As soon as a kernel debugger is attached, many of the kernel protection features are automatically disabled, including the kernel signature verification. Drivers do not even need a test signed certificate in this case, they will load even without any signature.



This is also total nonsense. The root certificates for kernel signing are hard-coded in the executable files, they are never read from the trusted roots store. The whole article seems to focus on removing certificate warnings in the GUI, a part which has absolutely nothing to do with the decision if a kernel driver is permitted to load or not.

Thanks for the insight.

I don't suppose it's viable to permanently patch in any of your own certificates then.




Does anyone know if there a central location where windows stores blacklisted certificates? Could this be easier to tamper with?

I recently cracked a program by patching a dll. The parent process won't load if any of its dlls are unsigned. Signing with your own certificate which you added to the trusted store does not work. I had to sign it with a leaked NVIDIA cert and then everything worked fine.
After updating windows the cracked program won't load anymore due to an invalid signature error on that dll. even through Windows explorer still shows it as validly signed. I assume the update bundled some kind of blacklist which broke that signing. Would be nice if I could keep the updates but get rid of the blacklisted certificates they include.

[KostyantynX]

Originally Posted by tame_mpeg

Thanks for the insight.

I don't suppose it's viable to permanently patch in any of your own certificates then.




Does anyone know if there a central location where windows stores blacklisted certificates? Could this be easier to tamper with?

I recently cracked a program by patching a dll. The parent process won't load if any of its dlls are unsigned. Signing with your own certificate which you added to the trusted store does not work. I had to sign it with a leaked NVIDIA cert and then everything worked fine.
After updating windows the cracked program won't load anymore due to an invalid signature error on that dll. even through Windows explorer still shows it as validly signed. I assume the update bundled some kind of blacklist which broke that signing. Would be nice if I could keep the updates but get rid of the blacklisted certificates they include.

Windows maintains a list of blacklisted certificates in a few different locations, primarily through the use of the Certificate Revocation List (CRL) and the Online Certificate Status Protocol (OCSP). These mechanisms are designed to ensure that certificates that have been compromised or are no longer valid are not trusted by the system.

1. Certificate Revocation List (CRL): This is a list of certificates that have been revoked by the Certificate Authority (CA) before their expiration date. Windows checks this list when validating certificates.

2. Trusted Root Certification Authorities: Windows has a store for trusted root certificates, but it also has a mechanism for blacklisting certificates that are no longer trusted.

3. Windows Update: Microsoft periodically updates the list of trusted and untrusted certificates through Windows Update. This can include adding new root certificates and blacklisting compromised ones.

Tampering with these lists is not straightforward and can lead to system instability or security vulnerabilities. Additionally, modifying system files or settings to bypass security measures can violate the terms of service for Windows and may expose your system to risks.

If you're encountering issues with a patched program after a Windows update, it's likely that the update included a new blacklist or modified the way signatures are validated. Unfortunately, there isn't a simple or safe way to selectively remove blacklisted certificates from Windows updates without risking system integrity.

For your specific situation, you might consider:

- Using a Virtual Machine: Run the patched program in a virtual machine with an older version of Windows that doesn't have the updated blacklist.
- Reverting Updates: If possible, you could revert to a previous version of Windows before the update that caused the issue, but this is not always feasible or secure.
- Exploring Alternative Patching Methods: Look for other ways to patch the program that do not rely on certificate signing.

Keep in mind that modifying software in this way can have legal and ethical implications, and it's important to consider the risks involved.

I still suggest that you consider contacting the author of the writeup.

[chants]

So this is implying the certificate manager API is useless in context of AuthentiCode certs? I assumed that as long as the TRCA has it and Trusted Publishers, you would be good, but i think this changed some years back.

So presumably Microsoft maintains TRCA, Trusted Publishers, revocations for Authenticide on kernel drivers in some hard coded way in the loader or near it at least. The question of where exactly is definetly an interesting one, though with memory integrity and signature checks on load, it won't be easy to patch the OS kernel. Doesn't look like an elegant solution exists beyond using test certificates in test signing mode.

[niculaita]

If you have a valid and trusted certificate, please sign these files https://we.tl/t-It39b2B9cv for me, so that I will not use test signing anymore!

[Fyyre]

Originally Posted by Kerlingen

This is also total nonsense. The root certificates for kernel signing are hard-coded in the executable files, they are never read from the trusted roots store. The whole article seems to focus on removing certificate warnings in the GUI, a part which has absolutely nothing to do with the decision if a kernel driver is permitted to load or not.

Right.. GUI warnings are not important.

Whole point of UPGDSED was to implement my "six byte pg/ds kill" in a more eleoquent manner.

Motivation came from wanting to keep making utility rootkits for x64 Windows - when Microsoft came out with signing for drivers. Signing is much bigger ass pain than KPP .. disable of KPP is same last version of Windows 11 I check...

Neat people still want to do this. Personally, I never cared enough to mess with the UEFI crap... not so sure its going to be all that different with it..

change exection flow, change the world.

[Fyyre]

Originally Posted by niculaita

If you have a valid and trusted certificate, please sign these files https://we.tl/t-It39b2B9cv for me, so that I will not use test signing anymore!

Sure.. not sure it will load a driver, but my company has valid code signing cert.. will DM you result, test then let me know.

[niculaita]

Problem was/are cat files. Have to be signed too same certificate as sys files.

[niculaita]

The hash for the file (Exetools.sys) is not present in the specified catalog file. The file is likely corrupt or the victim of tampering.
închidere

[niculaita]

So, please again sign again sys and cat acording to name, .sys and .inf files!
In .inf file DriverVer=08/05/2024,1.0.0.0001