Timeline 1 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

   Raw disk partition images are forensically complete snapshots of a storage partition. Unlike filesystem-level copies (like cp -r), they capture every bit on the partition: live files, deleted files, slack space (unused space within file clusters), unallocated space (sectors not belonging to any file), filesystem journal entries, and all metadata structures. This completeness is essential for forensic analysis where evidence may exist in unexpected locations.

   Timeline-1 is the second part of the timeline challenge series and uses a different disk image than Timeline-0 (note the different URL hash). While both challenges use the same methodology (fls + mactime), the specific filesystem content differs, meaning the flag is in a different location or encoded differently. Treating each disk image as an independent investigation is the correct approach.

2. Step 2Build a filesystem timeline
   fls -m produces a body file with MAC timestamps for every inode TSK can read. mactime -b body.txt -d sorts that into a comma-delimited (-d = delimited / CSV-style) timeline you can grep.
   bash

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

   Copied!

   bash

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

   Copied!
   Learn more

   Why fls autodetects the filesystem. TSK probes the image's superblock / boot sector signatures: ext4's magic number 0xEF53 at offset 0x438, NTFS's NTFS signature at offset 3 of the boot sector, FAT's OEM identifier and BPB layout, HFS+'s H+ at offset 1024, APFS's container superblock magic. If a known signature matches, fls picks the right parser and you don't pass -f manually. (When in doubt: fsstat partition4.img prints the detected type explicitly.)

   Allocated vs deallocated inodes. On ext4/NTFS, file metadata (timestamps, permissions, size, block pointers) lives in inode/MFT entries, separate from the directory entries that map names to inodes. When a file is deleted, the directory entry is often cleared first (or marked unused), and the inode is marked deallocated - but the metadata bytes are not zeroed. fls -r walks both allocated and deallocated inode entries, so deleted-file metadata persists in the timeline even if the data blocks have been reused. This is the entire reason filesystem timelines work for forensics.

   What -d actually does. mactime -d emits comma-delimited output (CSV-style) instead of the default human-readable columnar format. CSV is what you want for grep, awk, and spreadsheet imports. There's also -y (ISO 8601 dates) and -z UTC (force timezone), which keep results deterministic across machines.

   On a real system disk the CSV can run into millions of rows; for this challenge it's small enough that grep picoCTF timeline.csv finds the flag immediately. See the Volatility 3 guide for the in-memory equivalent of this workflow.

3. Step 3Search the timeline for the flag
   Grep the generated timeline for 'picoCTF'. The flag is embedded as a filename or path visible in the timeline output.
   bash

   grep picoCTF timeline.csv

   Copied!

   bash

   grep -i flag timeline.csv

   Copied!
   Learn more

   The mactime CSV output includes columns for: date/time of the MAC event, size in bytes, the MAC type (M/A/C/B for Modified/Accessed/Changed/Born), permissions, UID, GID, inode number, and the full file path. Searching for picoCTF in this output will find any filename containing that string, regardless of which column it appears in.

   Filename-based evidence is particularly valuable in forensics because filenames survive in specific scenarios where file content does not. Even if a file is deleted and its blocks overwritten, if the directory entry was not reused, the filename remains recoverable. TSK's fls marks recovered deleted file entries with an asterisk (*) before the filename, distinguishing them from currently allocated files. In this challenge, the flag might appear in either an active or deleted file entry.

4. Step 4Wrap in picoCTF{...} format
   Take the string found in the timeline and wrap it in picoCTF{...} as the challenge instructs.
   Learn more

   The wrapping instruction distinguishes this challenge from challenges where the full flag (including picoCTF{}) is directly embedded. When the challenge says to wrap the found string, it means the filesystem contains an intermediate artifact (a filename, a text string in a file, or a path component) that represents just the inner content of the flag. You must recognize which discovered string is the flag content and manually construct the complete flag.

   This type of challenge builds the important skill of artifact interpretation in forensics - not every piece of data found in an investigation is directly useful; analysts must identify which artifacts are significant and interpret them correctly in context. In real cases, evidence might be a username in a log file, a timestamp, a file path, or a command argument that needs to be combined with other artifacts to reconstruct the complete picture.

Flag

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