Timeline 0 picoCTF 2026 Solution

Description

1. Step 1Decompress the image
   Extract the raw partition image from the gzip archive.
   bash

   gunzip partition4.img.gz

   Copied!
   Learn more

   gzip is a lossless compression format based on the DEFLATE algorithm, commonly used to compress files for distribution. The .gz extension indicates a gzip-compressed file. gunzip decompresses it in place, removing the .gz extension. The resulting .img file is a raw byte-for-byte copy of a disk partition, including all filesystem structures, file data, and unallocated space.

   Disk images (raw, dd-format) capture everything on a storage device - not just the files, but also filesystem metadata (inodes, directory entries, timestamps), deleted files (data still present in unallocated sectors), and filesystem journal entries that record recent changes. This makes raw disk images the gold standard for digital forensics: they preserve all the evidence that a live filesystem might hide or modify during access.

2. Step 2Build a filesystem timeline
   fls is The Sleuth Kit's raw-image equivalent of ls. Two big differences: it reads filesystem metadata directly from the disk image (no mount required), and it reports deleted entries whose inodes haven't been overwritten yet.
   bash

   fls -m '/' -r partition4.img > body.txt

   Copied!

   bash

   mactime -b body.txt -d > timeline.csv

   Copied!
   Learn more

   fls vs ls. Plain ls shows the live filesystem state through the kernel: only allocated, currently-visible directory entries. fls parses the raw on-disk structures (ext4 inode tables, NTFS MFT, FAT directory blocks) directly. Two consequences: it works on a disk image without mounting (so no kernel state is touched, no timestamps are smudged), and it surfaces deleted-but-still-recoverable entries that ls never sees.

   What a body-file row looks like:

   MD5|name|inode|mode|UID|GID|size|atime|mtime|ctime|crtime
   0|/var/log/auth.log|2049|-/-rw-r-----|0|4|45821|1714521600|1714531200|1714531200|1714521600

   Pipe-delimited, eleven fields, epoch timestamps. mactime consumes this and emits a chronological CSV. Each MAC event becomes its own row, so a single inode can appear up to four times (atime, mtime, ctime, crtime).

   mactime CSV columns when grepping for the flag: Date, Size, Type (M/A/C/B), Mode, UID, GID, Inode, and finally File path (the rightmost column). The flag-as-filename trick means the flag string appears in that last column. fls marks deleted entries with (deleted) appended to the path or with a leading * in the inode column - both worth grepping if the filename was wiped from the live tree.

   Flag shape inside the timeline: the challenge says "wrap what you find in picoCTF{...}", so what appears in the timeline is the inner content - typically a single suspicious filename or path component. Example match line:

   Tue Apr 30 2024 13:22:14,512,...a..,r/rrwxr-xr-x,0,0,42,/tmp/h1dd3n_1n_pl41n_s1ght

   The flag content here is the filename component h1dd3n_1n_pl41n_s1ght; wrap it as picoCTF{h1dd3n_1n_pl41n_s1ght}. See the Volatility 3 guide for the memory-forensics analogue (Volatility:RAM :: TSK:disk).

3. Step 3Search the timeline for the flag
   Grep the timeline for 'picoCTF' to find the filename or path that contains the flag. The flag text is embedded in a filename or file path visible in the timeline.
   bash

   grep picoCTF timeline.csv

   Copied!

   bash

   grep -i flag timeline.csv

   Copied!
   Learn more

   Hiding data in filenames and directory names is a clever forensic challenge technique: the data exists in the filesystem metadata (directory entries) rather than file content, so tools that only extract file contents will miss it. The timeline approach works because fls reads directory entries directly from the disk image structure and outputs the full path of every file, including its name. This is the same reason filesystem timeline analysis can recover evidence even after files are deleted - the filename remains in the directory entry until that space is overwritten.

   In real forensic investigations, unusual filenames are significant indicators. Malware often creates files with names designed to blend in (e.g., svchost32.exe mimicking the legitimate svchost.exe) or to hide in plain sight in system directories. Exfiltration tools sometimes store collected data in files with innocuous names in temp directories. The timeline makes it easy to spot newly created files in unusual locations at suspicious times.

4. Step 4Wrap in picoCTF{...} format
   The challenge says to wrap what you find in picoCTF{...} format. Take the string from the timeline output and wrap it.
   Learn more

   The challenge instructs you to "wrap what you find" because the actual flag content appears in the timeline without the picoCTF{} wrapper - the filename or path contains just the inner content. This is a common CTF convention where challenges tell you the flag format explicitly when the discovered string needs wrapping. It prevents ambiguity about which part of the output constitutes the flag.

   This pattern of encoding information in filesystem metadata (filenames, timestamps, extended attributes, or directory structure) rather than file content is a real-world data hiding technique. Alternate Data Streams (ADS) on NTFS filesystems, extended attributes on Linux filesystems, and resource forks on macOS HFS+ are all metadata storage locations that can hide data from casual inspection while being visible to forensic tools. Digital forensics practitioners must know to look beyond file contents into all available metadata channels.

Flag

The flag is encoded as a filename or path visible in the filesystem timeline. Build it with fls -m + mactime, then grep for picoCTF.