Every summer the devs here at CloudShark engage in a “Summer Coding Challenge” to flex their programming muscles and relive the glory (horror?) days of computer science homework. It just so happens that one of those challenges this year made a great packet capture challenge for you CloudShark fans!
We got a lot of great answers - we have some of those solutions below, but if you don’t want it spoiled and want to try the capture for yourself, here it is:
The Challenge - “The Big Byte”
Your task is to create a cloudshark.org capture file session that shows a TCP session transfering at least 1,000,000 bytes of data (that’s a mega bite! Sorry - shark jokes are basically what we do all day). The amount of bytes transferred will be measured by looking at the TCP view of CloudShark’s protocol conversations tool. The winners will be those who create a capture file that meets this requirement with as few packets possible. Anything goes, so feel free to get creative!
Here were the two best answers worthy of repeating here. The first was from Ken Mix:
His capture got it down to only 53 packets! Here’s how he did it:
“To receive the packets I threw together a quick and dirty TCP server in Go. I cross-compiled the Go script for Linux and ran it on an Ubuntu 16.04.1 VM (which has pretty good defaults built in for large windows and fast scaling). For the payload I generated a 1MB dummy zip file, which I then sent to my Go server via netcat on the same machine using the loopback interface to take advantage of the 65k MTU.”
The winning capture is from Aaron Stephens, who got it down to 16 packets:
Aaron also gave us the python script that he used to generate it. Like he said, it was a “Great refresher on TCP”.
One more from us
When we did this challenge internally, our IPv6 expert and support guru Tom was able to do the impossible and put the entire 1 MB of data in a single packet. He did this using a few tricks surrounding IPv6 jumbograms.
“The pcap file format allows the user to set a snap length when capturing so that only a certain number of bytes are actually saved to the file when more bytes were seen when capturing. By using a hex editor to modify my capture I was able to create a packet that looked like quite a few more bytes were seen on the wire but were not saved to the file.”
Thanks for everyone who participated! Join us next time!