Quote:
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.