digital signed drivers

Bedanto · July 2, 2007, 12:41pm

Here is the situation.

When I replace an in box driver in vista with one of my own, go to
networking property page and open “update driver” option and select “Search
automatically for updated driver software” , vista picks up the original in
the box driver and replaces the updated driver.

SO i think that may be the in the box driver is digitally signed and mine is
not. So I go ahead and replace the in the box driver with one of my
digitally signed driver and repeat the above steps. It again does the same,
the ITB driver gets picked up.

Next I try enabling " Treat all digitally singed drivers equally" option in
“gpedit” but the result is same.

This is in Vista 32 (no sp1 installed).

any clues, whats going on?

bed

OSR_Community_User · July 2, 2007, 2:52pm

Tim:

You couldn’t be more correct about unnamed masses out there dedicating
themselves to ensuring that my computer will not function as it was
meant to/I want it to. I was thinking about that as I read this post,
and reflected on the massacre that was WFP, when I had some insight in
to where they might just get such an idea that security is preventing a
computer from functioning in a way that an observer would call
reasonable, and, for the love of God, whatever you do, don’t do what the
user specifically asks for. I have no issue whatsoever with features
like whatever this is now called in Vista, as long you can either
disable it permanently and it is documented how to do so clearly and
obviously; or it is equally well and accurately documented that it is
not possible to disable a certain feature. My preference is the former,
but I’ll settle for later if it means not wasting days on nonsense like
this. Even spyware must provide a way to uninstall itself completely,
otherwise it’s called a virus, like say, WFP.

mm

DDK MVP

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bedanto
Sent: Monday, July 02, 2007 12:41
To: Windows System Software Devs Interest List
Subject: [ntdev] digital signed drivers

Here is the situation.

When I replace an in box driver in vista with one of my own, go to
networking property page and open “update driver” option and select
“Search automatically for updated driver software” , vista picks up the
original in the box driver and replaces the updated driver.

SO i think that may be the in the box driver is digitally signed and
mine is not. So I go ahead and replace the in the box driver with one of
my digitally signed driver and repeat the above steps. It again does the
same, the ITB driver gets picked up.

Next I try enabling " Treat all digitally singed drivers equally" option
in “gpedit” but the result is same.

This is in Vista 32 (no sp1 installed).

any clues, whats going on?

bed

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Matthew_Carter · July 2, 2007, 3:49pm

> When I replace an in box driver in vista with one of my own, go to

networking property page and open “update driver” option and select
“Search
automatically for updated driver software” , vista picks up the original
in
the box driver and replaces the updated driver.

Windows Vista picks the best driver based on:

Signed by Windows signing authority (WHQL)
Signed by Third party signing authority
Best hardware device ID match
Driver Date from DriverVer in INF file
Driver Version from DriverVer in INF file

Reference:
http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/pnp-driver.doc

Yes, the unsigned will never be picked over an ITB signed driver in Windows
Vista, or Windows XP even I think. It would be in Windows 2000. It would
lose out in step 1 above.

SO i think that may be the in the box driver is digitally signed and mine
is
not. So I go ahead and replace the in the box driver with one of my
digitally signed driver and repeat the above steps. It again does the
same,
the ITB driver gets picked up.

Your signed driver loses in step 1.

Next I try enabling " Treat all digitally singed drivers equally" option
in
“gpedit” but the result is same.

It seems that setting this option will make 1 and 2 above equivalent so your
signed driver and the ITB driver will tie on that account and move to step
3.

You may have specified a less specific hardware ID in your INF than the
one ITB. Go into the details tab of the device properties in the device
manager and select ‘Hardware IDs’ to see a list of the hardware IDs that the
particular device reports, then look at ‘Matching Device ID’ I think to see
which one your device actually matched with.
The DriverVer line in your INF file may not specify a date that is newer
than the one ITB. Maybe you didn’t update the DriverVer line in the INF to
reflect the actual creation date of your new driver.
Its pretty unlikely that you have the same date as the ITB one, so you
wouldn’t make it this far. If you did, it would check the version number in
the INF.

Bedanto · July 2, 2007, 4:20pm

Matthew,

Thanks for the excellent tips.

Your signed driver loses in step 1.

So even if i have a whql qual driver in my lab, and MS signs it (I believe
once we whql ms signs it) then too the msft Inbox drier gets higher
precedence?

hardwre ids, version numbers, files dates and other things are all fine. the
above is the only doubt i have. if so then using gpedit doesnt help at all.

bed

