Timeline 1 picoCTF 2026 Solution

Description

1. Step 1

   Decompress the image

   Observation

   I noticed the challenge file is a .img.gz archive, which means the raw partition image is wrapped in a gzip container and cannot be parsed by any filesystem tool until it is extracted, so gunzip is the required first step.

   Extract the raw partition image from the gzip archive.

   bash

   gunzip partition4.img.gz

   Copied!

   What didn't work first

   Tried: Mounting the .gz file directly with sudo mount -o loop partition4.img.gz /mnt/disk before decompressing.

   mount will reject the gzip-compressed file with 'wrong fs type, bad option, bad superblock' because it sees a gzip header, not a filesystem signature. The raw partition image is buried inside the archive and must be extracted with gunzip first before any filesystem tool can parse it.

   Tried: Using tar -xzf partition4.img.gz instead of gunzip to decompress.

   tar expects a tar archive, not a bare gzip-compressed file, and will exit with 'This does not look like a tar archive'. A .img.gz file is a single file compressed with gzip - no tar container - so gunzip (or gzip -d) is the correct decompressor.

   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 2

   Build a filesystem timeline

   Observation

   I noticed this challenge is a direct sequel to Timeline-0 and involves a disk image, which suggested applying the same fls and mactime workflow to produce a MAC-timestamp-sorted CSV before trying to locate the flag.

   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!

   Expected output

   573417h13r_7h4n_7h3_1457_58527bb222

   What didn't work first

   Tried: Running fls without the -m flag to list files, then grepping for 'picoCTF' in the output to find the flag directly.

   fls without -m prints filename listings but not MAC timestamps, and the flag is not embedded in any filename or path in this challenge - it is encoded inside file content. The body file format produced by -m is required for mactime to parse and sort timestamps, which is the step that reveals the timestomped anomaly.

   Tried: Skipping mactime and grepping the body.txt output directly for suspicious filenames.

   The body file is pipe-delimited with raw epoch timestamps and is not human-readable without mactime's conversion. More importantly, the suspicious file (/etc/chat) has an unremarkable filename that blends in; the anomaly only becomes visible when mactime collapses all four identical MACB timestamps into a single row, which requires running mactime -b body.txt -d first.

   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 the key next move is not grepping for picoCTF (the flag does not appear in the timeline output as a filename or path), but filtering for entries where all four MACB timestamp types fire together - that pattern reveals timestomping. See the Volatility 3 guide for the in-memory equivalent of this workflow.

3. Step 3

   Spot the timestomped file

   Observation

   I noticed the challenge hint says the flag is hidden inside file content rather than a filename, which suggested the attacker used timestomping to camouflage the planted file and that grepping for 'macb' rows in the timeline CSV would expose the anomaly.

   Filter the timeline for entries where all four MACB timestamp slots fire at exactly the same instant - that pattern (macb appearing as a single combined event on one row) betrays deliberate timestamp manipulation. Among the results, .ash_history (the ash/Alpine shell history file) stands out: reading it via icat with its inode number reveals the only recorded command was power off, which is the anti-forensic action the hints reference. Next, look for other files with timestamps clustered near that same moment; /etc/chat appears there and is a second red flag because it is not a standard Linux config file.

   bash

   grep 'macb' timeline.csv | tail -n 30

   Copied!

   What didn't work first

   Tried: Grepping the timeline for 'picoCTF' to find the flag directly without filtering for macb entries.

   The flag does not appear as a filename or path in the timeline CSV - it is base64-encoded inside the content of /etc/chat. grep 'picoCTF' on the timeline returns no results, giving the false impression that this approach or disk image is wrong. The macb filter is the necessary pivot to identify which inode to examine with icat.

   Tried: Filtering for 'macb' in the timeline but focusing only on .ash_history and treating its 'power off' content as the flag.

   The .ash_history file reveals the anti-forensic action (powering off to hide evidence) but does not contain the flag - its content is just the shell command 'power off'. The actual flag is in /etc/chat (inode 32716), a separate timestomped entry in the timeline. Stopping at .ash_history means missing the planted file that holds the encoded flag.

   Learn more

   What timestomping looks like in the output. The mactime CSV has a column for which timestamp type fired: m (modified), a (accessed), c (changed / inode-changed), b (born / created). When an attacker uses a tool like touch -t or debugfs to set all four timestamps to the same value, mactime collapses them into a single row flagged macb. Legitimate files almost never have all four timestamps identical to the nanosecond on a live system, so this pattern is a reliable indicator of tampering.

   In this image, /etc/chat (inode 32716) shows the macb pattern. The name /etc/chat is not a standard Linux system file, which is a second red flag: a planted file hiding in a directory that looks like a normal config location.

4. Step 4

   Extract the file content with icat and base64-decode

   Observation

   I noticed the macb-filtered timeline revealed /etc/chat at inode 32716 as a non-standard Linux file with all four timestamps identical, which suggested its data blocks held the planted flag and that icat followed by base64 -d was the right extraction path.

   icat reads the data blocks pointed to by an inode and writes them to stdout, bypassing the directory layer entirely. First use icat with the .ash_history inode to confirm the only recorded command is power off - the deliberate anti-forensic action. Then extract /etc/chat (inode 32716), which holds a base64-encoded string; pipe through base64 -d to recover the flag inner content, then wrap it as instructed.

   bash

   icat partition4.img <ash_history_inode>

   Copied!

   bash

   icat partition4.img 32716

   Copied!

   bash

   icat partition4.img 32716 | base64 -d

   Copied!

   What didn't work first

   Tried: Mounting the image and using cat /mnt/disk/etc/chat instead of icat to read the file content.

   Mounting works for allocated files, but timestomped files may have inconsistent directory entry state, and a mounted path gives you no control over which inode you are reading. More critically, if the file were deleted (common in timestomping scenarios), cat via a mount would find nothing at all. icat reads the data blocks by inode number directly from the raw image, making it reliable regardless of directory layer state.

   Tried: Piping the icat output through base64 -e (encode) instead of base64 -d (decode).

   The file already contains a base64-encoded string. Running base64 -e on it would double-encode the content, producing a second layer of base64 that decodes to the original base64 string, not the flag. The -d flag is required to decode the stored base64 back into the plaintext flag inner content.

   Learn more

   Why icat instead of cat. Once you have the inode number from the timeline, icat is the correct tool: it bypasses the directory layer and reads the raw data blocks associated with that inode directly from the partition image. cat would require the file to be accessible via a mounted path, which may not work cleanly for timestomped or partially deleted entries.

   The raw output of icat partition4.img 32716 is a base64-encoded string (NTczNDE3aDEzcl83aDRuXzdoM18xNDU3XzU4NTI3YmIyMjIK). Piping that through base64 -d yields the flag inner content: 573417h13r_7h4n_7h3_1457_58527bb222. Wrap that in picoCTF{} as the challenge instructs to get the complete flag.

Flag

The flag is hidden in the content of /etc/chat (inode 32716), a timestomped file detectable by its identical MACB timestamps. Extract with icat and base64-decode to get the inner value.