Signing drivers with signtool for XP 64-bit

[OSR_Community_User]

I need to suppress the unsigned driver installation dialog for an automation project that I am working on. Now, for XP32, it is possible to suppress the dialog a control panel setting, but that has been removed in XP64. The MS KB article “Driver signing policy is automatically elevated for unsigned drivers” (http://support.microsoft.com/kb/831583) describes this as “by design”. In short, it appears that while on XP32 you can choose to ignore signed/unsigned warnings for unsigned drivers, the setting is ignored on XP64. Therefore, I need to sign our drivers for unattended installation via devcon, for automated testing.

Now, we have a Verisign certificate for signing of Windows Vista 32 and 64-bit drivers. Our signing process does work and the drivers are installed automatically, without a prompt, for each subsequent installation after the first when we check the box to allow further drivers signed by us to be installed without prompting. For some reason, however, the same signing infrastructure does not work for XP64, even with the OS-appropriate changes. Here is our sequence of commands:

/bin/SelfSign/inf2cat.exe /driver:… /os:Vista_X86, Vista_X64
/bin/SelfSign/inf2cat.exe /driver:… /os:XP_X86, XP_X64

$ /bin/SelfSign/signtool.exe sign /v /ac MSCV-VSClass3.cer /v /s my /n “” /t http://timestamp.verisign.com/scripts/timestamp.dll .sys 64.sys .cat 64.cat

$ /bin/SelfSign/signtool.exe verify /v /kp .cat .sys 64.cat
64.sys

The verified output for both XP and Vista is the following:

Verifying: Verifying: 64.sys
SHA1 hash of file: (not calculated)
Signing Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: 11/1/2025 6:54:03 AM
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

Issued to: Class 3 Public Primary Certification Authority
Issued by: Microsoft Code Verification Root
Expires: 5/23/2016 10:11:29 AM
SHA1 hash: 58455389CF1D0CD6A08E3CE216F65ADFF7A86408

Issued to: VeriSign Class 3 Code Signing 2004 CA
Issued by: Class 3 Public Primary Certification Authority
Expires: 7/15/2014 4:59:59 PM
SHA1 hash: 197A4AEBDB25F0170079BB8C73CB2D655E0018A4

Issued to: {Our Corporate Certificate}
Issued by: VeriSign Class 3 Code Signing 2004 CA
Expires: 1/22/2010 4:59:59 PM
SHA1 hash: E3EFA4F5D3D320CE51EA7CE9C54E3CE6FBBBC055

The signature is timestamped: 7/25/2008 4:34:16 PM
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: 12/31/2020 4:59:59 PM
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

Issued to: VeriSign Time Stamping Services CA
Issued by: Thawte Timestamping CA
Expires: 12/3/2013 4:59:59 PM
SHA1 hash: F46AC0C6EFBB8C6A14F55F09E2D37DF4C0DE012D

Issued to: VeriSign Time Stamping Services Signer - G2
Issued by: VeriSign Time Stamping Services CA
Expires: 6/14/2012 4:59:59 PM
SHA1 hash: ADA8AAA643FF7DC38DD40FA4C97AD559FF4846DE

Now, when I go to install this on XP64, the following message appears in setupapi.log:

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

Now, when I install the root certificate available on Microsoft.com (http://www.microsoft.com/whdc/winlogo/drvsign/crosscert.mspx) “Microsoft Cross-Certificates for Windows Vista Kernel Mode Code Signing” onto my XP64 machine, it shows up in the Certification Path with the message, “The issuer of this certificate could not be found.”

Does anyone have any hints as to why XP64 is being stubborn?

Thanks and Regards,
Joe

[OSR_Community_User]

xxxxx@broadcom.com wrote:

Does anyone have any hints as to why XP64 is being stubborn?

Yes. Microsoft wants to make its 64bit systems more secure than their
former operating system versions.

As far as I can tell from your certification chain, you have done the
signing and cross-certification correctly.

But this is not enough for an install without ANY prompt - you need a
WHQL signature (from Microsoft) on your CAT file for that.

Please note that even with a valid cross-certified signature, in device
manager on XP32/Vista32 your driver is always listed as “not signed”.

Is a User-Mode Driver (using UMDF) an option for your device?
These don’t require signing. (KMDF drivers do.)

[OSR_Community_User]

Vista, 32-bit and 64-bit both, have the ability to suppress subsequent
prompts, after an initial “Are you sure you wanted to install this
unsigned driver?” with a check box for “Always trust signed software
from {company}”. This works for all test setups. The same signing
process does not yield the same result on XP64.

What’s interesting is Microsoft exposes, via the control panel, the same
“Driver Signing Options” tab with the dialog of “what action do you want
Windows to take?” (referring to unsigned drivers) as it does in XP32. Of
course, the options are Ignore/Warn/Block, with Warn the default.
Setting it to “Ignore” works fine for XP32, but setting it to “Ignore”
for XP64 yields the following message in setupapi.log::

“#E245 The device installation digital signature failure policy has been
elevated from Ignore to Warn due to a proposed replacement of a
protected system file.”

This, of course, does not make sense, as if the same control panel
settings are exposed, it is reasonable to expect the same behavior for
both.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Monday, July 28, 2008 4:16 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Signing drivers with signtool for XP 64-bit

xxxxx@broadcom.com wrote:

Does anyone have any hints as to why XP64 is being stubborn?

Yes. Microsoft wants to make its 64bit systems more secure than their
former operating system versions.

As far as I can tell from your certification chain, you have done the
signing and cross-certification correctly.

But this is not enough for an install without ANY prompt - you need a
WHQL signature (from Microsoft) on your CAT file for that.

Please note that even with a valid cross-certified signature, in device
manager on XP32/Vista32 your driver is always listed as “not signed”.

Is a User-Mode Driver (using UMDF) an option for your device?
These don’t require signing. (KMDF drivers do.)

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[OSR_Community_User]

> I need to suppress the unsigned driver installation dialog

for an automation project that I am working on. Now, for
XP32, it is possible to suppress the dialog a control panel
setting, but that has been removed in XP64.

There’s good news and bad news.

If your device is in a non-WHQL device install class (like custom device
install class), I believe you can use an Authenticode signature to get
silent install. You will need to sign the .cat and add the certificate to
the system certificate store in the correct place.

If your device is in any class that has a WHQL test program, like network
adapter or storage miniport, then the ONLY real way to suppress the found
new hardware dialog is to get some kind of WHQL signature (or a test WHQL
signature if just for testing). This is the W2K8 behaivor and assume the
XP64 behaivor.

There are some ugly partial hacks around this, like making your setup
program look for the found new hardware dialog, and sending it mouse clicks.

Vista and later have ways to add your certificate to the certificate store,
and tell the OS it’s just as valid as a WHQL certificate, giving you silent
install.

Jan

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3304 (20080728) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[OSR_Community_User]

Joseph Koenig wrote:

This, of course, does not make sense, as if the same control panel
settings are exposed, it is reasonable to expect the same behavior
for both.

Welcome to Windows Driver Development Land. Microsoft makes the rules
here, and this is one example. Your assumption was that you are allowed
to expect something. This assumption is not necessarily true.

[OSR_Community_User]

This is discouraging. I still find this hard to believe, though. How do
system administrators that manage and deploy hundreds of machines deal
with unsigned drivers, seeing as how a lot of the larger corporations
use in-house written kernel code for any of a variety of reasons?

Furthermore, how come XP64 exposes the exact same dialog as XP32, that
specifically allows the installation of unsigned drivers, without
prompting and yet the behavior appears to be “broken?” If this appears
to be the case, I’d expect some sort of knowledge base article saying
that the “driver installation option” menu is broken in XP.

This is an NDIS miniport driver so, by your statement, we’re out of
luck. Not good (or encouraging)!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Monday, July 28, 2008 6:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Signing drivers with signtool for XP 64-bit

I need to suppress the unsigned driver installation dialog
for an automation project that I am working on. Now, for
XP32, it is possible to suppress the dialog a control panel
setting, but that has been removed in XP64.

There’s good news and bad news.

If your device is in a non-WHQL device install class (like custom device
install class), I believe you can use an Authenticode signature to get
silent install. You will need to sign the .cat and add the certificate
to
the system certificate store in the correct place.

If your device is in any class that has a WHQL test program, like
network
adapter or storage miniport, then the ONLY real way to suppress the
found
new hardware dialog is to get some kind of WHQL signature (or a test
WHQL
signature if just for testing). This is the W2K8 behaivor and assume the
XP64 behaivor.

There are some ugly partial hacks around this, like making your setup
program look for the found new hardware dialog, and sending it mouse
clicks.

Vista and later have ways to add your certificate to the certificate
store,
and tell the OS it’s just as valid as a WHQL certificate, giving you
silent
install.

Jan

__________ Information from ESET NOD32 Antivirus, version of virus
signature
database 3304 (20080728) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[Ken_Johnson]

I would assume that they probably use an KMCS/Authenticode signature with a code signing cert (e.g. VeriSign cert) that allows the driver to still load, though you get the pop-up at installation time for PNP drivers.

• S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Koenig
Sent: Tuesday, July 29, 2008 1:18 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Signing drivers with signtool for XP 64-bit

This is discouraging. I still find this hard to believe, though. How do
system administrators that manage and deploy hundreds of machines deal
with unsigned drivers, seeing as how a lot of the larger corporations
use in-house written kernel code for any of a variety of reasons?

Furthermore, how come XP64 exposes the exact same dialog as XP32, that
specifically allows the installation of unsigned drivers, without
prompting and yet the behavior appears to be “broken?” If this appears
to be the case, I’d expect some sort of knowledge base article saying
that the “driver installation option” menu is broken in XP.

This is an NDIS miniport driver so, by your statement, we’re out of
luck. Not good (or encouraging)!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Monday, July 28, 2008 6:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Signing drivers with signtool for XP 64-bit

I need to suppress the unsigned driver installation dialog
for an automation project that I am working on. Now, for
XP32, it is possible to suppress the dialog a control panel
setting, but that has been removed in XP64.

There’s good news and bad news.

If your device is in a non-WHQL device install class (like custom device
install class), I believe you can use an Authenticode signature to get
silent install. You will need to sign the .cat and add the certificate
to
the system certificate store in the correct place.

If your device is in any class that has a WHQL test program, like
network
adapter or storage miniport, then the ONLY real way to suppress the
found
new hardware dialog is to get some kind of WHQL signature (or a test
WHQL
signature if just for testing). This is the W2K8 behaivor and assume the
XP64 behaivor.

There are some ugly partial hacks around this, like making your setup
program look for the found new hardware dialog, and sending it mouse
clicks.

Vista and later have ways to add your certificate to the certificate
store,
and tell the OS it’s just as valid as a WHQL certificate, giving you
silent
install.

Jan

__________ Information from ESET NOD32 Antivirus, version of virus
signature
database 3304 (20080728) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[Tim_Roberts]

Joseph Koenig wrote:

This is discouraging. I still find this hard to believe, though. How do
system administrators that manage and deploy hundreds of machines deal
with unsigned drivers, seeing as how a lot of the larger corporations
use in-house written kernel code for any of a variety of reasons?

I think your last statement is simply false. What in-house kernel
drivers would you expect the secretaries and marketing types at Intel to
need?

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

[OSR_Community_User]

I was hypothesizing, and indeed it was a tangential comment that
probably shouldn’t have been added. A more specific and appropriate
comment would have been the following: “How do R&D companies that run
unit test scripts on XP64 handle the fully automated testing of their
driver?” which I believe is a very valid question.

The behavior that is witnessed with unsigned drivers does not provide
security on the order of Vista/2K8. Consider the hypothetical situation
for a developer with a verisign certificate:

Vista64:

1. Install via device manager
2. Get prompted to install an Authenticode-signed driver by Windows
3. Click OK, driver is installed and loaded
4. Copy recompiled .sys file to c:\windows\system32\drivers;
5. Enable/disable in the device manager does not enable the device.
   The signing requirement prevents any modifications to the driver unless
   it is resigned.

XP64:

1. Install via device manager
2. Get an insuppressible unsigned driver warning, click OK (since you
   cannot use an Authenticode signature to suppress a WHQL-class device,
   please see my original post @
   http://www.osronline.com/showthread.cfm?link=135850)
3. Click OK, driver is installed and loaded
4. Copy recompiled .sys file to c:\windows\system32\drivers;
5. Enable/disable in the device manager re-enables the device with your
   new kernel code that was copied at step 4.

Since you can clearly loaded unsigned kernel mode code after altering
the binary, this does not seem a “security measure.” It seems to me,
rather, that the “unsigned driver options” dialog in the control panel,
which presenting the same UI and options as XP32, does not in fact do
anything.

Joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, July 29, 2008 10:35 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Signing drivers with signtool for XP 64-bit

Joseph Koenig wrote:

This is discouraging. I still find this hard to believe, though. How
do
system administrators that manage and deploy hundreds of machines deal
with unsigned drivers, seeing as how a lot of the larger corporations
use in-house written kernel code for any of a variety of reasons?

I think your last statement is simply false. What in-house kernel
drivers would you expect the secretaries and marketing types at Intel to

need?

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

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[Don_Burn_1]

The simple answer for the unit test script is get a test signature. For the
security argument, consider that you are altering unblessed code you have
already installed, try the same on a signed driver and the system will
replace your copy with the original.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Joseph Koenig” wrote in message news:xxxxx@ntdev…
I was hypothesizing, and indeed it was a tangential comment that
probably shouldn’t have been added. A more specific and appropriate
comment would have been the following: “How do R&D companies that run
unit test scripts on XP64 handle the fully automated testing of their
driver?” which I believe is a very valid question.

The behavior that is witnessed with unsigned drivers does not provide
security on the order of Vista/2K8. Consider the hypothetical situation
for a developer with a verisign certificate:

Vista64:
1) Install via device manager
2) Get prompted to install an Authenticode-signed driver by Windows
3) Click OK, driver is installed and loaded
4) Copy recompiled .sys file to c:\windows\system32\drivers;
5) Enable/disable in the device manager does not enable the device.
The signing requirement prevents any modifications to the driver unless
it is resigned.

