I would investigate whether it is supposed to be in the middle of a blocking call and under what conditions it should return from it.
I got a look at it.
Basically, what happens is: - the entry point code just loops onto itself EntryPoint: jmp EntryPoint
- so, the creator of this program is likely to wait for the child to be looping on EntryPoint before going any further (wait until init is done, and entry point is called)
- however, when one thread calls SuspendThread on another thread (which is in running state), the later thread gets a USR1 signal. The signal handler for USR1 will wait on the server until the thread is resumed.
But, the address we get in GetThreadContext is the one from where the thread waits on the server (hence the 0xffffe410 address), not the address it was suspended from (as it's supposed to be) (the entry point address).
I don't think it will be easy to fix.
Possible ideas:
- implement suspend/resume in processes without any specific code. We dropped that long ago for stability issues (and race condition removal as well)
- cheat for context reading in server while suspended. it will require some surgery (getting whether we are in the condition of this program, getting back to the signal handler, getting the signal context from the stack, grab the real EIP from it). Doable, but very hard to maintain (code in server, will depend on how signal handlers are written in ntdll, code will be CPU specific...)
- storing context in server while entering USR1 signal handler (to be done without races, which will require some more work, as the server doesn't synchronize with the USR1 handler)
Nice can of worms :-/
A+
