PHWinfo - Afficher un message - Sniffer for Windows That Shows Process ID?

11/10/2007, 02h38

"User" <user@invalid.domain.com> wrote in message
news:kqqqg3lbgrj5a127invubeq1udn5e8iodd@4ax.com...
> On Wed, 10 Oct 2007 00:26:21 -0700, "Will" <westes-usc@noemail.nospam>
> wrote:
>
>>Can someone recommend a sniffer for Windows that will show the process ID
>>and name of the process sending or receiving each packet shown in the
>>sniffer?
>>
>>I normally use ethereal or wireshark and didn't see a straightforward way
>>to
>>include this information.
>
> A 'true' sniffer is runs at the kernel level, hooking into the network
> stack. Therefore, it has no concept of which process is involved with
> the actual network traffic.

I understand this, and that's why it's a tougher problem to solve and why I
am willing to pay some money for it. I guess that a sniffer running as
SYSTEM could be simultaneously parsing OS data structures related to
applications and network use, and simultaneously looking at raw packet data,
and then cross referencing them when that is possible. In some cases that
might give an ambiguous result, and in other cases it would surely be
possible to uniquely associate a pattern of network traffic with a process.
It's surely not perfect, but particularly for getting a historical record of
outgoing UDP traffic, I will take what I can get.

> Your best bet would be something like TCPVIEW ... used to be
> www.sysinternals.com (now actually redirected to MS$). It will show
> what process (and process id) is using any particular port at any
> given time.

That's a great tool for seeing listeners associated with processes. But
that's the low hanging fruit that even simple command line tools like
netstat give you. Unless you have the patience of a saint and don't mind
staring intently at the TCPView's windows for hours at a time, you probably
aren't going to see the process that sends UDP packets for 20 seconds once
every six hours. Those are exactly the forensics situations where I want
the capability I am asking for.

If you know of a way to set a "trap" in TCPView or a similar application
that can be conditional like "any application sending traffic to target IP X
on UDP port Y, that would also be a great tool to find.

--
Will

11/10/2007, 02h38	#2
Will Messages: n/a Hébergeur:	Re: Sniffer for Windows That Shows Process ID? "User" <user@invalid.domain.com> wrote in message news:kqqqg3lbgrj5a127invubeq1udn5e8iodd@4ax.com... > On Wed, 10 Oct 2007 00:26:21 -0700, "Will" <westes-usc@noemail.nospam> > wrote: > >>Can someone recommend a sniffer for Windows that will show the process ID >>and name of the process sending or receiving each packet shown in the >>sniffer? >> >>I normally use ethereal or wireshark and didn't see a straightforward way >>to >>include this information. > > A 'true' sniffer is runs at the kernel level, hooking into the network > stack. Therefore, it has no concept of which process is involved with > the actual network traffic. I understand this, and that's why it's a tougher problem to solve and why I am willing to pay some money for it. I guess that a sniffer running as SYSTEM could be simultaneously parsing OS data structures related to applications and network use, and simultaneously looking at raw packet data, and then cross referencing them when that is possible. In some cases that might give an ambiguous result, and in other cases it would surely be possible to uniquely associate a pattern of network traffic with a process. It's surely not perfect, but particularly for getting a historical record of outgoing UDP traffic, I will take what I can get. > Your best bet would be something like TCPVIEW ... used to be > www.sysinternals.com (now actually redirected to MS$). It will show > what process (and process id) is using any particular port at any > given time. That's a great tool for seeing listeners associated with processes. But that's the low hanging fruit that even simple command line tools like netstat give you. Unless you have the patience of a saint and don't mind staring intently at the TCPView's windows for hours at a time, you probably aren't going to see the process that sends UDP packets for 20 seconds once every six hours. Those are exactly the forensics situations where I want the capability I am asking for. If you know of a way to set a "trap" in TCPView or a similar application that can be conditional like "any application sending traffic to target IP X on UDP port Y, that would also be a great tool to find. -- Will