How did this unsigned driver get installed on Windows 7 64 bit?

Question

While developing our 64bit driver, we came to understand that every driver needs to be correctly digitally signed to install (except in Test Mode).

Recently, we stumbled over a driver (for an USB camera), that seems to be missing a valid signature. During installation, we get the red warning screen about unsigned drivers, but the device works correctly using this driver.

I have taken photos. Sorry for the wall of images, I was afraid to miss an important point, since I obviously don't understand what's going on here.

Devive Manager

Device Manager

Driver Properties

Driver Details

enter image description here

Driver Files from %system32%\DriverStore\FileRepository

enter image description here

Certificate Details

enter image description here

Test Mode was off for this (and our own driver correctly failed to load).

How did they do that? Why is Windows loading this driver? I would be grateful for some links into the documentation explaining this behaviour.

Edit:

Using the verbose CodeIntegrity log as suggested in the comments, I find nothing off. The log shows a line

Code Integrity found a file hash for the file in oem132.cat

This file exists in %system32%\catroot\some-guid and is identical to the cat file shown in the screenshot above; expired certificate included.

signtool verify /v /c .\mvBlueFOX_amd64.cat .\mvBlueFOX2.sys gives

Verifying: .\mvBlueFOX2.sys
File is signed in catalog: .\mvBlueFOX_amd64.cat
Hash of file (sha1): 19E6125B9C5F31E21EDA5DBAA5F77798F8E394C4

Signing Certificate Chain:
    Issued to: Class 3 Public Primary Certification Authority
    Issued by: Class 3 Public Primary Certification Authority
    Expires:   Thu Aug 03 00:59:59 2028
    SHA1 hash: A1DB6393916F17E4185509400415C70240B0AE6B

        Issued to: VeriSign Class 3 Code Signing 2009-2 CA
        Issued by: Class 3 Public Primary Certification Authority
        Expires:   Tue May 21 00:59:59 2019
        SHA1 hash: 12D4872BC3EF019E7E0B6F132480AE29DB5B1CA3

            Issued to: MATRIX VISION GmbH
            Issued by: VeriSign Class 3 Code Signing 2009-2 CA
            Expires:   Tue May 07 00:59:59 2013
            SHA1 hash: 75859F3121E3852E2894E1A7B388CB9E68EBC237

File is not timestamped.

SignTool Error: A certificate chain processed, but terminated in a root
        certificate which is not trusted by the trust provider.

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

