Timeline 0 picoCTF 2026 Solution

Description

1. Step 1

   Decompress the image

   Observation

   I noticed the downloaded file has a .gz extension, which indicates gzip compression, and suggested decompressing it with gunzip before any forensic tools can read the raw 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 2

   Build a filesystem timeline

   Observation

   I noticed the challenge is named 'Timeline 0' and asks about a disk image, which suggested the flag is hidden via timestamp manipulation and that generating a full MAC timeline with fls and mactime was the right way to surface the anomaly.

   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 through the kernel updates atime on files you access, smudging the very timestamps you are trying to analyze. More importantly, 'find' only shows allocated directory entries - it cannot surface deleted files or produce the epoch-format body file that mactime needs. fls reads raw on-disk inode tables without mounting, so it captures deleted entries and emits proper pipe-delimited body-file rows that mactime can sort chronologically.

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

   Without '-m /', fls outputs a simple listing format without the pipe-delimited body-file columns (MD5, inode, timestamps) that mactime expects. mactime -b requires the body-file format; feeding it the plain listing produces either an empty output or a parse error. The '-m /' flag tells fls to prepend the mount point so full paths appear in the body file and mactime can assemble the timeline correctly.

   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 3

   Identify the file with an anomalous 1985 timestamp

   Observation

   I noticed the timeline contained hundreds of entries from 2021 onward, so any entry stamped in 1985 (before Linux even existed) would be an impossible outlier pointing directly to a timestomped 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 suspiciously recent one. Filtering for /bin entries by path shows dozens of legitimate system binaries that were all created around the same time, with no obvious outlier. The correct approach is to filter by date, not by path - the 1985 timestamp is the anomaly because it predates Linux itself, which immediately stands out when you sort or grep the timeline chronologically.

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

   The ext4 filesystem stores four separate timestamps per inode (atime, mtime, ctime, crtime) and mactime surfaces all of them in the body file. 'ls -la' only displays mtime by default; switching to atime or ctime requires additional flags, and crtime (creation time) is not displayed by 'ls' at all. More critically, mounting the image can update atime on accessed files, potentially overwriting the exact evidence you are hunting. fls reads all four timestamps directly from the raw inode without touching the image.

   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 4

   Extract the file contents with icat

   Observation

   I noticed the fls body file recorded inode 4945 for /bin/bcab, which suggested using icat with that inode number to read the file's raw data blocks directly from the image without relying on a potentially absent directory entry.

   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 directory entry for /bin/bcab has been unlinked (deleted) by the attacker after planting the file, it will not appear in the mounted filesystem's directory tree even though the inode and data blocks are still present on disk. icat bypasses directory entries entirely and reads data blocks directly by inode number, so it recovers the file regardless of whether the directory entry exists. Using cp through a mount point fails silently for unlinked inodes.

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

   icat's syntax requires a numeric inode as the final argument, not a filesystem path. Passing a path string causes icat to report an error or interpret the argument incorrectly. The inode number 4945 comes from the fls body file output in the previous step - that is the correct argument to supply. If you need to convert a path to an inode number, run 'ifind -n /bin/bcab partition4.img' first.

   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 5

   Base64-decode the extracted content

   Observation

   I noticed the bcab file contained only alphanumeric characters with a trailing 'K' and a newline, a pattern consistent with base64 encoding, which suggested running base64 -d to recover the plaintext flag string.

   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.