Signing drivers with signtool for XP 64-bit

NTDEV
21

Thank you for spending the two hours of your time on this :slight_smile: Glad to
know I’m not insane.

It seems XP64 is the “forgotten” Microsoft OS.

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

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

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

22

wrote in message news:xxxxx@ntdev…
>
> Back to your original note… You’re not insane. The problem appears to
> be with Signtool.
>
> SIGNTOOL appears to be broken on
> 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

Absolute path ?

> And it “works.”
>
> Then I do:
>
> signtool1 verify /kp /v filespy\fSpy.sys
>

Relative path ?

//Daniel

23

xxxxx@osr.com wrote:
[nasty signtool bug on some x64 platforms, leaving out MSCVR cert]

The OP posted the verify output - the “Microsoft Code Verification Root”
certificate *is* at the start of his driver signature.

What IMHO breaks any chance of a “silent install” is this:

(a) Signtool replaces the signatures with each call (necessarily, e.g.
to update the cryptographic timestamp).

(b) Part of the *.cat file is a cryptographic checksum of each file in
the catalog. (IIRC, it’s an SHA1 hash.)

(c) When - as seen on the OPs posted command line - two *.cat and two
*.sys files are signed at the same time, the checksums in the CATalog
files *will not* match with the .sys files anymore.

We “sign-embedded” our USB bulk device driver *.sys before making
(inf2cat) and then signing the *.cat file. Otherwise install fails.

BTW, our driver does not need the embedded signature to run. But signing
the driver makes it extremely easy to check for file corruption.
We needed all necessary certificates anyway, so why not use them again?

24

xxxxx@resplendence.com wrote:

wrote in message news:xxxxx@ntdev…
>>
>> Back to your original note… You’re not insane. The problem appears
>> to be with Signtool.
>>
>> SIGNTOOL appears to be broken on
>> 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
>
> Absolute path ?

Where do you see an absolute path?

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

25

“Tim Roberts” wrote in message news:xxxxx@ntdev…
>>> signtool sign /v /ac d:\signing\mscv-vsclass3.cer /s my /n osr /t
>>> http://timestamp.verisign.com/scripts/timestamp.dll filespy\fSpy.sys
>>
>> Absolute path ?
>
> Where do you see an absolute path?
>

It’s the path of the cross certificate. I could just be completely wrong, I
wanted only to submit a possible hint. You know, I have a signtool alias
that absolutely nobody wants to know about, we all get absent - minded
sometimes. BTW did they mention recently they were investigating a signtool
issue on virtual machines (that could be related) ?

//Daniel

26

Hi,

And does that work for devices in WHQL signable classes, like say the IpoIB
driver? I can understand it working on the hca driver, as that’s in a custom
class.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tzachi Dar
Sent: Wednesday, July 30, 2008 3:06 AM
To: Windows System Software Devs Interest List
Cc: Reuven Amitai
Subject: RE: [ntdev] Signing drivers with signtool for XP 64-bit

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
>

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

__________ Information from ESET NOD32 Antivirus, version of
virus signature database 3309 (20080730) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

27

Ah, just shows you that we kernel devs sometimes thing alike. That was MY first guess too.

Same behavior with relative path, absolute path, and no path.

Signtool is just broken. Again. Er, still. Ah, MORE than we already knew it was.

Peter
OSR

28

Yes,

Actually we are also using this for Ethernet drivers.

Thanks
Tzachi

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

Hi,

And does that work for devices in WHQL signable classes, like
say the IpoIB driver? I can understand it working on the hca
driver, as that’s in a custom class.

Jan

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tzachi Dar
> Sent: Wednesday, July 30, 2008 3:06 AM
> To: Windows System Software Devs Interest List
> Cc: Reuven Amitai
> Subject: RE: [ntdev] Signing drivers with signtool for XP 64-bit
>
> 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
> >
>
> —
> 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
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 3309 (20080730) __________
>
> 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

29

xxxxx@resplendence.com wrote:

“Tim Roberts” wrote in message news:xxxxx@ntdev…
>>>> signtool sign /v /ac d:\signing\mscv-vsclass3.cer /s my /n osr /t
>>>> http://timestamp.verisign.com/scripts/timestamp.dll filespy\fSpy.sys
>>>
>>> Absolute path ?
>>
>> Where do you see an absolute path?
>>
>
> It’s the path of the cross certificate. I could just be completely
> wrong, I wanted only to submit a possible hint. You know, I have a
> signtool alias that absolutely nobody wants to know about, we all get
> absent - minded sometimes.

Ah, I see. It turns out that I have “signme.bat” scripts in two
different projects – one uses an absolute path to the cross cert, one
uses a relative path, and both work, so I suspect this is a non-issue.

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

30

Random thoughts from this thread:
Yes, we have a bug in signtool on 64 bit VM machines and not adding the cross-cert correctly. But cross-certs are only relevant to Vista/Server 2008 signatures (KMCS) as Ken points out above. Cross certs are totally irrelevant to XP64.

XP64 is the same code base as Server 2003, not XP32, hence the behavior difference. Read the docs for Server 2003 on technet for some hints.

