I'd like to be able to intercept/ modify data in tcp flow, on the side of tcp client. Examples for pcap show how to parse tcp packet header/ payload.
But suppose, i want to modify packet payload before tcp client reads it, or drop the packet entirely. How can i do that with pcap capure?
As above, you can't do interception/modification with pcap. For this you need one of the following OS-dependent techniques:
Linux: libnetfilter_queue + iptables
MacOS, FreeBSD: divert sockets + ipfw
Windows: WinPkFilter (commercial), WinDivert (LGPL), or write your own NDIS IM or WFP call-out driver.
(usual disclosure: WinDivert is my project).
Scapy used in conjunction with python is a very good tool cum library.
You can do all sorts of packet monitoring and editing via command line
Also you can build applications on top of scapy to do a specific task.
Scapy
You can't do that with libpcap or WinPcap; libpcap is built atop OS mechanisms that do not support that (those mechanisms exist to support passive packet capture and low-level packet capture and injection, not to support packet modification in the packet input and output path), and WinPcap's driver is built atop an OS mechanism of that sort.
You would have to find some mechanism, in whatever OS you're using, that supports tapping into the networking stack in a way that allows the tapping program to modify packets as they pass through the networking stack. Such a mechanism might not exist on some OSes; on OSes where it does exist, if there are any, it's probably very OS-dependent. (The mechanisms libpcap uses are also OS-dependent; libpcap exists, in part, to hide those differences from applications, to the maximum extend possible.)
Related
Is it possible to dump contents of tcp recv/send to a pcap file and then have wireshark analyse this. I want to do this because I want to log an applications conversations in order to debug issues but I don't want to have to write my own parsers (wireshark already supports it) and don't necessarily trust the application to parse frames correctly.
What follows is based on work that I've done exclusively on Windows.
I can't speak to how well any of this might apply to other systems.
FWIW, I would suggest editing your question (or at least tagging it)
to be more clear about what OS you're targeting.
If you are talking about writing what's received directly from a TCP client to a pcap file, the answer is no. The pcap file format requires at least some networking headers, e.g., the IP and TCP headers, in order for the file to be valid.
There are four approaches I see.
You could fake these headers for each read from the socket. This wouldn't necessarily require a lot of work, but it would require some knowledge of the relationships between the network header, the transport header, and the payload (i.e., your data) in order for everything to work right. If you're only interested in analysis of the payload in Wireshark, this might be a valid approach. However, if the analysis you're wanting to do in Wireshark is network analysis (i.e., analysis that includes the network headers), then you'll want to avoid this option and figure out how to capture the network headers directly.
You could use a raw socket to capture network traffic at the network layer. This will give you the IP packet - IP header, TCP header, and payload. You could dump this to a pcap file using LINKTYPE_RAW as the link-layer header type, and Wireshark will read the file fine. I've used this approach before.
The third approach would be to use WinPcap to collect your data. This is the same software that Wireshark uses behind the scenes to collect the data, and it's the approach I'm using now. If you have Wireshark installed, the WinPcap is already installed, too. WinPcap has a simple API with numerous examples for opening an interface, collecting the data, and dumping it to a pcap or pcap-ng file.
The fourth option is the simplest...just use Wireshark to collect the data simultaneously with your application.
HTH.
I am implemneting a code based on Raw sockets. In order to receive coming Ethernet frames I have to bind the socket I created to an Ethernet interface. The only way to do that, as far as I am concerned, is via setsockopt() function with the option SO_BINDTODEVICE.
The problem is that I am using FreeBSD which does not support such option. Is there any patch to use in order to enable this feature or any other trusted alternative?
You can use sendto if you are working with IPv6, see this example.
Unfortunately this doesn't work with IPv4.
As antiduh said, you can use libpcap to capture packets, provided you have access to /dev/bpf (which is usually restricted to root).
(Apologies: I uninstalled and reinstalled WinPcap and now I can see the extra interface! Suggestion found in Wireshark FAQ. I leave the original question below.)
I use WireShark to examine ethernet packet contents at the byte level (in/out of custom FPGA-based hardware). I have a USB-Ethernet adapter to add a second Ethernet port to my laptop. It was a cheap Chinese device bought on Ebay but now that I've found an appropriate driver, it works OK. However, I see that, on Windows, WinPcap/WireShark doesn't support Ethernet capture over USB.
While it would be nice if WireShark could be made to work on USB capture, I'm really looking for an alternative way to grab the raw ethernet bytes. I have some perl scripts set up that operate on the raw frames output from tshark, (Wireshark command line) and I could easily feed it from any stream of frames/bytes.
Is anyone doing something similar or is there a tidy way to output the raw bytes?
Sniffed raw USB bytes would be OK, but it would be nicer if someone has already programmed/scripted extracting the Ethernet frames. I'm using perl but any compiled app or python or C# or C++ or .. would be fine.
You mentioned python, scapy can do a LOT of raw packet things, might want to look at that. From their git:
Scapy is a powerful Python-based interactive packet manipulation
program and library.
It is able to forge or decode packets of a wide number of protocols,
send them on the wire, capture them, store or read them using pcap
files, match requests and replies, and much more. It is designed to
allow fast packet prototyping by using default values that work.
It can easily handle most classical tasks like scanning, tracerouting,
probing, unit tests, attacks or network discovery (it can replace
hping, 85% of nmap, arpspoof, arp-sk, arping, tcpdump, wireshark, p0f,
etc.). It also performs very well at a lot of other specific tasks
that most other tools can't handle, like sending invalid frames,
injecting your own 802.11 frames, combining techniques (VLAN
hopping+ARP cache poisoning, VoIP decoding on WEP protected channel,
...), etc.
Scapy supports Python 2.7 and Python 3 (3.3 to 3.6). It's intended to
be cross platform, and runs on many different platforms (Linux, OSX,
*BSD, and Windows).
Check them out at https://github.com/secdev/scapy
I don't have a Windows PC readily at hand to test, but as far as I can tell, there is no problem capturing Ethernet frames in Wireshark on Windows, from a USB-Ethernet adapter.
What you can't do, is capturing USB bus traffic, but that is not what you wanted, right?
To clarify, just select the USB-Ethernet device as you would any other, and you are set.
Does anyone know why should I use Winpcap and not just .Net sockets to sniff packets on my local pc?
TY
Sockets (.NET, Winsock, etc.) normally collect at layer 7, the Application layer. That is, whatever is sent by the sender is what is received by the receiver. All of the various headers that are added automatically on the sending side are stripped off by the time the receiver reads the data from the socket.
It is possible to configure a socket to be a raw socket, in which case, you can see all of the headers down to layer 3, the Network layer. Further still, you can put the raw socket in promiscuous mode, which allows you to see all of the traffic on the network, not just the packets destined for your machine. But even this is limited. For example, when you configure the raw socket, you specify the protocol type to use, e.g., IP, ICMP, etc. This limits the socket to "seeing" packets that adhere to that protocol. I have been unable to figure out how to make the socket see all packets at layer 3 regardless of protocol.
Winpcap operates as a device driver at layer 2, the Data Link layer. In this case, you see literally all of the packets on the network with full headers down to layer 2. Winpcap also offers filtering capability so you can narrow down the packets that are reported to you based on whatever criteria you provide.
As far as choosing between them, it really boils down to the requirements of your specific task. If you are trying to implement any kind of realistic network analysis capability, you'll be hardpressed to do that with just sockets. Winpcap makes more sense in that case. However, if you are only interested in IP packets, for example, then sockets will work fine for that.
As far as I understanf .Net sockets are an IPC to communicate between 2 processes. While winpcap is a library that help you to access the data link layer an sniff pacquets going through your network hardware (or virtual) devices on your machine. Data link layer allow to get the data on any socket (.Net or not) created on your system.
Is it possible to have libpcap remove a packet instead of just sniff it as it passes through? I'm wanting to intercept each packet and encapsulate it into a new packet along with measurement data, but both packets (mine and the original) both reach the destination.
It's not possible. You need to write a driver (for your operating system) to make the networking stack filter out packets.
The only way you could do this is by being the only physical path between the sender and receiver and turning off packet forwarding on the interceptor.
If you're capturing wireless traffic, there's nothing you can do. No software library can remove radio waves from the ambient air.
No, libpcap cannot "remove a packet".
It's not quite clear what you want to achieve, but it looks like you want to receive data, add some additional information to it, and republish it. If you are working with a datagram protocol such as UDP, then you might be able to simply resend your augmented data to a different UDP port.
In response to Ben S, you can't remove packets off the air, but you can stop them reaching their destination - using ARP cache poisoning etc.
As others mentioned, you can not use libpcap. libpcap is a passive listener. If you are on Linux, you can use a netfilter, which hooks into iptables. Here is an example of how to do that.
http://www.linuxjournal.com/article/7184