Read a pcap without Wireshark: headers, flows and TLS

What a capture file actually contains

A pcap is a sequential log of frames that crossed an interface. There is no index, no protocol tree and no analysis stored in it: a single global header at the front, then, for each packet, a small record header followed by the raw bytes. The colourful dissection you get in a GUI is recomputed from those bytes every time the file is opened, which is why reading the same capture with a different tool loses nothing.

The global header

A classic libpcap file opens with 24 bytes. The first four are the magic number: 0xa1b2c3d4 for microsecond timestamps and 0xa1b2cd34 for nanosecond ones. Seeing either value byte-swapped tells you the file was written on a machine with the opposite endianness, and every numeric field in it needs converting as you read. Next come the version numbers, in practice always 2.4, a timezone field and a significant-figures field that nobody uses, and then the two that matter: snaplen and network. Snaplen is the maximum number of bytes stored per packet. Network is the link-layer type, and in a classic pcap it applies to the whole file.

Per-packet headers and the snaplen trap

Each packet is preceded by 16 bytes: seconds, sub-second fraction, caplen and len. Those last two are different numbers and confusing them quietly ruins analysis. len is how many bytes the packet had on the wire. caplen is how many were written to the file. When caplen is smaller, the packet is truncated.

Truncation usually comes from a small snaplen passed to tcpdump -s at capture time. A snaplen of 96 leaves almost nothing after the Ethernet, IP and TCP headers. In that file your byte and flow statistics are still correct, because len carries the real size, but HTTP headers, DNS answers and the TLS server name are simply not there. The first thing to check in an unfamiliar capture is the share of packets where caplen < len. If it is high, stop hunting for content; you have metadata.

Link-layer types

The link type decides how the packet bytes are interpreted. LINKTYPE_ETHERNET (value 1) is the common case and means each packet starts with a 14-byte Ethernet header. Capture on a VPN or tunnel interface and you get LINKTYPE_RAW (101), where packets begin directly with an IP header; a reader that assumes Ethernet will produce confident nonsense. Listening on Linux's any pseudo-interface yields LINKTYPE_LINUX_SLL (113) with a synthetic 16-byte header. Wireless monitor mode gives 802.11 frames, usually behind a radiotap header. Most files that look "corrupt" are not corrupt; they just have a link type the reader did not expect.

pcap versus pcapng

Modern Wireshark writes pcapng by default and the filename usually still ends in .pcap, which is where the confusion starts. Instead of one global header, pcapng is a stream of blocks: a Section Header Block, an Interface Description Block per capture interface, and packets as Enhanced Packet Blocks. The practical gains are real. One file can hold several interfaces, each with its own link type and snaplen; timestamp resolution is declared per interface; packets and sections can carry comments; name resolution records can be embedded. The magic number differs too, 0x0a0d0d0a, so if a parser rejects your file that is the first thing to check.

From packets to flows and endpoints

Scrolling a packet list is rarely the right first move. Before you look at individual frames, aggregate. Two summaries answer most questions, and both are simple groupings.

• Flows: group by the five-tuple of source IP, source port, destination IP, destination port and protocol. For each flow you get packet count, byte count, first-seen and last-seen timestamps.
• Endpoints: group by address alone. Who talked a lot, who only listened, which host sent a single packet and went quiet.

Those two tables answer questions fast. Looking for a long-lived connection, sort flows by duration. Looking for an exfiltration, sort by bytes sent outbound. Looking for a scan, look for one host reaching many destinations with a packet or two each. The pcap to flows tool and the endpoint summary produce exactly these tables. When you do need per-field detail, pcap to JSON gives you dissected packets you can open in the JSON viewer and filter with a data structure you already know instead of a display-filter language you half remember.

These three tools upload the capture to the server for dissection; they do not run in your browser. If the file came from a sensitive network, make that decision deliberately.

What you can see when traffic is encrypted

Most of a modern capture is TLS, and "encrypted so there is nothing to see" is wrong. Part of the handshake is in the clear, and the envelope always is.

• Addresses and ports: always visible. Routing requires it.
• SNI: the server name the client puts in its ClientHello extension travels in plaintext. On shared hosting it is the only thing that tells you which of hundreds of sites was requested. It disappears only when Encrypted Client Hello is in use.
• The server certificate: in TLS 1.2 and earlier the server sends its certificate unencrypted, so you can read the subject, the issuer and the validity dates. In TLS 1.3 the certificate moved into the encrypted part of the handshake and is not visible.
• Sizes and timing: packet lengths, direction and inter-arrival gaps are all in the clear. That is not content, but it is behaviour: evenly spaced small packets look like a polling loop, a long one-directional burst looks like a download.

What you cannot see is equally definite: bodies, request headers, cookies, credentials, query strings. Without a TLS key log you will not decrypt them, and you only have a key log if you controlled the client. If the question is what a server offers rather than what one client did, checking it directly with the TLS checker is faster than reading a handshake. To make sense of the addresses on the other end, IP geolocation and whois fill in the ownership.

DNS is still the most informative cleartext you have

Unencrypted DNS remains common on internal networks and it is the richest context in a capture. Query names map addresses to meaning, and a flow table full of anonymous IPs becomes readable. On networks using DNS over HTTPS that context vanishes and you fall back to SNI and reverse lookups, which is worth knowing before you promise anyone a hostname-level report.

Capture files are heavy documents

A pcap carries far more than a log line. On any unencrypted protocol, session cookies, API keys, mail bodies and form fields are sitting in the file in plaintext. Even where traffic is encrypted, the file still exposes internal topology, hostnames, user agent strings and the domains people visited. A debugging capture taken for one bug can be a personal data collection you did not intend to make.

• Capture narrowly. A filter for the host and port you care about produces a smaller and cleaner file than recording an entire interface.
• Before sharing, drop unrelated flows and trim the file to the time window in question.
• Delete the file when the work is done and keep track of where copies ended up.
• Before uploading to any third-party service, ask whose data is in the file.

For client strings you pull out of a capture, the user agent parser saves guesswork. If you recover an Authorization header, read the rules in JWT debugging safely before you paste it anywhere. And when the investigation turns up a downloaded binary, reading its PE headers is the same triage discipline applied to a file instead of a wire.