Patching in your own kernel signing certificate

[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.

[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.

[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.