On 7/3/07, Matthew Carter wrote:
>
> > When I replace an in box driver in vista with one of my own, go to
> > networking property page and open “update driver” option and select
> > “Search
> > automatically for updated driver software” , vista picks up the original
> > in
> > the box driver and replaces the updated driver.
>
> Windows Vista picks the best driver based on:
> 1) Signed by Windows signing authority (WHQL)
> 2) Signed by Third party signing authority
> 3) Best hardware device ID match
> 4) Driver Date from DriverVer in INF file
> 5) Driver Version from DriverVer in INF file
>
> Reference:
>
> http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/pnp-driver.doc
>
> Yes, the unsigned will never be picked over an ITB signed driver in
> Windows
> Vista, or Windows XP even I think. It would be in Windows 2000. It would
> lose out in step 1 above.
>
> > SO i think that may be the in the box driver is digitally signed and
> mine
> > is
> > not. So I go ahead and replace the in the box driver with one of my
> > digitally signed driver and repeat the above steps. It again does the
> > same,
> > the ITB driver gets picked up.
>
> Your signed driver loses in step 1.
>
> > Next I try enabling " Treat all digitally singed drivers equally" option
> > in
> > “gpedit” but the result is same.
>
> It seems that setting this option will make 1 and 2 above equivalent so
> your
> signed driver and the ITB driver will tie on that account and move to step
> 3.
>
> 3) You may have specified a less specific hardware ID in your INF than the
> one ITB. Go into the details tab of the device properties in the device
> manager and select ‘Hardware IDs’ to see a list of the hardware IDs that
> the
> particular device reports, then look at ‘Matching Device ID’ I think to
> see
> which one your device actually matched with.
>
> 4) The DriverVer line in your INF file may not specify a date that is
> newer
> than the one ITB. Maybe you didn’t update the DriverVer line in the INF
> to
> reflect the actual creation date of your new driver.
>
> 5) Its pretty unlikely that you have the same date as the ITB one, so you
> wouldn’t make it this far. If you did, it would check the version number
> in
> the INF.
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Maxim_S_Shatskih · July 2, 2007, 4:33pm

Use the ImagePath registry value to bypass this.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Bedanto” wrote in message news:xxxxx@ntdev…
> Matthew,
>
> Thanks for the excellent tips.
>
> >Your signed driver loses in step 1.
>
> So even if i have a whql qual driver in my lab, and MS signs it (I believe
> once we whql ms signs it) then too the msft Inbox drier gets higher
> precedence?
>
> hardwre ids, version numbers, files dates and other things are all fine. the
> above is the only doubt i have. if so then using gpedit doesnt help at all.
>
> bed
>
>
>
> On 7/3/07, Matthew Carter wrote:
> >
> > > When I replace an in box driver in vista with one of my own, go to
> > > networking property page and open “update driver” option and select
> > > “Search
> > > automatically for updated driver software” , vista picks up the original
> > > in
> > > the box driver and replaces the updated driver.
> >
> > Windows Vista picks the best driver based on:
> > 1) Signed by Windows signing authority (WHQL)
> > 2) Signed by Third party signing authority
> > 3) Best hardware device ID match
> > 4) Driver Date from DriverVer in INF file
> > 5) Driver Version from DriverVer in INF file
> >
> > Reference:
> >
> >
http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/pnp-driver.doc
> >
> > Yes, the unsigned will never be picked over an ITB signed driver in
> > Windows
> > Vista, or Windows XP even I think. It would be in Windows 2000. It would
> > lose out in step 1 above.
> >
> > > SO i think that may be the in the box driver is digitally signed and
> > mine
> > > is
> > > not. So I go ahead and replace the in the box driver with one of my
> > > digitally signed driver and repeat the above steps. It again does the
> > > same,
> > > the ITB driver gets picked up.
> >
> > Your signed driver loses in step 1.
> >
> > > Next I try enabling " Treat all digitally singed drivers equally" option
> > > in
> > > “gpedit” but the result is same.
> >
> > It seems that setting this option will make 1 and 2 above equivalent so
> > your
> > signed driver and the ITB driver will tie on that account and move to step
> > 3.
> >
> > 3) You may have specified a less specific hardware ID in your INF than the
> > one ITB. Go into the details tab of the device properties in the device
> > manager and select ‘Hardware IDs’ to see a list of the hardware IDs that
> > the
> > particular device reports, then look at ‘Matching Device ID’ I think to
> > see
> > which one your device actually matched with.
> >
> > 4) The DriverVer line in your INF file may not specify a date that is
> > newer
> > than the one ITB. Maybe you didn’t update the DriverVer line in the INF
> > to
> > reflect the actual creation date of your new driver.
> >
> > 5) Its pretty unlikely that you have the same date as the ITB one, so you
> > wouldn’t make it this far. If you did, it would check the version number
> > in
> > the INF.
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>

Tim_Roberts · July 2, 2007, 4:55pm

