CyLab Security Academy (formerly picoCTF) Wireshark doo dooo do doo… is a Forensics Medium challenge that hands you a packet capture and asks you to find the flag hiding inside network traffic. The flag is there — but it’s ROT13-encoded, so a direct string search fails and throws you off track.
Article Overview
This is a writeup for Wireshark doo dooo do doo…, a Forensics Medium challenge on CyLab Security Academy (formerly picoCTF). You are given a .pcap file and need to find the flag in captured network traffic. The solution involves filtering for HTTP responses, following a TCP stream to read the response body, and recognizing that the string inside is ROT13-encoded.
In this article you’ll learn how to navigate a packet capture efficiently, use Wireshark’s Follow TCP Stream to reassemble HTTP payloads, and identify ROT13 encoding when a string looks like a flag but isn’t quite readable.
Introduction
My first move with any pcap challenge is to open it in Wireshark and hit Ctrl+F to search for “picoCTF” directly. Fast, often works. This time it returned nothing. The packet list showed hundreds of entries and no obvious hit.
That failure set the tone for the next twenty minutes: I kept trying to find the flag as plaintext when it wasn’t there in that form. Once I slowed down and actually worked through the HTTP traffic properly, the answer was one stream away.
What makes this challenge worth writing about is the ROT13 misdirection. In most pcap CTF problems, the flag shows up as readable text somewhere in the traffic. Here it looks like noise — until you recognize the pattern. A string starting with a brace-like structure, all letters and digits, no obviously random characters. That’s the ROT13 tell.
Challenge Overview
The challenge provides a single .pcap file — a packet capture of network traffic. No other files, no hints about what to look for. The challenge name “doo dooo do doo” doesn’t hint at the technique, just the general vibe of digging through noise.
When I opened the capture in Wireshark, I saw a mix of protocols — DNS, TCP, HTTP. About 100-200 packets total, which sounds manageable until you’re clicking through them one by one.
Step 1 — Searching for the Flag Directly (and Failing)
Ctrl+F in Wireshark opens the Find Packet dialog. I typed “picoCTF” and searched across Packet Bytes, then Packet Details, then Strings. Nothing. The string wasn’t anywhere in the capture as plaintext.
I then tried searching for just “CTF” — same result. At this point I started to wonder if I had the right file, but the file came directly from the challenge download so that wasn’t it.
The lesson I always relearn: when you can’t find the flag directly, it’s encoded. The question is how.
Step 2 — Filtering HTTP Traffic and Following TCP Streams
I switched from searching to filtering. HTTP traffic is usually the most interesting in web-related captures, so I applied the display filter:
http
This collapsed the view down to just HTTP packets. A few GET requests and some responses. I looked for HTTP 200 OK responses — successful responses are where content lives. Found one with Content-Type: text/html.
Right-clicked that packet → Follow → TCP Stream. This is the key move. Instead of looking at individual packets, Follow TCP Stream reassembles the entire conversation between client and server and shows the full HTTP request and response as readable text.
The response body contained this:
cvpbPGS{c33xno00_1_f33_h_qrnqorrs}
That’s not a picoCTF flag — but it’s shaped like one. Curly braces, alphanumeric content, underscore separators. The structure screams “flag format” even though the letters are wrong.
Step 3 — Recognizing and Decoding ROT13
The string has braces (which survive ROT13 unchanged) and a mix of letters and digits. Digits also survive ROT13 unchanged — only letters shift. When you see a string that looks like a flag but the alphabetic characters are wrong while the structure is intact, ROT13 is the first thing to try.
Quick mental check: “c” is the 3rd letter. ROT13 shifts by 13: c + 13 = p. So “cvpb” → “pico”. Confirmed.
Decode on the command line:
$ echo 'cvpbPGS{c33xno00_1_f33_h_qrnqorrs}' | tr 'A-Za-z' 'N-ZA-Mn-za-m'
picoCTF{p33kab00_1_s33_u_deadbeef}
Or in Python:
import codecs
print(codecs.decode('cvpbPGS{c33xno00_1_f33_h_qrnqorrs}', 'rot_13'))
# picoCTF{p33kab00_1_s33_u_deadbeef}
Capture the Flag
Flag: picoCTF{p33kab00_1_s33_u_deadbeef}
Read the flag: “peekaboo I see you deadbeef.” The challenge is named after a playful sound — the flag is a matching joke. The server was hiding in the traffic, you peeked through the stream, and there it was. “deadbeef” is a classic hex constant used in low-level debugging and malware analysis, which fits the forensics theme.
The misdirection was the ROT13 encoding. A direct Ctrl+F search for the flag will always fail in a challenge like this. The flag isn’t hidden by obscurity in where it is — it’s right there in the HTTP response body — but in what form it takes.
Full Trial Process Table
| Step | Action | Tool / Command | Result | Why it failed / succeeded |
|---|---|---|---|---|
| 1 | Search for “picoCTF” string directly | Ctrl+F → Strings in Wireshark | No results | Flag is ROT13-encoded; plaintext search misses it |
| 2 | Apply HTTP display filter | http filter in Wireshark | Reduced view to HTTP packets only | HTTP traffic is where response content lives |
| 3 | Find HTTP 200 response, Follow TCP Stream | Right-click → Follow → TCP Stream | Full HTTP response body visible | Reassembles fragmented packets into readable payload |
| 4 | Identify encoded string in response body | Visual inspection | Found cvpbPGS{c33xno00_1_f33_h_qrnqorrs} | Flag structure with wrong letters → encoding suspected |
| 5 | Decode ROT13 | tr 'A-Za-z' 'N-ZA-Mn-za-m' | picoCTF{p33kab00_1_s33_u_deadbeef} | ROT13 confirmed by “c”→”p” mental check |
Short Explanations for Commands and Techniques Used
Wireshark Display Filters
Display filters narrow the packet list without discarding data from the capture. Common filters for CTF use: http (all HTTP traffic), http.response.code == 200 (successful responses only), tcp (all TCP). Filters are applied in the bar at the top of the Wireshark window. The Wireshark display filter reference covers all available syntax.
Follow TCP Stream
TCP breaks data into segments (packets). A single HTTP response might be split across 10 or 20 packets. Follow TCP Stream reassembles all packets in a TCP conversation and presents the full payload in one view — client data in red, server data in blue. This is the most efficient way to read HTTP bodies, form data, and other application-layer content in a pcap. Access it by right-clicking any packet in the conversation and choosing Follow → TCP Stream.
ROT13 Identification and Decoding
ROT13 shifts every letter 13 positions in the alphabet. Because the alphabet has 26 letters, ROT13 is self-inverse: encode and decode are the same operation. Numbers, punctuation, and braces are not affected.
In CTF, the fastest ROT13 identification: take the first letter of the suspicious string and count forward 13. If “c” → “p” and the result starts to look like “pico,” you’ve confirmed it. Decode with tr 'A-Za-z' 'N-ZA-Mn-za-m' on the command line or codecs.decode(s, 'rot_13') in Python.
Beginner Tips
- If Ctrl+F string search fails, the flag is probably encoded. ROT13, Base64, hex, and URL encoding are the most common in CTF pcap challenges. Try each quickly before spending time on deeper analysis.
- Use Follow TCP Stream aggressively. Clicking through individual packets is slow. Right-click any packet that looks interesting and Follow TCP Stream to see the full conversation in one go.
- Filter before searching. Apply
httpordnsortcpfirst to reduce noise, then search within the filtered view. Searching 20 packets is much faster than searching 200. - The ROT13 tell: flag structure with wrong letters. If you see braces, underscores, and mixed alphanumerics but the letters don’t spell anything, check the first letter. If c + 13 = p, it’s ROT13.
- Wireshark’s Statistics → HTTP → Requests gives a quick overview of all HTTP endpoints in the capture. Useful for finding where the interesting traffic is without manually reading every packet.
What You Learn
This challenge builds three specific skills. First: working with packet captures without losing patience — filtering, not scrolling. Second: Follow TCP Stream as the standard move for reading application-layer data. Third: recognizing encoded strings by structure rather than content. When the shape is right but the letters are wrong, it’s encoded, not random.
The ROT13 lesson transfers directly to log analysis and web application testing. Developers sometimes ROT13-encode debug output or comments that they don’t want to be immediately obvious. In a real incident response scenario, finding an encoded string in HTTP traffic is worth decoding — it could be a C2 beacon, an exfiltrated credential, or a developer shortcut left in production code.
If I hit this challenge again, I’d go directly to the HTTP filter and Follow TCP Stream on every 200 response before doing any string search. That approach would solve it in under two minutes. The Ctrl+F shortcut only works when you know what encoding to search for — and here, you don’t know yet.
Further Reading
For a harder pcap forensics challenge that goes beyond HTTP — including raw TCP reconstruction and covert channel analysis — see the Ph4nt0m 1ntrud3r picoCTF Writeup, which required parsing binary packet data to reassemble a fragmented flag.
For a broader reference on the tools used in forensics challenges — including where Wireshark fits alongside other common tools — see CTF Forensics Tools: The Ultimate Guide for Beginners on alsavaudomila.com.
Leave a Reply