Collaborative Development picoCTF 2024 Solution

Description

1. Step 1List every branch

   Observation

   The description talks about a team working on separate features, which means the flag is split across Git branches rather than sitting in one commit.

   git branch -a lists local and remote-tracking branches. In this repo all four branches are local, and each feature/part-* branch holds one segment of the flag, so you can check them out directly.

   bash

   git branch -a

   Copied!

   Sample output:

     feature/part-1
     feature/part-2
     feature/part-3
   * main

   What didn't work first

   Tried: Run git log --all --oneline hoping to see every branch's commits in one list

   git log --all does reach every ref, but it interleaves the commits without grouping them by branch. You get hashes and messages and still cannot tell which branches exist or how many segments there are. git branch -a lists the names directly, which makes the feature/part-* convention obvious.

   Tried: Run git branch without -a and assume the listed branches are everything

   This drop-in happens to carry all its branches locally, so the plain listing is complete here. That is a property of this archive, not a rule: clone a real repo and unmerged work lives only under remotes/origin/, invisible without -a. Reaching for -a by reflex costs nothing and stops you concluding that main is all there is.

   Learn more

   Git branches are lightweight pointers to commits, enabling parallel lines of development. The -a flag shows both local branches and remote-tracking branches (remotes/origin/...).

   The naming convention feature/part-1 follows GitFlow, where feature branches are prefixed with feature/. Other common conventions: feat/, issue numbers (issue-123), or author initials. Consistent naming makes intent obvious at a glance.

   In security research, inspecting every branch can reveal information that was accidentally committed to a feature branch and never merged. Credentials, API keys, and partial implementations sometimes hide in abandoned branches. Tools like trufflehog and git-secrets automate branch-wide secret scanning.

2. Step 2Inspect each feature branch

   Observation

   The listing shows feature/part-1, feature/part-2, and feature/part-3. Each branch holds one consecutive segment of flag.py, to be read in that order.

   Checkout each branch and read flag.py. Each branch's flag.py defines or prints one segment of the flag; concatenate the three segments in order (part-1, part-2, part-3) to assemble the full flag.

   bash

   git checkout feature/part-1 && cat flag.py

   Copied!

   Expected output

   print("Printing the flag...")
   print("picoCTF{t3@mw0rk_", end='')

   Repeat for feature/part-2 and feature/part-3. Each adds one more print() line holding the next segment, and the three segments joined in order give the full flag.

   What didn't work first

   Tried: Run git show feature/part-1 instead of checking out the branch first

   git show on a branch name prints that branch's tip commit and its diff, not the file as it stands. A raw patch is awkward to read when you only want the string. Either check the branch out and cat the file, or ask for the blob explicitly with git show feature/part-1:flag.py.

   Tried: Try to read flag.py while still on main without switching branches

   On main, flag.py is a single line, print("Printing the flag..."), with no segment attached; the segments live only on the feature branches. Check out the feature branch first so the working tree reflects its version.

   Learn more

   git checkout <branch> switches your working tree to a different branch, updating all tracked files to match that branch's latest commit. In modern Git (2.23+), the more explicit git switch <branch> is preferred for branch switching while git checkout is reserved for file restoration.

   Splitting a secret across branches demonstrates a real security concern: data spread across feature branches is easy to miss compared to a single committed secret. Automated secret scanners need to check every branch, not just the default branch.

   Reading the branches one at a time avoids merge conflicts entirely. If you do try to merge them, expect conflicts where parts overlap or modify the same line of flag.py. Resolving by reading is faster than resolving by merging.

3. Step 3Optional: merge for a single view

   Observation

   Checking out each branch works but takes three passes. Merging the branches into main assembles the whole file in one place, at the cost of resolving conflicts by hand.

   Merge the branches into main one at a time, in part order. The first merge fast-forwards cleanly; part-2 and part-3 each conflict on flag.py because every branch appends to the same region. Resolve by deleting the conflict markers and keeping both print() lines in part order, then run the file to print the assembled flag.

   bash

   git checkout main && git merge feature/part-1

   Copied!

   bash

   git merge feature/part-2   # conflict in flag.py: keep both lines, part-1 first

   Copied!

   bash

   git merge feature/part-3   # same again, then python3 flag.py

   Copied!

   What didn't work first

   Tried: Merge all three branches in one command: git merge feature/part-1 feature/part-2 feature/part-3

   That asks for an octopus merge, and the octopus strategy refuses to resolve content conflicts. Git fast-forwards to part-1, hits a conflict in flag.py on part-2, and bails out with 'Should not be doing an octopus', leaving main exactly where it started. Merge them one at a time so you get a normal conflict you can actually edit.

   Tried: Resolving each conflict by picking one side (git checkout --ours or --theirs) to make the merge finish quickly

   Taking one side throws the other segment away, so flag.py ends up printing a third of the flag. The conflict here is not a disagreement to arbitrate; both hunks belong, in part order. Edit the file by hand, drop the <<<<<<< markers, and keep every print() line.

   Learn more

   git merge integrates changes from one or more branches into the current branch. When multiple branches modify the same file in the same location, Git creates a merge conflict - it marks the conflicting sections and requires a human to choose how to resolve them. This is a fundamental part of collaborative development.

   Git uses a three-way merge algorithm: it finds the common ancestor commit of both branches and compares each branch's changes against that ancestor. Changes that don't overlap are merged automatically; overlapping changes become conflicts. Understanding this algorithm helps predict when conflicts will occur and how to structure commits to minimize them.

   In production workflows, merges are often done via pull requests on platforms like GitHub or GitLab, which add code review, CI/CD checks, and discussion threads before the merge happens. The --no-ff flag forces a merge commit even when a fast-forward is possible, preserving branch history in the commit graph for auditing purposes.

Flag

Concatenate the outputs from each feature/part-* branch (or resolve the merged file) to reveal the full flag above.