Description
Someone's commits seems to be preventing the program from working. Who is it?
Download the challenge zip, unzip it locally, then change into the drop-in directory.
wget https://artifacts.picoctf.net/c_titan/74/challenge.zip && \
unzip challenge.zip && \
cd drop-in/Solution
Walk me through itgit log over the entire repo. You need to focus on message.py to pinpoint the culprit.- Step 1List repository historyRun git log --oneline --decorate to scan the commit subjects. Look for messages that don't match real engineering work (vague performance claims, generic refactors, anything dropped in by 'the intern').bash
git log --oneline --decorateSample output (truncated):
a3f1d20 (HEAD -> main) update README 2b7c84e fix typo in greeting 9e44c11 optimize file size of prod code 4d11baf refactor message printer 12c0abb initial commit
The "optimize file size of prod code" subject is the suspicious one. Real engineering changes name what changed, not vague performance claims.
Learn more
git logis your window into a repository's entire history. Every commit records a snapshot of the project along with metadata: who made the change (author name + email), when, and a message describing why.The flags here do specific things:
--onelinecollapses each commit to a single line (hash + message).--decorateshows branch and tag labels so you can see where HEAD points.
In CTFs, repos are often seeded with a long history to hide a single suspicious commit. Scanning with
--onelinelets you spot unusual messages fast. - Step 2Focus on the suspicious fileRun git log message.py to narrow the search to the file that broke the flag printer. You're interested in the commit introducing the bogus optimization.bash
git log message.pyLearn more
Passing a filename to
git logfilters the output to only commits that touched that specific file. This is one of git's most useful forensic tools - instead of sifting through every commit in the repo, you see only the history relevant to one path.This technique is called file-level blame tracing and is commonly used in real incident response: if a bug was introduced into a specific module,
git log path/to/file.pyimmediately surfaces who touched it and when.You can go even further with
git log -p message.pyto see the actual diff for every change to that file inline. - Step 3Blame the culpritOnce you've identified the offending commit, take note of the author line; that name is the flag. You can double-check by running git show <COMMIT_HASH>.bash
git show <COMMIT_HASH>Learn more
git show <hash>prints everything about a single commit: the author, date, full message, and a unified diff showing exactly what lines were added or removed. It's the most direct way to inspect what a specific commit actually did.The author field records who originally wrote the change. This is distinct from the committer; in workflows involving rebases or patches, these can be different people. In this challenge the author is who you're after.
git blame message.pyannotates every line with the commit hash and author that last changed it. Combined with grep, it gives you an alternative path to the same answer:git blame message.py | grep <suspicious_line>prints the author of just the line you care about.
Related guides
Linux Command Line Basics for CTF
This challenge uses git and grep in the terminal. The Linux CLI guide covers these commands and the other shell tools that appear across General Skills challenges.
Flag
picoCTF{@sk_th3_1nt3rn_ea3...}
The flag is the author of the suspicious commit (the "optimize file size of prod code" change in message.py). It appears in the git log message.py output once you examine the file history.
Frequently asked questions
Common questions about the Blame Game solution and the techniques it uses.
Why doesn't plain git log reveal the flag?
git log over the whole repo shows every commit across every file, so the malicious change is buried in noise. The challenge only makes sense when you scope the log to message.py, the file whose optimization comment introduced the bug. Filtering by path is what separates this challenge from Time Machine, which was solvable from the unfiltered log.
What is the difference between git log <file>, git show, and git blame here?
git log message.py lists every commit that touched the file so you can spot the suspicious one. git show <hash> prints that one commit's author, date, message, and diff so you can verify it. git blame message.py annotates each line with the commit and author that last touched it, which is useful if you care about a single line rather than the file's full history. In this challenge the author of the suspicious commit is the flag.
Why is the commit author the flag and not the committer?
In git the author is whoever originally wrote the change, while the committer is whoever applied it (they can differ after rebases or patch imports). picoCTF sets the author to the flag value on the planted commit, so reading the Author line of the malicious commit gives you picoCTF{@sk_th3_1nt3rn_ea3...} directly.