There is a fair amount of one-time dinking around to create a
certificate, get it registered in the certificate stores on the host and
target machines, and add /testsign to boot.ini using bcdedit, but once
that is done, all it takes is one “signtool” command to get the binary
signed. Vista64 loads it just like a built-in.
I had been moaning about how difficult the code-signing stuff was until
I actually sat down to do it, he said, sheepishly.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
There is a fair amount of one-time dinking around to create a
certificate, get it registered in the certificate stores on the host
and
target machines, and add /testsign to boot.ini using bcdedit, but once
that is done, all it takes is one “signtool” command to get the binary
signed. Vista64 loads it just like a built-in.
I had been moaning about how difficult the code-signing stuff was
until
I actually sat down to do it, he said, sheepishly.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
OK. That was really easy. It took maybe fifteen minutes to get a file
signed with an embedded signature and loaded on Longhorn Beta 3 without
F8 or WinDbg.
Thanks,
mm
>> xxxxx@probo.com 2007-06-11 16:34 >>>
Martin O’Brien wrote:
What document, Tim? I’d be most interested in this as well.
The link was posted here just last week, so I thought I would save
time
by skipping it. That’ll teach me.
There is a fair amount of one-time dinking around to create a
certificate, get it registered in the certificate stores on the host
and
target machines, and add /testsign to boot.ini using bcdedit, but once
that is done, all it takes is one “signtool” command to get the binary
signed. Vista64 loads it just like a built-in.
I had been moaning about how difficult the code-signing stuff was
until
I actually sat down to do it, he said, sheepishly.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Sorry, but either I misunderstand what you’re saying or this IS NOT CORRECT.
For WDM: If you supply a completion routine, and if Irp->PendingReturned is set
and you do not reclaim the IRP, then you MUST call IoMarkIrpPending in your
completion routine.
This is *EXACTLY* what I was saying in my discussion with Calvin, but, as it eventually turned out, I was wrong. As Elyas had explained, the above statement holds true if and only if your Dispatch() routine returns the same status as IoCallDriver() does. However, if your Dispatch() routine calls
IoMarkIrpPending() before passing IRP down the stack (and, hence, has no option other than returning STATUS_PENDING), you should NOT call IoMarkIrpPending() from your completion routine. What you see below is a relevant code snippet from IoCompleteRequest() implementation that Elyas had provided in order to demonstrate how PendingReturned bit gets propagated up the stack when you call IoCompleteRequest(). As you will see, my above statement describes a single iteration of a ‘for’ loop( although it seems that
may statement about calling IoMarkIrpPending()after the completion routine returns is, indeed, wrong - more on this right after the code sample):
status = stackPointer->CompletionRoutine( deviceObject,
Irp,
stackPointer->Context
);
if (status == STATUS_MORE_PROCESSING_REQUIRED) {
//
// Note: Notice that if the driver has returned the above
// status value, it may have already DEALLOCATED the
// packet! Therefore, do NOT touch any part of the
// IRP in the following code.
//
return;
}
} else {
if (Irp->PendingReturned && Irp->CurrentLocation <=
Irp->StackCount) {
IoMarkIrpPending( Irp );
}
ZeroIrpStackLocation( stackPointer );
}
}
}
///////////////////
While IoCompleteRequest DOES call IoMarkIrpPending, it only does so if you DO
NOT supply a completion routine.
Actually, this, indeed, seems to be the case - it looks like I just got confused with the number of braces ( as you can see, the above code sample is not-so-well indented). Thank you so much for your correction - if you did not correct me, I would stay blissfully ignorant of this issue…
Be forwarned!! This probably will apply to no one, but just in case. Any
signing aside from an official Microsoft signature will always be weaker
than an official Microsoft signature. I don’t know if this is mentioned
anywhere, but it bit me a while back. IF you need to replace a native
system binary…test signing will not allow you to do this on Vista. You
have to have a real signature, which you can’t get (and probably don’t
want), in order to get past system protection and replace a native system
binary. Even though it is often instructive to replace system binaries with
those of your own for research and or testing purposes, it isn’t possible
via test signing…and just isn’t possible in anyway I know of on Vista
unless your Microsoft. I find this to be annoying, but probably most people
never do this anyway. I do wish there were some way to turn this crap off
for testing purposes. Anyway, just FYI.
Bill M.
“Martin O’Brien” wrote in message news:xxxxx@ntdev… > OK. That was really easy. It took maybe fifteen minutes to get a file > signed with an embedded signature and loaded on Longhorn Beta 3 without > F8 or WinDbg. > > Thanks, > > > mm > >>>> xxxxx@probo.com 2007-06-11 16:34 >>> > Martin O’Brien wrote: >> What document, Tim? I’d be most interested in this as well. >> > > The link was posted here just last week, so I thought I would save > time > by skipping it. That’ll teach me. > > It’s the “Kernel-Mode Code Signing Walkthrough” white-paper, first > presented at a hands-on session at WinHEC 2006: > http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx > > > There is a fair amount of one-time dinking around to create a > certificate, get it registered in the certificate stores on the host > and > target machines, and add /testsign to boot.ini using bcdedit, but once > that is done, all it takes is one “signtool” command to get the binary > signed. Vista64 loads it just like a built-in. > > I had been moaning about how difficult the code-signing stuff was > until > I actually sat down to do it, he said, sheepishly. > > – > 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 >
I do wish there were some way to turn this crap off
for testing purposes.
Well, speaking as someone from a security background, I do have to point out that once you get any kernel-mode code running (say, signed with your own root certificate), you can poke around and do “bad” things. Like…
I assume that there’s probably a shared kernel function exported from some OS module that validates a signature as specifically coming from Microsoft (not just any CA). This functionality must be built into the kernel support routines since it is required during boot. It wouldn’t be that difficult to locate said function and patch it to always return a success code. Then everything would appear to be signed by MS.
I’m actually rather surprised that no one has done this yet.
I haven’t tried this myself, but I have heard that you can replace an MS
binary by taking ownership of the file in an RAA cmd window using the
“takeown /f” command, and then modify the permissions to give you full
control, and then just copy a replacement binary over it and SFP won’t
replace it.
The signature (except on 64-bit Windows) only really has any effect
during installation (and even in x64, a properly signed replacement
binary will load just fine).
Bill McKenzie wrote:
Be forwarned!! This probably will apply to no one, but just in case. Any
signing aside from an official Microsoft signature will always be weaker
than an official Microsoft signature. I don’t know if this is mentioned
anywhere, but it bit me a while back. IF you need to replace a native
system binary…test signing will not allow you to do this on Vista. You
have to have a real signature, which you can’t get (and probably don’t
want), in order to get past system protection and replace a native system
binary. Even though it is often instructive to replace system binaries with
those of your own for research and or testing purposes, it isn’t possible
via test signing…and just isn’t possible in anyway I know of on Vista
unless your Microsoft. I find this to be annoying, but probably most people
never do this anyway. I do wish there were some way to turn this crap off
for testing purposes. Anyway, just FYI.
Bill M.
“Martin O’Brien” wrote in message > news:xxxxx@ntdev… >> OK. That was really easy. It took maybe fifteen minutes to get a file >> signed with an embedded signature and loaded on Longhorn Beta 3 without >> F8 or WinDbg. >> >> Thanks, >> >> >> mm >> >>>>> xxxxx@probo.com 2007-06-11 16:34 >>> >> Martin O’Brien wrote: >>> What document, Tim? I’d be most interested in this as well. >>> >> The link was posted here just last week, so I thought I would save >> time >> by skipping it. That’ll teach me. >> >> It’s the “Kernel-Mode Code Signing Walkthrough” white-paper, first >> presented at a hands-on session at WinHEC 2006: >> http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx >> >> >> There is a fair amount of one-time dinking around to create a >> certificate, get it registered in the certificate stores on the host >> and >> target machines, and add /testsign to boot.ini using bcdedit, but once >> that is done, all it takes is one “signtool” command to get the binary >> signed. Vista64 loads it just like a built-in. >> >> I had been moaning about how difficult the code-signing stuff was >> until >> I actually sat down to do it, he said, sheepishly. >> >> – >> 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 >> > > >
– Ray (If you want to reply to me off list, please remove “spamblock.” from my email address)
I haven’t tried this myself, but I have heard that you can replace
an MS binary by taking ownership of the file in an RAA cmd window
using the “takeown /f” command, and then modify the permissions to
give you full control, and then just copy a replacement binary over
it and SFP won’t replace it.
No, no… If you already called IoMarkIrpPending and returned STATUS_PENDING, then SL_PENDING_RETURNED is already set in your stack location. Thus, it doesn’t MATTER if you call IoMarkIrpPending again in your completion routine. I can’t have been cleared, since you SET it. So, if you check Irp->PendingReturned (indicating the driver BELOW YOU returned STATUS_PENDING) and if Irp->PendingReturned is TRUE, then the worst that’s going to happen is you set SL_PENDING_RETURNED again once it’s already set.
If it were incorrect then the code snippet shown above couldn’t do precisely this in ABSENCE of a completion routine.
What you CANNOT do is blindly call IoMarkIrpPending (as was shown a few years back in several DDK sample drivers). THIS doesn’t work, and is indeed dangerous.
Let’s either drop this or take it off line, please…
In my experience it is still there. Maybe marketoids changed the name
but old APIs still work. My tool written originally for w2k which stops
WFP/SFC thread still works at Vista. It causes WinLogon crash but
surprisingly it isn’t fatal at Vista and binaries can be replaced. I
haven’t examined what causes the crash; I just needed to replace few
kernel drivers with checked versions and it worked so I was happy
“Steve Dispensa” wrote in message news:xxxxx@ntdev… > > On Jun 11, 2007, at 7:14 PM, Ray Trent wrote: > >> I haven’t tried this myself, but I have heard that you can replace an MS >> binary by taking ownership of the file in an RAA cmd window using the >> “takeown /f” command, and then modify the permissions to give you full >> control, and then just copy a replacement binary over it and SFP won’t >> replace it. > > I thought WFP was gone on Vista? > > http://msdn2.microsoft.com/en-us/library/aa382503.aspx > > -sd > > > >
Well, the new system uses filesystem ACLs instead of a watchdog
thread, or so I had thought.
On Jun 11, 2007, at 11:33 PM, Bill McKenzie wrote:
WRP now…a rose by any other name…
“Steve Dispensa” wrote in message > news:xxxxx@ntdev… >> >> On Jun 11, 2007, at 7:14 PM, Ray Trent wrote: >> >>> I haven’t tried this myself, but I have heard that you can >>> replace an MS >>> binary by taking ownership of the file in an RAA cmd window >>> using the >>> “takeown /f” command, and then modify the permissions to give >>> you full >>> control, and then just copy a replacement binary over it and SFP >>> won’t >>> replace it. >> >> I thought WFP was gone on Vista? >> >> http://msdn2.microsoft.com/en-us/library/aa382503.aspx >> >> -sd >> >> >> >> > > > > — > 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
From my experience the new system is tightened down much more than the old.
Not sure the mechanics involved.
Bil M.
“Steve Dispensa” wrote in message news:xxxxx@ntdev… > Well, the new system uses filesystem ACLs instead of a watchdog thread, > or so I had thought. > > On Jun 11, 2007, at 11:33 PM, Bill McKenzie wrote: > >> WRP now…a rose by any other name… >> >> “Steve Dispensa” wrote in message >> news:xxxxx@ntdev… >>> >>> On Jun 11, 2007, at 7:14 PM, Ray Trent wrote: >>> >>>> I haven’t tried this myself, but I have heard that you can replace an >>>> MS >>>> binary by taking ownership of the file in an RAA cmd window using the >>>> “takeown /f” command, and then modify the permissions to give you >>>> full >>>> control, and then just copy a replacement binary over it and SFP >>>> won’t >>>> replace it. >>> >>> I thought WFP was gone on Vista? >>> >>> http://msdn2.microsoft.com/en-us/library/aa382503.aspx >>> >>> -sd >>> >>> >>> >>> >> >> >> >> — >> 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 > >
As one who’s worked on the storage stack for a number of years, I feel
that I can shed some light on our internal throught processes in this
area.
We’ve been looking at using KMDF for portions of the storage stack for
some time now. To help you understand why we’ve not made a full jump
yet, it helps to realize that the drivers we ship are OS specific, and
thus a major benefit of KMDF (cross-platform support to wxp,
semi-supported w2k) doesn’t apply to the storage stack. Add in the
limited pnp/power management that must occur, and its clear that a
number of the benefits simply didn’t apply.
Most development is incremental. This mitigates risk, and utilizes the
value of code which people are familiar with. Making a large-scale
switch to a new code base brings the risk of regressions, and
invalidates a majority of the understanding of the previous code paths.
As with most decisions here, it became one of resources and timing.
With all that said, we are still strongly considering using KMDF in the
storage stack, especially at the class layer (disk, cdrom, tape, …).
Even without the cross-platform support requirements, the abstractions
and consistent coding APIs make a compelling argument.
My summary: If the code is new, it should use KMDF. If the code has to
deal with basic PNP/Power (as most drivers do), you should strongly
consider KMDF. If you have to deal with advanced PNP/Power (i.e.
selective suspend), then KMDF should be used as it handles the
gazillion(*) edge cases for you and avoids customer blue screen.
Henry Gabryjelski
Senior Software Development Engineer
US - Windows Device Experience
Microsoft Corporation
(*) Ok, slight exaggeration, but there are a lot of edge cases.
-----Original Message-----
From: David J. Craig [mailto:xxxxx@yoshimuni.com]
Sent: Sunday, June 10, 2007 10:33 PM
Subject: Re: Reasons NOT to use KMDF
The answer to that question is simple. Most of the storage stack does
not
have any PnP or Power processing in it. The port drivers supply all the
PnP
& Power logic required for their miniports. There is some indication
that
some of the miniports will have a KMDF framework in the future, and a
few
might work now if rewritten properly. There have been a few posts about
how
to use KMDF to write drivers that use WDM lower edge.
Most of the samples in the WDK were written by third parties. While I
think
the original floppy driver was written by Microsoft I heard a third
party
did the split of floppy.sys into two drivers. Some of the samples are
from
third party companies. If you mean disk.sys and cleanup.sys in the
storage
stack they are the disk class drivers. Cleanup.sys is the PnP and power
support for disk.sys and I think other class drivers from Microsoft also
use
it.
–
David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation
wrote in message news:xxxxx@ntdev… > Sorry to have brought up the bit about UMDF not working in 2003, but > that’s actually what inspired this thread–it was a gotcha I never knew > about and wondered about KMDF limits I might not know about. So KMDF is > perfectly fine for boot start drivers–excellent news. But as others > confirmed, the large distribution size can be a negative or even a show > stopper. > > I wonder why not all examples in the WDK are KMDF. It appears the entire > storage stack doesn’t use it at all for instance. You would think that if > this is really the way to go, Microsoft would lead by example, even if it > cost them extra time because it would set the stage for all new driver
