I am using GetThreadContext() and SetThreadContext() on a thread of another process and I have a few problems. First of all, I inject some code to the memory of that other process and then use the two API functions to change the execution. Everything works out okay when I just change CONTEXT.regEip, but when I try to set my own stack (the memory for stack is allocated in the other process as well), there seems to be a problem. SetThreadContext() works out okay and returns TRUE, but the target application just quits when you switch to it. Any ideas?
Posted on 2001-11-01 20:34:53 by comrade
Why do you need to change the value of the stack pointer? It might be ok when your code is executing but when your code is done and the execution resumed where it was redirected to your code, the app will find that the stack is not what it expects. When it pops something from the stack, that value might be anything.
Posted on 2001-11-02 10:32:55 by Iczelion
I do restore the old stack pointer and all the other registers I modify.
Posted on 2001-11-02 13:24:32 by comrade
Are you sure your new stack is dword-aligned? Without that, the app may terminate.

Posted on 2001-11-03 12:03:18 by japheth
If he uses VirtualAllocEx (which is the only method I know of that
can alloc memory in another process), it will be page-aligned, which
should definitely be enough for a stack :P.
Posted on 2001-11-07 04:51:47 by f0dder

i meant ESP should be dword "aligned", not the stack of course :)
Posted on 2001-11-07 05:11:37 by japheth
Speaking of VirtualAllocEx(), is there an alternative to it on Windows 9x/ME as it is not available there?
Posted on 2001-11-08 18:03:57 by comrade
Yes, there is. With Elicz's PrcHelp: http://www.anticracking.sk/EliCZ/export.htm
Posted on 2006-04-19 23:38:34 by comrade
Forgive me for jumping in late..

If the target process is not being Debugged, then you should make sure that the target thread is paused before you get or set the thread context.
If the target process is multithreaded, I highly recommend pausing ALL its threads, even if you only manipulate ONE of them.. this prevents some issues relating to interdependant threads (for example, applications with a 'guardian thread' that monitors/manipulates the execution of other threads).

Are you aware of the contents of the stack when you switch it?
You are throwing away a bunch of stuff that's in there, like return addresses, procedural stackframes, and the default Exception Handler info.

If you have a JIT debugger, try to determine the absolute Top of the target stack address space and duplicate the content of the target's stack in your new one, then set the cpu TRAP flag (OR the Context.regFlags value with 0100h), then switch the target's stack register(s), then continue execution.
The TRAP flag will cause a STEP exception to be generated, which will trigger your debugger to open at the first instruction in the target thread.
Now you can continue Stepping through the target thread in your debugger, and figure out why it's exploding :)

Posted on 2006-04-20 01:02:15 by Homer