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.

--
Will

"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

In article <ruudnahccPsa7ZDanZ2dnUVZ_s2tnZ2d@giganews.com>,
Will <westes-usc@noemail.nospam> wrote:
>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.

Why don't you provide a real email address so we could take this offline?

>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.

What exactly are in these UDP packets? Maybe that info would give a huge
clue as to which service or application is sending them?

>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.

If the app in question sends packets repeatedly for 20 seconds, then a filter
in Wireshark (or your favorite sniffer) that shows the packet will give you
the time to run netstat as soon as the packet shows up. Patience is part of
the game in network forensics (as in most detective work). )

Patrick
========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
Patrick Klos Email: patrick@klos.com
Klos Technologies, Inc. Web: http://www.klos.com/
================================================== ==========================

Will 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.


this is indeed a noble search ! I have looked for the same thing
myself.

netstat can see process id, but only offers a snapshot, it's
stateless, and as a result of it only doing a snapshot, it doesn't
record whether the packet is incoming or outgoing. And of course it's
only a snapshot style port status thing.

You said something like TCPView do what you want ""if you had the
patience of a saint?" But from what I remember, TCPView is not a packet
sniffer. You never see inside the packet.

I did find a port logger (software running on the machine of course,
it's necessary for this) that records process id , and whether the
packet is incoming or outgoing. But it's not a packet sniffer.
Sygate personal firewall, probably the last free version. Maybe
available from oldversion.com or elsewhere. You can turn off the
firewall feature leaving just the port logger. Though the last time i
installed it it crashed, maybe blocking outgoing , and so I removed it
and haven't tried it since.

Somebody should really write what you suggest. It'd be only a small
addition to Ethereal. Indeed, it's not purely a 'packet' thing, but in
a strict definition of packet, neither is TCP. TIME isn't a purely
packet thing either, by any definition, though ethereal displays it
alongside the packet. MS Word is popular because it draws pictures,
doesn't just allow the writing of words. I have to get into this silly
philosophical thing, since a post implied ethereal or a packet sniffer
*shouldn't* do it, so I think some people don't get it.

Somebody posted writing as if this was some personal problem Will has,
requesting they email in private (perhaps since he writes software and
sells it). OK. But It is not just his thing. It's as he described it.
A general thing.

I notice also xananews tried to set follow-up to
comp.dcom.net-management , so if anybody uses that, then be careful!

Didn't check further if there is a product using this library:
"
When I capture a packet from a local machine, does the Packet Sniffer SDK
provide a process information (e.g. process id) related with the packet?
Yes, please use HNLBAdapter component.
"
(http://www.microolap.com/products/network/pssdk/faq/)

So, at worse you could create it yourself or have it created... :-)

Or do more searches on the field of honeypots:
"
Sebek version 3 extends this functionality by intercepting a new set of
system calls. Additionally, it retrieves the parent process id (PPID) and
the inode associated with any file-related event.
"
(http://www.securityfocus.com/infocus/1855)

On Oct 10, 3:26 pm, "Will" <westes-...@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.
>
> --
> Will

Try Netpeeker

<jameshanley39@yahoo.co.uk> wrote in message
news:470e2247$0$13931$fa0fcedb@news.zen.co.uk...
> Will 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.
>
> this is indeed a noble search ! I have looked for the same thing
> myself.
>
> netstat can see process id, but only offers a snapshot, it's
> stateless, and as a result of it only doing a snapshot, it doesn't
> record whether the packet is incoming or outgoing. And of course it's
> only a snapshot style port status thing.
>
> You said something like TCPView do what you want ""if you had the
> patience of a saint?" But from what I remember, TCPView is not a packet
> sniffer. You never see inside the packet.
>
> I did find a port logger (software running on the machine of course,
> it's necessary for this) that records process id , and whether the
> packet is incoming or outgoing. But it's not a packet sniffer.
> Sygate personal firewall, probably the last free version. Maybe
> available from oldversion.com or elsewhere. You can turn off the
> firewall feature leaving just the port logger. Though the last time i
> installed it it crashed, maybe blocking outgoing , and so I removed it
> and haven't tried it since.
>
> Somebody should really write what you suggest. It'd be only a small
> addition to Ethereal.

Can you expand on that last thought? Are you saying the developers of
Ethereal could do this easily, or did you mean that there is some add-on API
for Wireshark that would let us add this in?

--
Will

On Oct 14, 10:00 am, "Will" <westes-...@noemail.nospam> wrote:
> <jameshanle...@yahoo.co.uk> wrote in message
>
> news:470e2247$0$13931$fa0fcedb@news.zen.co.uk...
>
>
>
>
>
> > Will 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.
>
> > this is indeed a noble search ! I have looked for the same thing
> > myself.
>
> > netstat can see process id, but only offers a snapshot, it's
> > stateless, and as a result of it only doing a snapshot, it doesn't
> > record whether the packet is incoming or outgoing. And of course it's
> > only a snapshot style port status thing.
>
> > You said something like TCPView do what you want ""if you had the
> > patience of a saint?" But from what I remember, TCPView is not a packet
> > sniffer. You never see inside the packet.
>
> > I did find a port logger (software running on the machine of course,
> > it's necessary for this) that records process id , and whether the
> > packet is incoming or outgoing. But it's not a packet sniffer.
> > Sygate personal firewall, probably the last free version. Maybe
> > available from oldversion.com or elsewhere. You can turn off the
> > firewall feature leaving just the port logger. Though the last time i
> > installed it it crashed, maybe blocking outgoing , and so I removed it
> > and haven't tried it since.
>
> > Somebody should really write what you suggest. It'd be only a small
> > addition to Ethereal.
>
> Can you expand on that last thought? Are you saying the developers of
> Ethereal could do this easily, or did you mean that there is some add-on API
> for Wireshark that would let us add this in?
>

I don't know C/C++ , but I'm saying that for developers it'd be easy.

netstat is a tiny program and does it.
sygate firewall had a very simple port logger program that did it.

So there would be an API. Not for Wireshark. But an API - presumably a
windows or linux one - that can be accessed by the language that
wireshark is written in. Wireshark or any program could access it.


when I say "did it", netstat or sygate firewall did it, i'm referring
to knowing it for 'connections'. Essentially that means it knows it
for packets. Worst case scenario, this shows that if sitting on a
client or server, the software can only know the process id when one
process is used for the entire connection(i've never even see more
than one used anyway. So even for a worst case scenario, 1 process is
a fair assumption to make). One doesn't know if one doesn't try it.
But either way, reasoning shows it's a simple , small thing.