Crack the Gate 1 picoMini by CMU-Africa Solution

Description

1. Step 1

   Find and decode the hidden comment

   Observation

   I noticed the HTML source contained a comment with garbled but space-separated text that preserved word boundaries and letter frequency, which are hallmarks of ROT13 and suggested decoding it to reveal a developer note.

   View the page source and locate the ROT13-encoded HTML comment. Decode it with tr or an online ROT13 tool. The comment reveals a custom HTTP header that bypasses authentication.

   bash

   echo 'ABGR: Wnpx - grzcbenel olcnff: hfr urnqre K-Qri-Npprff: lrf' | tr 'A-Za-z' 'N-ZA-Mn-za-m'

   Copied!

   Expected output

   NOTE: Jack - temporary bypass: use header X-Dev-Access: yes

   What didn't work first

   Tried: Try decoding the comment with base64 instead of ROT13.

   Running 'echo ABGR... | base64 -d' throws an invalid character error because ROT13 output is not valid base64. The giveaway that it is ROT13 is that the ciphertext preserves word boundaries and has the right letter frequency for English - base64 encodes to a dense stream of mixed alphanumeric characters with no spaces.

   Tried: Copy the encoded comment and paste it into a Caesar cipher brute-forcer trying all 25 shifts.

   Most Caesar brute-force tools output all 25 shifts at once and leave you to eyeball the right one, which works but is slower than targeting shift-13 directly. More critically, some tools operate only on uppercase or lowercase and silently drop the other case, mangling the decoded output and hiding the flag phrase.

   Learn more

   ROT13 (rotate 13) is a simple substitution cipher that shifts each letter forward 13 positions in the alphabet. Because the alphabet has 26 letters, applying ROT13 twice returns the original text - encoding and decoding use the same operation. It is not a security mechanism; it is used to obscure text from casual reading (like spoiler tags on forums).

   HTML comments (<!-- ... -->) are sent to every browser that requests the page - they are visible to anyone who uses "View Source" or browser developer tools. Developers sometimes leave backdoor notes, API keys, internal URLs, or debug instructions in comments, assuming they are invisible because they don't render visually. This is a very common finding in bug bounty hunting.

   The tr command translates (replaces) characters. The pattern tr 'A-Za-z' 'N-ZA-Mn-za-m' maps each letter to its ROT13 equivalent - A becomes N, B becomes O, and so on, wrapping around at Z. This is a standard one-liner for quick ROT13 decoding in the terminal.

2. Step 2

   Send the login request with the bypass header

   Observation

   I noticed the decoded ROT13 comment explicitly named a custom header X-Dev-Access: yes as a temporary bypass, which suggested sending a POST login request with that header added via curl to skip authentication.

   The decoded message says to include the header 'X-Dev-Access: yes'. Send the login POST request with this header added - authentication is bypassed and the flag is returned.

   bash

   curl -X POST https://<host>/login -H 'X-Dev-Access: yes' -d 'email=ctf-player@picoctf.org&password=anything'

   Copied!

   What didn't work first

   Tried: Try sending the bypass header as a GET request instead of POST.

   A GET request to the /login endpoint typically returns the login form HTML rather than processing credentials, so the server ignores the bypass header and the flag is never returned. The decoded comment specifies a login action which corresponds to the POST method that submits the form.

   Tried: Add the custom header using browser developer tools Network tab instead of curl.

   Browser developer tools let you inspect and replay requests, but they do not allow adding arbitrary custom headers to a new form submission - the browser enforces CORS and form submission rules that strip unknown headers. You need a command-line tool like curl or a proxy like Burp Suite that gives full control over every header sent.

   Learn more

   Custom HTTP headers like X-Dev-Access are non-standard headers that applications sometimes use for internal communication, feature flags, or - as in this case - poorly implemented developer shortcuts. HTTP headers can be set to any arbitrary value by the client, so any authentication logic that trusts a client-supplied header without cryptographic verification is bypassed trivially.

   This class of vulnerability appears in real-world applications as "debug modes," "admin bypass headers," or internal IP allowlisting that trusts X-Forwarded-For. The lesson is that the server can never trust any input from the client - headers, cookies, POST body, and URL parameters are all fully controlled by the person making the request.

   curl -H adds a custom header to the request. -X POST changes the HTTP method, and -d sends URL-encoded form data in the request body. These three flags together replicate what a browser sends when you click a login button, while adding the extra bypass header the server is secretly checking for.

Flag

Per-instance flag confirmed from multiple independent sources. Different users received different hex suffixes: ..., 83812a02. Format prefix is consistent across all instances.