Remote operations -- need for advice

Alexander Yaworsky yaworsky at migusoft.ru
Mon Jun 21 06:00:22 CDT 2004


I'm thinking how to implement CreateRemoteThread and besides fix memory management functions.
The complete (afaik) list includes:
RtlCreateUserThread
NtAllocateVirtualMemory
NtFreeVirtualMemory
NtProtectVirtualMemory
NtQueryVirtualMemory
NtLockVirtualMemory (do nothing?)
NtUnlockVirtualMemory (do nothing?)
NtFlushVirtualMemory
NtMapViewOfSection
NtUnmapViewOfSection

Suggested implementation.
Let's add two groups of handlers to the wineserver, something like remote_operation_xxxx
and remote_operation_xxxx_complete.
remote_operation should do the following:
1) suspend_for_ptrace();
2) inject a piece of code into required process and start its execution;
3) resume_after_ptrace();
4) place calling thread into suspended state (or into some wait state?)

remote_operation_complete should prepare reply and resume thread suspended by remote_operation.
Injected code should call required function and then remote_operation_complete
in context of required process.
The question is: how to correctly get address of function?
imho possible solutions are:
1) assume ntdll loaded at the same address for all processes -- unreliable;
2) get dll base address from per-process dll list and parse ELF by hand -- too complicated (?);
3) pass relative offsets and add them later to the ntdll's base address -- unreliable
    a bit: ntdll may be replaced, although, it is unlikely;
4) extend the struct process (server/process.h) and the request init_process with
    pointers to required functions -- most reliable and simple but looks ugly.
What do you think?




More information about the wine-devel mailing list