Can anyone tell me if there’s a way to use Detours with kernel-mode drivers?
The thinking is to architect a framework for unit-testing driver binaries
using Detours to intercept all HAL calls. Interrupts would be injected by
calling ISRs and DPCs directly.
I imagine such a framework would comprise user-mode executables, the DUT
driver binary and the ‘hardware emulation layer’ kernel? DLLs. There would
also have to be communications between the user-mode executable and the
kernel DLL doing the Detouring.
Obviously the testing would be limited in nature - more data-path and
algorithmic testing than testing that it operates as a windows driver as
such - but perhaps worth considering none-the-less.
Can it be done? Has it been done?
Regards,
–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http: 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266</http:>
> Can anyone tell me if there’s a way to use Detours with kernel-mode drivers?
DEFINITELY NOT!!!
In order to understand why, consider the following scenario:
First instruction of the target function is, say, 2 bytes long. Thread X executes it and gets preempted. While thread X is in standby state, you modify the beginnning of the target function with
JMP, which is 5 bytes long. What happens when thread X resumes execution??? The answer is obvious - its EIP point right to the middle of your JMP instruction. BANG!!!
When you are in the user mode, you can make sure that all threads of the target process are suspended, and, after having overwritten the address, you can adjust their EIPs with SetThreadContext() if necessary. However, you cannot do it in the kernel mode, can you???
The only thing you can do here is to take advantage of INT3 opcode, i.e. something that I have described in the article at http://www.codeproject.com/system/soviet_direct_hooking.asp.
This is the only possible way to work around the above mentioned problem…
Sorry, detours is purely UM only. Since you own the binary, you could
rig this yourself by judicious use of #defines to redirect to your own
simulation library (which if you had detours you would have to write
anyways). For usb devices there is DSF (Device simulation framework), http://msdn2.microsoft.com/en-us/library/aa469592.aspx which is detours
“like”
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark McDougall
Sent: Sunday, August 26, 2007 10:17 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Detours?
Hi,
Can anyone tell me if there’s a way to use Detours with kernel-mode
drivers?
The thinking is to architect a framework for unit-testing driver
binaries
using Detours to intercept all HAL calls. Interrupts would be injected
by
calling ISRs and DPCs directly.
I imagine such a framework would comprise user-mode executables, the DUT
driver binary and the ‘hardware emulation layer’ kernel? DLLs. There
would
also have to be communications between the user-mode executable and the
kernel DLL doing the Detouring.
Obviously the testing would be limited in nature - more data-path and
algorithmic testing than testing that it operates as a windows driver as
such - but perhaps worth considering none-the-less.
Can it be done? Has it been done?
Regards,
–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http: 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266
> Since you own the binary, you could rig this yourself by judicious use of #defines to
redirect to your own simulation library
If I got it right, he wants to do it with HAL.DLL, i.e. with the binary that he does not own. Therefore,
the above approach does not really apply. Certainly, if you are “adventurous character” you can try to provide your own implementation of HAL.DLL. This bogus DLL will export all entry points that the real HAL.DLL does, and, depending on your objectives, these entry points will either forward the job to the actual HAL.DLL, or do parts of the job themselves. However, I am not sure that this suits the OP’s objectives - normally you would go for Detours-style hooking only when you want to intercept non-exported calls (otherwise, a simple IDT hooking will work just fine) …
If I got it right, he wants to do it with HAL.DLL, i.e. with the binary
that he does not own. Therefore, the above approach does not really
apply. Certainly, if you are “adventurous character” you can try to
provide your own implementation of HAL.DLL. This bogus DLL will export
all entry points that the real HAL.DLL does, and, depending on your
objectives, these entry points will either forward the job to the
actual HAL.DLL, or do parts of the job themselves. However, I am not
sure that this suits the OP’s objectives - normally you would go for
Detours-style hooking only when you want to intercept non-exported
calls (otherwise, a simple IDT hooking will work just fine) …
For the record, we do own the binary, but the idea is to test the
production-built driver binary as-distributed.
And no, the plan isn’t to be overly “adventurous”. If the job was
relatively painless, then we’d consider doing it. But an all-out emulation
of HAL.DLL is out of the question.
Thanks again!
Regards,
–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http: 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266</http:>
I did my own app based on this. I can select a kernel mode function, and
ever call to this function will be shown to me…
Steffen
“Mark McDougall” wrote in message news:xxxxx@ntdev… > Hi, > > Can anyone tell me if there’s a way to use Detours with kernel-mode > drivers? > > The thinking is to architect a framework for unit-testing driver binaries > using Detours to intercept all HAL calls. Interrupts would be injected by > calling ISRs and DPCs directly. > > I imagine such a framework would comprise user-mode executables, the DUT > driver binary and the ‘hardware emulation layer’ kernel? DLLs. There would > also have to be communications between the user-mode executable and the > kernel DLL doing the Detouring. > > Obviously the testing would be limited in nature - more data-path and > algorithmic testing than testing that it operates as a windows driver as > such - but perhaps worth considering none-the-less. > > Can it be done? Has it been done? > > Regards, > > – > Mark McDougall, Engineer > Virtual Logic Pty Ltd, http: > 21-25 King St, Rockdale, 2216 > Ph: +612-9599-3255 Fax: +612-9599-3266 ></http:>
“The SZ” wrote in message news:xxxxx@ntdev… > Check this out: > > http://www.ddj.com/showArticle.jhtml;jsessionid=BX0BHRAY3GW4MQSNDLRCKHSCJUNN2JVN?articleID=184416246 > > It’s Kernel Mode Tracing. > > I did my own app based on this. I can select a kernel mode function, and > ever call to this function will be shown to me… > > Steffen > The problem here is that many of the functions the OP would be most interested in are actually macros. All the READ_REGISTER_XXX calls are for instance. Also, of course the code assumed an x86 so won’t work with x64.
As people already suggested, since the OP owns the original binary, he can create his own instrumentation. Consider the CUV approach that OSR did, where the functions are redefined as macros calling functions with a different name.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, August 27, 2007 08:29
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Detours?
“The SZ” wrote in message news:xxxxx@ntdev… > Check this out: > > http://www.ddj.com/showArticle.jhtml;jsessionid=BX0BHRAY3GW4MQSNDLRCKHSC JUNN2JVN?articleID=184416246 > > It’s Kernel Mode Tracing. > > I did my own app based on this. I can select a kernel mode function, and > ever call to this function will be shown to me… > > Steffen > The problem here is that many of the functions the OP would be most interested in are actually macros. All the READ_REGISTER_XXX calls are for instance. Also, of course the code assumed an x86 so won’t work with x64.
As people already suggested, since the OP owns the original binary, he can create his own instrumentation. Consider the CUV approach that OSR did,
where the functions are redefined as macros calling functions with a different name.
“Mark McDougall” wrote in message news:xxxxx@ntdev… > Hi, > > Can anyone tell me if there’s a way to use Detours with kernel-mode drivers? > > The thinking is to architect a framework for unit-testing driver binaries > using Detours to intercept all HAL calls. Interrupts would be injected by > calling ISRs and DPCs directly. > > I imagine such a framework would comprise user-mode executables, the DUT > driver binary and the ‘hardware emulation layer’ kernel? DLLs. There would > also have to be communications between the user-mode executable and the > kernel DLL doing the Detouring. > > Obviously the testing would be limited in nature - more data-path and > algorithmic testing than testing that it operates as a windows driver as > such - but perhaps worth considering none-the-less. > > Can it be done? Has it been done? > > Regards, > > – > Mark McDougall, Engineer > Virtual Logic Pty Ltd, http: > 21-25 King St, Rockdale, 2216 > Ph: +612-9599-3255 Fax: +612-9599-3266 ></http:>
Oh, wow, SoftICE reinvented ? We used to call it “Capt’n Hook”, the hooking
engine. BoundsChecker, TrueTime and TrueCoverage used it too. By the way, if
you want to safely intercept code, multiprocessor proof, you can use the
CMPXCHG8B instruction.
Alberto.
----- Original Message -----
From: “Mark McDougall” To: “Windows System Software Devs Interest List” Sent: Monday, August 27, 2007 8:35 PM Subject: Re: [ntdev] Detours?
> Martin O’Brien wrote: > >> I wouldn’t necessarily recommend doing this, but: >> http://www.vitoplantamura.com/index.aspx?page=kdetours >> here’s an implementation with source code. > > Very interesting indeed… thanks for the link! > > Regards, > > – > Mark McDougall, Engineer > Virtual Logic Pty Ltd, http: > 21-25 King St, Rockdale, 2216 > Ph: +612-9599-3255 Fax: +612-9599-3266 > > — > 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</http:>
On Mon, Aug 27, 2007 at 10:02:00PM -0400, Alberto Moreira wrote:
Oh, wow, SoftICE reinvented ? We used to call it “Capt’n Hook”, the hooking
engine. BoundsChecker, TrueTime and TrueCoverage used it too. By the way,
if you want to safely intercept code, multiprocessor proof, you can use the
CMPXCHG8B instruction.
As Anton pointed out, the use of cmpxchg8b will not solve the problem of
another thread executing within the sequence of instructions that are
overwritten by the jump instruction. Alternative tricks would be needed
to ensure that this does not happen. This is likely one of the reasons
why Microsoft uses a two-byte no-op (mov edi, edi) rather than two
one-byte no-op (nop / nop) instructions in their binaries that are
compiled to support hotpatching.
As an aside, about 22 yrs back I had a classmate in a graduate school who
used to sit in the front bench and one day one of the professor asked him a
question about an on-topic math course. His answer was “Sometime it is true
and sometime it is not”. The professor answered back … " It is not the
whitehouse where you would answer something like that …" From that point
on I get fairly confused when topics like this comes around …
But, I’ve seen kernel mode version of detour works fine. And I used it a
lot…
If one uses it to test drivers or other kernel module it surely is a great
tool, but I’m afraid that it could be very tempting to carry that knowledge
to binaries that would be on the field. So there is a Yes/No answer for the
OP’s query.
-pro
On 8/27/07, Alberto Moreira wrote: > > Oh, wow, SoftICE reinvented ? We used to call it “Capt’n Hook”, the > hooking > engine. BoundsChecker, TrueTime and TrueCoverage used it too. By the way, > if > you want to safely intercept code, multiprocessor proof, you can use the > CMPXCHG8B instruction. > > Alberto. > > > > ----- Original Message ----- > From: “Mark McDougall” > To: “Windows System Software Devs Interest List” > Sent: Monday, August 27, 2007 8:35 PM > Subject: Re: [ntdev] Detours? > > > > Martin O’Brien wrote: > > > >> I wouldn’t necessarily recommend doing this, but: > >> http://www.vitoplantamura.com/index.aspx?page=kdetours > >> here’s an implementation with source code. > > > > Very interesting indeed… thanks for the link! > > > > Regards, > > > > – > > Mark McDougall, Engineer > > Virtual Logic Pty Ltd, http: > > 21-25 King St, Rockdale, 2216 > > Ph: +612-9599-3255 Fax: +612-9599-3266 > > > > — > > 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 ></http:>
You can use DSF for usb devices currently, there are other bus types
that we are working on internally but I don’t know the release schedule
(if at all) for them.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Monday, August 27, 2007 5:52 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Detours?
I have heard about some Device Simulation Framework from Microsoft
to do
exactly this.
“Mark McDougall” wrote in message news:xxxxx@ntdev… > Hi, > > Can anyone tell me if there’s a way to use Detours with kernel-mode drivers? > > The thinking is to architect a framework for unit-testing driver binaries > using Detours to intercept all HAL calls. Interrupts would be injected by > calling ISRs and DPCs directly. > > I imagine such a framework would comprise user-mode executables, the DUT > driver binary and the ‘hardware emulation layer’ kernel? DLLs. There would > also have to be communications between the user-mode executable and the > kernel DLL doing the Detouring. > > Obviously the testing would be limited in nature - more data-path and > algorithmic testing than testing that it operates as a windows driver as > such - but perhaps worth considering none-the-less. > > Can it be done? Has it been done? > > Regards, > > – > Mark McDougall, Engineer > Virtual Logic Pty Ltd, http: > 21-25 King St, Rockdale, 2216 > Ph: +612-9599-3255 Fax: +612-9599-3266 >
> I’ve seen kernel mode version of detour works fine.
Sure - it is going to work fime *most of the time*, but once in a while you may BSOD for no apparent reason. As I already said, disassembly-style hooking is *potentially* unsafe in the kernel mode, although it does not mean that you will bluescreen on every other run of the program. This is why Intel instruction set defines one-byte INT3 opcode -as long as it is just one byte, everything is OK. However, if you insert INT3 instruction (which is 2 bytes long), you potentially may have exactly the same problem JMP instruction does…
For a hint, one should ask a simple question " How can I craft, let say, an
array of bits that could be the frame (prolog and epilog) of let say stdcall
signature/method" and I want to execute that array as if a function call is
made … If one can craft this (s)he will get enough honing to get this
right. So essentially for testing of drivers one can use detour without
much fear of BSOD…
-pro
On 8/27/07, xxxxx@hotmail.com wrote: > > > I’ve seen kernel mode version of detour works fine. > > Sure - it is going to work fime most of the time, but once in a while > you may BSOD for no apparent reason. As I already said, disassembly-style > hooking is potentially unsafe in the kernel mode, although it does not > mean that you will bluescreen on every other run of the program. This is why > Intel instruction set defines one-byte INT3 opcode -as long as it is just > one byte, everything is OK. However, if you insert INT3 instruction (which > is 2 bytes long), you potentially may have exactly the same problem JMP > instruction does… > > Anton Bassov > > — > 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 >
For a hint, one should ask a simple question " How can I craft, let say, an
array of bits that could be the frame (prolog and epilog) of let say stdcall
signature/method" and I want to execute that array as if a function call is
made …
There is no problem with crafting your custom prolog and epilog whatsoever. Please read my very first post on this thread, and you will see where the actual problem here lies. You just have no control over things that happened *before* you have overwritten your target function. Therefore,
if you overwrite more than one byte it may well happen that EIP of some thread that is currently inactive points right to the middle of your array, so that you will bluescreen when this thread resumes execution . As long as you are in the user mode, you can easily solve the problem by suspending all threads in the target process before overwriting the target function, and, if necessary, adjusting their EIPs with SetThreadContext() before giving them a chance to run again.
However, you cannot do it in the kernel mode. This is why Detours-style hooking is potentially unsafe in the kernel mode - in order to hook the kernel code safely, you have to hook INT3 and INT1 handlers, and insert 0xCC opcode to the beginning of the function. Please check http://www.codeproject.com/system/soviet_direct_hooking.asp, so that you will see how I did it…
Just to be clear, I’ve never used what he implements, and there are many
well known problems with this sort of patching.
Good luck,
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark McDougall
Sent: Monday, August 27, 2007 20:35
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Detours?
You have your reason, and I have mine. Before we go really off-topic, we
should probably go off-line if there is a need…
For OP’s requirement to test drivers, it perfectly suits.
I personally used it a lot to test drivers ( both 32 bit and 64 bit). The
BSOD’s were mostly our fault(s), not the kernel’s fault…
When it is used this way, one can tests the interfaces in positive and
negative ways.
But I would not recommend this to permanently change the kernel behavior,
since that is, we all know, creates problem(s) than solves any…
-pro
On 8/28/07, xxxxx@hotmail.com wrote: > > Prokash, > > > For a hint, one should ask a simple question " How can I craft, let say, > an > > array of bits that could be the frame (prolog and epilog) of let say > stdcall > > signature/method" and I want to execute that array as if a function call > is > > made … > > There is no problem with crafting your custom prolog and epilog > whatsoever. Please read my very first post on this thread, and you will see > where the actual problem here lies. You just have no control over things > that happened before you have overwritten your target function. Therefore, > if you overwrite more than one byte it may well happen that EIP of some > thread that is currently inactive points right to the middle of your array, > so that you will bluescreen when this thread resumes execution . As long as > you are in the user mode, you can easily solve the problem by suspending all > threads in the target process before overwriting the target function, and, > if necessary, adjusting their EIPs with SetThreadContext() before giving > them a chance to run again. > However, you cannot do it in the kernel mode. This is why Detours-style > hooking is potentially unsafe in the kernel mode - in order to hook the > kernel code safely, you have to hook INT3 and INT1 handlers, and insert 0xCC > opcode to the beginning of the function. Please check > http://www.codeproject.com/system/soviet_direct_hooking.asp, so that you > will see how I did it… > > Anton Bassov > > > > > — > 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 >