Martin O’Brien wrote:

You couldn’t be more correct about unnamed masses out there dedicating
themselves to ensuring that my computer will not function as it was
meant to/I want it to. I was thinking about that as I read this post,
and reflected on the massacre that was WFP, when I had some insight in
to where they might just get such an idea that security is preventing
a computer from functioning in a way that an observer would call
reasonable, and, for the love of God, whatever you do, don’t do what
the user specifically asks for.

Yes, but…

You always need to remember that the folks who hang out in this forum
are completely unrepresentative of the typical Windows user. WFP, as
well a substantial percentage of the “improvements” in Vista, make
things more difficult for you and me. That’s undeniable and
irritating. However, we simply do not matter. We are an immeasurably
small fraction of the Windows user base. For your secretary, or your
mother, or your grandmother, all of that handholding and protection is a
Very Good Thing indeed.

In another life, I am a square dancer, and I have naturally become a
“computing resource” for the square dance community in Oregon. I cannot
count the number of times that I’ve had to clean up messes by people who
thought they were following instructions, or thought they were smart
enough to administer their own machines (or even knew what it meant to
“administer”), or who believed that a DLL with a teddy bear icon was
somehow damaging to their computers.

We who have to work in this environment will find a way around the
restrictions, but I don’t blame Microsoft for adding them.

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

Bedanto · July 2, 2007, 5:07pm

thanks max, but this is NDIS miniport, the link says it wont work.

http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/46713.mspx?mfr=true

bed

On 7/3/07, Maxim S. Shatskih wrote:
>
> Use the ImagePath registry value to bypass this.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> “Bedanto” wrote in message news:xxxxx@ntdev…
> > Matthew,
> >
> > Thanks for the excellent tips.
> >
> > >Your signed driver loses in step 1.
> >
> > So even if i have a whql qual driver in my lab, and MS signs it (I
> believe
> > once we whql ms signs it) then too the msft Inbox drier gets higher
> > precedence?
> >
> > hardwre ids, version numbers, files dates and other things are all fine.
> the
> > above is the only doubt i have. if so then using gpedit doesnt help at
> all.
> >
> > bed
> >
> >
> >
> > On 7/3/07, Matthew Carter wrote:
> > >
> > > > When I replace an in box driver in vista with one of my own, go to
> > > > networking property page and open “update driver” option and select
> > > > “Search
> > > > automatically for updated driver software” , vista picks up the
> original
> > > > in
> > > > the box driver and replaces the updated driver.
> > >
> > > Windows Vista picks the best driver based on:
> > > 1) Signed by Windows signing authority (WHQL)
> > > 2) Signed by Third party signing authority
> > > 3) Best hardware device ID match
> > > 4) Driver Date from DriverVer in INF file
> > > 5) Driver Version from DriverVer in INF file
> > >
> > > Reference:
> > >
> > >
>
> http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/pnp-driver.doc
> > >
> > > Yes, the unsigned will never be picked over an ITB signed driver in
> > > Windows
> > > Vista, or Windows XP even I think. It would be in Windows 2000. It
> would
> > > lose out in step 1 above.
> > >
> > > > SO i think that may be the in the box driver is digitally signed and
> > > mine
> > > > is
> > > > not. So I go ahead and replace the in the box driver with one of my
> > > > digitally signed driver and repeat the above steps. It again does
> the
> > > > same,
> > > > the ITB driver gets picked up.
> > >
> > > Your signed driver loses in step 1.
> > >
> > > > Next I try enabling " Treat all digitally singed drivers equally"
> option
> > > > in
> > > > “gpedit” but the result is same.
> > >
> > > It seems that setting this option will make 1 and 2 above equivalent
> so
> > > your
> > > signed driver and the ITB driver will tie on that account and move to
> step
> > > 3.
> > >
> > > 3) You may have specified a less specific hardware ID in your INF than
> the
> > > one ITB. Go into the details tab of the device properties in the
> device
> > > manager and select ‘Hardware IDs’ to see a list of the hardware IDs
> that
> > > the
> > > particular device reports, then look at ‘Matching Device ID’ I think
> to
> > > see
> > > which one your device actually matched with.
> > >
> > > 4) The DriverVer line in your INF file may not specify a date that is
> > > newer
> > > than the one ITB. Maybe you didn’t update the DriverVer line in the
> INF
> > > to
> > > reflect the actual creation date of your new driver.
> > >
> > > 5) Its pretty unlikely that you have the same date as the ITB one, so
> you
> > > wouldn’t make it this far. If you did, it would check the version
> number
> > > in
> > > the INF.
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at
> > > http://www.osronline.com/page.cfm?name=ListServer
> > >
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Bedanto · July 2, 2007, 5:23pm

