Ability to read PCAP files

[lkowolowski]

Describe the solution you'd like
it would be very nice to be able to read pcap files. This would allow troubleshooting of packers captured on other devices where this application doesn’t run.
Writing is also nice, but less important than reading.

[GyulyVGC]

Thanks for the feedback.
What would you expect after reading a pcap file?
I think that something should be changed with respect to the current views.
For example, the chart would be meaningless since data are not flowing in real-time.
Would it be suitable in your opinion the same current representation with charts and notifications removed?

[lkowolowski]

This is all based on spending about 15min looking at things. Feel free to tell me if I've missed something, or don't understand how things already work. Also, none of this is criticism. This is a slick tool.

I think the charts and inspection would be useful. Things like traffic rate, network host, application protocol. These would be based on the sample that is read from the pcap file. It wouldn't have any realtime aspects associated (changing graphs, lists, etc), but would show the information in a time slice that equals the beginning-to-end of the capture.
Examples:

• load a pcap and see how many bits/bytes were transmitted in the time slice captured
• load a pcap and see which countries the associated IPs in the time slice belong to
• load a pcap and see which protocols used how much of the bits/bytes from the first example

The inspection window giving an overview of the list of packets is nice. Being able to drill into more details of a packet would be awesome, but that may be different (related) feature.

[GyulyVGC]

Yeah, it's pretty much what I was thinking about, with the only difference that I had in mind to exclude charts.
Actually it would be nice to have them though.
Instead of reporting the number of seconds (on the x axis) I could report the corresponding timestamp and aggregate the data to display them in the same space of the current charts.
Aggregating data and not displaying them second by second, would make meaningless the data on the y axis though... but that's something I'll better think about.

Being able to drill into more details of a packet would be awesome, but that may be different (related) feature.

This request has already been raised, but I prefer to keep it separate for the moment.
Support for PCAP files will come earlier than support for packets payload in GUI (which possibly may never land if we'll provide the ability to also write PCAP).

[GyulyVGC]

Write of PCAP files has been implemented in #473.

I was starting to work also on PCAP files read, but I've realised that there are some aspects I was neglecting that will require me more time, and that's the reason why I'm postponing the introduction of this feature to version 1.4.

One of the aspects to keep in mind is that while reading PCAPs we don't have the knowledge about local IP addresses, so there is the need to completely change the approach used to identify traffic directionality.
A possible workaround is instantiate two different captures as suggested in rust-pcap/pcap#299 (one dedicated to incoming traffic and the other dedicated to outgoing traffic), and this implies important architectural changes to the app backend.

[GyulyVGC]

Quick update: I've tested setting direction to the capture as suggested in rust-pcap/pcap#299 but it's not supported on all platforms and it only works with live captures, not PCAP files (this is also documented here).

[CodeCommandoPants]

If you were to use this tool on a campus network using a span/mirrored port, for example, it wouldn’t be hard for the network operator to map internal IPs that are NAT'ed to a virtual private IP address.

For instance, consider a network with three users accessing YouTube:

YouTube server: 100.100.100.100
User1: 10.0.0.1
User2: 10.0.0.2
User3: 10.0.0.3

A PCAP file capturing a connection to YouTube from User1 would contain packets like:
TCP Example (YouTube Connection)

Initial SYN packet (client to server):
    IP_SRC = 10.0.0.1
    IP_DEST = 100.100.100.100
    PAYLOAD = SYN

Server response (SYN-ACK):
    IP_SRC = 100.100.100.100
    IP_DEST = 10.0.0.1
    PAYLOAD = SYN-ACK

Data transmission (YouTube video stream, TCP segments):
    IP_SRC = 100.100.100.100
    IP_DEST = 10.0.0.1
    PAYLOAD = Video data

All subsequent packets in this TCP session would follow this source-destination structure.
UDP Example (Bi-Directional Traffic)

Now, consider a case where User1 is communicating with a game server over UDP:

Client sends a UDP request to the game server:
    IP_SRC = 10.0.0.1
    IP_DEST = 200.200.200.200 (Game server)
    PROTO = UDP
    PORT_SRC = 54321
    PORT_DEST = 12345
    PAYLOAD = Game state update request

Server responds with game state updates:
    IP_SRC = 200.200.200.200
    IP_DEST = 10.0.0.1
    PROTO = UDP
    PORT_SRC = 12345
    PORT_DEST = 54321
    PAYLOAD = Updated game world state

Since UDP is connectionless, these packets exist independently and don’t rely on a handshake like TCP does.

[ZeroDot1]

I recommend adding a function to extract all domains and IP v4 and V6 addresses to this function to make the work of security researchers more convenient.