Creating an effective packet sniffer in .NET

Question

I'm looking to create what I call a proxy, although that definition is probably somewhat inaccurate.

Typically, you have something like this:

Client --------- Server

What I want to do is introduce a proxy, without a new layer, like this:

Client ----+---- Server
           |
         Proxy

I do not want this:

Client---Proxy---Server

I understand that WinPCap does something similar to this, but it's an under documented subject as far as I can see.

So far I've tried a few things, most notably listening on the same port as the client for messages. This resulted in little more than receiving a load of crap packets from random applications (in spite of listening on a specific port). I couldn't find a lot to suggest I was reading the correct data, although I believe I have found that now, after making some minor modifications.

Does anyone know of any reason against using this method? Or is there some more sustainable way of doing it?

Answer 1

If you look for packet sniffer instead of proxy it'll give you more relevant links:

• http://www.codeproject.com/Articles/17031/A-Network-Sniffer-in-C
• Any good .net packet sniffers around?
• http://www.c-sharpcorner.com/UploadFile/fyratkocak/PacketSniffer12032005034955AM/PacketSniffer.aspx

[EDIT - something else to check is whether promiscuous mode is enabled on the network card. This tells the network card to pass all the packets up the stack, regardless of content. Without this, you might not get all the packets that you'd expect. More about this on Wikipedia and how to enable promiscuous mode on Windows 7+]

Answer 2

You want what is called Raw Socket access (and use a hub or a switch that can send all the packets to your network adapter). You also want your network card in what is called "promiscuous mode", where it takes in all packets without filtering on MAC-address.

When you both get the traffic on the wire and your network adapter takes them in unfiltered, your program will get all the packets exactly as they are sent on the network (although you have to make sure you OS's TCP-UDP/IP stack doesn't sneak in an pick up TCP packets you would want to listen to, but if you target two other computers configuration that would not be a problem.

I'm not sure how well windows does this, but anyway.

When you get the packets, you have to read the ethernet headers (and you can filter based on the targets mac addresses), and then you have to pick out the IP-packets, as well as the TCP/UDP-packets and put them in order to get something reasonable out of the traffic. Not super-easy, but far from impossible either.