SharkFest the anual wireshark developer conference has just concluded and I had an absolute blast! I bought a pass to all 3 pre-conference training classes (spanning 4-days) and also a full-conference pass:
This year I presented at SharkFest! My presentation was titled “School from Home: Watching the wire with Wireshark” where I talked about some interested traffic I found coming from the school provided Chromebooks and how I took a deeper dive to taking advantage of implied trust. (When ever the video gets posted to YouTube I’ll include a link)
I spent most of the 2nd day of conference presentation playing the CTF. The CTF this year was really well done with tons of challenges and some really hard ones too. If you want a CTF that focussed on packet captures and packet analysis this is the place to be. Overall I got 5th place out of 68 teams and I’m happy with that.
Because of a configuration error I realised after completing all my slides and generating my example PCAPs, I needed to spend most of my time during the training classes pulling double duty. I was halfway participating in class and the other half remaking my slides and PCAPs. I even spent most of Day-1 from the conference finalizing my slides and semi-rehearsing for my presentation.
This was the first ‘conference’ I’ve spoken at. While I typically don’t have any major stage fright, I was feeling a bit nervous because everyone who was presenting were folks who I look up to as experts in the field of packet analysis and I was exeriencing some major imposter syndrome.
Despite my imposter syndrome, I felt good about the execution of my presentation. I would’nt have changed anything about my presentation except timing. I should’ve start of a little faster pace because at around the halfway mark I realized I only made it through 1/4th of my slides. I quickly picked up the pace and at that rate I felt was too fast and not comprehendible. I also had to gloss-over or skip some more in-depth analysis but… It is what it is. I’ll make that a lessons Learned.
The Wireshark column headers supports unicode characters, such as emojis. As soon as I learned this I started graffiti’ing my profiles with pointless and rediculous smiley faces. This might seem useless but there are a few practical uses:
I’ve seen SharkFest presentations before where customizing you profiles can give you an advantage or efficiency when analyzing certain traffic. While it really just comes down to personal preferences, in the past I brushed this idea under-the-rug and focused on my protocol fundamentals. Well, maybe it’s a sense maturity, but I now recognize the value of coloring rules: It’s not just coloring rows for personal preference but also creating a column for your coloring rules and using the rule name as a filter.
Maybe this^ needs a blog post all on it’s own?
Recently I’ve needed to dive into the file structure of PCAP and PCAPng file types. See: Modifying PCAPng File Structure Using A Raw Hex Editor and https://twitter.com/showipintbri/status/1437070853062156296.
I had no idea you could investigate the file structure itself within Wireshark. For that navigate to: View > Reload as File Format/Capture
^ This is exactly why I love attending conferences. You learn about cool projects people are doing. Tips & Tricks to make your job easier and an opportunity to as experts questions!
Last year I took Chris Greer’s TCP trainings prior to SharkFest. I learned a ton! Infact there was so much to learn I deffinitely didn’t absorb all of it. So, this year I signed up for the training again hoping that a second time going over the material it would sink-in a little more… and it did. My focus was on day 2 of the training as Day 1 is alot of TCP basics and Wireshark basics. Day 2 is some more advanced TCP topics such as TCP SACK and understanding stream graphs. <- This was the content I came for.
I was having trouble remembering which lines indicated the various TCP header components. Also, I just wanted more organic practice of looking at the graphs on real traffic to help train my eyes and my mind to recognize graph shapes and paterns.
I often have to open files greater than 1 GB. This is one of the reasons I lean on so many other tools for processing large files before diving in with the Wireshark Microscope. Processing large captures in Wireshark is dificult because each time you change or update a display filter it needs to re-scan the entire file which can takes time. Read filters will apply to when you open the PCAP so your subsequent display filters will be on a much smaller sub-set of traffic.
The Read filter can be fore when to open a PCA from the Wireshark interface: File > Open…
NOTE: It is will still take time on initial load.
NOTE: When a display filter is applied it can still take a long time if the after the read filter you still have alot of packets.
During the CTF there was a challenge about TCP Window Scaling. This one took me a while. Alot longer than it should have but I was stuck on the fact that Wireshark was calculating the ‘Calculated Window Size’ for me and I couldn’t figure out the math it was use or hos it was deriving the values it was using. Sure I could’ve just popped into the chat and asked one of th emany experts on the subject but I really wanted to figure this out on my own.
The Window Scale value is a single byte in width. The Window Scale Factor is 2^[window Scale Value]: 2 to the ___th power.
This value, if the option is agreed upon from both end points, is applied to all TCP packets after the SYN & SYN/ACK.
Reference: https://datatracker.ietf.org/doc/html/rfc1323#page-8
I title this section “Window Scaling, OMG Window Scaling” because there’s something to be said about memory and emotions. I don’t know the exact science behind it but you are much more likely to remember shomething if you have a specific emotion tied to that event or that thing. In this case, the emotion I felt when finally sorting out the window scaling I’ll never forget this now. Forever it will be burned in my brain as: “Two to the __nth!”
While it’s been on my radar for much longer, Sharkfest has been amazing for me over the past 2 years. I have learned so much about packet analysis and understanding the network traffic that uses the plumbing we(network engineers) build. I also had fun hanging out in the “Developerd Den” where I was chatting and interacting with some of Wiresharks core developers. I was able to ask about certain features and make suggestions for upcoming features. Wireshark truly is an amazing project with a great community around it 🤘.