HLK tests for a camera filter driver

NTDEV
1

I’m working on a camera filter driver, based on the toaster example:
https://github.com/Microsoft/Windows-driver-samples/tree/master/general/toaster/toastDrv/kmdf/filter/generic

Now, I want to sign it for Windows 10, and I need to pass HLK tests first. I don’t see my driver in the “software device” category, but I see the camera in the “device manager” category. I tried choosing the camera and running the tests, but I fail in some tests. For example, the “InfVerif INF Verification” test checks the inf file of the camera driver, not my filter driver, and says that my inf file’s publisher must not be Microsoft.

What’s the correct way to do the tests properly in my case? Thanks.

2

xxxxx@gmail.com wrote:

I’m working on a camera filter driver, based on the toaster example:
https://github.com/Microsoft/Windows-driver-samples/tree/master/general/toaster/toastDrv/kmdf/filter/generic

Now, I want to sign it for Windows 10, and I need to pass HLK tests first. I don’t see my driver in the “software device” category, but I see the camera in the “device manager” category. I tried choosing the camera and running the tests, but I fail in some tests. For example, the “InfVerif INF Verification” test checks the inf file of the camera driver, not my filter driver, and says that my inf file’s publisher must not be Microsoft.

What’s the correct way to do the tests properly in my case? Thanks.

You’re not really installing the filter using the INF, are you?  The INF
file in the toastDrv\kmdf\filter sample doesn’t just install the
filter.  It installs a function driver PLUS the filter.  That
combination can be run through WHQL, but as far as I know, there is no
way to WHQL a filter driver by itself.

Fortunately, you don’t have to.  As a filter driver, you won’t have an
INF.  You’ll install this manually, by copying the file, creating a
service, and tweaking the registry.  There won’t be a driver package as
such.  You can use create a fake package using a fake INF, run the fake
package through the attestation signing process, and deliver the signed
filter driver.  The attestation-signed driver is indistinguishable from
a WHQL-signed driver.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

> You’re not really installing the filter using the INF, are you?

Actually, I am. But I’m using an INF file which is based on the following, not on the toaster INF file:

https://github.com/flowerinthenight/windows-camera-class-filter-driver/blob/master/ccfltr/ccfltr.inf

Why not use an INF file? Is it not the correct way?

run the fake package through the attestation signing process

I see that attestation signing works for Windows 10, and I indeed was able to use it without passing any tests. Nice! But what about Windows 7 and 8?

4

On May 27, 2018, at 7:03 AM, xxxxx@gmail.com wrote:
>
>> You’re not really installing the filter using the INF, are you?
>
> Actually, I am. But I’m using an INF file which is based on the following, not on the toaster INF file:
>
> https://github.com/flowerinthenight/windows-camera-class-filter-driver/blob/master/ccfltr/ccfltr.inf
>
> Why not use an INF file? Is it not the correct way?

Well, a [DefaultInstall] INF is not a PnP INF in the normal sense. It’s basically a shortcut for an installation app. It does work, and I shouldn’t disparage them…

> I see that attestation signing works for Windows 10, and I indeed was able to use it without passing any tests. Nice! But what about Windows 7 and 8?

Your traditional cross-signing will continue to work well on Windows 7 and Windows 8. When you use attestation signing, the CAT file you get back is only valid for Windows 10, but for a filter driver, you don’t need to use the CAT file. The signed driver file you get back will work just fine in all versions of Windows.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

> Your traditional cross-signing will continue to work well on Windows 7 and Windows 8.

I did that. It works on Windows 10, but Windows 7 says that the driver is not signed, even though it shows as signed in the .sys file properties, which is weird. I tried both using the inf file and using sc create, both show the same unsigned error. I tried both signing with sha1 and sha256, the result is the same.
Any hints?

6

On May 28, 2018, at 2:29 AM, xxxxx@gmail.com wrote:
>
>> Your traditional cross-signing will continue to work well on Windows 7 and Windows 8.
>
> I did that. It works on Windows 10, but Windows 7 says that the driver is not signed, even though it shows as signed in the .sys file properties, which is weird. I tried both using the inf file and using sc create, both show the same unsigned error. I tried both signing with sha1 and sha256, the result is the same.

Signed and cross-signed? You’ve checked that “signtool verify /v /kp xxxx.sys” actually shows the Microsoft Code Verification Root?

An un-modified original Windows 7 system will not handle SHA256, but if you’re up-to-date on your updates, it should be fine.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

Below is the signtool output. Looks good to me, so I’m quite puzzled.
Screenshot: https://i.imgur.com/WDYo9GZ.png

signtool.exe verify /v /kp CamFilter.sys

Verifying: CamFilter.sys

Signature Index: 0 (Primary Signature)
Hash of file (sha1):

Signing Certificate Chain:
Issued to: DigiCert High Assurance EV Root CA
Issued by: DigiCert High Assurance EV Root CA
Expires:
SHA1 hash:

Issued to: DigiCert EV Code Signing CA (SHA2)
Issued by: DigiCert High Assurance EV Root CA
Expires:
SHA1 hash:

Issued to:
Issued by: DigiCert EV Code Signing CA (SHA2)
Expires:
SHA1 hash:

The signature is timestamped: Tue May 29 10:47:44 2018
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires:
SHA1 hash:

Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires:
SHA1 hash:

Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires:
SHA1 hash:

Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires:
SHA1 hash:

Issued to: DigiCert High Assurance EV Root CA
Issued by: Microsoft Code Verification Root
Expires:
SHA1 hash:

Issued to: DigiCert EV Code Signing CA (SHA2)
Issued by: DigiCert High Assurance EV Root CA
Expires:
SHA1 hash:

Issued to:
Issued by: DigiCert EV Code Signing CA (SHA2)
Expires:
SHA1 hash:

File has page hashes.

Successfully verified: CamFilter.sys

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0

8

xxxxx@gmail.com wrote:

Below is the signtool output. Looks good to me, so I’m quite puzzled.
Screenshot: https://i.imgur.com/WDYo9GZ.png

> signtool.exe verify /v /kp CamFilter.sys

Some time ago I had a similar problem.

The reason was that all certificates were available in the certification
store on my development machine, so signtool always returned success
when I ran it on that machine.

However, a cross cert was missing in the cert chain of signatures
appended to the file, so only when I ran signtool on a different machine
with none of my certs in the cert store I got an appropriate error
telling that a cross cert was missing from the file.

Haven’t looked at the details of this thread, but this sounds similar.

Martin

Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: xxxxx@meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de https://www.meinbergglobal.com
Training: https://www.meinberg.academy

9

Thank you for trying to help Martin.

I restored a clean after-install snapshot of Windows 7 SP1 x64, and ran signtool with the above command. Got the same output, including the Cross Certificate Chain. Then I tried to install the driver via the inf file, and got the same “Windows requires a digitally signed driver” error.

Any other clues are welcome.

10

xxxxx@gmail.com wrote:

Thank you for trying to help Martin.

I restored a clean after-install snapshot of Windows 7 SP1 x64, and ran signtool with the above command. Got the same output, including the Cross Certificate Chain. Then I tried to install the driver via the inf file, and got the same “Windows requires a digitally signed driver” error.

Any other clues are welcome.

OK, one more idea.

Our kernel driver file has 2 signatures: SHA1 and SHA256.

A basic install of even Windows Server 2008 R2 SP1 was unable to
detect and verify the signature of the kernel driver file. What I
observed is:

  • In the device manager, if you open the properties page for the device,
    click on the “Driver” tab, and then “Driver Details”, then the “Driver
    File Details” dialog says, “Not digitally signed”.

  • However, in the file manager, when I right-clicked on the driver file
    located in c:\windows\system32\drivers\ and selected “Properties” from
    the context menu, then only *one* signature was reported on the “Digital
    signatures” tab, but no hint which signature this refers to, i.e. the
    SHA1 or the SHA256 signature.

Anyway, after I had applied all online updates that are available today,
the “Digital signatures” tab of the properties of the driver file shows
both signatures, the kernel driver loads fine and the driver works as
expected, even though the “Driver File Details” from the device manager
still says, “Not digitally signed”.

So it turned out that a patch after SP1 was required to fix this. See also:

https://support.microsoft.com/en-us/help/3033929/microsoft-security-advisory-availability-of-sha-2-code-signing-support

https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2015/3033929

Don’t know if this also works with EV certs, or if another patch is
required to support that one.

I’ve recently ordered an EV cert but haven’t received it, yet.

Martin

Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: xxxxx@meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de https://www.meinbergglobal.com
Training: https://www.meinberg.academy

11

Hi Paul,
Maybe I’m wrong , but
it seems that you forgot to enable the testsigning bootconfig on your testsystem.
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/the-testsigning-boot-configuration-option

Hans.

12

Thank you Martin, you pushed me in the right direction. After installing the update, I was able to get the filter driver to load.

Turns out that the sha1 signature was a sha256 in disguise. It showed up as sha1, but the certification path used sha256, so probably the kernel wasn’t able to handle it without the update.

After a bit of Googling I stumbled upon the following guide, and DigiCert support confirmed that it’s the way to go to issue an additional, real sha1 certificate.
https://www.digicert.com/code-signing/code-signing-dual-signing-sha256-sha1.htm

It works like a charm now. Thank you for your help guys :slight_smile:

13

xxxxx@kobil.de wrote:

Hi Paul,
Maybe I’m wrong , but
it seems that you forgot to enable the testsigning bootconfig on your testsystem.
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/the-testsigning-boot-configuration-option

No, the point of this whole exercise is that he has a
legitimately-signed driver package.  He’s not doing test signing.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.