MatchTheRegex picoCTF 2023 Solution

Description

1. Step 1

   Derive the pattern

   Observation

   I noticed the challenge is a login form that validates input against a hidden pattern, which suggested the regex itself would be embedded in the client-side source since any browser-executed logic is readable by the user.

   Searching the page source reveals a comment with the regex ^p.....F!?, which matches a literal p, then exactly 5 of any character, then F, then an optional !. That's 7 to 8 characters total. picoCTF (7 chars) and picoCTF! (8 chars) both fit.

   What didn't work first

   Tried: Opening the Elements panel in DevTools instead of View Page Source to look for the regex.

   The Elements panel shows the live DOM after JavaScript has run and may not display HTML comments the same way. View Page Source (Ctrl+U or right-click) shows the raw HTML exactly as the server sent it, including developer comments that contain hints like the regex pattern.

   Tried: Trying to guess the password without reading the source, entering common strings like 'password' or 'admin'.

   Random guessing is ineffective because the regex constrains the input precisely. The pattern is hidden in the source code as an HTML comment, so the reliable approach is always to read the page source first and find the validation logic before attempting any input.

   Learn more

   Regular expressions (regex) are patterns that describe sets of strings. In the pattern ^p.....F!?, each meta-character has a specific meaning: ^ anchors the match to the start of the string; each . matches any single character; F matches the literal letter F; and !? makes the exclamation mark optional (zero or one occurrences). Count carefully: p + 5 dots + F + optional ! = 7 or 8 characters. Note also that the regex is case-sensitive by default, so the literal p and F mean lowercase p and uppercase F. picoCTF matches; picoctf does not.

   This challenge illustrates a critical security mistake: client-side validation. When the regex check runs in JavaScript in the browser, any user can read the source and reverse-engineer the required input. The server should always re-validate input server-side and never expose the validation logic, or the answer, to the client. Paste the literal pattern ^p.....F!? into our Regex Tester and try picoCTF and picoCTF! against it to confirm the match before submitting.

   Finding validation logic in HTML comments or JavaScript is a standard recon step in web CTFs. Always right-click → View Page Source and search for comments (<!--), TODO, password, or regex. Browser DevTools also expose minified JavaScript that can be pretty-printed and searched.

   Client-side validation implemented in JavaScript has a second weakness beyond readability: it can be bypassed entirely by sending the HTTP request directly, skipping the browser. Tools like curl or Burp Suite's Repeater allow you to craft POST requests with any body content and submit them straight to the server endpoint, bypassing all JavaScript checks. If the server doesn't independently validate the input, any client-side restriction is meaningless.

   Regex itself can be a source of security vulnerabilities. ReDoS (Regular Expression Denial of Service) occurs when a server-side regex with catastrophic backtracking is given specially crafted input that causes exponential evaluation time. For example, the pattern (a+)+ applied to a string of repeated 'a' characters followed by a non-matching character causes the regex engine to explore an exponential number of possibilities. A single malicious HTTP request can pin a CPU core indefinitely. OWASP tracks this as a DoS vulnerability and recommends using timeout wrappers or non-backtracking regex engines for user-supplied patterns.

2. Step 2

   Submit picoCTF!

   Observation

   I noticed the regex pattern ^p.....F!? requires a literal p, exactly 5 arbitrary characters, a literal F, and an optional !, which meant picoCTF (7 chars) and picoCTF! (8 chars) are the natural candidates given the challenge name itself fits the structure.

   Entering picoCTF! passes the regex and displays the flag. picoCTF (without the bang) also matches because !? is optional.

   What didn't work first

   Tried: Submitting the raw regex pattern itself, like '^p.....F!?', as the input.

   The regex is the validation rule, not the answer. The form expects a string that satisfies the pattern, not the pattern itself. The correct input is a string like 'picoCTF' or 'picoCTF!' that the regex would match.

   Tried: Submitting 'picoctf' (all lowercase) because it starts with p and has the right length.

   Regex patterns are case-sensitive by default. The pattern requires an uppercase F as the 7th character, and 'picoctf' ends with lowercase f, so it fails the match. The correct input must use 'picoCTF' with uppercase C, T, and F to satisfy the literal character requirements.

   Learn more

   Once you understand the regex, satisfying it is trivial. The pattern ^p.....F!? accepts "picoCTF" (7 characters: p-i-c-o-C-T-F) with an optional trailing !. The string picoCTF! matches: ^p (starts with p), five dots filled by i,c,o,C,T, then F, then ! satisfying !?.

   This kind of challenge teaches regex literacy - a universally useful skill. Regex is used in log analysis, input sanitization, search tools (grep -E), programming language parsers, and security tools like YARA rules and Snort/Suricata signatures. Understanding regex lets you both write better validation and spot weak validation that can be bypassed.

   Regex-based input validation is also frequently incomplete in ways that enable injection attacks. For example, a regex that checks for valid email format might not prevent SQL injection if the email is then embedded directly in a query. The correct pattern is to validate format with regex and sanitize separately for the target context - they are distinct concerns. A string can pass format validation and still be dangerous to pass to a database query, shell command, or HTML renderer.

   When auditing web applications for weak validation, browser DevTools' Console tab lets you execute JavaScript directly against the page's context. You can call validation functions with custom inputs (validate('test')), inspect the result, and iterate quickly without modifying any files. This is faster than editing source and reloading for testing regex behavior or understanding what a validation function actually accepts.

Flag

Any string that satisfies the secret regex unlocks the flag; picoCTF! works fine.