Hi again, would anyone be kind enough to point out how to extract information on named pipes and pipestreams (owner/object/IO details) from kernel dumps in Win7 x64. I can see them on my system using Pipelist (sysint) but having trouble finding debugging references.
My understanding is they are implemented as $msft .NET constructs moreso now, but they have been used by Unix and C for a bit longer and would/should predate .NET.
Would like to extract the details of all (named) pipe objects.
Any help/pointers would be appreciated. Thx.
xxxxx@exemail.com.au wrote:
Hi again, would anyone be kind enough to point out how to extract information on named pipes and pipestreams (owner/object/IO details) from kernel dumps in Win7 x64. I can see them on my system using Pipelist (sysint) but having trouble finding debugging references.
This is not going to be easy. You’re talking about spelunking into
undocumented and underdocumented structures here. Names pipes are part
of the kernel namespace (in \.\Pipe). Assuming you can find the root
of the kernel object tree, you can probably find the list of names, and
from that get a set of file handles. But then what? The implementation
of named pipes is done by a kernel file system driver (npfs.sys), the
implementation of which is not provided. There’s no good way for you to
start from a file handle and proceed to a stream buffer, for example.
My understanding is they are implemented as $msft .NET constructs moreso now, but they have been used by Unix and C for a bit longer and would/should predate .NET.
They have nothing to do with .NET, nor do they have anything to do with
C. .NET is just an application run-time library (how’s that for
reducing hundreds of man-years of work into one flippant sentence?).
All .NET APIs eventually call into Win32 APIs.
Would like to extract the details of all (named) pipe objects.
What kind of details are you hoping to get?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim, thanks for the reply. If you don’t mind can you wrap that up in 2-3 lines of script and I’ll get cracking on it! (;o)
I reference .net since the first 10 pages of interweb search returns links on the System.IO namespace or C# code. Powershell has a nice one liner to retrieve a list of names
[System.IO.Directory]::GetFiles(“\.\pipe\”) <- is there a debugging equivalent?
I see that windows has a \NamedPipe\ device, which links to the \FileSystem\Npfs driver
!devstack \Device\NamedPipe
!DevObj !DrvObj !DevExt ObjectName
fffffa800d964060 \FileSystem\Npfs fffffa800d9641b0 NamedPipe
Then -
!object \filesystem\npfs
Object: fffffa800cd174d0 Type: (fffffa800cdd94b0) Driver
ObjectHeader: fffffa800cd174a0 (new version)
HandleCount: 0 PointerCount: 3
Directory Object: fffff8a00008bd00 Name: Npfs
!drvobj fffffa800cd174d0 7
Driver object (fffffa800cd174d0) is for:
\FileSystem\Npfs
Driver Extension List: (id , addr)
Device Object list:
fffffa800d964060
[… list cont’d …]
From here would like to list all pipes, pipe end points (if local or remote), local process ID’s, SID token, device handles, I/O, protocol etc to know who or what is using pipes and why.
It is part of a system auditing process. Thanks.
xxxxx@exemail.com.au wrote:
I reference .net since the first 10 pages of interweb search returns links on the System.IO namespace or C# code. Powershell has a nice one liner to retrieve a list of names
[System.IO.Directory]::GetFiles(“\.\pipe\”) <- is there a debugging equivalent?
I see that windows has a \NamedPipe\ device, which links to the \FileSystem\Npfs driver
Sure. There are a number of user-mode APIs for trolling the namespace.
But you wanted to do this from a dump file, right? Just because there
is a user-mode API does not mean it’s possible to extract it from a dump.
From here would like to list all pipes, pipe end points (if local or remote), local process ID’s, SID token, device handles, I/O, protocol etc to know who or what is using pipes and why.
It is part of a system auditing process.
You don’t do system auditing from a post-mortem dump. If you want to
extract this information from a running system, you could accomplish
much of what you want. But from a dump? No way. Almost all of that
requires data structures that belong to the internal operation of the
npfs.sys driver. Assuming you could find them, the content of those
structures is not documented.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
not sure what you mean by I/O, protocol etc, but this will give you list of
pipes
0: kd> !object \device\namedpipe
Object: 866c1200 Type: (867e7e70) Device
ObjectHeader: 866c11e8 (old version)
HandleCount: 0 PointerCount: 2
Directory Object: e10116f0 Name: NamedPipe
0: kd> !devhandles 866c1200
On Fri, Jun 26, 2015 at 2:29 AM, wrote:
> Hi Tim, thanks for the reply. If you don’t mind can you wrap that up in
> 2-3 lines of script and I’ll get cracking on it! (;o)
>
> I reference .net since the first 10 pages of interweb search returns links
> on the System.IO namespace or C# code. Powershell has a nice one liner to
> retrieve a list of names
>
> [System.IO.Directory]::GetFiles(“\.\pipe\”) <- is there a debugging
> equivalent?
>
> I see that windows has a \NamedPipe\ device, which links to the
> \FileSystem\Npfs driver
>
> > !devstack \Device\NamedPipe
> !DevObj !DrvObj !DevExt ObjectName
> > fffffa800d964060 \FileSystem\Npfs fffffa800d9641b0 NamedPipe
>
> Then -
> > !object \filesystem\npfs
> Object: fffffa800cd174d0 Type: (fffffa800cdd94b0) Driver
> ObjectHeader: fffffa800cd174a0 (new version)
> HandleCount: 0 PointerCount: 3
> Directory Object: fffff8a00008bd00 Name: Npfs
>
> >!drvobj fffffa800cd174d0 7
> Driver object (fffffa800cd174d0) is for:
> \FileSystem\Npfs
> Driver Extension List: (id , addr)
>
> Device Object list:
> fffffa800d964060
>
> [… list cont’d …]
>
> From here would like to list all pipes, pipe end points (if local or
> remote), local process ID’s, SID token, device handles, I/O, protocol etc
> to know who or what is using pipes and why.
>
> It is part of a system auditing process. Thanks.
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other 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
>
Maybe I should start by asking - is livekd (sysint) a valid proxy for live system auditing? (Tim?)
Sergey - thank you!! Legend. That looks embarrassingly simple and seems to output everything. Now to look into the returned results. A question if I am allowed -
Q. the !devhandles appears to rely on the integrity of the process linked list? i.e thinking of a malicious process dissociated from l/links
I appreciate the replies above Tim and Sergey - thank you.
windbg relies on kernel structures
so if kernel is compromised then windbg can be wrong
On Fri, Jun 26, 2015 at 5:48 AM, wrote:
> Maybe I should start by asking - is livekd (sysint) a valid proxy for live
> system auditing? (Tim?)
>
> Sergey - thank you!! Legend. That looks embarrassingly simple and seems to
> output everything. Now to look into the returned results. A question if I
> am allowed -
>
> Q. the !devhandles appears to rely on the integrity of the process linked
> list? i.e thinking of a malicious process dissociated from l/links
>
> I appreciate the replies above Tim and Sergey - thank you.
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other 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
>
xxxxx@exemail.com.au wrote:
Maybe I should start by asking - is livekd (sysint) a valid proxy for live system auditing? (Tim?)
No way. That would be silly. If you have a live system, then you
should just run an auditing application, so you can use the system
resources that are available to you. By attempting to do the same thing
using livekd, you are essentially taking on the task of reverse
engineering the entire Windows kernel. That’s nonsense.
I would also point out that livekd does not freeze the system
(obviously), so things are changing underneath your feet without any
interlocks. When you use the APIs, that’s all handled for you.
Q. the !devhandles appears to rely on the integrity of the process linked list? i.e thinking of a malicious process dissociated from l/links
Yes, but that’s hopeless anyway. How would YOU plan to find a rogue
process that disassociated itself from the linked lists? Once you have
an intruder in kernel mode, the game is over. There is nothing you can
do. Whatever you do can be bypassed or rerouted.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks Tim, certainly a lot to think about and I am not discounting anything you have said. The reality is bad actors don’t play inside sandboxes nor do they obey the untold rules of interfacing. At some point relying on 3rd party software loses it’s efficacy and you need to be able to audit what is not being monitored. I get the impression that relying on API’s is not going to cut it security wise.