OpenRCE Blog Entry

Radim Picha (EliCZ) <apihooks

com

seznam

cz>

Thursday, February 15 2007 02:08.06 CST

This Rtl function was in NT since its very begin, it was used by winsrv for remote break-in and by posix subsystem to perform signal handling. I think the main reason for this function was non-existence of user APC support prior NT 4.0. In NT 4.0 and 2000 it still persisted but I think it could be re-implemeted via apc. Since XP this function became rudimetary. I think using RtlRemoteCall for arbitrary thread is not good because it works with CONTEXT_FULL. Imagine thread that waits (in kernel mode), you get/set its context, you must wait (how long?) for the thread to return from the wait with a wait return value. The the thread goes to your target function and then you're about to return the thread's context, you will return it, but you will return bad wait return value (value as it was before the wait was satisfied)! For known-thread scenario one could use APC - server: QueueUserAPC, client: alertable wait. Compared to CreateRemoteThread, RtlRemoteCall requires a handle to the target thread in addition but well, it doesn't send dll notifications.

AlexIonescu

Posted: Thursday, February 15 2007 09:59.50 CST

Your APC example doesn't make a lot of sense to me. You want to queue the APC in the server, not in the client, which implies thata the server needs to do the alertable wait. It works well for a known thread scenario, but APCs aren't always the best thing to do, and RtlRemoteCall avoids having to deal with them, and also allows arbitrary execution.

If you do a GetSetContext on a thread that's in a kernel-mode wait, the wait will be interrupted, this is actually one of the problems of doing this.

The best solution for IPC remains LPC, but RtlRemoteCall is just another method of doing it within the framework that I specified. Also, using your APC method, how would you reply back to the client? That would mean that the client also needs to be in an alertable wait... sounds kind of messy/complicated to me.

EliCZ

Posted: Sunday, February 18 2007 06:49.29 CST

First example:
http://apihooks.com/EliCZ/bugs/rc-nono.c
------

Now polemics:

------
Alex: If you do a GetSetContext on a thread that's in a kernel-mode wait, the wait will be interrupted, this is actually one of the problems of doing this.

EliCZ: The example shows the wait is not interrupted by GetSetContext. Maybe I missed something.

------
EliCZ_Re: The wait return value is lost.

EliCZ: Yes. The example shows the wait return value is lost.
Maybe I'm doing something bad.

------
Alex: RtlRemoteCall for hijacking arbitrary thread.

EliCZ: The target code will be executed when? After this happens, the thread's behaviour is undefined.

------
Alex: RtlRemoteCall for server-client.

EliCZ: Well, once the server exposes its threads (for set_context) then
the clients (not only) may do everything with the server (so there's no security).

------
EliCZ_Re: ... APC.

EliCZ: I mentioned it just as similar but thread-safe alternative to RtlRemoteCall,
I would never use it for server-client. I think, except the hProcess and hThread is
RtlRemoteCall something like a fiber switch.

------
Alex: RtlRemoteCall as IPC.

EliCZ: Subjectively, never.

------
Off topic:

Alex: RtlRemoteCall is worth mentioning.

EliCZ: RtlGetCurrentProcessorNumber on x64 is worth mentioning.

------
Plus:
http://disc.server.com/discussion.cgi?disc=148775;article=969;title=Coding%2FASM%2FSystem;pagemark=20

Daniel

Posted: Friday, February 23 2007 22:56.01 CST

I think following is the one reason that target won't be interrupted.

It is require to queue a special APC to suspend a thread and APCs queued will not be trigged when running in some "critical sections" in which case the APCs was disabled. Because of that, it seem that target will not interrupted!

However EliCZ's example2 look like a deadlock ... ;p

However, I have no ideas about who uses RtlRemoteCall() although Alex tell us that it was used by winsrv (seem only used hen debugging) and posix subsystem.

Because of lacking "engineering resouces" of Windows, I can'
figure why exporting RtlRemoteCall? The Big problem for me.

any suggestions? TIA