Sniffer for Windows That Shows Process ID?

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.

Your best bet would be something like TCPVIEW ... used to be

(now actually redirected to MS$). It will show what process (and process id) is using any particular port at any given time.

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.

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.

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

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

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). :o)

Patrick ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! ========= Patrick Klos Email: snipped-for-privacy@klos.com Klos Technologies, Inc. Web:

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

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

what's wrong with netstat ? i think netstat -a -o will show all connections and their PID (not processname) tasklist can show you PID and processname of running tasks

Try Netpeeker

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.

If you "don't know C/C++", how can you imagine that you might have any idea what is easy or hard?

That so called "reasoning" is silly nonsense based on willful ignorance.

You can write code to relate TCP or UDP connections to processes IDs by

1. look at all sockets (or equivalent) in the system and their associated TSBs or other "connection" information until you find the connection you care about based in its (addr,port,add,port) 4-tuple (or equivalent for a protocol other than TCP or UDP).

This is equivalent to `netstat -naA` on many systems.

1. look at all file descriptors (or equivalent) in the system until you find one associated with the socket from step #1. Except for wierd special cases in some systems, each file descriptor will be owned by one *or more* prcoesses, which gives you your PIDs (plural). I often use `netstat -naA` and then `fstat | grep xxhexxxxx`

That works because every connection needs to be associated with a socket (or equivalent) so that the system knows what to do with incoming packets. Every socket needs to be associated with processes so that the system knows to destroy the socket at the end the last process that cares about it. Packets (in non-trivial systems) are a whole other kettle of fish. Processes do things such as sendto() system calls that dump packets into queues to be sent and forget them. Packets need to last in the system only until they are put on the wire. In normal situations, there is no reason to spend the CPU cycles or memory that would be required to remember which process created each packet sitting in a queue to be sent.

The supposed "simple, small thing" of being able to find the process that sent a packet is either the large thing of changing the operating syustem to maintain PIDs or pointers in mbufs (or equivalents) or the not so small thing of inserting a shim between all applications on the system and all system calls that can send packets, and having the shim maintain enough state (or logs) so that it can guess and pick a process that probably sent a given packet. Other people have mentioned packages that sound to me as if they do the latter.

Vernon Schryver snipped-for-privacy@rhyolite.com

So the quick summary would be: tracking the process ID in a sniffer would be relatively easy for connection oriented protocols like TCP since the Windows OS has data structures that give strong clues about the sender and receiver that could be parsed to match on address/port of sender and receiver. Of course this approach would miss the rogue application that fakes packets and tries to make them appear to come from a different process. But it is a lot more than what we have today and would be very useful.

The tracking of process ID in a sniffer would be extremely difficult for datagrams since it would require either enhancements to the OS or the installation of traps or filters for all of the various OS calls that allow a datagram to be sent. Such filtering to track process IDs has overhead associated with it, so it might be something that you would only want to make active during a sniffer session.

Did you look at the MicroOlap Sniffer SDK another poster had mentioned at

Did you have any opinion on it?

It is very useful, but it is not a lot more than we what we have in UNIX-like operating systems. As I tried to say, I often find processes with `netstat -A`, grep, and fuser, fstat, or one of the other active file listers whose names I can never remember. (ldstat? liostat?)

I'm not a Windows expert, although I do ship code that uses TCP and UDP on Windows 95 through XP.

Using grep and so forth is clumsy in UNIX, but some versions of fuser eliminate that clumsiness. See

?q=pid+process+TCP

That is a slight overstatement. If the application uses connected UDP sockets, then there are almost the same clues to sender and receiver as with TCP. Lately I've been using `netstat -A` etc. on UDP more than TCP.

Note that talking about "tracking of process ID in a sniffer" gives me pause. When I last looked, "Sniffer" was a registered trademark for a family of boxes that plug into networks to snoop on passing packets. Such boxes can have no notion even of whether the source and destination of packets have a notion of process ID. That's why I always write "packet snooping" or similar instead of "sniffing."

Vernon Schryver snipped-for-privacy@rhyolite.com

I guess netstat -o does neither of those. It's a small program that with that switch, associates process id with a connection.

No doubt the code to do it can be put into a function and accessed via the function's interface. A simple thing.

Worst case, a program like ethereal could run netstat -o and find the process id. And assume it applies to all packets within that connection.

Better case, it uses the function that netstat uses. This was what I referred to as a simple thing for a programmer. Simple conceptually.

Will - CommView from Tamos Neil Pike Protech Computing Ltd

In WindowsXP you can use "netstat -ao" to see connections and the associated process ID (which you can then patch to process IDs/ processes in task manager).

"netstat -p TCP -ao" if you only wanna see TCP and not UDP.

Pipe it to find if you want something specific, ie: C:\\>netstat -p TCP -ao|find "slashdot" TCP machinename:2939 slashdot.org:http ESTABLISHED

3444 TCP machinename:2940 images.slashdot.org:http ESTABLISHED 3444 TCP machinename:2942 images.slashdot.org:http ESTABLISHED 3444

Though tdimon is not actually a packet sniffer it may help in conjunction with running a packet sniffer. It will show name but not process ID and show time. Port reporter may be something else that can be used along with a packet sniffer.

Steve

DOH that shoulda said "match" not "patch"..."(which you can then match to process IDs) processes in task manager)"