How to permanently disable driver signature enforcement during HLK testing?

One problem i have encountered during HLK testing, is that when i disable driver signature enforcement during HLK testing and set the testsigning on (because obviously i have not received the Microsoft digital certificate to load and install drivers normally), after reboot which is required by some tests, the signature enforcement comes back on.

Note that i have disabled DSE by holding shift during shutdown and pressing 7 during boot.

My questions are:

  1. Shouldn’t i do the tests with a driver that is not signed? Because i think if i do a self sign it might solve the problem, but wouldn’t Microsoft just append its signature after my self signed cert in that case? What is the official way of doing the tests?

  2. How is my test passing after reboot when my driver is not even loaded?! For example the Hyper-V test seems to require a reboot even tho it states it doesn’t, and the funny thing is that after the reboot, even tho my driver is not even loaded anymore, i pass the tests! This doesn’t even make any sense?

use bcdedit to enable testsigning and install the test cert.
Mark Roddy

@Mark_Roddy said:
use bcdedit to enable testsigning and install the test cert.
Mark Roddy

But if i self sign the driver and then create the package, wouldn’t that cause Microsoft to append its signature after my self sign cert? Because that’s the case with attestation signing.

If you sign your SYS file, then they will append their signature. However, they throw out your CAT file and create a brand new one, so it will only contain the Microsoft signature.

@Tim_Roberts said:
If you sign your SYS file, then they will append their signature. However, they throw out your CAT file and create a brand new one, so it will only contain the Microsoft signature.

So what should i do if i want the final driver (not the cat) to be signed only by Microsoft and not have a self signed cert? Signtool doesn’t seem to have an option to remove a specific signature from the driver.

Because it seems like i have two options right now:

  1. Self sign the driver and do the HLK tests, but that causes the package to contain the self signed driver, thus Microsoft appends its signature.

  2. Don’t self sign the driver and disable the DSE during boot (testsigning is not enough in this case), but this causes the driver to not load when HLK reboots the machine, because disabling the DSE requires holding shift during reboot, etc.

So what should i do if i want the final driver (not the cat) to be signed only by Microsoft and not have a self signed cert?

Why would you go to the trouble? What do you gain?

@Tim_Roberts said:

So what should i do if i want the final driver (not the cat) to be signed only by Microsoft and not have a self signed cert?

Why would you go to the trouble? What do you gain?

I Think OP doesn’t want their production driver to have a self signed digital certificate in it, also i think having a self signed digital certificate as the first certificate caused problems on some systems, didn’t it?

@Richard_M said:
2. How is my test passing after reboot when my driver is not even loaded?! For example the Hyper-V test seems to require a reboot even tho it states it doesn’t, and the funny thing is that after the reboot, even tho my driver is not even loaded anymore, i pass the tests! This doesn’t even make any sense?

This is really strange, surely if the driver is not loaded after the reboot the test should fail, but then again, nothing is certain with HLK… i also encounter so many random problems with it.

@Tim_Roberts said:

So what should i do if i want the final driver (not the cat) to be signed only by Microsoft and not have a self signed cert?

Why would you go to the trouble? What do you gain?

@brad_H said:

@Tim_Roberts said:

So what should i do if i want the final driver (not the cat) to be signed only by Microsoft and not have a self signed cert?

Why would you go to the trouble? What do you gain?

I Think OP doesn’t want their production driver to have a self signed digital certificate in it, also i think having a self signed digital certificate as the first certificate caused problems on some systems, didn’t it?

That is correct, i want my final driver to only have a Microsoft signature, having a self signed signature before the Microsoft signature probably will cause problems and there is no need for a self sign signature to be present in there.

Well as far as I know, you can test with one binary and submit a
different binary, I don’t think there is any verification or attempt to
exclude you from doing that. But also, again as far as I know, WHQL only
signs the cat file and it creates its own cat file.

Before the Big Clamp Down, release signing the binaries was a typical
approach. Easy to do, easy to test, easy to submit. Now you need
attestation signing. So do that and stop worrying about it.

Mark Roddy

You don’t have to sign the .SYS file for your testing. All you have to sign is the CAT, and Microsoft replaces that.

Because it seems like i have two options right now:

  1. Self sign the driver and do the HLK tests, but that causes the package to contain the self signed driver, thus Microsoft appends its signature.

  2. Don’t self sign the driver and disable the DSE during boot (testsigning is not enough in this case), but this causes the driver to not load when HLK reboots the machine, because disabling the DSE requires holding shift during reboot, etc.

A third option is what I do. Use the MSFT portal to attestation sign the driver. Put that on your HLK machine without any need to disable signature checks nor install a test cert. When you are done, roll up that same signed driver in the HLK package and send it to MSFT again. When it comes back it (the .sys) has their sig and my real sig (i.e. not a test sig) and we’re done. Because a .cat is not a PE file it can only hold one signature so it is limited to the MSFT one no matter what you do. But I like additionally having my sig on the driver itself.

@Mark_Roddy said:
Well as far as I know, you can test with one binary and submit a
different binary, I don’t think there is any verification or attempt to
exclude you from doing that. But also, again as far as I know, WHQL only
signs the cat file and it creates its own cat file.

I’ve never tried this but that would be shocking. To the point of making the entire HLK process pointless. If you could just run all the tests with a dummy passthrough driver, and then submit your completely different driver, then what exactly are we certifying? Surely the process can’t have that big of a hole??

I can only speak for the case of a non-pnp driver, but from my experience you can request an attestation signature then add your signature to the .sys file after that of MS. It works for Windows 10 and 7.

I don’t think that many will disagree that the various testing and signing processes put in place by Microsoft over the years are useless. But consider that their purpose is something a bit different than what you imagine. They artificially increase the barrier to produce a driver; which means that anyone who does so has something to loose, and they establish a legal basis for culpability if your product is constructed in an unethical way. The same is true of all engineering and technical standards processes. Various government and regulatory bodies are tasked with ensuring the safety etc. of things that they can’t possibly evaluate themselves, so they turn the regulations around and make it a professional and ethical obligation on the part of the practitioners who can.

@Mark_Roddy said:
Well as far as I know, you can test with one binary and submit a
different binary, I don’t think there is any verification or attempt to
exclude you from doing that. But also, again as far as I know, WHQL only
signs the cat file and it creates its own cat file.

Is it actually possible with the HLK? If so, by replacing the driver on the test client after passing the tests and before building the packet?