Pitter, Patter, Platters picoCTF 2020 Mini-Competition Solution

Description

1. Step 1

   Option A: View the disk image in FTK Imager (Windows)

   Observation

   I noticed the challenge description explicitly called out 'slack space' as the hiding location, which suggested using a forensic tool like FTK Imager that can read raw sector data beyond what the OS exposes through normal file system access.

   Open FTK Imager and add the disk image as an evidence item. Navigate to the root of the file system. You will see suspicious-file.txt with the text 'nothing to see here but you may want to look here'. FTK Imager also identifies slack space associated with that file and displays the flag bytes stored there.

   Learn more

   FTK Imager is a free forensic imaging and preview tool from AccessData. It can open raw disk images (.dd) and display the file system structure, including slack space that the OS would normally hide. The slack space entry shows the flag written in reverse order.

   File system slack space arises because files are stored in fixed-size clusters. When a file does not fill its last cluster exactly, the leftover bytes retain whatever was previously stored there. This space is invisible to a normal directory listing but fully visible to forensic tools that read raw sector data.

2. Step 2

   Option B: Use strings with Unicode mode on Linux

   Observation

   I noticed that running strings without flags produced no useful output from the disk image, which suggested the hidden data was not plain ASCII and pointed toward Unicode encoding stored in the slack space of the suspicious file.

   Run strings with the -e l flag (16-bit little-endian Unicode) on the disk image. The flag is stored in Unicode in the slack space and appears in the strings output in reverse order after the 'you may want to look here' line.

   bash

   strings -e l suspicious.dd.sda1 | more

   Copied!

   Expected output

   picoCTF{b3_5t1ll_my_h34rt}

   What didn't work first

   Tried: Running strings without any encoding flag on the disk image

   The default strings command scans for ASCII byte sequences. The flag in the slack space is encoded as 16-bit little-endian Unicode, so the null bytes between each character break every ASCII match. The output will show other ASCII strings on the disk but the flag bytes will be completely invisible. Adding -e l switches the scan to 16-bit little-endian Unicode and reveals the flag.

   Tried: Using strings -e b (big-endian Unicode) instead of -e l

   The -e b flag scans for 16-bit big-endian Unicode. Windows NTFS and FAT store Unicode text in little-endian byte order, so the byte pairs in the slack space do not match the big-endian pattern. The flag will not appear in output, even though Unicode mode is active. The correct flag is -e l for little-endian.

   Learn more

   The default strings command looks for ASCII sequences. The -e l flag tells it to look for 16-bit little-endian Unicode strings instead, which is how the flag data is encoded in the slack space. Without this flag the flag bytes are invisible to strings.

   Martin also uses strings -n 15 to filter for strings of at least 15 characters, which helps reduce noise when scanning a disk image.

3. Step 3

   Reverse the flag string

   Observation

   I noticed the strings output showed a recognizable but backwards string like '}tr4h_ym_ll1t5_3b{FTCocip', which indicated the flag was stored in reverse byte order in the slack space and needed to be flipped with rev to read correctly.

   The flag text appears in the strings output in reverse order. Pipe it through rev to get the correct flag. The flag is picoCTF{b3_5t1ll_my_h34rt} (the closing curly brace may need to be added manually).

   bash

   strings -e l suspicious.dd.sda1 | grep -A 1 'look here' | tail -1 | rev

   Copied!

   What didn't work first

   Tried: Running rev on the full strings output instead of isolating the flag line first

   Without the grep filter, rev reverses every line including directory entries, file names, and other strings found on the disk image. The flag line is buried in hundreds of reversed strings and is easy to miss. The grep -A 1 'look here' | tail -1 pipeline isolates exactly the line immediately after the hint text, then rev produces only the readable flag.

   Tried: Skipping rev and reading the raw strings output directly

   The data was written into the slack space in reverse byte order, so the raw strings output shows the flag characters in reverse - for example '}tr4h_ym_ll1t5_3b{FTCocip'. Reading it as-is produces a nonsense string. The rev step is required to flip the characters back into the correct order to get picoCTF{b3_5t1ll_my_h34rt}.

   Learn more

   The Unix rev command reverses each line of its input character by character. The data was stored backwards in the slack space, so a single pass through rev recovers the readable flag.

   The suspicious-file.txt content says: "nothing to see here but you may want to look here." This is the hint pointing directly to the slack space of that file. In a real forensic investigation, unusual file content pointing elsewhere is always worth investigating in the surrounding disk sectors.

Flag

The flag is stored in reverse order in the file system slack space of suspicious-file.txt. Use FTK Imager on Windows or 'strings -e l | rev' on Linux to recover it.