WebNet1 picoCTF 2019 Solution

Description

1. Step 1

   Decrypt the TLS traffic using the key

   Observation

   I noticed the challenge provided both a pcap file and an RSA private key, which suggested the capture contained encrypted TLS traffic that could be retrospectively decrypted by supplying the server's private key to Wireshark.

   Add the provided RSA key in Wireshark's TLS preferences (Edit > Preferences > Protocols > TLS > RSA keys list). Re-open the pcap. The encrypted traffic becomes readable HTTP. Follow the TLS streams and look at the HTTP response bodies.

   Learn more

   When you follow the first TLS stream you will find a Pico-Flag HTTP header, but it reads picoCTF{this.is.not.your.flag.anymore}. That is a deliberate decoy. The challenge description hints that the flag has moved, so keep looking.

   One of the HTTP responses transfers a JPEG image (vulture.jpg). The real flag is a plain string embedded inside that image file, not in the HTTP headers.

2. Step 2

   Export the transferred image and search it for the flag

   Observation

   I noticed the decrypted HTTP stream contained a JPEG image file (vulture.jpg) being transferred, and the challenge description said the flag had moved out of the HTTP headers, which suggested the flag was embedded as a raw string inside the image file itself.

   Use Wireshark's File > Export Objects > HTTP (or tshark --export-objects) to save the JPEG from the capture. Then run the strings command on the saved file and grep for the flag prefix. The flag appears as a plain string inside the image file.

   bash

   # Export HTTP objects with tshark (alternative to Wireshark GUI):

   Copied!

   bash

   tshark -r capture.pcap -o 'ssl.keys_list:0.0.0.0,443,http,picopico.key' --export-objects 'http,out'

   Copied!

   bash

   Copied!

   bash

   # Search the exported JPEG for the flag string

   Copied!

   bash

   strings out/vulture.jpg | grep pico

   Copied!

   Expected output

   picoCTF{honey.roasted.peanuts}

   What didn't work first

   Tried: Run strings on the original pcap file instead of the exported JPEG to find the flag.

   The pcap file stores raw TLS ciphertext, so strings on the pcap produces garbled binary fragments and no readable flag. The flag only becomes a plain ASCII string after the TLS layer is stripped and the JPEG payload is extracted. Export HTTP objects first, then run strings on the resulting image file.

   Tried: Use steghide to extract hidden data from the exported vulture.jpg.

   steghide expects a passphrase and looks for data hidden with its own LSB-embedding algorithm. This JPEG has no steghide-compatible payload - the flag was simply appended or embedded as a raw string, not steganographically encoded. strings finds it immediately without any passphrase or steganography tool.

   Learn more

   strings extracts printable character sequences from any binary file. Because the flag was stored as a raw ASCII string inside the JPEG data, no image-analysis tool is needed - a simple grep finds it immediately.

   This challenge demonstrates that when network traffic contains binary files, those files may themselves contain hidden data. Checking transferred files with strings or a hex viewer is a fast first step before reaching for heavier forensics tools.

Flag

Decrypt the TLS stream with the RSA key, export the transferred JPEG, then run strings on it to find the flag stored as a plain string inside the image file.