DISKO 4 picoCTF 2026 Solution

Description

1. Step 1Decompress the image

   Observation

   The download is a .dd.gz, so the raw image is inside a gzip wrapper. fls and icat need a seekable file, not a compressed stream.

   Extract the raw disk image from the gzip archive.

   bash

   gunzip disko-4.dd.gz

   Copied!

   What didn't work first

   Tried: Trying to mount the .gz file directly with 'sudo mount -o loop disko-4.dd.gz /mnt' before decompressing.

   mount reads raw blocks and expects a filesystem signature at byte 0, where gzip has put a compressed stream instead. The kernel reports a wrong filesystem type or a missing superblock. Decompress first.

   Tried: Using 'zcat disko-4.dd.gz | fls -' or piping gunzip stdout directly into TSK tools.

   TSK tools like fls use lseek internally to jump between filesystem structures at arbitrary byte offsets. They require a seekable file, not a stream, so piping fails with 'unable to open image' or incorrect inode walks. Decompress to a real file first.

   Learn more

   A .dd file (named after the dd Unix utility) is a raw sector-by-sector copy of a disk or partition. Unlike archive formats, it preserves every byte including deleted data, slack space, and filesystem metadata. This makes it the standard format for digital forensics - it captures the disk's complete state at the moment of acquisition.

   gzip is a lossless compression format. gunzip file.gz decompresses and removes the .gz file, leaving the raw image. The resulting .dd file is often several gigabytes even for small disk images, because raw disk images include all sectors whether or not they contain data. Use ls -lh disko-4.dd to check the decompressed size.

   Tools for working with disk images include The Sleuth Kit (TSK) suite (mmls, fls, icat), Autopsy (a GUI frontend to TSK), and mount -o loop for read-only filesystem access. For CTF forensics, the TSK command-line tools are preferred for their scriptability.

2. Step 2List deleted files and find the inode

   Observation

   The flag file was deleted, so the ordinary directory tree will not list it. fls with -d walks the raw inode metadata and surfaces deallocated entries that still hold their block pointers.

   Use fls -r -d to enumerate deleted files, then grep for the flag filename to map it to its inode number. Alternatively, generate a mactime body file from fls output for full timeline context before picking the target inode.

   bash

   fls -r -d disko-4.dd | grep -i flag

   Copied!

   bash

   # Or generate a body file for timeline analysis:

   Copied!

   bash

   fls -m / disko-4.dd > body.txt

   Copied!

   bash

   # Validate the inode before carving:

   Copied!

   bash

   istat disko-4.dd <inode>

   Copied!

   Expected output

   r/r * 532021:	flag.txt

   What didn't work first

   Tried: Running 'fls -r disko-4.dd | grep -i flag' (without the -d flag) to look for deleted files.

   Without -d, fls traverses live directory entries, and this file's entry has been cleared, so the grep finds nothing: it exists only in the metadata layer. The flag tells fls to walk inode structures looking for deallocated inodes instead.

   Tried: Using 'strings disko-4.dd | grep picoCTF' to find the flag without going through TSK.

   strings looks for printable ASCII, and this file's content is a gzip blob with none. Recover the inode data with icat first, then decompress it.

   Learn more

   fls (file listing) is a TSK tool that lists files and directories from a filesystem image by reading its metadata structures directly - bypassing the OS. The -d flag shows only deleted files (those with a deallocated inode), and -r recurses into subdirectories. The output includes the inode number, which is needed for the next step.

   When a file is deleted in most filesystems (ext2/3/4, FAT, NTFS), the OS marks the inode as free and removes the directory entry, but does not zero out the data blocks. The file's data persists on disk until those blocks are reallocated for a new file. This is why forensic tools can recover deleted files - the data is still physically present, just invisible to the normal filesystem layer.

   The ext4 filesystem specifically marks inodes with a deletion time (dtime) when they are unlinked. fls -d finds inodes where the deletion time is set. On some filesystems (NTFS), the MFT (Master File Table) retains entries for deleted files until the MFT slot is reused, providing additional metadata like original file name and timestamps.

   Run istat disko-4.dd <inode> before carving to validate the recovery is worth attempting. istat shows the deletion timestamp, file size, and the list of direct/indirect block pointers. If the block pointers are zeroed (some kernels clear them on unlink) or pointing to obviously reallocated blocks, icat will return zeros or garbage and you should switch to file carving (foremost, scalpel) instead.

3. Step 3Recover the deleted file

   Observation

   fls gives the inode number, which means the inode and its block pointers survive. icat reads those blocks directly, so no carver is needed.

   Save the icat output to a file, then check its type. The recovered inode is itself a gzip-compressed file, so you must decompress it before you can read the flag.

   bash

   icat disko-4.dd <inode> > recovered.gz

   Copied!

   bash

   gunzip recovered.gz

   Copied!

   bash

   cat recovered

   Copied!

   What didn't work first

   Tried: Running 'icat disko-4.dd 532021 > recovered' and immediately catting the file without checking its type first.

   The recovered data is gzip-compressed, so printing it raw fills the terminal with binary. Run file on it, see the compression, rename and decompress before reading.

   Tried: Using 'foremost -i disko-4.dd -o carved/' or photorec to carve the deleted file instead of using the inode number.

   Carvers scan for magic bytes and earn their keep when the inode's block pointers are zeroed. Here the inode is intact and fls already gave you its number, so carving is extra work and tends to produce false-positive fragments. icat is faster and exact.

   Learn more

   icat (inode concatenate) is a TSK tool that reads the data blocks pointed to by an inode and outputs them to stdout. Even for deleted files where the directory entry is gone, the inode may still contain valid block pointers if the blocks have not been overwritten. Running icat disko-4.dd 532021 recovers the data of inode 532021 regardless of its deletion status.

   The reliability of recovery depends on what happened after deletion. If the disk was idle after the file was deleted (as in most CTF challenges), all original data blocks are intact. If the system continued to run and create files, some blocks may have been reallocated and overwritten. In that case, partial recovery is possible using file carving tools like foremost or photorec, which scan raw disk data for file format signatures (magic bytes).

   This technique is used in real digital forensics investigations to recover evidence after suspects attempt to delete it. Simply deleting files, even emptying the recycle bin, is insufficient to destroy evidence. Secure deletion needs an explicit overwrite of the data blocks (a single full pass is enough on modern drives; the multi-pass folklore about reading overwritten bits back with a microscope has never been demonstrated on real hardware), encryption whose key is then destroyed, or physical destruction of the platters.

   For more on the surrounding command-line forensic workflow, see the Linux CLI for CTF post.

Flag

Recovered via icat disko-4.dd 532021 > recovered.gz, then gunzip.