1

I created an SSH agent (similar to PuTTY's pageant.exe) which has a predefined protocol: Authentication requests are sent to the agent window via WM_COPYDATA containing the name of a file mapping:

// mapname is supplied via WM_COPYDATA
HANDLE filemap = OpenFileMapping(FILE_MAP_ALL_ACCESS, FALSE, mapname);

Is it possible to find out which process (ultimatively, the process name) created a particular file mapping?

I can use GetSecurityInfo on "filemap" to get the security attributes (SID, GID, ...) but how to I get the process itself?

Important note: It is NOT possible to change the protocol (e.g. add information about the sender to WM_COPYDATA) because this is the predefined protocol used by all PuTTY-like applications!

divB
  • 896
  • 1
  • 11
  • 28
  • It is possible to enumerate all HANDLE, in user space, in a undocumented way. It is then possible to filter for "section" handle (MemoryMapping). But the trouble begins here. It may be possible to stay in user space and use "OpenProcess", "DuplicateHandle" and GetFinalPathNameByHandle (in a dedicated thread, as that cans "hang") but Memory Mappings are not files... Only way is to dynamically load a little kernel driver, but it must be signed on 64b OS. – manuell Dec 01 '13 at 17:17

1 Answers1

1

Don't try to find the process by file handle, it's complicated you need to enumerate process to find open handles for each. The WM_COPYDATA message send you the handle of the sender window, a call to GetWindowThreadProcessId should give your answer.

Keep in mind that WM_COPYDATA is a way to communicate between 32 and 64 bits process so your process maybe in different space than the caller.

Edit-->
You receive the sender HWND in the WM_COPYDATA you only have to use that HWND to get the process ID

switch (uiMsg)
{
case WM_COPYDATA:
    {
        DWORD theProcessID;
        GetWindowThreadProcessId((HWND) wParam, &theProcessID);
        COPYDATASTRUCT *pMyCDS = (PCOPYDATASTRUCT) lParam;
        /*...*/
    }
    /*...*/
}
ColdCat
  • 1,192
  • 17
  • 29
  • As mentioned above: It is NOT possible to change the protocol. I forgot to mention this. With "it is complicated" you mean it requires a kernel driver (as mentioned in the answer above)? Or is there indeed a userspace way (enum all processes, enum all handles from each, check if the handle is the one we got over WM_COPYDATA)? Regarding 32 vs 64 bit: I don't understand.The processes are always in a different address space, that's WHY WM_COPYDATA is used. – divB Nov 30 '13 at 19:34
  • edit made to show that HWND is already in WM_COPYDATA without changing anything. – ColdCat Nov 30 '13 at 23:34
  • You should note that the wParam of WM_COPYDATA may be NULL. Nothing prevents to SendMessage without an 'emitter" window – manuell Dec 02 '13 at 16:42