packet basics

Overview

Underneath every port scan, DNS lookup, and HTTP request are packets — the discrete units of data that networks actually move. When you capture and inspect packets, you see the raw truth of what crossed the wire, byte for byte. In CTFs, the Forensics category regularly hands you a packet capture file and asks you to find a flag hidden inside the traffic. To do that, you need a working mental model of what a packet is and how protocols are layered inside it.

This lesson builds that model and shows how packet analysis fits into safe, authorized challenges.

Learning objectives

• Define a packet and explain encapsulation across network layers.
• Identify the layered structure of a typical packet (frame, IP, transport, application).
• Explain what a packet capture (PCAP) is and how it is produced.
• Describe how to follow a stream and extract data from captured traffic.
• Relate packet analysis to the Forensics CTF category and to defense.

Core concept

A packet is a formatted unit of data carried across a network. Data does not travel as one big blob; it is broken into packets, each carrying a piece of the payload plus headers that tell the network how to deliver it and how to reassemble the whole.

Packets are built through encapsulation: each network layer wraps the data from the layer above it with its own header, like nested envelopes. A simplified view of a packet carrying web traffic:

• Link layer (frame) — e.g. Ethernet header with source/destination MAC addresses.
• Network layer — the IP header with source/destination IP addresses.
• Transport layer — the TCP or UDP header with source/destination ports and (for TCP) sequence/acknowledgment numbers and flags.
• Application layer — the actual payload, e.g. the HTTP request or response, DNS message, or other protocol data.

When you read a captured packet, you peel these layers from outside in: which machines (MACs), which hosts (IPs), which service (ports/protocol), and finally the content.

How it works

A packet capture records the packets seen on a network interface and saves them, commonly as a PCAP file. Analysts open captures in a traffic-analysis tool to inspect each packet's layers and to reconstruct conversations.

Two ideas make captures useful in CTFs:

• Filtering — a capture can hold thousands of packets. Display filters narrow the view to what matters, e.g. only HTTP traffic, only packets to a certain IP, or only DNS queries. Filtering is how you find the needle.
• Following a stream — because TCP breaks data across many packets, tools can reassemble a full conversation (all the bytes of one TCP connection) so you can read an entire HTTP exchange or file transfer as continuous text rather than packet by packet.

Since much classic protocol traffic is unencrypted, a capture of HTTP, FTP, or DNS can plainly reveal requested URLs, submitted credentials, transferred files, or text — which is exactly where forensics flags hide. Encrypted traffic (HTTPS) shows metadata (who talked to whom, when, how much) but not the plaintext content without keys.

Practical example

A Forensics challenge provides capture.pcap from an authorized lab scenario and hints that "someone logged into the web app." You open it and filter to HTTP:

# Illustrative: filter to HTTP, then follow one TCP stream
# (display filter)
http

# After selecting the login POST and "Follow TCP Stream":
POST /login HTTP/1.1
Host: ctf.local
Content-Type: application/x-www-form-urlencoded
Content-Length: 39

username=admin&password=flag{p4ck3ts_t3ll_all}

Reading this capture:

• Filtering to http cut thousands of packets down to the web conversations.
• Following the TCP stream reassembled the fragments of one connection into a readable request.
• The unencrypted POST /login body reveals the submitted form fields — and the "password" here is the challenge flag, planted in cleartext because the traffic was HTTP, not HTTPS.

The whole exercise happens on a capture file provided by the challenge; you are analyzing recorded lab traffic, not intercepting anyone's live communications.

Cybersecurity relevance

• Forensics challenges: reading PCAPs to extract flags, files, or evidence is a staple CTF skill and mirrors real incident-response work.
• Understanding protocols concretely: seeing IP/TCP/HTTP layered in a real packet cements everything from the earlier lessons — addresses, ports, transport, and application data all in one view.
• Why encryption matters: a capture of plaintext HTTP or FTP exposes credentials and content, which is the practical argument for HTTPS/TLS. Recognizing this drives good defensive design.
• Detection and monitoring: defenders analyze captures and flow data to spot intrusions, exfiltration, and scans. The same reading skills serve blue-team work.
• Ethics and scope: capturing live traffic on networks you do not own or lack permission to monitor is a serious violation. In CTFs you work with provided capture files or your own isolated lab traffic only.

Common mistakes

• Trying to read a huge capture packet by packet instead of filtering and following streams.
• Forgetting encapsulation and getting lost about which header is which layer.
• Assuming everything is encrypted (or assuming nothing is) — check the protocol; plaintext protocols leak content, HTTPS does not.
• Overlooking non-HTTP protocols in a capture (DNS, FTP, SMB) where the flag might actually be.
• Capturing real, non-lab traffic without authorization, which is unethical and often illegal.

Key takeaways

• A packet is a unit of network data built by encapsulation: link/frame, IP, transport (TCP/UDP), and application layers nested together.
• A packet capture (PCAP) records traffic; analysts filter it and follow streams to reconstruct conversations.
• Unencrypted protocols reveal their content in captures, which is why forensics flags often hide in HTTP, FTP, or DNS traffic.
• Packet analysis ties together IPs, ports, transport, and application data — and only ever on provided or self-owned, authorized captures.

Check your understanding

• Name the layers you would peel back in a packet carrying an HTTP request, from the outermost header inward.
• Why does "following a TCP stream" make a captured HTTP conversation easier to read than viewing individual packets?
• Why can a capture of HTTP traffic reveal a submitted password while a capture of HTTPS traffic generally cannot?