What made this challenge interesting#

The visible repository tree was basically useless. That was the trap. The real artifact was not the README.md in the repo. The real artifact was the whole GitHub surface around it:

• commits
• refs
• comments
• events
• forks

That changed the challenge from “find the flag in the repo” to “figure out which GitHub evidence is trustworthy.”

Step 1: Confirm that the visible repo is too small#

The first pass was very simple:

1
curl -L --silent https://api.github.com/repos/tamuctf/phantom/contents
2
curl -L --silent https://api.github.com/repos/tamuctf/phantom/commits

The main observations were:

• the challenge pointed to https://github.com/tamuctf/phantom
• the repo only exposed a tiny README.md
• the default branch only showed one visible commit

So the public tree alone was clearly not the answer.

Step 2: Expand the evidence surface#

Once I treated GitHub as the forensic artifact, I started checking everything public that GitHub exposes:

1
curl -L --silent https://api.github.com/repos/tamuctf/phantom/issues
2
curl -L --silent https://api.github.com/repos/tamuctf/phantom/comments
3
curl -L --silent https://api.github.com/repos/tamuctf/phantom/pulls
4
curl -L --silent https://api.github.com/repos/tamuctf/phantom/events
5
curl -L --silent https://api.github.com/repos/tamuctf/phantom/git/refs

This produced one very tempting flag-looking string:

1
gigem{u_find_it_bro_bye_bye}

But I rejected it for a simple reason: it came from a participant comment, not from the author.

WARNING

This challenge had noisy evidence on purpose. A string that looks like a flag is not enough if the source is weak.

Step 3: Follow author-controlled signals#

The event feed was the turning point:

1
curl -L --silent 'https://api.github.com/repos/tamuctf/phantom/events?per_page=100'
2
curl -L --silent 'https://api.github.com/orgs/tamuctf/events?per_page=100'

From there, I found that the author account cobradev4 had created a private fork before the public solve noise started. That strongly suggested hidden history still existed somewhere.

The most important clue was a hidden commit reference:

1
b365313472870cbf887a42a7be75df741b60c8d3

So I fetched that commit directly:

1
curl -L --silent \
2
  https://api.github.com/repos/tamuctf/phantom/commits/b365313472870cbf887a42a7be75df741b60c8d3

That returned a full commit object, even though it was not reachable from the public branch tips.

The key details were:

1
author: Noah Mustoe <62711423+cobradev4@users.noreply.github.com>
2
date: 2026-03-16T02:02:46Z
3
message: Add flag

And the patch itself contained the flag.

Why this was the right flag#

I trusted this artifact because it was:

• author-created
• dated before public player contamination
• clearly labeled with Add flag
• recoverable from a hidden commit object, which matched the challenge idea perfectly

That was much stronger evidence than a participant saying “this one is real” or “this one is fake.”

Concept map#

1
flowchart TD
2
    A["Prompt points to tamuctf/phantom"] --> B["Visible repo looks empty"]
3
    B --> C["Treat GitHub metadata as forensic surface"]
4
    C --> D["Check comments, events, refs, forks"]
5
    D --> E["See fake-looking flag in participant comment"]
6
    E --> F["Reject low-trust evidence"]
7
    D --> G["Find author-controlled private fork activity"]
8
    G --> H["Recover hidden commit reference"]
9
    H --> I["Fetch hidden commit by SHA"]
10
    I --> J["Patch contains real flag"]

Flag

gigem{917hu8_f02k5_423_v32y_1n7323571n9_1d60b3}

What changed from the first challenge#

This time, the public history looked even cleaner:

• the public repo only had the Initial commit
• there was no easy full hidden SHA to grab immediately
• I had to prove that hidden commit objects existed before I could recover them

That made the solve feel much more methodical.

Step 1: Confirm the public state#

I started by verifying what was normally reachable:

1
git clone https://github.com/tamuctf/phantom2 repo
2
cd repo
3
git log --oneline --all

Only one commit appeared publicly:

1
454b12bba923297b4af5582a49cd8a3e20986ea1

So if the flag existed in Git history, it had to be somewhere outside the normal branch view.

Step 2: Build a short-SHA oracle#

Direct high-rate queries against the normal GitHub endpoints got throttled, so the cleaner path was raw.githubusercontent.com.

The key idea was:

1
https://raw.githubusercontent.com/tamuctf/phantom2/<prefix>/README.md

Behavior:

• 200 means the short prefix resolves to a reachable commit where README.md exists
• 404 means no such resolution
• prefixes shorter than 4 hex chars do not resolve

That gave me a very usable existence oracle.

Step 3: Enumerate 4-hex prefixes#

I scanned all 0000 to ffff prefixes and found five valid ones:

1
432c
2
454b
3
b36f
4
d3ca
5
dd21

Two were already known public/reachable values, which meant the other prefixes were the interesting ones.

Step 4: Expand hidden prefixes to full SHAs#

For each hidden prefix, I extended one nibble at a time:

1. try prefix + [0..f]
2. keep the only nibble that returns 200
3. repeat until the SHA reaches 40 hex characters

That recovered the hidden SHAs, including:

1
d3cab66d23265b36ecd8cd410554bdfc603e3416

Then I fetched the content at each hidden commit:

1
curl -L "https://raw.githubusercontent.com/tamuctf/phantom2/<sha>/README.md"

The winning one was d3cab66..., because its README.md contained the flag.

Step 5: Confirm with commit metadata#

I still wanted one more layer of proof, so I checked the commit metadata and patch. That confirmed:

• the message was Add flag (if you comment on this commit, you will be banned)
• the modified file was README.md
• the patch contained the same flag string

That was enough to treat it as the final answer.

IMPORTANT

The smart part of this challenge is that it was not really about brute force. It was about turning GitHub’s object-resolution behavior into a clean oracle.

Concept map#

1
flowchart TD
2
    A["Prompt points to tamuctf/phantom2"] --> B["Public history shows only Initial commit"]
3
    B --> C["Need hidden object discovery"]
4
    C --> D["Use raw.githubusercontent short-SHA resolution as oracle"]
5
    D --> E["Enumerate all 4-hex prefixes"]
6
    E --> F["Find valid prefixes"]
7
    F --> G["Expand hidden prefixes nibble by nibble"]
8
    G --> H["Fetch README.md at each hidden SHA"]
9
    H --> I["d3cab66... contains the flag"]

Flag

gigem{57up1d_917hu8_3v3n7_4p1_a8f943}

What made this one approachable#

The binary was not stripped and still had DWARF debug info. That saved a lot of time.

From the first recon pass, I could recover:

• struct layouts
• handler names
• global symbols like g_channels, g_auth, and g_ops

That made the exploit path much easier to reason about.

Step 1: Reconnaissance#

The first pass was the usual survey:

1
file military-system
2
checksec file military-system
3
nm -C military-system
4
llvm-dwarfdump --debug-info military-system
5
strings -tx military-system | less

The important facts were:

• aarch64
• PIE, full RELRO, NX, canary
• dynamic glibc binary
• debug symbols and DWARF still present

That immediately told me I should spend more time understanding the program state than fighting blind disassembly.

Step 2: Find the stale metadata bug#

The core bug chain came from channel drafts.

Simplified logic looked like this:

1
if (channel->draft) {
2
    free(channel->draft);
3
}
4

5
channel->open = 0;

But the program did not clear:

• channel->draft
• channel->draft_size

So after close_channel, the program still trusted stale draft metadata in:

• view_status
• edit_draft

That gave me:

1. an information leak
2. a write primitive on freed memory

Step 3: Leak heap and PIE#

The closed-channel status output already gave the exact values I needed:

1
[STATUS] last_draft=0x55000218e0
2
[STATUS] diagnostic_hook=0x55000017a0

From there I computed:

1
pie_base         = diagnostic_hook - 0x17a0
2
g_ops            = pie_base + 0x20020
3
transmit_report  = pie_base + 0x1274
4
encoded_fd       = g_ops ^ (last_draft >> 12)

So the status screen was effectively leaking both the heap side and the code side of the exploit.

Step 4: Poison tcache and overwrite the hook#

The exploit plan became very direct:

1. open two channels
2. queue same-sized drafts
3. close both channels so the chunks are freed
4. leak last_draft and diagnostic_hook
5. use stale edit_draft to poison the freed chunk’s fd
6. allocate twice until a chunk overlaps g_ops
7. overwrite status_hook with transmit_report
8. trigger menu option 5

The important idea is that I did not try to satisfy the g_auth clearance logic. I just skipped it by jumping into the flag-reading routine through another path.

Step 5: Trigger the indirect call#

The final trigger was simple. Once status_hook pointed to transmit_report, menu option 5 became my flag path:

1
Slot: [PATRIOT-7] Transmitting sealed report:
2
gigem{st4le_dr4ft_tcache_auth_bypass}

That completed the chain:

• stale pointer after free
• heap leak
• PIE leak
• safe-link-aware tcache poison
• function-pointer overwrite
• auth bypass

Why the exploit works#

I like this one because every step is really a trust failure:

1. the program trusted metadata after free
2. it trusted a stale pointer for status output
3. it trusted a stale pointer for editing
4. it trusted a global callback pointer
5. it assumed only the “authorized” menu path could reach transmit_report

Once the first assumption broke, the rest followed quite naturally.

Concept map#

1
flowchart TD
2
    A["Open channels and queue drafts"] --> B["Close channel frees draft"]
3
    B --> C["draft pointer and draft_size stay stale"]
4
    C --> D["View status leaks heap and hook pointer"]
5
    C --> E["Edit draft writes into freed chunk"]
6
    D --> F["Recover heap base and PIE base"]
7
    F --> G["Compute safe-linked fd for &g_ops"]
8
    E --> H["Poison tcache freelist"]
9
    G --> H
10
    H --> I["Allocate over g_ops"]
11
    I --> J["Overwrite status_hook with transmit_report"]
12
    J --> K["Trigger menu option 5"]
13
    K --> L["Bypass clearance gate and print flag"]

Flag

gigem{st4le_dr4ft_tcache_auth_bypass}