Have you looked through the options that allow unsigned drivers to permanently run? For example the DDISABLE_INTEGRITY_CHECKS within bcedit? — Samuel Nicholson, Dec 13 '13 at 15:59
No, I thought there was only TESTSIGNING. Is there a list of all those? Our own unsigned driver was not loaded, so the requirement could not have been disabled globally. — Jens, Dec 13 '13 at 19:14
IIRC, the expiry date for a certificate is not taken into consideration when used for code-signing. So if the only problem with the signature is that the certificate expired, the behaviour you describe is as-expected. (Device Manager should be showing the driver as signed, though; I'm not sure what's going on there. At a guess there's something wrong with the signature on the catalog.) — Harry Johnston, Dec 16 '13 at 00:18
@HarryJohnston: I thought that you'd need to use a timestamping service for the signing process to keep the signature valid after the certificate's expiration date. This driver seems not to have used this feature. — Jens, Dec 16 '13 at 07:18
That could explain why you get a warning during installation and why Device Manager says the driver is unsigned. But perhaps the kernel doesn't enforce that rule? — Harry Johnston, Dec 16 '13 at 19:19
Have you enabled the Code Integrity Verbose event view as per http://msdn.microsoft.com/en-us/windows/hardware/gg487332.aspx ? — Harry Johnston, Dec 16 '13 at 19:28
What does `signtool` say about the `.sys` file? Also, is it a boot-start driver? Better link for code integrity event logging: http://msdn.microsoft.com/en-us/library/ff539911%28v=vs.85%29.aspx — Harry Johnston, Dec 16 '13 at 19:36
@Harry: I've updated my post with the information you suggested. I don't think that this is a boot start driver (its only a usb camera). — Jens, Dec 17 '13 at 08:36
Not sure, but the text at the very end of the question "A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider." suggests that there might be something wrong with the root certificates on that particular computer. Maybe a root certificate update is necessary or the root certificate store is broken? — PMF, Dec 20 '13 at 08:02
@PMF: This driver installs and runs fine on several 64bit machines, despite being signed with an expired certificate. I don't think a broken certificate store is the cause for that. — Jens, Dec 20 '13 at 09:39
@Jens: Sorry, I was somehow assuming that this problem occurred only on one particular computer. — PMF, Dec 20 '13 at 10:07
Maybe it can helps you: http://www.tomshardware.co.uk/forum/3173-63-driver-signed-windows-setup and : http://www.sevenforums.com/drivers/163345-unsigned-driver-installation-during-windows-7-installation.html . This is a way to install unsigned driver manually. But I don't know, how make it programmatically. — Dima Kurilo, Dec 20 '13 at 14:15
I think the signtool output answers the question. mvBlueFOX2.sys is not "unsigned" or "test-signed". It is signed with the certificate chain that the system does not like, but not enough to reject the driver at load time. Certificate chain check results have many parameters, they may be interpreted differently by different parts of the OS. So if you could get your driver signed with similar certificate chain you would probably get the same result (the driver is loaded with warning.) — glagolig, Dec 20 '13 at 20:08
maybe i don't understand the question right but you can install unsigned driver, windows only WARNS you about a missing signature, but it will still work. you only need to sign it if you want to install drivers completely without user interaction — weberik, Feb 27 '14 at 15:54
@weberik: The 64bit versions of Windows require that kernel mode drivers are signed. — Jens, Feb 27 '14 at 15:59
@Jens I have the same thing, using unsigned drivers fine without test signing or signature enforcement disabled. The answers here are non answers. Did you ever find out why? — Lewis Kelsey, Jun 26 '22 at 01:11

score 1 · Answer 1 · answered Sep 05 '14 at 07:45

You can disable Driver Signature Check enforcement as follows. Open a command prompt as an admin and type:

bcdedit -set loadoptions DISABLE_INTEGRITY_CHECKS

bcdedit -set TESTSIGNING ON

See security risk warning. If it doesn't work for whatever reason you can just remove loadoptions with bcedit and switch testsigning off.

bcdedit /deletevalue loadoptions

bcdedit -set TESTSIGNING OFF

Goodluck!

score 0 · Answer 2 · edited May 14 '14 at 20:46

0

By default Windows 7 is set to reject unsigned drives. But there are many inside out options that can change this property. One can change these properties unknowingly. Seems this is the case with your system.

For further reference see Windows 7 - Disable signature verification of drivers

edited May 14 '14 at 20:46

Thomas Weller

55,411
20
125
222

answered Feb 27 '14 at 11:14

Charana STR

69
1
2
9

1

Welcome on StackOverflow. Please use the preview feature and check what your answer looks like. In addition, please include the relevant information of linked content so that the answer is still useful when the link is broken. – Thomas Weller May 14 '14 at 20:47

score 0 · Answer 3 · answered May 24 '14 at 08:15

Initial notification seen at the time of installation indicates that the driver is not gone through Microsoft windows hardware compatibility test. In x64, windows enforcing signed drivers is to check the integrity of the driver at load time. It doesn't validates whether the certificate is signed by a trusted root or the time stamp is valid. You can create a driver even with expired certificate. This driver is signed by a valid certificate which is expired. I used to signed my drivers with expired certificate by back dating the system time while signing & load it successfully. Code signing has to be done only with a list of vendor certificate, which is mentioned in microsoft site "VeriSign Class 3 Code Signing" is one of them.

score -1 · Answer 4 · answered Jan 13 '14 at 12:39

As way of an answer, it maybe not the answer your looking for, but it's still pertinent information on the subject.

I agree with the last comment on the post (The one you asked to be posted as the answer) but on top of that I'd also like to add that it is rather easy to get windows 7 X64 to use unsigned drivers (I know this because I have to do it to use my DVB-T usb device)

If you restart the PC and press F8 to get the F8 menu up, you should find that there is an option in there to allow unsigned drivers to run.

If you don't boot with this option there is nothing stopping you from installing the driver, but it won't run. However if you then at a later date boot your PC, use the F8 menu and select the unsigned drivers option any unsigned drivers installed in the system that previously could not run will then be seen to run.

I have to confess, I've done this myself many times, and since I can often leave my PC booted and running for 3/4 weeks at a time, I've actually booted in F8 mode, then subsequently forgot I've done so, then wondered why I have an unsigned driver running and loaded.

I'm not promoting this as the answer to your question, but I'm merely posting it as an alternative thread that you may want to explore, based on my own experiences running unsigned drivers on X64-W7

How did this unsigned driver get installed on Windows 7 64 bit?

4 Answers4