Description
A full disk image hides the flag in a text file inside /root/. Use Sleuth Kit command-line tools (mmls, fls, icat) to find the file by inode and extract its contents.
Decompress the image and use mmls disk.flag.img to find the largest partition's start sector.
Run fls -r -o <offset> disk.flag.img to list all files recursively, then grep for flag to find the relevant inode.
Use icat -o <offset> disk.flag.img <inode> to extract the file and read the flag.
gunzip disk.flag.img.gzmmls disk.flag.imgfls -r -o <OFFSET> disk.flag.img | grep flagicat -o <OFFSET> disk.flag.img <INODE>Solution
Want to try it yourself first?
The guided walkthrough reveals hints one step at a time.
Step 1
Find the flag file with Sleuth KitObservationI noticed the challenge provides a full disk image rather than a simple filesystem archive, which suggested a partition table sits at sector 0 and the actual filesystem starts at an offset; mmls is the correct tool to read that offset before fls can list the files recursively.Runmmls disk.flag.imgto find the largest partition's start sector. Use that as the offset forfls -r -o <offset> disk.flag.imgto list all files. Search the output forflagto find the inode numbers of the interesting files.bashmmls disk.flag.imgbashfls -r -o <OFFSET> disk.flag.img | grep flagWhat didn't work first
Tried: Running
fls disk.flag.img | grep flagwithout the -o offset flagWithout -o, fls tries to read the filesystem starting at sector 0, which is the Master Boot Record, not a valid filesystem. It will error with 'Cannot determine file system type' or return no results. The correct offset (the partition start sector shown by mmls) must be passed with -o so fls reads the actual ext4 or FAT partition.
Tried: Using
lsorfindafter mounting the raw image directly withmount disk.flag.img /mntMounting without specifying the partition offset will fail because the image starts with a partition table, not a filesystem. You need
mount -o loop,offset=$((sector * 512)) disk.flag.img /mntwith the correct byte offset. Even then, icat is preferred for forensic work because mount may update access timestamps and modify the image.Learn more
The Sleuth Kit is a collection of open-source command-line tools for forensic analysis.
mmlsreads the partition table,flslists filesystem entries (including deleted files), andicatextracts a file by its inode. All three are preinstalled on the picoCTF web shell.A disk image is a sector-by-sector copy of a storage device. It captures not just the visible files but also filesystem metadata, slack space, and deleted file remnants. Working with an image rather than the live device preserves evidence integrity and allows repeated analysis.
The
flsoutput may show two entries for the flag - one could be a deleted version. Try both inode numbers withicatto see which one contains the flag text.Step 2
Extract the flag file with icatObservationI noticed the fls output returned an inode number for the flag text file inside /root/, which suggested using icat with that inode and the same partition offset to pull the file's raw bytes directly without needing to mount the image.Runicat -o <offset> disk.flag.img <inode>to extract the file. The output contains the flag directly. If the file appears garbled, it may be UTF-16 encoded - try the other inode first, or pipe throughstrings.bashicat -o <OFFSET> disk.flag.img <INODE>bashicat -o <OFFSET> disk.flag.img <INODE> | stringsExpected output
picoCTF{by73_5urf3r_3497...}What didn't work first
Tried: Running icat with the inode from the deleted file entry instead of the live one
When fls shows two results for the flag file, one is the live entry and one is a deleted remnant (marked with an asterisk). Using the deleted inode may return garbled or empty data if those blocks were partially reused. Try the inode without the asterisk first, which corresponds to the current live file.
Tried: Using
caton the mounted image path instead of icatIf you mount the partition and cat the file, you may get a raw byte stream that looks like garbled text if the file is UTF-16 encoded. icat piped through strings handles this more cleanly by filtering non-printable bytes. More importantly, cat via a mount updates the file's access time and is not forensically sound.
Learn more
icat(inode cat) extracts the data blocks of a file given its inode number, writing the raw bytes to stdout. This works even on deleted files whose directory entries have been removed, as long as the data blocks haven't been overwritten. The-oflag specifies the partition offset in sectors as returned bymmls.If the file is encoded as UTF-16 (two bytes per character), the raw output will look like every character has a null byte between it. Piping through
stringsfilters out non-printable bytes and shows the readable flag text.
Interactive tools
- Hex ViewerView text or raw hex bytes as a xxd-style hex dump with byte offset, hex columns, and ASCII sidebar. Highlights printable characters and null bytes.
- File Magic IdentifierIdentify file types from magic numbers. Paste hex bytes or drop a file to detect PNG, JPEG, ZIP, PDF, ELF, PCAP, SQLite, and dozens of other formats.
- Strings ExtractorPull printable text from any binary, library, or image. ASCII and UTF-16 detection, configurable minimum length, flag-like highlight, no command line needed.
Flag
Reveal flag
picoCTF{by73_5urf3r_3497...}
Even without Autopsy, you could mount the image read-only and inspect the same path via standard Linux utilities.