hi,

maybe you can help me out, due my lack of driver programming experience...
My test OS is a xp sp2.

I hooked KiFastCallEntry, and i like to suspend the calling process in the case that it calls a specific service index.
After that that i like to inform another process about this call, and then continue with the execution of the first application.

But as the sysenter instruction disables the interrupts, the whole system would freeze whenever i would switch the execution at this point.

So my questions are:

is it possible to suspend or better to switch the execution in KiFastCallEntry?
if yes how can i switch the execution to the next process in the schduler queque?
is there any better method to accomplish this task?

Hi

What is it you're trying to do in this "other" process (your own presumably) that you couldn't do in the KiFastCallEntry hook itself on the target? I mean, if you only wanted to modify the target process address space you could probably do that within the hook is what I'm thinking.

I'll presume for the moment yours is a ring3 logging app or something, which you should be able to inform through an Event that "something" has happened in your hook. The problem would be, like you say, to be able to inform your app, and to let it do something, before resuming execution of the original thread.

I have no idea if this would work without trying it, but I might look at something like running KiSuspendThread, or otherwise modifying the ETHREAD flags to put the thread in a suspended state. Presumably KiFastCallEntry would return cleanly and the thread would remain suspended until you resume it later, which you could probably do from ring3.

Have a look at the SuspendApc stuff here to see where I'm going with this..

http://uninformed.org/index.cgi?v=8&a=2&p=17



Another option, and I'm just batting ideas around here, though a bit more involved might be to let the target thread suspend itself. Something I've done several times, you can queue an APC from a kernel mode hook which is mapped via an MDL into a targets address space and will in theory run immediately upon return to usermode.

In other words, the APC should run before the continuation of the code which called the particular KiFastCallEntry service. If the APC you've injected calls SuspendThread on itself it will do just that. This should give your notification Event to your own process plenty of time to kick in. The important part will be to make sure the thread returns (from the APC) to the proper original point of execution when you resume it. You should be able to embed the proper return address (and return value) when you're creating the APC.

For an example of MDL mapping an APC into a target to run covert code you can look at the code I posted recently here:

https://www.rootkit.com/board.php?thread=11733&did=edge0&disp=11733&closed=1

Cheers,
Kayaker

If you're hooking the MSR/call, any code you'll run will destroy the context of the caller... that's why SYSENTER does a cli, so you can save that context. So you can just repeat what Windows does, and then issue a STI. But that's extremly messy..if all you're doing is hook a function, just hook that function alone?

More importantly, this won't work on 64-bit, so you should probably revisit your design.