Pitter, Patter, Platters picoCTF 2020 Mini-Competition Solution

Description

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

   Observation

   The description names slack space as the hiding place. That calls for a forensic tool like FTK Imager, which reads raw sector data beyond what the OS exposes through normal file 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 2Option B: Use strings with Unicode mode on Linux

   Observation

   Plain strings turns up nothing useful in the disk image. So the hidden data is not ASCII, which points at Unicode text sitting 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

   Default strings scans for ASCII. The flag in the slack space is 16-bit little-endian Unicode, so the null byte between each character breaks every ASCII match. You will see other strings on the disk while the flag stays invisible. Adding -e l switches the scan to little-endian Unicode.

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

   The -e b flag scans for 16-bit big-endian Unicode, but Windows NTFS and FAT store Unicode little-endian, so the byte pairs in the slack space never match the big-endian pattern. The flag stays absent even with Unicode mode on. Use -e l.

   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.

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

3. Step 3Reverse the flag string

   Observation

   The strings output shows a recognizable but backwards string, '}tr4h_ym_ll1t5_3b{FTCocip'. The flag was stored in reverse byte order, so rev flips it back into readable form.

   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 everything else on the disk image, and the flag gets buried among hundreds of them. The grep -A 1 'look here' | tail -1 pipeline isolates the line right after the hint, so rev outputs only the flag.

   Tried: Skipping rev and reading the raw strings output directly

   The data was written into the slack space in reverse byte order, so strings shows the flag backwards, as '}tr4h_ym_ll1t5_3b{FTCocip'. Read it as-is and it is nonsense. rev flips the characters back to give 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.