Delphi - Inter Process communication between lower level and higher level processes

Question

I have a Small vcl application in delphi that run with admin privileges, this app only receive messages and poke mouse events. The second application run with normal user priveleges(lower than first), this app cannot send messages to first app. Im sure that the cause is the level of privileges, higher and low, because if I run both with lower or higher, they communicate with success. How I can do IPC where I can send message to higher level application from the lowest level application ? Or it is not possible ?

This is the way that I use to send messages:

The higher app uses this code to handle winapi.messages:

procedure TfrMouseDriver.WMCopyData(var Message: TWMCopyData);
var
  S: WideString;
  cmd, sX, sY: String;
  s2,F: String;
  WParam: WideString;
  i, z, X, Y: integer;
begin
  X := 1;
  Y := 1;
  if true then
  begin
    s:=  PWideChar(Message.CopyDataStruct.lpData);
    s2:=  PChar(Message.CopyDataStruct.lpData);
    ...

And the lowest level application send messages with this way:

procedure TfrPenDriver.btnIPCClick(Sender: TObject);
var
  CopyData: CopyDataStruct;
  hMouse : HWND;
  Msg : WideString;
begin

  Msg := 'CM_MOVE:000500:000230';

  hMouse := FindWindow(PCHAR('TfrMouseDriver'),nil);

  if hMouse > 0 then
  begin
    CopyData.dwData := 0;
    CopyData.lpData := PWideChar(Msg);
    CopyData.cbData := (1 + Length(Msg))*SizeOf(WideChar);
    Winapi.Windows.SendMessage(hMouse, WM_COPYDATA, 0, LPARAM(@CopyData));
  end;
end;

Im looking I way to do IPC between this apps with diferent user levels, where the lowest level need to send to higher level app.

Answer 1

Mailslots for local machine inter-process communication is your best bet due to their simplicity and they are implemented via a driver in Windows, like pipes. This driver is msfs.sys on NT-based systems. You don't need any special privileges enabled either in order to create mailslots, read/write to them etc. and they work with any process type, application level and in any foreign session.

Window handles (HWND) are session-specific and will not work across other user sessions so in this case you run into problems using WM_COPYDATA since it relies on a window handle and as already mentioned, UIPI restrictions on more modern Windows operating systems can be a problem.

Another reason why WM_COPYDATA isn't great is this... Suppose that you're running executable code inside the context of another process (say a system process such as csrss) that isn't an "interactive" process. Maybe you've injected a DLL and want to send an IPC message with WM_COPYDATA... You can expect the process to crash or depending on the criticality of the process, expect a BSOD. This happens because these processes don't appreciate user32.dll API calls such as SendMessage, which WM_COPYDATA as an IPC system, relies on.

Stick to mailslots.