Description

Can you find the flag in this disk image?

Setup

Download and decompress the disk image.

Mount the image and explore the git repository inside.

gunzip disk.img.gz

sudo mount -o loop disk.img /mnt/disk

Solution

Step 1Decompress and quick strings check
Extract the disk image, then run strings as a fast pre-check for an obvious flag.
```
gunzip disk.img.gz
```
```
strings disk.img | grep picoCTF
```
Learn more
Running strings disk.img | grep picoCTF is always the first triage step for a disk image challenge. If the flag is stored in plaintext anywhere in the image — inside a file, in git object data, in filesystem metadata, or even in unallocated slack space — this one-liner finds it instantly without requiring mounting or filesystem parsing.
strings looks for sequences of at least 4 consecutive printable ASCII characters by default. You can lower the threshold with -n 3 or raise it with -n 8. For UTF-16 strings (common in Windows artifacts) use strings -e l. The tool ignores file structure entirely, which means it finds text even in compressed sections, inside binary headers, and in deleted-but-not-overwritten file content.
Step 2Detect partition layout and mount
Use mmls to find the correct partition offset, then mount it.
```
mmls disk.img
```
```
sudo mount -o loop,offset=$((512*<start_sector>)) disk.img /mnt/disk
```
```
ls /mnt/disk
```
Learn more
mmls is part of The Sleuth Kit (TSK), a widely used open-source digital forensics toolkit. It reads MBR and GPT partition tables and displays each partition's slot number, type, start sector, end sector, length, and description. This is faster and more forensically reliable than fdisk -l, which is designed for live disks rather than raw image files.
Disk images often contain multiple partitions: a small EFI system partition, a swap partition, and the main Linux ext4 data partition. You need to mount the correct one. The data partition is typically the largest and is usually type 0x83 (Linux) in MBR layouts or has a matching GUID in GPT layouts. mmls output includes a Description column that helps identify it.
After mounting, the filesystem is accessible under the mount point just like any other directory. You can use standard file tools (ls, find, cat) to explore it. Mounting with -o ro (read-only) is best practice to avoid accidentally modifying the evidence.
Step 3Copy the git repository
Locate and copy the .git directory to a writable path.
```
find /mnt/disk -name '.git' -type d
```
```
cp -r /mnt/disk/<repo_path> /tmp/repo
```
```
cd /tmp/repo
```
Learn more
The .git directory is the heart of any git repository. It contains all objects (blobs, trees, commits, tags), all refs (branches, tags, HEAD), the stash, notes, reflog, and configuration. An entire repository's history is fully recoverable from just this directory — the working tree files are simply checked-out copies of objects already in .git/objects/.
Copying the repository to a writable location is necessary because git commands write to the repository (updating the reflog, for example) and the mounted filesystem may be read-only or owned by root. Working in /tmp avoids permission issues. The copy is an exact duplicate — all objects, refs, and configs are preserved, so all git forensics commands work identically on the copy.
Step 4Comprehensive git history search
The flag may be in commit patches, a deleted branch, stash entry, annotated tag, git note, reflog, or a dangling unreachable object. Search all eight locations.
```
git log --all -p | grep -A2 picoCTF
```
```
git branch -a
```
```
git stash list
```
```
git tag -l && git show $(git tag -l | head -1)
```
```
git notes list
```
```
git reflog
```
```
git fsck --unreachable 2>&1 | grep blob
```
```
git fsck --lost-found && cat .git/lost-found/other/*
```
Learn more
Git's content-addressed storage means nothing is truly deleted until git gc prunes unreachable objects. A developer who commits a secret and then removes it in a later commit has only hidden it from casual inspection — the blob containing the secret remains as a dangling object in .git/objects/. The same is true for force-pushed-over commits (visible in the reflog), dropped stash entries, and deleted branches (still in the reflog until expiry).
git fsck --unreachable lists every object in the object store that cannot be reached by following any ref. These are the objects that git gc would delete. They include old versions of files, commits on deleted branches, and stash entries that were dropped. git fsck --lost-found goes further and writes them into .git/lost-found/other/ (blobs) and .git/lost-found/commit/ (commits) so they can be read with standard tools.
This challenge may hide the flag in any of these locations, requiring you to check all of them systematically. In real security investigations, tools like truffleHog, gitleaks, and git-secrets automate this search across all git history locations and flag any strings matching credential patterns.
Step 5Extract the flag
Read content from whichever location held the flag.
```
git show <commit>
```
```
git cat-file -p <blob-hash>
```
Learn more
git cat-file -p <hash> prints the raw content of any git object. For a blob (file snapshot) it prints the file content. For a commit it prints the commit message, author, timestamp, and tree reference. For a tree it lists the directory entries. The -p flag means "pretty-print" — it automatically detects the object type and formats accordingly.
Once you identify a suspicious hash from git fsck, git reflog, or git stash list, git cat-file -p <hash> reveals its content without needing to check out any branch or restore any working tree files. This is the most direct way to inspect raw git objects and is an essential technique for both forensics and debugging git corruption issues.

Flag

picoCTF{...}

The flag is hidden somewhere in the git history. It may be in a deleted branch, stash, tag, note, reflog entry, or unreachable dangling object.

Forensics Git 1

Description

Solution

Flag

Useful tools for Forensics

More Forensics

Binary Digits

DISKO 4

Forensics Git 0