XP64:
1) Install via device manager
2) Get an insuppressible unsigned driver warning, click OK (since you
cannot use an Authenticode signature to suppress a WHQL-class device,
please see my original post @
http://www.osronline.com/showthread.cfm?link=135850)
3) Click OK, driver is installed and loaded
4) Copy recompiled .sys file to c:\windows\system32\drivers;
5) Enable/disable in the device manager re-enables the device with your
new kernel code that was copied at step 4.

Since you can clearly loaded unsigned kernel mode code after altering
the binary, this does not seem a “security measure.” It seems to me,
rather, that the “unsigned driver options” dialog in the control panel,
which presenting the same UI and options as XP32, does not in fact do
anything.

Joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, July 29, 2008 10:35 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Signing drivers with signtool for XP 64-bit

Joseph Koenig wrote:
> This is discouraging. I still find this hard to believe, though. How
do
> system administrators that manage and deploy hundreds of machines deal
> with unsigned drivers, seeing as how a lot of the larger corporations
> use in-house written kernel code for any of a variety of reasons?
>

I think your last statement is simply false. What in-house kernel
drivers would you expect the secretaries and marketing types at Intel to

need?

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

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[OSR_Community_User]

The answer for at least one such organization is that we testsign
everything for unit/integration/system test, using WHQL test signatures
for official test builds plus the ‘make all signed drivers equal’
workaround for inbox bias BUG in W2K8, and selfsigned test signatures
for private developer builds of drivers plus testsigning mode boots of
developer test systems. Yes it is all a pain in the ass. And not cheap
either.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Koenig
Sent: Tuesday, July 29, 2008 1:49 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Signing drivers with signtool for XP 64-bit

