A pcap is a transcript. Every packet that crossed the interface during the capture window, in order, with timestamps, with headers intact. Reading one without context is like reading a technical conversation in a language you partially understand: you can follow the broad shape, but the meaning is in the details, and the details require both the specification and the patience to compare what you are reading against what was supposed to happen.

Wireshark is the standard tool because it does the comparison for you: it parses each packet against the relevant protocol specification and shows you the fields, their values, and whether they are valid. For most purposes this is sufficient. For security research it is the starting point. Wireshark tells you what is there. The question is what is not there, what is there that should not be, and what the timing between packets reveals that the content does not.

What to look for first

Start with the conversation graph rather than the individual packets. Most captures contain multiple TCP streams, multiple DNS queries, possibly multiple protocols. Understanding the overall shape — how many distinct conversations are present, between which endpoints, initiated by whom — before you dive into a single packet saves the time you would otherwise spend reading packets out of context.

Retransmissions are worth noting. A TCP segment retransmitted once might be packet loss. Retransmitted several times, in a pattern, suggests something more deliberate — a sender that is not waiting for acknowledgement, or a receiver that is deliberately not acknowledging. The protocol machine on both sides is visible in the capture if you know what normal behaviour looks like and are prepared to read for deviations.

Unexpected fields: protocol header fields set to non-default values. IP options present when they should not be. TCP flags in combinations that are syntactically valid but semantically unusual — the SYN/FIN combination, the Christmas tree packet familiar from early IDS research. These are not always malicious, but they are always worth understanding. The question is whether they are there for a reason, and whether that reason is the one you would expect.

The dog that did not bark

The most instructive analysis of any packet capture I have done has been of what was absent rather than what was present. A TLS handshake that does not include the expected cipher suites. A DNS query that is never answered. An authentication exchange that completes without the challenge step that the protocol requires. The absence of an expected packet is not visible in the capture unless you know, from the specification, that it should be there.

This is why reading specifications is not optional for this kind of work. The pcap tells you what happened. The specification tells you what was supposed to happen. The gap between the two is the finding, or the lead to the finding, or occasionally the explanation for behaviour that looked suspicious but was actually correct. You need both documents open at once.

Timing as signal

The timestamps in a packet capture are often more informative than the content. A request and response with a 300-millisecond round-trip time tells you something about where the server is. A sequence of requests with suspiciously regular 50-millisecond spacing tells you something about whether they were issued by a human. A protocol exchange that proceeds without the expected pauses for processing tells you something about whether it was replayed from a recording rather than generated fresh.

TfL contactless payment transactions complete in under 300 milliseconds — that constraint is architectural, not incidental, because a gate that holds you for longer than that creates a queue. Reading the pcap for an EMV transaction requires understanding that timing constraint and reading each packet against it. The specification tells you what each message is. The timing tells you whether the implementation respects the design.

A packet capture is a record of a conversation — its content, its timing, and its silences. The interesting conversations are rarely the ones that follow the protocol correctly. The PING that reveals something is usually the one that arrives fractionally late, or not at all.