CanYouSee picoCTF 2024 Solution

Description

1. Step 1

   Inspect EXIF metadata

   Observation

   I noticed the challenge involved a JPEG file with data described as 'hidden,' which suggested the data was not in the visible pixels but in the structured metadata layer that viewers never render, making exiftool the natural first tool to run.

   Run exiftool to dump every field. The Attribution URL entry stands out because it holds a Base64-looking string instead of a normal URL.

   bash

   exiftool ukn_reality.jpg

   Copied!

   ...
   Attribution URL                : aGVsbG8gd29ybGQ=
   ...

   What didn't work first

   Tried: Run strings on ukn_reality.jpg instead of exiftool, hoping to spot the encoded value in raw output.

   strings prints printable byte sequences directly from the binary, so it does surface Base64-looking text, but it also floods the terminal with JPEG marker bytes and Huffman table fragments that look similar. Worse, strings has no concept of EXIF field names, so you cannot tell which string belongs to Attribution URL versus a camera model or copyright notice. exiftool parses the structured metadata format and labels every field, making the anomalous value immediately obvious.

   Tried: Use steghide on ukn_reality.jpg to look for hidden data embedded in the pixel values.

   steghide hides data using LSB steganography in the image pixel data and requires a passphrase to extract it. This challenge hides the data in EXIF metadata fields, not in the pixels, so steghide extract finds nothing and prompts for a passphrase that does not exist. The correct tool is exiftool, which reads the structured metadata layer rather than the image content.

   Learn more

   exiftool reads, writes, and edits metadata across a wide variety of file formats. Run it without arguments and it dumps every field it can find: EXIF, IPTC, XMP, ICC Profile, JFIF, and more. For forensics this broad dump is always the right first step.

   The Attribution URL is an XMP field typically used to credit the source of an image, so legitimate values look like https://example.com/photo. A long alphanumeric string with no slashes or dots is an obvious signal that something has been encoded into the field.

   Base64 uses only A-Z, a-z, 0-9, +, /, and = (padding). If a metadata field contains only these characters and its length is a multiple of 4, it's almost certainly Base64. Recognising that pattern in otherwise structured metadata is a core forensics reflex.

2. Step 2

   Extract just the encoded value

   Observation

   I noticed the Attribution URL field contained a string of only alphanumeric characters and equal-sign padding rather than a real URL, which are the hallmarks of base64 encoding and suggested piping the isolated value through base64 -d to recover the flag.

   A quick pipeline can isolate the Attribution URL value, strip whitespace, and hand the text to base64 -d. The decoded output is the entire flag.

   bash

   exiftool ukn_reality.jpg | grep "Attribution URL" | cut -d":" -f2- | tr -d " " | base64 -d

   Copied!

   Expected output

   picoCTF{ME74D47A_HIDD3N_a6d...}

   What didn't work first

   Tried: Run base64 -e (or omit the flag entirely) instead of base64 -d, expecting the tool to auto-detect direction.

   base64 without any flag defaults to encoding mode, so it takes the literal ASCII text aGVsbG8gd29ybGQ= as input and produces a doubly-encoded string that looks like noise. The -d flag explicitly switches to decode mode. This is a very common slip when using base64 for the first time, and the garbled output gives no clear error message to diagnose it.

   Tried: Use cut -d":" -f2 (without the trailing dash) to extract the Attribution URL value.

   cut -f2 returns only the second colon-delimited field. For a value like aGVsbG8gd29ybGQ= that contains no colons this still works, but the same pipeline applied to a URL-style value such as https://example.com would silently clip everything after the first colon, leaving only //example.com. The correct form -f2- means field 2 through end-of-line, so any embedded colons in the value are preserved.

   Learn more

   The pipeline chains small Unix tools, each with a single responsibility: grep finds the line, cut -d":" -f2- takes everything after the first colon, tr -d " " strips whitespace, and base64 -d decodes the result.

   The trailing dash in -f2- is the important detail. -f2 alone takes only the second colon-delimited field, which would clip the value if the URL itself contained colons (e.g. https://...). -f2- means "field 2 to the end," which keeps embedded colons intact.

   Base64 reverses the lossless encoding that maps arbitrary binary into printable ASCII. Every 3 input bytes become 4 output characters, which is why the encoded string is roughly 33% longer than the data it carries.

   This grep then extract then decode pattern shows up constantly in CTFs and real forensics. The shell one-liner is faster than a GUI tool and the muscle memory transfers directly to log analysis and incident response.

Flag

Decoding the Attribution URL entry reveals the complete flag shown above.