findme picoCTF 2023 Solution

Description

1. Step 1Capture the response
   After submitting the test credentials, the POST /login response includes two id query parameters in the redirect URL (302 Location header). Highlight them in the Network tab's Headers pane and copy each id value.
   Learn more

   Browser DevTools Network tab records every HTTP request and response made by the page, including XHR/Fetch calls triggered by form submissions. With "Preserve log" enabled, the history persists across page navigations, which is critical here because the server redirects after login and would otherwise clear the log.

   Concretely, in this challenge the login form submits a POST /login with username=test&password=test!. The server returns 302 Found with a Location header that includes a query string like ?id=cGlj...VzX2Fs&id=bF90aG...YmJhZTlhfQ==. Both id values are in the redirect URL itself. The browser will follow the redirect automatically, so without "Preserve log" the intermediate 302 disappears and you only see the final landing page.

   Clicking on the POST /login request in the Network tab reveals four sub-panels: Headers (where the Location header carrying the ids lives), Payload (POST body you sent), Preview, and Response. The id parameters in this challenge are not hidden form fields and not in the response body; they are query parameters appended to the redirect URL.

   Real-world relevance: APIs sometimes return internal identifiers, session tokens, or other sensitive strings in response bodies or redirect URLs that developers intended only for internal use. Tools like Burp Suite automate the capture and replay of these requests for deeper analysis. HTTP redirects (status codes 301, 302, 307, 308) are handled automatically by browsers, meaning the intermediate responses are invisible unless you specifically preserve them.

2. Step 2Decode and concatenate
   Base64-decode each id separately, then join the strings to form the complete picoCTF flag.
   Learn more

   Splitting a secret across multiple fields is a simple obfuscation technique. Each id value decodes to a fragment of the flag; concatenating them in order reconstructs the full string. This mirrors how real applications sometimes split tokens across multiple cookies or headers - a pattern that can leak partial secrets even when individual components look innocuous.

   To decode Base64 in the terminal: echo 'cGlj...' | base64 --decode. In Python: import base64; base64.b64decode('cGlj...').decode(). CyberChef's "From Base64" operation handles it visually. Remember that Base64 strings always have a length that is a multiple of 4; padding = characters fill gaps when the input length isn't divisible by 3.

   The broader lesson: never treat Base64 as a security measure. It is transparent encoding, not encryption. Treat any Base64 data found during reconnaissance as plaintext that simply needs one decoding step.

   Recognizing Base64 on sight is a useful habit. Base64 strings use the characters A-Z, a-z, 0-9, +, and /, and are padded with = to make the total length a multiple of 4. URL-safe Base64 replaces + with - and / with _ to avoid conflicts with URL syntax. If you see a long string of alphanumerics ending in one or two = characters, Base64 is almost always the right first guess.

   Splitting secrets across multiple fields or responses is a simple obfuscation pattern that can also appear in malware command-and-control (C2) communications. A C2 server might return a multi-part command spread across multiple HTTP responses, each looking innocuous on its own, to evade pattern-based network detection. Reassembling and decoding these fragments is a standard malware analysis task. The skills developed in this challenge - capturing all responses, extracting and joining fragments, then decoding - map directly to real incident response work.

Alternate Solution

Flag

The fragments must be concatenated before submitting.