I’m a PhD student in computer science and I’m working on named pipes for academic reasons. I’m trying to find a way to identify the server communication endpoint when a client opens a connection or exchanges some data (getting for example the PID of the process that created the named pipe). By now, I’m working on Windows XP, so I’m using SSDT patching to intercept system call (NtCreateFile for instance) and I’m detecting a connection to a named pipe by matching the file path against the string "??\pipe". At this point, my issue is to find a way to get the PID of the server that created this named pipe.
It seems that three objects are created in the Object Manager: one created when the server creates the listenning pipe and two when the client opens the connection. I was wondering if the kernel was using these objects to do the mapping between the client and server thread.
By tracing into the kernel, I saw that the pipe creation in the server part generates an IRP_MJ_CREATE_NAMED_PIPE request sent to npfs.sys and that the connection on the client side generates an IRP_MJ_CREATE.
I expected read / write operation to generate IRP_MJ_READ / IRP_MJ_WRITE, but I put some breakpoints on the handlers and it doesn’t seems to be the case, which let me think that this mapping is not done in the npfs.sys driver but in the kernel itself.
If you need any more information please let me know, thanks a lot,
Cheers,
J.
On 4/21/2011 11:18 AM, xxxxx@yahoo.com wrote:
I’m a PhD student in computer science and I’m working on named pipes for academic reasons. I’m trying to find a way to identify the server communication endpoint when a client opens a connection or exchanges some data (getting for example the PID of the process that created the named pipe). By now, I’m working on Windows XP, so I’m using SSDT patching to intercept system call (NtCreateFile for instance) and I’m detecting a connection to a named pipe by matching the file path against the string "??\pipe". At this point, my issue is to find a way to get the PID of the server that created this named pipe.
It seems that three objects are created in the Object Manager: one created when the server creates the listenning pipe and two when the client opens the connection. I was wondering if the kernel was using these objects to do the mapping between the client and server thread.
By tracing into the kernel, I saw that the pipe creation in the server part generates an IRP_MJ_CREATE_NAMED_PIPE request sent to npfs.sys and that the connection on the client side generates an IRP_MJ_CREATE.
I expected read / write operation to generate IRP_MJ_READ / IRP_MJ_WRITE, but I put some breakpoints on the handlers and it doesn’t seems to be the case, which let me think that this mapping is not done in the npfs.sys driver but in the kernel itself.
To gain anything useful you’ll need to implement a legacy filter driver
which attaches to NPFS. There are IOCtls handled by NPFS which implement
the impersonation in some cases, of course most of these are completely
undocumented. But I would start with a filter on NPFS and go from there,
you won’t really glean much from patching.
Pete
If you need any more information please let me know, thanks a lot,
Cheers,
J.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295