Driver Signing Issue with Windows 7 64-Bit Install

Have a Windows 7 driver built with Microsoft VS 2013. I am signing the package and have obtained a Production Certificate. I am not signing the driver itself.

When built as a 32-bit driver, everything works fine and I get a window asking me if I want to install the driver with our company name. Works as expected!

When built as a 64-bit driver, it does not behave the same way. Now I get a window stating “Windows can’t verify the publisher of this driver software”. I am using the same certificate!
When the INF file is selected, it appears to be signed and there is a “This driver has an Authenticode™ signature” message.

I get the following in setupapi.dev.log:

sig: {_VERIFY_FILE_SIGNATURE} 09:43:50.815
sig: Key = uio48.inf
sig: FilePath = C:\Windows\System32\DriverStore\Temp{15abed4f-b7f1-3277-48d0-5421bb960b6e}\uio48.inf
sig: Catalog = C:\Windows\System32\DriverStore\Temp{15abed4f-b7f1-3277-48d0-5421bb960b6e}\uio48.cat
flq: {SPFILENOTIFY_CABINETINFO}
flq: {SPFILENOTIFY_CABINETINFO - exit(0x00000000)}
flq: {SPFILENOTIFY_FILEEXTRACTED}
flq: {SPFILENOTIFY_FILEEXTRACTED - exit(0x00000000)}
flq: {SPFILENOTIFY_CABINETINFO}
flq: {SPFILENOTIFY_CABINETINFO - exit(0x00000000)}
flq: {SPFILENOTIFY_FILEEXTRACTED}
flq: {SPFILENOTIFY_FILEEXTRACTED - exit(0x00000000)}
! sig: Verifying file against specific (valid) catalog failed! (0x800b0109)
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
sig: {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 09:43:50.877
sig: {_VERIFY_FILE_SIGNATURE} 09:43:50.877
sig: Key = uio48.inf
sig: FilePath = C:\Windows\System32\DriverStore\Temp{15abed4f-b7f1-3277-48d0-5421bb960b6e}\uio48.inf
sig: Catalog = C:\Windows\System32\DriverStore\Temp{15abed4f-b7f1-3277-48d0-5421bb960b6e}\uio48.cat
flq: {SPFILENOTIFY_CABINETINFO}
flq: {SPFILENOTIFY_CABINETINFO - exit(0x00000000)}
flq: {SPFILENOTIFY_FILEEXTRACTED}
flq: {SPFILENOTIFY_FILEEXTRACTED - exit(0x00000000)}
flq: {SPFILENOTIFY_CABINETINFO}
flq: {SPFILENOTIFY_CABINETINFO - exit(0x00000000)}
flq: {SPFILENOTIFY_FILEEXTRACTED}
flq: {SPFILENOTIFY_FILEEXTRACTED - exit(0x00000000)}
sig: Success: File is signed in Authenticode™ catalog.
sig: Error 0xe0000242: The publisher of an Authenticode™ signed catalog has not yet been established as trusted.
sig: {_VERIFY_FILE_SIGNATURE exit(0xe0000242)} 09:43:50.955
sto: Validating driver package files against catalog ‘uio48.cat’.
!!! sto: Failed to verify file ‘WdfCoInstaller01011.dll’ against catalog. Catalog = uio48.cat, Error = 0xE000024B
!!! sto: Catalog did not contain file hash. File is likely corrupt or a victim of tampering.
!!! sto: Driver package appears to be tampered. Filename = C:\Windows\System32\DriverStore\Temp{15abed4f-b7f1-3277-48d0-5421bb960b6e}\uio48.inf, Error = 0x800F024B
! sto: Driver package appears to be tampered but user wants to install it anyway.

I am running out of ideas. Thanks in advance fo any assistance.

Peter,

you have created a separate NG for WinDbg.

Can you also create one for driver signing? :slight_smile:


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Have a Windows 7 driver built with Microsoft VS 2013. I am signing the package and have obtained a Production Certificate. I am not signing the driver itself.
>
> When built as a 32-bit driver, everything works fine and I get a window asking me if I want to install the driver with our company name. Works as expected!
>
> When built as a 64-bit driver, it does not behave the same way. Now I get a window stating “Windows can’t verify the publisher of this driver software”. I am using the same certificate!
> When the INF file is selected, it appears to be signed and there is a “This driver has an Authenticode™ signature” message.
>
> I get the following in setupapi.dev.log:
>
> sig: {_VERIFY_FILE_SIGNATURE} 09:43:50.815
> sig: Key = uio48.inf
> sig: FilePath = C:\Windows\System32\DriverStore\Temp{15abed4f-b7f1-3277-48d0-5421bb960b6e}\uio48.inf
> sig: Catalog = C:\Windows\System32\DriverStore\Temp{15abed4f-b7f1-3277-48d0-5421bb960b6e}\uio48.cat
> flq: {SPFILENOTIFY_CABINETINFO}
> flq: {SPFILENOTIFY_CABINETINFO - exit(0x00000000)}
> flq: {SPFILENOTIFY_FILEEXTRACTED}
> flq: {SPFILENOTIFY_FILEEXTRACTED - exit(0x00000000)}
> flq: {SPFILENOTIFY_CABINETINFO}
> flq: {SPFILENOTIFY_CABINETINFO - exit(0x00000000)}
> flq: {SPFILENOTIFY_FILEEXTRACTED}
> flq: {SPFILENOTIFY_FILEEXTRACTED - exit(0x00000000)}
> ! sig: Verifying file against specific (valid) catalog failed! (0x800b0109)
> ! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
> sig: {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 09:43:50.877
> sig: {_VERIFY_FILE_SIGNATURE} 09:43:50.877
> sig: Key = uio48.inf
> sig: FilePath = C:\Windows\System32\DriverStore\Temp{15abed4f-b7f1-3277-48d0-5421bb960b6e}\uio48.inf
> sig: Catalog = C:\Windows\System32\DriverStore\Temp{15abed4f-b7f1-3277-48d0-5421bb960b6e}\uio48.cat
> flq: {SPFILENOTIFY_CABINETINFO}
> flq: {SPFILENOTIFY_CABINETINFO - exit(0x00000000)}
> flq: {SPFILENOTIFY_FILEEXTRACTED}
> flq: {SPFILENOTIFY_FILEEXTRACTED - exit(0x00000000)}
> flq: {SPFILENOTIFY_CABINETINFO}
> flq: {SPFILENOTIFY_CABINETINFO - exit(0x00000000)}
> flq: {SPFILENOTIFY_FILEEXTRACTED}
> flq: {SPFILENOTIFY_FILEEXTRACTED - exit(0x00000000)}
> sig: Success: File is signed in Authenticode™ catalog.
> sig: Error 0xe0000242: The publisher of an Authenticode™ signed catalog has not yet been established as trusted.
> sig: {_VERIFY_FILE_SIGNATURE exit(0xe0000242)} 09:43:50.955
> sto: Validating driver package files against catalog ‘uio48.cat’.
> !!! sto: Failed to verify file ‘WdfCoInstaller01011.dll’ against catalog. Catalog = uio48.cat, Error = 0xE000024B
> !!! sto: Catalog did not contain file hash. File is likely corrupt or a victim of tampering.
> !!! sto: Driver package appears to be tampered. Filename = C:\Windows\System32\DriverStore\Temp{15abed4f-b7f1-3277-48d0-5421bb960b6e}\uio48.inf, Error = 0x800F024B
> ! sto: Driver package appears to be tampered but user wants to install it anyway.
>
> I am running out of ideas. Thanks in advance fo any assistance.
>

xxxxx@winsystems.com wrote:

Have a Windows 7 driver built with Microsoft VS 2013. I am signing the package and have obtained a Production Certificate. I am not signing the driver itself.

When built as a 32-bit driver, everything works fine and I get a window asking me if I want to install the driver with our company name. Works as expected!

When built as a 64-bit driver, it does not behave the same way. Now I get a window stating “Windows can’t verify the publisher of this driver software”. I am using the same certificate!

! sig: Verifying file against specific (valid) catalog failed! (0x800b0109)
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

That’s ignorable. You will get that until your package is signed by WHQL.

sto: Validating driver package files against catalog ‘uio48.cat’.
!!! sto: Failed to verify file ‘WdfCoInstaller01011.dll’ against catalog. Catalog = uio48.cat, Error = 0xE000024B
!!! sto: Catalog did not contain file hash. File is likely corrupt or a victim of tampering.
!!! sto: Driver package appears to be tampered. Filename = C:\Windows\System32\DriverStore\Temp{15abed4f-b7f1-3277-48d0-5421bb960b6e}\uio48.inf, Error = 0x800F024B
! sto: Driver package appears to be tampered but user wants to install it anyway.

I assume you can see the error there. It’s saying that the copy of
WdfCoInstaller01011.dll that it found in your package is not the same
one that was there when you built your CAT file. Are you creating your
final driver package by hand, or are you letting the project do it? If
you’re building it by hand, do you understand that there are different
co-installer DLLs for 32-bit and 64-bit?


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

I have made some progress. I was using the 32-bit version of the Coinstaller. Once I used the right version, I now receive a message asking if I want to install drivers from our company. Looks good so far.

Now Windows 7 64-bit is requiring that I use signed drivers. I get a Program Compatibility Assistant window that states “Windows requires a digitally signed driver”. From what I have read, I thought that only the package has to be signed.

Is there some setting that I need to change?

! sig: Verifying file against specific (valid) catalog failed! (0x800b0109)
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
sig: {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 12:04:11.336
sig: {_VERIFY_FILE_SIGNATURE} 12:04:11.336
sig: Key = uio48.inf
sig: FilePath = C:\Windows\System32\DriverStore\Temp{0d8684c3-fe81-22d4-ad1a-060d69414c73}\uio48.inf
sig: Catalog = C:\Windows\System32\DriverStore\Temp{0d8684c3-fe81-22d4-ad1a-060d69414c73}\uio48.cat
flq: {SPFILENOTIFY_CABINETINFO}
flq: {SPFILENOTIFY_CABINETINFO - exit(0x00000000)}
flq: {SPFILENOTIFY_FILEEXTRACTED}
flq: {SPFILENOTIFY_FILEEXTRACTED - exit(0x00000000)}
flq: {SPFILENOTIFY_CABINETINFO}
flq: {SPFILENOTIFY_CABINETINFO - exit(0x00000000)}
flq: {SPFILENOTIFY_FILEEXTRACTED}
flq: {SPFILENOTIFY_FILEEXTRACTED - exit(0x00000000)}
sig: Success: File is signed in Authenticode™ catalog.
sig: Error 0xe0000242: The publisher of an Authenticode™ signed catalog has not yet been established as trusted.
sig: {_VERIFY_FILE_SIGNATURE exit(0xe0000242)} 12:04:11.398
sto: Validating driver package files against catalog ‘uio48.cat’.
! sto: Driver package signer is unknown but user trusts the signer.

Padon my lack of experience, but what is an NG?

xxxxx@winsystems.com wrote:

I have made some progress. I was using the 32-bit version of the Coinstaller. Once I used the right version, I now receive a message asking if I want to install drivers from our company. Looks good so far.

Now Windows 7 64-bit is requiring that I use signed drivers. I get a Program Compatibility Assistant window that states “Windows requires a digitally signed driver”. From what I have read, I thought that only the package has to be signed.

The situation is complicated (and this is all before Windows 10, when
things REALLY got messy!).

There are two different signature checks. There is the install-time
check, which applies only to PnP driver packages. This check is done on
all of the systems, 32 and 64, clear back to XP. Here, it is your CAT
file signature that matters. If the CAT file is WHQL signed, install is
silent. If your CAT file is signed by your own certificate (ANY
code-signing certificate), you’ll get a “do you trust this publisher?”
warning. If your CAT file is unsigned or missing, you get the dreaded
“unsigned driver” warning. The user can bypass any of those and allow
the driver to be installed. Once a device is installed, this check
never occurs again.

Then, there is KMCS (kernel-mode code signing), which is done each and
every time the driver is LOADED, but only on 64-bit systems. For this
check, you can sign the SYS file, or if you have a driver package, you
can sign the CAT file. For this check, you must use a class 3
code-signing certificate, AND you must use the appropriate
cross-certificate from Microsoft to cross into their certificate
domain. You can check whether you have done this correctly using
“signtool verify /kp /v”. If you do not see the “Microsoft Code
Verification Root”, then you probably did not use a cross-certificate.

Remember that the CAT contains a checksum of all of the files. If you
only sign the CAT, then it only covers the original SYS file. You can’t
copy in a replacement SYS file for debugging, unless you sign that SYS.

Padon my lack of experience, but what is an NG?

Where did you see that? It’s usually “No Good”.


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

Thanks for the assistance. “NG” was in the response from Maxim right before your first response.

Here is what I got for the ‘signtool verify /kp /v’ command. I do see the Microsoft line you mentioned. What now? How do I determine if I have a Class 3 certificate?

Verifying: j:\uio48\uio48.cat

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

Signing Certificate Chain:
Issued to: DigiCert High Assurance EV Root CA
Issued by: DigiCert High Assurance EV Root CA
Expires: Sun Nov 09 19:00:00 2031
SHA1 hash: 5FB7EE0633E259DBAD0C4C9AE6D38F1A61C7DC25

Issued to: DigiCert SHA2 High Assurance Code Signing CA
Issued by: DigiCert High Assurance EV Root CA
Expires: Sun Oct 22 07:00:00 2028
SHA1 hash: F7E0F449F1A2594F88856C0758F8E6F627E5F5A2

Issued to: WinSystems, Inc
Issued by: DigiCert SHA2 High Assurance Code Signing CA
Expires: Thu Jun 28 07:00:00 2018
SHA1 hash: XXXXXXXXXXD554BDA6E290D4BCB8EB682842847A

The signature is timestamped: Thu Oct 22 11:18:07 2015

Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Thu Dec 31 18:59:59 2020
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires: Wed Dec 30 18:59:59 2020
SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1

Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires: Tue Dec 29 18:59:59 2020
SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4

Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 08:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

Issued to: DigiCert High Assurance EV Root CA
Issued by: Microsoft Code Verification Root
Expires: Thu Apr 15 14:55:33 2021
SHA1 hash: 2F2513AF3992DB0A3F79709FF8143B3F7BD2D143

Issued to: DigiCert SHA2 High Assurance Code Signing CA
Issued by: DigiCert High Assurance EV Root CA
Expires: Sun Oct 22 07:00:00 2028
SHA1 hash: F7E0F449F1A2594F88856C0758F8E6F627E5F5A2

Issued to: WinSystems, Inc
Issued by: DigiCert SHA2 High Assurance Code Signing CA
Expires: Thu Jun 28 07:00:00 2018
SHA1 hash: XXXXXXXXXXD554BDA6E290D4BCB8EB682842847A

Successfully verified: j:\uio48\uio48.cat

Number of files successfully Verified: 1

Number of warnings: 0

Number of errors: 0

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-593972-
xxxxx@lists.osr.com] On Behalf Of Tim Roberts

xxxxx@winsystems.com wrote:
> Padon my lack of experience, but what is an NG?

Where did you see that? It’s usually “No Good”.

Max asked PGV to create a new one. In this context, it means newsgroup, but it refers to an OSR mailing list/web forum/newsgroup, because the OSR lists are all 3.

:slight_smile:

Phil

Not speaking for LogRhythm
Phil Barila | Senior Software Engineer
720.881.5364 (w)
LogRhythm, Inc.
The Security Intelligence Company
A LEADER in Gartner’s SIEM Magic Quadrant four consecutive years (2012-2015)
A CHAMPION in Info-Tech Research Group’s 2015 SIEM Vendor Landscape Report
SANS “Best of the Year” in SIEM, 2014
Perfect 5-Star Rating in SC Magazine (2009-2014)

xxxxx@winsystems.com wrote:

Thanks for the assistance. “NG” was in the response from Maxim right before your first response.

Here is what I got for the ‘signtool verify /kp /v’ command. I do see the Microsoft line you mentioned. What now? How do I determine if I have a Class 3 certificate?

You’re using an SHA2 EV certificate, which is fancier yet. Windows 7
requires a hot-fix to be able to use SHA2 certificates, but if you are
hooked up to automatic updates, the hot fix should be installed.

So, tell us the sequence of events here. What are you using to install
the driver, what parts work, what dialogs do you see, and where does it
go awry?


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

Well I got a different build of Windows 7 64-bit and everything appears to be good now. Maybe all the failed attempts with the wrong Coinstaller affected the system? I appreciate the assistance. I did learn something so it wasn’t a total waste of time.

> silent. If your CAT file is signed by your own certificate (ANY

code-signing certificate), you’ll get a “do you trust this publisher?”
warning.

In Vista+, you can get rid of this by installing your cert to Local Machine/Trusted Publishers.

This is what is done by SetupAPI if you check the “Always trust” checkbox in the dialog and say “yes”.

More: XP seems to check this signature on each new devnode creation, and 2003 IIRC just plain does not support custom certs (I can be wrong here, since my tests on 2003 were not so comprehensive).

check, you can sign the SYS file, or if you have a driver package, you
can sign the CAT file.

For a boot-start driver, you must sign the .SYS in any case.

> Padon my lack of experience, but what is an NG?

Newsgroup?


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

>the failed attempts with the wrong Coinstaller affected the system?

Oh yes, when debugging driver install, it is better to reset the OS to the clean state often.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com