Timeline 0 picoCTF 2026 Solution

Description

1. Step 1Decompress the image

   Observation

   The download is gzip-compressed. Decompress it before any forensic tool can read the partition bytes.

   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

   Observation

   The name says timeline and the artifact is a disk image, so the flag is hidden behind manipulated timestamps. Build a full MAC timeline with fls and mactime and the anomaly surfaces.

   fls is The Sleuth Kit's raw-image equivalent of ls. It reads filesystem metadata directly from the disk image (no mount required) and emits a body file whose rows encode the MAC timestamps, inode number, and full path for every entry. mactime then sorts those rows chronologically into a human-readable timeline.

   bash

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

   Copied!

   bash

   mactime -b body.txt > timeline.txt

   Copied!

   Expected output

   71m311n3_0u7113r_h3r_43a2e7af

   What didn't work first

   Tried: Mount the image with 'sudo mount -o loop partition4.img /mnt' and run 'find /mnt' to list all files.

   Mounting updates the access time on everything you touch, smudging the exact timestamps you came to read. find also sees only allocated directory entries, so it misses deleted files and cannot produce the epoch-format body file mactime needs. fls reads the on-disk inode tables without mounting, captures deleted entries, and emits rows mactime can sort.

   Tried: Run 'fls -r partition4.img' without the '-m /' flag and pipe directly to mactime.

   Without the mount-point flag, fls prints a plain listing with none of the pipe-delimited columns mactime expects, so mactime returns nothing or a parse error. That flag also prepends the mount point, which is what puts full paths in the body file.

   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. It works on a disk image without mounting (so no kernel state is touched, no timestamps are smudged) and 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 timeline. Each MAC event becomes its own row, so a single inode can appear up to four times (atime, mtime, ctime, crtime).

3. Step 3Identify the file with an anomalous 1985 timestamp

   Observation

   The timeline runs from 2021 onward, so an entry stamped 1985, before Linux existed, is impossible and points straight at the planted file.

   Scan the timeline for entries that fall outside the plausible date range. One file, /bin/bcab at inode 4945, carries a January 1985 timestamp - decades before the filesystem was created. This impossibly old date is the anti-forensic technique called timestomping: an attacker sets MAC timestamps to a meaningless value so the file blends into the noise of system binaries or, paradoxically, gets pushed so far back in the timeline that a casual search misses it.

   bash

   grep 'Jan.*1985\|1985' timeline.txt

   Copied!

   What didn't work first

   Tried: Search the timeline for suspicious files by looking for recently modified system binaries with 'grep /bin timeline.txt'.

   Timestomping pushes the forged file to an impossibly old date, not a recent one. Filtering by path gives you dozens of legitimate binaries created around the same moment and no outlier at all. Filter by date instead: a 1985 timestamp predates Linux and stands out the moment the timeline is sorted.

   Tried: Use 'ls -la --full-time /mnt/bin/' after mounting the image to spot the unusual timestamp.

   ext4 keeps four timestamps per inode and mactime shows all of them. ls shows modification time by default, needs flags for the others, and never shows creation time at all. Worse, mounting can update access times and overwrite the evidence you came for. fls reads all four from the raw inode without touching anything.

   Learn more

   Timestomping is an anti-forensic technique where an attacker deliberately modifies the MAC timestamps on a file - using tools like touch -t, debugfs, or Metasploit's timestomp module - to make the file appear older (or newer) than it really is. The goal is to throw off timeline analysis: if you sort by date and everything looks normal except one file dated 1985, that anomaly is exactly the clue you need.

   In this challenge the suspicious file is /bin/bcab with inode 4945. Every other file on the partition dates from 2021 or later; the 1985 date is impossible for a filesystem that did not exist until recently. That inconsistency is the signal - the file was planted and its timestamp was deliberately forged.

   See the Volatility 3 guide for the memory-forensics analogue (Volatility:RAM :: TSK:disk).

4. Step 4Extract the file contents with icat

   Observation

   The body file gives an inode number for that file. Read its data blocks directly with icat, which does not depend on a directory entry still existing.

   icat (inode concatenate) is a Sleuth Kit tool that reads the data blocks pointed to by a given inode and streams them to stdout. Because it works by inode number rather than filename, it recovers file content even when the directory entry has been deleted or the path has been obscured. Pipe the output to a file so you can inspect it.

   bash

   icat partition4.img 4945 > bcab

   Copied!

   bash

   cat bcab

   Copied!

   What didn't work first

   Tried: Mount the image and copy the file with 'cp /mnt/bin/bcab ./bcab' instead of using icat.

   If the attacker unlinked the directory entry after planting the file, it never appears in a mounted tree even though the inode and its data blocks are still there. icat skips directory entries and reads blocks by inode number, so it works either way. Copying through a mount point fails silently on an unlinked inode.

   Tried: Use 'icat partition4.img /bin/bcab' with the path instead of the inode number 4945.

   icat wants a numeric inode as its last argument, not a path; a path string produces an error or a misread argument. The inode came from the body file in the previous step. To go the other way, from a path to an inode, use ifind.

   Learn more

   The output of icat partition4.img 4945 is the raw bytes stored at inode 4945. In this challenge those bytes are a base64-encoded string:

   NzFtMzExbjNfMHU3MTEzcl9oM3JfNDNhMmU3YWYK

   Base64 is a binary-to-text encoding that represents arbitrary bytes using only printable ASCII characters. It is commonly used to embed binary payloads in text-safe contexts. The trailing K and newline are standard base64 padding/line-ending artifacts.

5. Step 5Base64-decode the extracted content

   Observation

   The extracted file is alphanumeric with a trailing newline, which reads as base64. Decode it.

   Pipe the file through base64 -d (or base64 --decode) to recover the plaintext flag content. The decoded string is the inner part of the flag; wrap it in picoCTF{...} as the challenge instructs.

   bash

   base64 -d bcab

   Copied!

   The decoded output is 71m311n3_0u7113r_h3r_43a2e7af. Wrap it per the challenge instructions: picoCTF{71m311n3_0u7113r_h3r_43a2e7af}.

   Learn more

   Why base64 here? Base64 lets an attacker store arbitrary binary data (or simply an obfuscated string) inside a file in a way that survives copy-paste or text-based transmission without corruption. A forensic analyst who only runs strings on files will see the encoded blob and might dismiss it; the extra decode step is part of the obfuscation. The challenge teaches you to always try base64 decode on short, character-class-limited strings you recover from disk images.

   The name of the challenge - "Timeline 0" - signals the primary forensic primitive: build a MAC timeline, spot the temporal outlier, then chase the inode to its data. This pattern (timeline anomaly leads to hidden payload) appears in real incident-response work whenever an attacker uses timestomping to hide a dropper or persistence mechanism in a system binary directory like /bin.

Flag

The flag is the base64-decoded content of inode 4945 (/bin/bcab), a file whose impossibly old 1985 timestamp marks it as the timestomped anomaly in the MAC timeline. Build the timeline with fls + mactime, spot the 1985 outlier, extract with icat, and decode with base64 -d.