How does NVCleanstall rebuild security catalogs?

[FuzzleSnuz]

I've been using NVCleanstall since I discovered it about a year ago and it works great. One of its features intrigues me: adding new device identifiers to the various INFs and rebuilding the associated security catalogs. I have a use-case for that ability on something different: Intel's RST driver, which neglects to include their latest Optane devices, one of which I recently purchased and was disappointed to find is not "supported" by that specific driver.

So my question is, how does NVCleanstall rebuild the security catalogs without using a test-signing certificate? Being that it is a CLR application, I would gladly take a look into the msil and learn for myself, but Mr. W1zzard has of course obfuscated it I recall seeing a thread here on this site within the last year where someone else lamented the fact that the program is not easily disassembled and they could not learn how it achieved some task, and in that thread W1zzard made a post saying he would be happy to explain how NVCleanstall does certain tasks without divulging the exact source code. I don't know if that offer is still on the table, but I would love to know how NVCleanstall is rebuilding these security catalogs, so that I can replicate that ability for myself to fix this stupid Intel driver.

And I really hope the answer isn't simply paying two grand for NVCleanstall's own big boy certificate™ from Sectigo or something.

 

[W1zzard]

It generates a self-signed certifiacte and puts that in the trusted store of the machine

And I really hope the answer isn't simply paying two grand for NVCleanstall's own big boy certificate™ from Sectigo or something.

I do have one of those expensive EV code signing certificate, but obviously can't ship the private key with NVCleanstall

 

[FuzzleSnuz]

Damn, I was hoping it was some kind of clever black magic. I suppose self-signing works in this case because the Nvidia driver's kernel mode PEs don't need their accompanying infs modified?

Thanks for the response.

 

[W1zzard]

I suppose self-signing works in this case because the Nvidia driver's kernel mode PEs don't need their accompanying infs modified?

I do modify the INF, this is np. You obviously have to rebuild the hashes in the CAT file

some kind of clever black magic

Actually being able to circumvent the system would be a major security issue that I would report to MS .. even though the whole EV/signing system is in a sad state

 

[FuzzleSnuz]

I do modify the INF, this is np. You obviously have to rebuild the hashes in the CAT file

I'm always kicking myself for not getting into win32 and learning it properly. I think I'm confused here over an assumption I have that might not be correct.

What I'm uncertain about is a lack of agreement between the signatures on the kernel mode files and those in the cat files. That is, the scenario where a .sys is signed by Nvidia and also cross-signed by a Microsoft WHQL cert, but the signature for the .inf (stored in the .cat) is instead self-signed by NVCleanstall's one-off certificate. Wouldn't Windows refuse to load the driver because the signature for the .inf is not the same certificate used to sign the .sys file(s)? I could be completely wrong here but I thought that the same certificate used on the inf file also had to be used to sign every .dll and .sys that said inf file installs.

 

[W1zzard]

because the signature for the .inf is not the same certificate used to sign the .sys file(s)?

That's not enforced. The .sys only needs to be signed with a MS WHQL signature, so no way to modify the .sys

 

[FuzzleSnuz]

That's not enforced. The .sys only needs to be signed with a MS WHQL signature, so no way to modify the .sys

Ok, good to know. Thanks for the help and for maintaining NVCleanstall!