You SHOULD be able to disable the warning on Server 2003. And the error message indicates that you do, but it gets flipped back on. I wonder if the problem is that one of the DLLs in the driver package is a file that you shouldn’t be trying to replace? Did we ever see the list of the files in the driver package?

Finally, you can sign the driver package binaries AFTER you create/sign the catalog file. The signature is placed on the binary in a location that isn’t included in the hash that is put in the catalog file - you will get the same hash of a .sys file before and after the signature is applied. So, the problem is not the order of the signing of the .sys file.

31

Ahhh… You might be missing my post.

SignTool does not work correct on S03 SP2 x64, on a REAL machine. It fails to add the cross cert to the image.

So, if my build box is a 64-bit system with S03 SP2 installed, and part of my build process is signing the executable, that does not work.

SignTool really needs somebody to spend some time making it work correctly. Maybe you can take a hammer to the security folks?

Bug list:

(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 certain smart cards (eToken, specifically), cuz signtool won’t read it. So, instead of being able to store your company code signing cert on a smart card that can be physically secured, you’re effectively forced to store it on a machine in the “personal” cert store.
(c) Signing Wizard not supported by SignTool
(d) SignTool broken on (at least) S03 SP2 x64

I just list 'em,

P

32

xxxxx@microsoft.com wrote:

Finally, you can sign the driver package binaries AFTER you
create/sign the catalog file. The signature is placed on the binary
in a location that isn’t included in the hash that is put in the
catalog file - you will get the same hash of a .sys file before and
after the signature is applied. So, the problem is not the order of
the signing of the .sys file.

Great news, this simplifies the signing batches somewhat – please have
this information added to the WDK documentation.

When checking, I found one difference between
(a) signtool verify runs of individual *.sys files and
(b) verifying all together with one signtool invocation:

(a) signtool verify of individual files:
Verifying: testem-a.sys
SHA1 hash of file: E8D04C012907BB55A0E42DE9DFBB1ED05F3F6034
Verifying: testem-b.sys
SHA1 hash of file: E8D04C012907BB55A0E42DE9DFBB1ED05F3F6034

(b) signtool verify of all files together:
Verifying: testem-a.sys
SHA1 hash of file: E8D04C012907BB55A0E42DE9DFBB1ED05F3F6034
Verifying: testem-b.sys
SHA1 hash of file: (not calculated)

Just another signtool quirk, or does this mean anything?

Now I’ll have to revise our build/sign process: I do remember problems
when doing sign_embedded after CAT generation. If it was not caused by
Signability (we changed to inf2cat after problems in December 2006),
something may be lurking in the batch files that I must find and fix.

33

Hagen Patzke wrote:

xxxxx@microsoft.com wrote:
> Finally, you can sign the driver package binaries AFTER you
> create/sign the catalog file. The signature is placed on the binary
> in a location that isn’t included in the hash that is put in the
> catalog file - you will get the same hash of a .sys file before and
> after the signature is applied. So, the problem is not the order of
> the signing of the .sys file.

Great news, this simplifies the signing batches somewhat – please have
this information added to the WDK documentation.

It’s documented somewhere because I saw it during a preliminary read-up
of this area. On the other hand, I made sure my scripts signed the .sys
first as I couldn’t find that statement again when I was setting it up
for real, and it didn’t seem worth the effort of looking harder.

34

Is there is already a correction available ?

I 've got a similar problem when :

  1. I signed the driver on a old MMX200 machine with XP 32bit SP2 ( 256 MB of RAM )
  2. Installation of the driver on Server 2008 64 bit bleats about " Unable to verify the pusblisher … malicious software …
    blalbla
  3. When pushing “accept” however , installation continues without a problem and the driver starts working. The driver starts after
    reboot too without a problem.
  4. The properties of the *cat and *sys files show up the signatures without any error or warning notice. The certificate installs as
    well in “trusted publishers”

When I perform the signing on another machine ( Pentium 4 with 1 GB ) also with XP 32 bit SP2 , the signing runs perfect and the
problem above on Server 2008 does not occur.

Thanks ,

Christiaan

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Thursday, July 31, 2008 11:41 PM
Subject: RE:[ntdev] Signing drivers with signtool for XP 64-bit

>


>
> Ahhh… You might be missing my post.
>
> SignTool does not work correct on S03 SP2 x64, on a REAL machine. It fails to add the cross cert to the image.
>
> So, if my build box is a 64-bit system with S03 SP2 installed, and part of my build process is signing the executable, that does
> not work.
>
> SignTool really needs somebody to spend some time making it work correctly. Maybe you can take a hammer to the security folks?
>
> Bug list:
>
> (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 certain smart cards (eToken, specifically), cuz signtool won’t read it. So, instead of
> being able to store your company code signing cert on a smart card that can be physically secured, you’re effectively forced to
> store it on a machine in the “personal” cert store.
> (c) Signing Wizard not supported by SignTool
> (d) SignTool broken on (at least) S03 SP2 x64
>
> I just list 'em,
>
> P
>
> —
> 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