Lion Cipher Lab
Reassemble a TCP stream from a PCAP, from scratch
- Foundations
- Advanced
- ~75 min
- Free · no account required
Why it matters
Every time you click Wireshark's "Follow TCP Stream" or run tcpflow, a pile of reassembly logic runs that you never see: TCP data does not arrive in order, segments get retransmitted, packets show up early and wait for a gap to fill, and the tool silently sorts all of it by sequence number to hand you clean bytes. If you only ever consume that output, you cannot answer the question that matters in an investigation -- can I trust this stream? -- because you do not know what the tool did to produce it. That gap is not academic: TCP reassembly ambiguity is a real evasion class. When two segments…
What you'll learn
- reading the libpcap file format by hand (magic 0xa1b2c3d4, version, snaplen, linktype)
- parsing per-packet record headers (ts_sec, ts_usec, incl_len, orig_len)
- decoding an Ethernet II frame, an IPv4 header (IHL, total length, protocol), and a TCP header (ports, seq, ack, data offset, flags) byte by byte
- reassembling a TCP conversation by SEQUENCE number instead of arrival order
- de-duplicating a retransmitted segment and buffering an out-of-order segment until the gap fills
- computing the initial-sequence-number offset so byte one is stream-relative
- carving application-layer content (an HTTP request) out of a reassembled stream
- proving that naive arrival-order reassembly produces garbage
- reasoning about reassembly-ambiguity evasion: overlapping segments, a missing SYN, and 2^32 sequence wrap-around
- knowing when to trust Wireshark / tcpflow and when to distrust the tool's stream
Steps in this lab
- What you are about to build, and how to open a terminal
- The libpcap file format: a header, then records
- The three headers inside each frame: Ethernet, IPv4, TCP
- Write the script: build a scrambled capture, then parse it back
- Run it and read the measured payoff
- How the reassembly actually decided the order
- Named failure modes: overlap, missing SYN, and 2^32 wrap-around
- Why this, not Wireshark, tcpflow, or scapy -- and when NOT to do it by hand