ok folks, something is missing out here.

I followed every detail of Matthew’s email here is the deal…

My driver is whql qualified but not signed by MS so I do see the point where
it was replaced by MSFT driver.

So far so good, but then I go to gpedit and ‘request’ vista to treat me
equally.

So after that all signed drivers should be equal. So the difference should
in in device id’s in the infs. THEY ARE THE SAME. identical.

So I trace down to the versions, hell ofcourse the msft driver version (and
date) is older than the OTB driver.

Then y is vista picking the MSFT driver???

Bed

On 7/3/07, Tim Roberts wrote:
>
> Martin O’Brien wrote:
> >
> >
> >
> > You couldn’t be more correct about unnamed masses out there dedicating
> > themselves to ensuring that my computer will not function as it was
> > meant to/I want it to. I was thinking about that as I read this post,
> > and reflected on the massacre that was WFP, when I had some insight in
> > to where they might just get such an idea that security is preventing
> > a computer from functioning in a way that an observer would call
> > reasonable, and, for the love of God, whatever you do, don’t do what
> > the user specifically asks for.
> >
>
> Yes, but…
>
> You always need to remember that the folks who hang out in this forum
> are completely unrepresentative of the typical Windows user. WFP, as
> well a substantial percentage of the “improvements” in Vista, make
> things more difficult for you and me. That’s undeniable and
> irritating. However, we simply do not matter. We are an immeasurably
> small fraction of the Windows user base. For your secretary, or your
> mother, or your grandmother, all of that handholding and protection is a
> Very Good Thing indeed.
>
> In another life, I am a square dancer, and I have naturally become a
> “computing resource” for the square dance community in Oregon. I cannot
> count the number of times that I’ve had to clean up messes by people who
> thought they were following instructions, or thought they were smart
> enough to administer their own machines (or even knew what it meant to
> “administer”), or who believed that a DLL with a teddy bear icon was
> somehow damaging to their computers.
>
> We who have to work in this environment will find a way around the
> restrictions, but I don’t blame Microsoft for adding them.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Matthew_Carter · July 2, 2007, 5:37pm

> So even if i have a whql qual driver in my lab, and MS signs it (I believe

once we whql ms signs it) then too the msft Inbox drier gets higher
precedence?

No, if your driver is WHQL signed by MS then it has the same precedence as
the Microsoft in box driver. Both are signed by Microsoft. However,
there’s another peculiarity that seems to be particular to Vista about where
your driver INF file is located. Below is a quote from one of the MSDN
pages:

After a device is attached, Setup first attempts to locate and install a
driver in a trusted system context without user interaction, as follows:

(Windows Vista) The driver package must be installed in the driver store.
This includes inbox drivers, installed drivers other than inbox drivers, and
preinstalled drivers. The INF file for the driver package cannot specify the
InteractiveInstall flag in the INF ControlFlags section. Setup does not
attempt to access Windows Update to locate matching drivers and does not
search for preloaded drivers in the locations that are specified by the
DevicePath registry value.

Reference:
http://msdn2.microsoft.com/en-us/library/aa477011.aspx

It seems to me that this is saying that you have to use DPInst or something
to install ANY driver package into the driver store *before* you can attempt
for Windows to detect it, if you don’t want to update the driver manually.
I guess that means the inf needs to be in the INF folder, not on a CDROM or
in some random folder that the user tells it to look in. It won’t even get
to the part where it asks the user what folder unless it checked the driver
store and didn’t find a match, which you are saying it does for your
particular device. Maybe you should check out that page yourself.

OSR_Community_User · July 2, 2007, 7:27pm

Absolutely. It’s the lack of accurate and timely information that
drives me out of my mind. For example, I have a large set of custom
debugging code that, among other things, uses RPC as a transport between
host and target. I’ve used this for years, and it’s grown to involve
some debugging hardware and things from user mode to hypervisors. In
any case, when they broke RPC in Vista, it created a lot of tedious work
for me to convert to sockets, but, as you said, this isn’t about me, and
I know that. What pisses me off is that, contrary to the SDK
documentation, if one messed around with GPEDIT and took ownership of
basically the Windows folder on some of the Beta’s of Vista, RPC would
work. Somewhere along the way, I couldn’t get this to work anymore,
which I knew was coming at some point, but the part that drives me out
of my mind is that maybe it still is possible to get it work, just with
new secret values (like WFP), et. c, and there’s nothing reliable to
trust, as the documentation was blatantly false in the first place. The
other thing about this lock down stuff is that by not documenting how to
disable it selectively, security just gets routed by methods like I used
(on test machines is a secure facility).

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, July 02, 2007 16:55
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] digital signed drivers