findme picoCTF 2023 Solution

Description

1. Step 1Capture the response

   Observation

   The login form fires a POST followed by 302 redirects, so the server is putting data in the Location header before the final page loads. Only the Network tab with Preserve log enabled will show those intermediate responses.

   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.

   What didn't work first

   Tried: Checking the Response or Preview sub-panel of the POST /login request for the id values.

   The id parameters are not in the response body; they ride in the Location header of the 302. Check the Preview and Response tabs first and you find them empty and conclude the server sent nothing. The Location header lives in the Headers sub-panel, under Response Headers.

   Tried: Submitting the form without first enabling Preserve log in the Network tab.

   Without Preserve log, the browser clears the Network panel as it follows the 302, so the intermediate POST vanishes and only the final landing request remains. Tick Preserve log before clicking login and every intermediate response stays in the panel.

   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

   Observation

   The second id parameter ends in Base64 padding while the first does not, and neither fragment decodes to a whole flag on its own: the first has the opening picoCTF{ but no closing brace, the second has the brace but no prefix. The flag is split across two encoded chunks, to be decoded and then joined.

   Base64-decode each id separately, then join the strings to form the complete picoCTF flag.

   What didn't work first

   Tried: Joining the two raw Base64 strings and decoding the result in one go, instead of decoding each id on its own.

   Here the first fragment happens to encode a whole number of 3-byte groups, so it ends without any padding and joining the two raw Base64 strings decodes cleanly to the whole flag. That is luck, not a rule: if the first fragment had ended in one or two equals signs, concatenating the encoded text would produce garbage after the padding. Decoding each fragment on its own and joining the plaintext works in both cases, so it is the habit worth keeping.

   Tried: Treating the decoded output of just the first id value as the complete flag.

   The first fragment decodes to something starting picoCTF{ and ending mid-word, with no closing brace. A partial decode looks like corruption, which invites re-encoding or trying another decoder. The split is deliberate: decode both fragments and join them for the full string.

   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.

Flag

The fragments must be concatenated before submitting.