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.

bash

gunzip disk.img.gz

bash

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

Solution

Walk me through it

Step 1Decompress and quick strings check
Extract the disk image, then run strings as a fast pre-check for an obvious flag.
bash
gunzip disk.img.gz
bash
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.
bash
mmls disk.img
bash
sudo mount -o loop,offset=$((512*<start_sector>)) disk.img /mnt/disk
bash
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.
bash
find /mnt/disk -name '.git' -type d
bash
cp -r /mnt/disk/<repo_path> /tmp/repo
bash
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
Walk every hiding place. Don't concatenate lost-found blobs - cat them per-file with a header so you can identify the source. Iterate every tag rather than peeking at only the first one.
bash
git log --all -p | grep -A2 picoCTF
bash
git branch -a
bash
git stash list && git stash show -p
bash
for tag in $(git tag -l); do echo "=== $tag ==="; git show "$tag"; done
bash
for c in $(git log --all --format=%H); do git notes show "$c" 2>/dev/null; done
bash
git reflog
bash
git fsck --unreachable 2>&1 | grep blob
bash
git fsck --lost-found
bash
grep -rB1 picoCTF .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.
bash
git show <commit>
bash
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.
For more on the surrounding shell workflow, see Linux CLI for CTF.

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.

How to prevent this

Deleted branches, dropped stashes, and amended commits all leave objects behind. Do not rely on deletion to remove secrets.

Pre-commit secret scanning (gitleaks, trufflehog, detect-secrets) is the only intervention that prevents the bug. Deletion after the fact does not help; the blob is already in .git/objects/.
For accidental commits: rotate the secret first, then rewrite history (git filter-repo) and force-push. Notify anyone who has cloned the repo to re-clone fresh; old clones still hold the secret.
On servers, run git gc --prune=now --aggressive after history rewrites to actually drop unreachable objects. On GitHub/GitLab, the "remove sensitive data" flow is more reliable than gc.

Forensics Git 1 picoCTF 2026 Solution

Description

Solution

Flag

How to prevent this

Useful tools for Forensics

Related reading

What to try next

Commitment Issues

Blame Game

Time Machine

MY GIT

Collaborative Development

Bithug