Quantum Scrambler picoCTF 2025 Solution

Description

1. Step 1Understand the scramble routine

   Observation

   The source is provided, and the scramble function only pops and appends sublists without touching any byte value. Nothing is encrypted; undo the reordering and the bytes are back.

   The provided code repeatedly pops elements and appends prefixes, but never modifies the underlying data. It simply reorders sublists, meaning the plaintext bytes are still present.

   Learn more

   Security through obscurity is the antipattern this challenge demonstrates. The "Quantum Scrambler" name sounds sophisticated, but examining the source reveals it is purely a permutation - a reordering of data with no cryptographic key, no mixing of values, and no information loss. Every original byte is present in the output; only their arrangement changed.

   True encryption transforms data in a way that is computationally infeasible to reverse without the key. Permutation-only schemes fail this test because the number of possible arrangements is finite (factorial of input length), and more importantly, in this challenge the permutation algorithm is deterministic and provided in source. Anyone who reads quantum_scrambler.py can reverse it instantly.

   This is a common mistake in amateur cryptography: building elaborate pipelines of bit shifts, rotations, and shuffles that look complex but lack true randomness or key material. Claude Shannon's formal definition of confusion (substitution that hides the relationship between key and ciphertext) and diffusion (spreading plaintext influence across many ciphertext bits) are the properties that distinguish real ciphers from shuffles like this one.

2. Step 2Iterate through the nested lists

   Observation

   The output is a deeply nested Python list, because each step appends a growing copy of the earlier elements as a sublist. Only the non-list positions of each top-level sublist are original bytes, so descending recursively would just collect duplicates.

   Parse the saved result with ast.literal_eval (the server prints a banner before the data, so take only the final line via splitlines()[-1]). The scramble function builds each new element by appending a slice of all prior elements as a nested sublist, so the full tree contains many duplicate copies of earlier hex values. A naive recursive DFS that descends into every sublist will therefore emit each value multiple times, producing a corrupted result. The correct approach is to iterate only one level deep: for each top-level sublist, collect items that are strings and skip items that are lists (those are the embedded copies). This visits every original byte exactly once in the order the flag was written.

   python

   # Use ast.literal_eval, NOT eval (server output is untrusted):
   python3 - <<'PY'
   import ast
   with open('result') as f:
       data = ast.literal_eval(f.read().strip().splitlines()[-1])
   out = []
   for sublist in data:
       for item in sublist:
           if not isinstance(item, list):
               out.append(item)
   print(''.join(chr(int(c, 16)) for c in out))
   PY

   Copied!

   Expected output

   picoCTF{python_is_weird9ece...}

   What didn't work first

   Tried: Use a recursive DFS to collect all strings from every level of the nested list.

   Each step embeds a snapshot of the earlier elements, so a recursive walk revisits those copies and emits every value several times. Because each element embeds a copy of every element before it, the duplication compounds exponentially: a flag of a couple of dozen characters flattens into thousands, with the early bytes repeating over and over. Stay one level deep and skip list items instead of descending, and each byte is visited once.

   Tried: Call eval() instead of ast.literal_eval() to parse the server output.

   eval() runs arbitrary expressions, not just literals, so anything injected into the server response executes. This particular output is benign, but ast.literal_eval parses only literals and is strictly safer. eval() on untrusted input is a vulnerability, not a parsing strategy.

   Learn more

   Using Python's eval() to parse the output is a quick CTF trick because the server's output is a valid Python literal (a nested list of strings). In production code, eval is dangerous - it executes arbitrary Python, so it should never be used on untrusted input. The safe alternative is ast.literal_eval(), which parses only Python literals (strings, numbers, lists, dicts, tuples) without executing arbitrary expressions.

   The scramble function contains the line A[i-1].append(A[:i-2]), which splices a copy of all previously processed elements into the current sublist as a nested list. This means each iteration buries a growing snapshot of earlier data deeper in the structure. A recursive DFS would follow those nested copies and re-emit every hex byte it finds inside them, and because each snapshot itself contains earlier snapshots the count grows exponentially rather than linearly, turning a couple of dozen real bytes into thousands of decoded characters. Recognizing that the original data lives exactly at the non-list positions of each top-level sublist, and skipping the nested list items entirely, is the key insight.

   In real reverse engineering, you often encounter proprietary serialization formats or obfuscated data structures that must be parsed before the payload can be analyzed. Fluency with Python for rapid data structure manipulation - list comprehensions, slicing, zip, map - is invaluable for quickly prototyping parsers and decoders during CTF competitions.

3. Step 3Decode to ASCII

   Observation

   Every collected element is a 0x-prefixed hex string in the ASCII range. Convert each to an integer and then a character.

   The same chr(int(c, 16)) line at the bottom of the script is the hex-to-ASCII conversion - each chunk like '0x70' becomes 'p'. Joining them prints the picoCTF flag; nothing further to do.

   Learn more

   Hexadecimal representation of bytes is ubiquitous in low-level security work. Each byte (0 to 255) maps to a two-digit hex value (0x00 to 0xff). The int(chunk[2:], 16) idiom strips the 0x prefix and converts the remaining hex digits to an integer in base 16. chr() then maps the integer to its Unicode character; for values 32 to 126 (printable ASCII) this is the familiar character set.

   The inverse operations are equally important: hex(ord('A')) gives 0x41, and '{:02x}'.format(65) gives '41'. These conversions appear constantly in cryptography, binary exploitation, and network protocol analysis. Python's bytes type and its .hex() / bytes.fromhex() methods are often more ergonomic for bulk conversions than character-by-character loops.

   The lesson here is that adding visual complexity to data (wrapping bytes in 0x-prefixed hex strings and nesting them in lists) does not add security. Any transformation that is purely cosmetic and reversible without a key provides zero cryptographic protection. Recognizing "fake encryption" quickly is a valuable CTF skill that also translates to evaluating real-world security claims about data "obfuscation" products.

Flag

The key insight is that the scramble only permutes bytes; the flag values survive intact at the non-list positions of each top-level sublist. Skip nested list items to avoid duplicates from embedded copies.