WebDecode picoCTF 2024 Solution

Description

1. Step 1Inspect the element

   Observation

   The prompt tells you to use the web inspector, so the flag is not on the rendered page. It is somewhere in the raw DOM, likely a non-standard attribute.

   The challenge prompt says use the web inspector. Open DevTools (F12), focus the Elements panel, and scan the source for unusual attributes. The About section carries a non-standard attribute named notify_true holding a Base64 blob.

   Learn more

   Custom HTML attributes (anything not in the HTML spec) appear in the page source and DevTools but are invisible to casual readers. Developers occasionally hide data this way as a quick way to embed values without displaying them. Scanning DevTools for unusual attribute names is a standard reconnaissance step on any web challenge.

   HTML data attributes (the official way to embed custom data) use the prefix data-, e.g., data-user-id="42". Non-prefixed custom attributes like notify_true still work in browsers but are technically invalid HTML5. Either way, any value stored there is fully accessible to anyone who views the page source: not a secure storage location.

   • Right-click any element and choose Inspect to jump directly to that element in the DevTools Elements panel.
   • Use Ctrl+F inside the Elements panel to search for notify or base64 patterns across the full DOM.
   • document.querySelector('[notify_true]').getAttribute('notify_true') in the Console tab also extracts the value programmatically.
2. Step 2Decode the blob

   Observation

   The notify_true attribute holds a long alphanumeric string whose length is a multiple of four. That is Base64, so decode it.

   Pipe the attribute value into base64 -d. Quick sanity check first: the first eight characters cGljb0NU decode to picoCT, so any picoCTF flag base64-encodes to a string starting with that prefix.

   bash

   echo cGljb0NU | base64 -d

   Copied!

   bash

   echo cGljb0NURnt3ZWJfc3VjYzNzc2Z1bGx5X2QzYzBkZWRfMDJjZGNiNTl9 | base64 -d

   Copied!

   Expected output

   picoCTF{web_succ3ssfully_d3c0ded_...}

   If base64 -d errors with "invalid input", the blob probably has stray newlines or whitespace from the copy. Strip them first:

   echo "<blob>" | tr -d '\n ' | base64 -d

   What didn't work first

   Tried: Trying to decode the blob using base64 -D (uppercase D) on Linux

   On Linux, base64 uses -d for decode; the uppercase -D flag is a macOS-ism, and GNU coreutils rejects it with an invalid option error naming - 'D' instead of decoding anything. Use base64 -d (lowercase) on Linux and base64 -D on macOS.

   Tried: Pasting the blob into a hex-to-ASCII converter instead of a Base64 decoder

   The value contains characters like G and j that are not hex digits, so a hex decoder errors out immediately. The alphabet and the length being a multiple of four both say Base64.

   Learn more

   Base64 is an encoding scheme that represents binary data using only 64 ASCII-safe characters (A-Z, a-z, 0-9, +, /). It was originally designed to safely transmit binary data over channels that only support text, such as email. It is not encryption: there is no key, and anyone who sees the encoded string can decode it instantly. See the CTF encodings reference, the Burp Suite Decoder shortcut for one-keystroke stacked decodings, and the web bug patterns post for more places this shows up.

   You can recognize base64 by its characteristics: the character set is limited to alphanumerics plus + and /, the string length is always a multiple of 4 (padded with = signs), and the encoded length is about 33% larger than the original.

   Common places developers accidentally leave base64-encoded secrets: HTML attributes, JavaScript variables, URL parameters, HTTP response headers, and API responses. Security researchers routinely grep for base64-like strings when reviewing web application source code.

Flag

Decoding the notify_true attribute reveals the flag above.