I was hypothesizing, and indeed it was a tangential comment that
probably shouldn’t have been added. A more specific and appropriate
comment would have been the following: “How do R&D companies that run
unit test scripts on XP64 handle the fully automated testing of their
driver?” which I believe is a very valid question.

The behavior that is witnessed with unsigned drivers does not provide
security on the order of Vista/2K8. Consider the hypothetical situation
for a developer with a verisign certificate:

Vista64:

1. Install via device manager
2. Get prompted to install an Authenticode-signed driver by Windows
3. Click OK, driver is installed and loaded
4. Copy recompiled .sys file to c:\windows\system32\drivers;
5. Enable/disable in the device manager does not enable the device.
   The signing requirement prevents any modifications to the driver unless
   it is resigned.

XP64:

1. Install via device manager
2. Get an insuppressible unsigned driver warning, click OK (since you
   cannot use an Authenticode signature to suppress a WHQL-class device,
   please see my original post @
   http://www.osronline.com/showthread.cfm?link=135850)
3. Click OK, driver is installed and loaded
4. Copy recompiled .sys file to c:\windows\system32\drivers;
5. Enable/disable in the device manager re-enables the device with your
   new kernel code that was copied at step 4.

Since you can clearly loaded unsigned kernel mode code after altering
the binary, this does not seem a “security measure.” It seems to me,
rather, that the “unsigned driver options” dialog in the control panel,
which presenting the same UI and options as XP32, does not in fact do
anything.

Joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, July 29, 2008 10:35 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Signing drivers with signtool for XP 64-bit

Joseph Koenig wrote:

This is discouraging. I still find this hard to believe, though. How
do
system administrators that manage and deploy hundreds of machines deal
with unsigned drivers, seeing as how a lot of the larger corporations
use in-house written kernel code for any of a variety of reasons?

I think your last statement is simply false. What in-house kernel
drivers would you expect the secretaries and marketing types at Intel to

need?

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

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[Ken_Johnson]

There are actually two different driver signing checks. There is the PnP driver signing nag, that has been there since win2k. That is essentially unchanged in Windows x64, except that the option to suppress the nag is turned off. The nag does not exist for non-PnP drivers. The PnP driver signing nag requires a WHQL or in-box signature to bypass completely. Recent OS’s display a slightly less scary dialog box in the signing nag prompt if the driver is Authenticode-signed (i.e. signed with a VeriSign code signing cert), but the nag remains in that case.

Then, there is the KMCS (kernel mode code signing) signing check. This exists only on Windows x64 - there is no equivalent on 32-bit Windows. The KMCS check is done as part of mapping an image section into kernel address space, and not as a part of the installation process (as with the PnP driver signing nag). Any Authenticode signature from a CA that Microsoft has cross-signed with their private KMCS CA will allow an image to be mapped to kernel address space.

If you edit the binary on disk, the KMCS signature check will fail and you will not be able to load the driver. This is independent of the installation time PnP driver signing nag.

• S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Koenig
Sent: Tuesday, July 29, 2008 1:49 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Signing drivers with signtool for XP 64-bit

I was hypothesizing, and indeed it was a tangential comment that
probably shouldn’t have been added. A more specific and appropriate
comment would have been the following: “How do R&D companies that run
unit test scripts on XP64 handle the fully automated testing of their
driver?” which I believe is a very valid question.

The behavior that is witnessed with unsigned drivers does not provide
security on the order of Vista/2K8. Consider the hypothetical situation
for a developer with a verisign certificate:

Vista64:

1. Install via device manager
2. Get prompted to install an Authenticode-signed driver by Windows
3. Click OK, driver is installed and loaded
4. Copy recompiled .sys file to c:\windows\system32\drivers;
5. Enable/disable in the device manager does not enable the device.
   The signing requirement prevents any modifications to the driver unless
   it is resigned.

XP64:

1. Install via device manager
2. Get an insuppressible unsigned driver warning, click OK (since you
   cannot use an Authenticode signature to suppress a WHQL-class device,
   please see my original post @
   http://www.osronline.com/showthread.cfm?link=135850)
3. Click OK, driver is installed and loaded
4. Copy recompiled .sys file to c:\windows\system32\drivers;
5. Enable/disable in the device manager re-enables the device with your
   new kernel code that was copied at step 4.

Since you can clearly loaded unsigned kernel mode code after altering
the binary, this does not seem a “security measure.” It seems to me,
rather, that the “unsigned driver options” dialog in the control panel,
which presenting the same UI and options as XP32, does not in fact do
anything.

Joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, July 29, 2008 10:35 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Signing drivers with signtool for XP 64-bit

Joseph Koenig wrote:

This is discouraging. I still find this hard to believe, though. How
do
system administrators that manage and deploy hundreds of machines deal
with unsigned drivers, seeing as how a lot of the larger corporations
use in-house written kernel code for any of a variety of reasons?

I think your last statement is simply false. What in-house kernel
drivers would you expect the secretaries and marketing types at Intel to

need?

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

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[OSR_Community_User]

This clarifies a bit. Still, according to MSDN
(http://msdn.microsoft.com/en-us/library/aa906239.aspx), KMCS applies
only to Vista x64 and Windows Server 2008 and not Windows XP 64-bit
Edition. According to that same link, they’ve only elaborated on this
PnP lockout on Vista and 2K8, without mentioning anything about XP
64-bit Edition.

And none of this explains why XP x64 is giving me the messages I
discussed in my original post. According to another MSDN doc, at
(http://msdn.microsoft.com/en-us/library/aa906265.aspx), it is stated,
specifically, that:

"Windows Server 2003, Windows XP, and Windows 2000 do not require a
driver to be signed during the early development and test phase of a
driver prior to the final testing of a release signed driver. In
addition, a system administrator can set the driver signing option in
Device Manager such that Plug and Play (PnP) device installation
installs unsigned drivers without user interaction. A system
administrator can set the driver signing option to Ignore, Warn, or
Block, as follows:

* If Ignore is set, PnP device installation installs an unsigned
driver without displaying a user dialog.
* If Warn is set, PnP device installation displays a dialog that
informs the user a signature is not valid, and gives the user the option
to cancel the installation of the driver.
* If Block is set, PnP device installation displays a dialog that
informs the user that an unsigned driver cannot be installed.

To automate the installation of an unsigned driver, set the driver
signing option to Ignore."

Which, of course, still does not explain the following warning that I am
getting:

“#E245 The device installation digital signature failure policy has been
elevated from Ignore to Warn due to a proposed replacement of a
protected system file.”

Which seems to be the root-cause of my problem. In theory, it appears
that XP should not be throwing the PnP Warning if I have it set to
Ignore, which I do. And yet, it is. This is not the expected behavior,
according to MSFT.

Hmmm -
Joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Tuesday, July 29, 2008 11:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Signing drivers with signtool for XP 64-bit

There are actually two different driver signing checks. There is the
PnP driver signing nag, that has been there since win2k. That is
essentially unchanged in Windows x64, except that the option to suppress
the nag is turned off. The nag does not exist for non-PnP drivers. The
PnP driver signing nag requires a WHQL or in-box signature to bypass
completely. Recent OS’s display a slightly less scary dialog box in the
signing nag prompt if the driver is Authenticode-signed (i.e. signed
with a VeriSign code signing cert), but the nag remains in that case.

Then, there is the KMCS (kernel mode code signing) signing check. This
exists only on Windows x64 - there is no equivalent on 32-bit Windows.
The KMCS check is done as part of mapping an image section into kernel
address space, and not as a part of the installation process (as with
the PnP driver signing nag). Any Authenticode signature from a CA that
Microsoft has cross-signed with their private KMCS CA will allow an
image to be mapped to kernel address space.

If you edit the binary on disk, the KMCS signature check will fail and
you will not be able to load the driver. This is independent of the
installation time PnP driver signing nag.

• S

[Tim_Roberts]

Joseph Koenig wrote:

Which, of course, still does not explain the following warning that I am
getting:

“#E245 The device installation digital signature failure policy has been
elevated from Ignore to Warn due to a proposed replacement of a
protected system file.”

Which seems to be the root-cause of my problem.

What exact filenames does your INF install?

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

[Ken_Johnson]

Misinteperted your original post. Yes, KMCS is new to Vista/Srv08 (x64). The signing nag is not a hard barrier on any platform, only KMCS is. You can install a non-PnP driver on Srv03 or XP x64 even if it is not signed, or otherwise hack around the signing nag in underhanded ways (button whacker type). Not that you *should* do this.

Of course, whether KMCS really adds any security is highly debatable. Unlike the PnP nag, though, at least it tries to be enforceable.

• S

-----Original Message-----
From: Joseph Koenig
Sent: Tuesday, July 29, 2008 16:19
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Signing drivers with signtool for XP 64-bit

This clarifies a bit. Still, according to MSDN
(http://msdn.microsoft.com/en-us/library/aa906239.aspx), KMCS applies
only to Vista x64 and Windows Server 2008 and not Windows XP 64-bit
Edition. According to that same link, they’ve only elaborated on this
PnP lockout on Vista and 2K8, without mentioning anything about XP
64-bit Edition.

And none of this explains why XP x64 is giving me the messages I
discussed in my original post. According to another MSDN doc, at
(http://msdn.microsoft.com/en-us/library/aa906265.aspx), it is stated,
specifically, that:

“Windows Server 2003, Windows XP, and Windows 2000 do not require a
driver to be signed during the early development and test phase of a
driver prior to the final testing of a release signed driver. In
addition, a system administrator can set the driver signing option in
Device Manager such that Plug and Play (PnP) device installation
installs unsigned drivers without user interaction. A system
administrator can set the driver signing option to Ignore, Warn, or
Block, as follows:

* If Ignore is set, PnP device installation installs an unsigned
driver without displaying a user dialog.
* If Warn is set, PnP device installation displays a dialog that
informs the user a signature is not valid, and gives the user the option
to cancel the installation of the driver.
* If Block is set, PnP device installation displays a dialog that
informs the user that an unsigned driver cannot be installed.

To automate the installation of an unsigned driver, set the driver
signing option to Ignore.”

Which, of course, still does not explain the following warning that I am
getting:

“#E245 The device installation digital signature failure policy has been
elevated from Ignore to Warn due to a proposed replacement of a
protected system file.”

Which seems to be the root-cause of my problem. In theory, it appears
that XP should not be throwing the PnP Warning if I have it set to
Ignore, which I do. And yet, it is. This is not the expected behavior,
according to MSFT.

Hmmm -
Joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Tuesday, July 29, 2008 11:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Signing drivers with signtool for XP 64-bit

There are actually two different driver signing checks. There is the
PnP driver signing nag, that has been there since win2k. That is
essentially unchanged in Windows x64, except that the option to suppress
the nag is turned off. The nag does not exist for non-PnP drivers. The
PnP driver signing nag requires a WHQL or in-box signature to bypass
completely. Recent OS’s display a slightly less scary dialog box in the
signing nag prompt if the driver is Authenticode-signed (i.e. signed
with a VeriSign code signing cert), but the nag remains in that case.

Then, there is the KMCS (kernel mode code signing) signing check. This
exists only on Windows x64 - there is no equivalent on 32-bit Windows.
The KMCS check is done as part of mapping an image section into kernel
address space, and not as a part of the installation process (as with
the PnP driver signing nag). Any Authenticode signature from a CA that
Microsoft has cross-signed with their private KMCS CA will allow an
image to be mapped to kernel address space.

If you edit the binary on disk, the KMCS signature check will fail and
you will not be able to load the driver. This is independent of the
installation time PnP driver signing nag.

- S

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[OSR_Community_User]

Joseph Koenig wrote:

How do system administrators that manage and deploy hundreds of
machines deal with unsigned drivers,

They use imaging or deployment tools. Like they always have.

seeing as how a lot of the larger corporations use in-house written
kernel code for any of a variety of reasons?

And hundreds of people in these crporations use XP64 or Vista64?
Sorry, I can’t really believe this.

My assumption is that currently Microsoft enforces higher security for
the OS variants that predominantly run on hi-performance machines and
thus are primarily used for servers (IMHO they forgot the gamers,
though), partially to test if this causes support problems.

Once 64bit is pre-installed on the PC you can buy at next corner’s food
discounter or at your friendly four-letter mail-order company, there
will be a solution for your problem.

[OSR_Community_User]

Here is our 2 cents about this issue:

1. Bottom line is installing on XP 64-bit works without user having to
   press anything.
   This happens after setting the control panel to ignore installation of
   unsigned drivers.

2. My guess is that the reason that it doesn’t work for you is that you
   have some problem in sighing the files.

Here is the way that we sign our drivers:
.cdf -> .cat
C:\WINDDK\6001.18001\bin\SelfSign\MakeCat.exe -v %s.cdf

sign .cat
C:\WINDDK\6001.18001\bin\SelfSign\signtool.exe" + " sign /v /ac
c:\whql\MSCV-VSClass3.cer /s my /n
“Mellanox Technologies” /t
http://timestamp.verisign.com/scripts/timstamp.dll %s.cat

sign .sys
C:\WINDDK\6001.18001\bin\SelfSign\signtool.exe" + " sign /v /ac
c:\whql\MSCV-VSClass3.cer /s my /n
“Mellanox Technologies” /t
http://timestamp.verisign.com/scripts/timstamp.dll %s.sys"

Thanks,
Tzachi & Reuven.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Koenig
Sent: Wednesday, July 30, 2008 12:16 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Signing drivers with signtool for XP 64-bit

This clarifies a bit. Still, according to MSDN
(http://msdn.microsoft.com/en-us/library/aa906239.aspx), KMCS
applies only to Vista x64 and Windows Server 2008 and not
Windows XP 64-bit Edition. According to that same link,
they’ve only elaborated on this PnP lockout on Vista and 2K8,
without mentioning anything about XP 64-bit Edition.

And none of this explains why XP x64 is giving me the
messages I discussed in my original post. According to
another MSDN doc, at
(http://msdn.microsoft.com/en-us/library/aa906265.aspx), it
is stated, specifically, that:

"Windows Server 2003, Windows XP, and Windows 2000 do not
require a driver to be signed during the early development
and test phase of a driver prior to the final testing of a
release signed driver. In addition, a system administrator
can set the driver signing option in Device Manager such that
Plug and Play (PnP) device installation installs unsigned
drivers without user interaction. A system administrator can
set the driver signing option to Ignore, Warn, or Block, as follows:

* If Ignore is set, PnP device installation installs an
unsigned driver without displaying a user dialog.
* If Warn is set, PnP device installation displays a
dialog that informs the user a signature is not valid, and
gives the user the option to cancel the installation of the driver.
* If Block is set, PnP device installation displays a
dialog that informs the user that an unsigned driver cannot
be installed.

To automate the installation of an unsigned driver, set the
driver signing option to Ignore."

Which, of course, still does not explain the following
warning that I am
getting:

“#E245 The device installation digital signature failure
policy has been elevated from Ignore to Warn due to a
proposed replacement of a protected system file.”

Which seems to be the root-cause of my problem. In theory, it
appears that XP should not be throwing the PnP Warning if I
have it set to Ignore, which I do. And yet, it is. This is
not the expected behavior, according to MSFT.

Hmmm -
Joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Tuesday, July 29, 2008 11:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Signing drivers with signtool for XP 64-bit

There are actually two different driver signing checks.
There is the PnP driver signing nag, that has been there
since win2k. That is essentially unchanged in Windows x64,
except that the option to suppress the nag is turned off.
The nag does not exist for non-PnP drivers. The PnP driver
signing nag requires a WHQL or in-box signature to bypass
completely. Recent OS’s display a slightly less scary dialog
box in the signing nag prompt if the driver is
Authenticode-signed (i.e. signed with a VeriSign code signing
cert), but the nag remains in that case.

Then, there is the KMCS (kernel mode code signing) signing
check. This exists only on Windows x64 - there is no
equivalent on 32-bit Windows.
The KMCS check is done as part of mapping an image section
into kernel address space, and not as a part of the
installation process (as with the PnP driver signing nag).
Any Authenticode signature from a CA that Microsoft has
cross-signed with their private KMCS CA will allow an image
to be mapped to kernel address space.

If you edit the binary on disk, the KMCS signature check will
fail and you will not be able to load the driver. This is
independent of the installation time PnP driver signing nag.

• S

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

[OSR_Community_User]

Tzachi Dar wrote:
[…]

Here is the way that we sign our drivers:
.cdf -> .cat
[…]
sign .cat
[…]
sign .sys

This order invalidates the .CAT signature.

It should be

(1) sign .sys files (if necessary / wanted)

(2) make .cat file
(using the proper hashes of the signed sys files)

(3) sign .cat file

Comments?
BR -H

[OSR_Community_User]

xxxxx@broadcom.com wrote:
$ /bin/SelfSign/signtool.exe sign /v /ac MSCV-VSClass3.cer /v /s my /n
“” /t http://timestamp.verisign.com/scripts/timestamp.dll
.sys 64.sys .cat 64.cat

Thanks to Tzachi Dar I noticed that this will not work.

Reason: the CAT file is a CATalog of your driver files that contains the
names and cryptographic checksums (SHA1 hashes or alike) of the driver
files.

Signing the driver .sys files after CAT creation makes sure the
signature in the CAT file does not match the .sys file anymore!

The order must be

(a) sign driver.sys files
=> add “embedded” signature to driver

(b) make CATalog file
=> list of files and file hashes

(c) sign CATalog file
=> add signature to CATalog file

Unfortunately the KMCS walkthrough explains embedded signatures after
the CAT file signature, and it does not mention anywhere that signing a
SYS file after CAT file generation voids the stored file hash.

HTH -H

[Peter_Viscarola_OSR]

Back to your original note… You’re not insane. The problem appears to be with Signtool.

SIGNTOOL appears to be broken on certain x64 platforms. When I try to sign an executable on my 64-bit S03 Sp2 box, with a known good set of certs, the cross-cert is not properly added to executable that I’ve signed.

I do the usual:

signtool sign /v /ac d:\signing\mscv-vsclass3.cer /s my /n osr /t http://timestamp.verisign.com/scripts/timestamp.dll filespy\fSpy.sys

And it “works.”

Then I do:

signtool1 verify /kp /v filespy\fSpy.sys

And I get a cert chain that chains up to “Class 3 Public Primary Certification Authority”, instead of “Microsoft Code Verification Root”

Not the least bit helpful, assuming you want to install the image on an x64 system running Vista or later.

Take the same driver executable, the same copy of signtool, the same certificates… and move them over to a VM running 32-bit XP Pro… use the exact same command… and it works correctly. I get a cert chain that chains up to the “Microsoft Code Verification Root”.

So, it appears that signtool is once again broken in certain situations for cross-certs. You can add this problem to the list of (a) Can’t have the verisign root cert in your private cert store or the cross-cert isn’t added, (b) Can’t store your code signing cert on various smart cards, cuz signtool can’t read it.

Finding this problem was a really good use of 2 hours of my time (today alone)… I’m so very happy.

Peter
OSR