DISKO 1 picoGym Exclusive Solution

Description

1. Step 1

   Decompress and identify the disk image

   Observation

   I noticed the challenge provides a .dd.gz file, which indicates a gzip-compressed raw disk image; the .gz extension made it clear that decompression with gunzip was required before any disk forensics tool could read the raw sector data.

   Run gunzip disko-1.dd.gz to produce the raw .dd image. Running file disko-1.dd reports a DOS/MBR boot sector with a FAT32 filesystem - a straightforward layout with no hidden partitions.

   bash

   gunzip disko-1.dd.gz

   Copied!

   bash

   file disko-1.dd

   Copied!

   Expected output

   disko-1.dd: DOS/MBR boot sector; partition 1 : ID=0xb, start-CHS (0x0,1,1), end-CHS (0x3ff,63,32), startsector 2048, 204800 sectors, extended partition table (last)

   What didn't work first

   Tried: Trying to mount the image directly with mount disko-1.dd /mnt to browse files before decompressing

   The .dd.gz file is still gzip-compressed, so mount sees a gzip stream instead of a FAT32 partition table and returns 'wrong fs type' or 'invalid argument'. Decompression with gunzip must come first to expose the raw sector data that mount and all other disk tools expect.

   Tried: Using fdisk -l disko-1.dd.gz to inspect partition layout before gunzip

   fdisk reads the file as a raw byte stream and immediately encounters the gzip magic bytes (0x1f 0x8b) instead of an MBR signature (0x55 0xAA at offset 510). It reports 'GPT PMBR size mismatch' or no valid partition table found. Running file after gunzip on the actual .dd file is the correct step.

   Learn more

   Disk images are bit-for-bit copies of storage media stored as regular files. The .dd format is a raw binary dump produced by the dd utility (or forensic equivalents like dcfldd). Compressing disk images with gzip is standard practice because raw images often contain large regions of zero bytes that compress dramatically. The gunzip command decompresses in place, replacing the .gz archive with the original file.

   The file command identifies file formats by reading magic bytes - a fixed byte signature at the start of the file that identifies its type, independent of the filename extension. For disk images, file reports the partition table type (MBR or GPT) and the filesystem of the first partition. Knowing the filesystem type (FAT32, ext4, NTFS, etc.) tells you which forensic tools can parse it and what kind of metadata structures to expect.

2. Step 2

   Search for the flag with strings

   Observation

   I noticed the challenge description says the flag is stored as a plain string inside the FAT32 filesystem, which suggested that strings piped through grep -i pico would locate it directly in the raw image without needing to mount the disk or use more complex forensic tooling.

   Run strings on the raw disk image and pipe through grep -i pico. The flag is stored as a plain ASCII string directly inside the filesystem and is visible immediately - no mounting or filesystem tools needed.

   bash

   strings disko-1.dd | grep -i pico

   Copied!

   What didn't work first

   Tried: Running strings disko-1.dd | grep picoCTF (case-sensitive, no -i flag)

   If the flag is embedded in a filesystem metadata field or directory entry with mixed-case or uppercase letters, the case-sensitive grep silently drops it and produces no output. The -i flag is essential because FAT32 stores filenames and attributes in ways that may alter casing. The challenge description confirms the flag is a plain string, but its exact case in the binary is not guaranteed.

   Tried: Mounting the image and using find /mnt -type f -exec grep -r pico {} ; to locate the flag as a file

   This approach assumes the flag is stored inside a named file, but in this challenge the flag is written directly into the disk image as raw bytes - possibly in a file's data area, slack space, or metadata - and is not necessarily accessible as a readable file via a normal mount. The strings pipe finds any printable sequence anywhere in the image, which is faster and does not require root permissions for mount.

   Learn more

   The strings command scans a binary file for sequences of printable ASCII characters of a minimum length (default 4). It works directly on raw disk images without mounting, making it a fast first-pass tool in forensics. Any file content, filesystem metadata, directory entries, or deleted fragments that contain readable text appear in the output.

   In a real forensic investigation, strings alone is insufficient because it provides no context about which file contained the text or its location on disk. For deeper analysis, The Sleuth Kit tools - fls to list files by inode, icat to extract a file by inode number, and fsstat for filesystem statistics - give complete visibility into the file structure. For DISKO 1, the flag is embedded as a plain string with no obfuscation, so strings | grep is all that is needed.

   The -i flag to grep makes the search case-insensitive. Always use it when searching for pico because some challenges embed flags in all-caps metadata or filenames that picoCTF alone would miss.

Flag

The flag lives as a plain string in the FAT32 image. `strings disko-1.dd | grep -i pico` finds it on the first try.