Opening the provided “hello.pcap” file with Wireshark and examining the protocol hierarchy within the pcap shows only UDP traffic. Wireshark believes a few of the packets are malformed real-time transport control packets while the majority of the packets are data.

Observing the UDP conversations within Wireshark, only a single “connection” occurred within the pcap. The connection is between port 9090 and 53321 on 127.0.0.1. The inconsistency of protocols above combined with a single connection within the trace file leads to the conclusion the protocol being used is non-standard.

The first packet in the trace contains the data “hello :)” followed by an 0x0a. This is the only packet with a length that’s not 8234 and sent from port 53321 to port 9090. The second packet contains data which starts with “BZh” which is the magic file header for a bzip file. Ignoring the first “hello” packet, a bzip archive can be extracted from the trace file. Decompressing the bzip archive reveals a second pcap trace.

Using similar techniques as before, multiple FTP over IPv6 connections can be observed within the pcap. Following one of the FTP connections reveals a series of requests and responses, which all streams mimic:

1) an anonymous FTP login occurs

2) a series of change directory commands is issued to /this/is/going/to/be/so/much/fun/

3) a size request for a file resulting in a response of 61052

4) a REST request for a specified byte offset of the file

5) the TCP connection is then reset

This series of commands is indicative of an FTP range request.

Reassembling the bytes of the file transferred via FTP range requests provides a tarball. Within the tarball is a third pcap trace file.

Again, observing protocols and conversations within the pcap reveals multiple HTTP connections between two end points. By observing the HTTP response codes in the connections a participant may have noticed only “206 Partial Content” codes. These codes are used to respond to HTTP range requests. The “Range” header is also included in all requests issued within the trace file.

Similar to FTP range requests, HTTP range requests can be used to request specific byte ranges for resources. Reassembling the byte ranges reveals a fourth and final packet trace file.

Within this trace file is a single TLS session between a host and Google. Within the requested SNI names of the “Client Hello” message of the TLS exchange additional server names (besides www.google.com) are present. This should be a big red flag to participants as this indicates the client would accept HTTP host names besides www.google.com. These SNI entries are also not ASCII characters, which also may have been a red flag.

The additional SNI entries in hexadecimal representation follow:

1) 61707f4a

2) 6801117501561d11

3) 7811795450435511680144117d585a54116172706162110b75

4) 4c

Knowing previous challenge flags took the form of “PAN{ FLAG }” XORing the first value of the first SNI entry, 0x61, with 0x50 (“P” in hexadecimal) revealed the key, 0x31, used to XOR the remaining characters with. Doing so produces the key for this challenge:

PAN{Y0 D0g, I Heard Y0u Like PCAPS :D}

This challenge tested the participant’s knowledge of standard networking protocols and how these protocols can be (mis)used to fragment data at the application layer. It also tested the participant’s tenacity as it was a rather long and obfuscation heavy challenge. Tools used to solve this challenge could include Wireshark, common command line utilities, Bro, and Python’s dpkt module.