In the kernel I want to inject a thread into a user space application.
In this case, a WOW64 application.
To get a 32 bit thread processed properly by wow64, it is my understanding I need to call PsWrapApcWow64Thread(&ApcContext, &pInjectionStub);
to ensure the thread is called in 32 bit mode.
Using the exact same driver binary, and exact same user space application I get different behavior between vista 64 sp2 and win7 - 64. Win7-64 works properly.
Here is the important parts of the code. Checking etc. cut out for brevity.
PVOID pInjectionStub ;
PVOID ApcContext = NULL;
ZwAllocateVirtualMemory(ZwCurrentProcess(), &pInjectionStub , NULL, &RegionSize, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
On win7 64:
Before Wrap call
ApcContext = 0x0000000000000000 pInjectionStub = 0x00000000001d0000
After wrap call
ApcContext = 0x0000000000000000 pInjectionStub = 0xffffffffff8c0000
On vista 64:
Before wrap call
ApcContext = 0x0000000000000000 pInjectionStub = 0x00000000001c0000
After wrap call
ApcContext = 0x001c000000000000 pInjectionStub = 0x0000000000000000
With the injectionStub address changing to null, the kapc I use to schedule it runs as a kernel apc, and thus does not achieve the desired result on vista 64.
I remember reading something about application contexts and WOW64, but not the details. Is it possible my ApcContext should not be initialized to NULL ?
What’s the point of this exercise? What you’re trying to achieve by injecting a thread?
You are asking about a totally undocumented API, whose usage is
questionable. Why do you think you need to do this from the kernel.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:
> In the kernel I want to inject a thread into a user space application.
> In this case, a WOW64 application.
> To get a 32 bit thread processed properly by wow64, it is my understanding I need to call PsWrapApcWow64Thread(&ApcContext, &pInjectionStub);
> to ensure the thread is called in 32 bit mode.
>
> Using the exact same driver binary, and exact same user space application I get different behavior between vista 64 sp2 and win7 - 64. Win7-64 works properly.
> Here is the important parts of the code. Checking etc. cut out for brevity.
>
> PVOID pInjectionStub ;
> PVOID ApcContext = NULL;
>
> ZwAllocateVirtualMemory(ZwCurrentProcess(), &pInjectionStub , NULL, &RegionSize, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
>
> On win7 64:
> Before Wrap call
> ApcContext = 0x0000000000000000<br>> pInjectionStub = 0x00000000001d0000
>
> After wrap call
> ApcContext = 0x0000000000000000<br>> pInjectionStub = 0xffffffffff8c0000
>
> On vista 64:
> Before wrap call
> ApcContext = 0x0000000000000000<br>> pInjectionStub = 0x00000000001c0000
>
> After wrap call
> ApcContext = 0x001c000000000000<br>> pInjectionStub = 0x0000000000000000
>
>
> With the injectionStub address changing to null, the kapc I use to schedule it runs as a kernel apc, and thus does not achieve the desired result on vista 64.
>
> I remember reading something about application contexts and WOW64, but not the details. Is it possible my ApcContext should not be initialized to NULL ?
I thought guys here knew everything, even undocumented api’s.
The usage is to hook processes so that I can monitor calls to specific dlls.
It is for a security product though, so if I tell you more I’d have to suicide.
I am not a hakzor or attempting criminal behavior if that is the question.
Undocumented APIs canNOT be used in a product. Period.
And there is no point of monitoring user mode behavior from within user mode. By definition, usermode is untrusted. If you inject code in a compromised process, and run your thread, it can get compromised, as well.
A trusted monitor can only run in trusted environment (kernel mode).