PyShark – Using the packet Object

This entry is part 4 of 4 in the series Intro to PyShark

So far in this series we’ve done a lot with capturing packets and working with the capture object, but finally we’re going to get to the fun part and finally start playing with some PACKETS!!!!

When we have captured packets in a capture object, they are stored as a list of packet objects.  These packet objects will have methods and attributes that give us access to the header and payload info of each packet.  As stated in a previous post we have control for how much info about the packets we store in each packet option through the only_summaries argument in the LiveCapture and ReadCapture modules. Continue reading

PyShark – Using the capture Object

This entry is part 3 of 4 in the series Intro to PyShark

Before we get started you should read a few things in this post about the differences here between the current version of PyShark (0.3.3) and the documentation on the website. Everything I cover in this post will be things I’ve tested and confirmed work in the current version.

Now that we know how to use the FileCapture and LiveCapture modules to capture some packets, let’s see what options we have with the returned capture object (truncated list for brevity):

Continue reading

PyShark – FileCapture and LiveCapture modules

This entry is part 2 of 4 in the series Intro to PyShark

The two typical ways to start analyzing packets are via PyShark’s FileCapture and LiveCapture modules. The first will import packets from a saved capture file, and the latter will sniff from a network interface on the local machine. Running these modules will return a capture object which I will cover in depth in the next post. For now, let’s see what we can do with these two modules.

Both modules offer similar parameters that affect packets returned in the capture object. These definitions are taken directly out of the docstrings for these modules:

  • interface: [LiveCapture only] Name of the interface to sniff on. If not given, takes the first available.
  • bpf_filter: [LiveCapture only] A BPF (tcpdump) filter to apply on the cap before reading.
  • input_file: [FileCapture only] File path of the capture (PCAP, PCAPNG)
  • keep_packets: Whether to keep packets after reading them via next(). Used to conserve memory when reading large caps.
  • display_filter: A display (wireshark) filter to apply on the cap before reading it.
  • only_summaries: Only produce packet summaries, much faster but includes very little information.
  • decryption_key: Optional key used to encrypt and decrypt captured traffic.
  • encryption_type: Standard of encryption used in captured traffic (must be either ‘WEP’, ‘WPA-PWD’, or ‘WPA-PWK’. Defaults to WPA-PWK).

Continue reading

Intro to PyShark for Programmatic Packet Analysis

This entry is part 1 of 4 in the series Intro to PyShark

I can hardly believe it took me this long to find PyShark, but I am very glad I did! PyShark is a wrapper for the Wireshark CLI interface, tshark, so all of the Wireshark decoders are available to PyShark! It’s so amazing that I started a new project just so I could use this amazing new tool: Cloud-Pcap.

You can use PyShark to sniff from a interface or open a saved capture file, as the docs show on the overview page here:

Continue reading

Differences between PyShark 0.3.3 and Documentation

While working with Pyshark I’ve found that some of the documentation doesn’t quite line up so I’m writing this post to help people that might run into the same situation. The intro doc is found here and I’ll be comparing it to what actually happens when using the newest version (0.3.3) of Pyshark.

Continue reading

Scapy p.02 – Installing Python and Scapy

This entry is part 2 of 11 in the series Building Network Tools with Scapy

Installing Python

Scapy was originally written for Python 2, but since the 2.4 release (March 2018), you can now use Scapy with Python 3.4+! I will prefer Python 3 in examples but will also include notes about big differences between each python version and Scapy if they exist.

If you’re using a Mac or running some version of *nix you probably already have Python 2 (and maybe even Python 3) installed. To check, open a terminal and type python3 or python. You should see something like this:

If you are running Windows or for some other reason do not have Python installed already, go to the Python download page and grab the installer for your platform.


Installing Scapy

There are multiple ways to install Scapy depending on your platform. Check out the Scapy installation guides to find instructions and installer packages relevant to your platform. Once Scapy is installed, you should be able to run it from the terminal, just like we did with Python, and get something that looks like this:

I highly recommend install IPython in your scapy environment as it makes interactive mode much more enjoyable!

Continue reading

Scapy p.07 – Monitoring ARP

This entry is part 7 of 11 in the series Building Network Tools with Scapy

Using Scapy in a Python Script

So far we’ve been working with Scapy in interactive mode. It’s very powerful but there are times when it would be easier to work with a Python script instead. In order to use Scapy, we have to import the Scapy module like this:

This will import all Scapy functions, but if you know that you will only need a few of the functions, you can import them individually as well like this:

Continue reading

Scapy p.09 – Scapy and DNS

This entry is part 9 of 11 in the series Building Network Tools with Scapy

We’ve been able to work with Ethernet, ARP, IP, ICMP, and TCP pretty easily so far thanks to Scapy’s built in protocol support. Next on our list of protocols to work with are UDP and DNS.

DNS Request and Response

Using the sr1() function, we can craft a DNS request and capture the returned DNS response. Since DNS runs over IP and UDP, we will need to use those in our packet: Continue reading

Scapy Sniffing with Custom Actions, Part 2

In the previous article I demonstrated how to add a custom function to change the formatting of the packet output in the console or do some sort of custom action with each packet. That example passed the function (a Callable) without any additional args. When the prn passed function is called (with each packet), it receives a single argument of the packet that was just sniffed.

Using nested functions to harness the power of closure, you can bind any number of arguments to the function that is executed on each packet by Scapy. In order to bind additional arguments to the prn function, we have to use nested functions (similar to a decorator). Check out this example, created to upload the scapy packet info to an API via the Python Requests module:

This may seem a little strange, but here’s an order-of-events explanation for what’s happening:

  1. We define our url & token variables, just like in the first example.
  2. We define the custom_action function. This will be run when the scapy sniff function first runs to get the value info for the prn argument. Note the two parameters that we pass into custom_action.
  3. Inside custom_action, we create another function that takes the scapy implicitly passed packet as a parameter. This is the function that will upload the packet info to our API.
  4. The upload_packet function is nested in custom_action so it has access to the url & token variables because it is inside the parent function’s scope.
  5. The return value of custom_action is the upload_packet function, so this function will be run along with every sniffed packet based on the prn argument. Even though the custom_action function is not executed to take in the url & token parameters, they are locked into the nested upload_packet function due to Python’s capacity for ‘closure’.
  6. After we define the custom_action and nested upload_packet functions, we run the Scapy sniff function with the returned value of custom_action passed via the prn argument.

Using closures to ‘lock-in’ any number of arguments to the custom_action function gives us much more flexibility. I was able to modularize my custom_action.py file in order to clean up my Scapy sniffing script.

Here’s another example that achieves the same affect using functools.partial to close in the url & token arguments:

See how I was able to move a big chunk of verbose packet protocol checking into a separate module by looking at my two python files in this project: Scapy-to-API