weirdSnake picoCTF 2024 Solution

Description

1. Step 1Recover the key

   Observation

   The download has no extension, and the challenge name points at Python. This is compiled bytecode, so unmarshal the code object and disassemble it with the dis module, then watch the LOAD_CONST sequence that builds the key character by character.

   A .pyc file is a small header followed by a marshalled code object, so read past the header before unmarshalling. Disassemble the result and scan for a sequence of LOAD_CONST ops that push single characters onto the stack, ending in BUILD_STRING. That sequence reconstructs key_str (in this challenge it builds out to t_Jo3). Convert it to a list of integers for the XOR step:

   python

   python3 -c "import dis, marshal; f = open('snake','rb'); f.read(16); dis.dis(marshal.load(f))" | less

   Copied!

   bash

   key_list = [ord(c) for c in 't_Jo3']

   Copied!

   What didn't work first

   Tried: Run uncompyle6 directly on the snake file expecting clean source output with the key visible as a string literal.

   uncompyle6 often fails on bytecode from versions it does not fully support, reporting an internal error or dropping exactly the constant-building section. dis works on the raw opcodes without trying to infer high-level structure, so the LOAD_CONST sequence stays visible whatever the Python version.

   Tried: Use the strings utility on the snake file to look for the key printed as a plain ASCII sequence.

   The key is built one character at a time by separate LOAD_CONST opcodes, so it never exists as a contiguous string on disk. strings only finds printable runs above a minimum length, and single characters scattered through bytecode never qualify. The disassembly is what shows them being assembled.

   Learn more

   Python source files (.py) are compiled to bytecode (.pyc) by the CPython interpreter before execution. Bytecode is a lower-level, platform-independent instruction set for the Python Virtual Machine: not machine code, but not source code either. It sits in the middle: harder to read than Python, but much easier to recover than compiled C or C++.

   Tools like uncompyle6, decompyle3, or pycdc can reconstruct Python source from bytecode with high fidelity. Python's built-in dis module disassembles bytecode into human-readable opcode mnemonics; useful when decompilers fail on unusual or obfuscated bytecode.

   • python3 -m dis snake does not work here: the module compiles its argument as source text, so a bytecode file raises a SyntaxError. Skip the 16-byte header and hand the marshalled code object to dis.dis instead, as in the command above.
   • uncompyle6 snake attempts full source reconstruction (install with pip install uncompyle6).
   • Strings built character-by-character show up as repeated LOAD_CONST 't', LOAD_CONST '_', ... followed by a BUILD_STRING N op that joins them.
2. Step 2Recreate the input list

   Observation

   The disassembly shows a BUILD_LIST preceded by a long run of LOAD_CONST instructions pushing integers. Those integers are the ciphertext the program XORs against the key.

   The bytecode stores the ciphertext integers in a list (input_list). Copy those numbers into your script.

   Learn more

   In Python bytecode, list literals are stored as a series of LOAD_CONST instructions (one per element) followed by a BUILD_LIST opcode. The disassembly makes these values directly visible - no decryption needed to extract the ciphertext list. This is a fundamental asymmetry in obfuscation via compilation: the data the program operates on must be present at runtime, so it is always recoverable from the bytecode.

   ord(c) converts a character to its ASCII integer value (e.g., ord('A') == 65). The key is stored as a string but used as a list of integers during XOR operations, so converting it with [ord(c) for c in key_str] produces the correct numeric representation.

   Recognizing that a program stores integers in a list and XORs them against a key is a pattern found constantly in CTF reversing challenges and in real malware - it is one of the simplest ways to obfuscate strings like API keys, C2 addresses, or flags without using a proper cipher.

3. Step 3XOR decrypt

   Observation

   A BINARY_XOR joins elements of the two lists, so this is repeating-key XOR. Apply the same XOR with itertools.cycle and the plaintext comes back.

   XOR each ciphertext byte with the cycling key. Watch out: zip(a, b) stops at the shorter sequence, so if you pass the raw key_list and it is shorter than input_list you silently lose the tail of the message. Use itertools.cycle to repeat the key. The Python for CTF guide covers more idioms like this.

   python

   from itertools import cycle
   result = ''.join(chr(a ^ b) for a, b in zip(input_list, cycle(key_list)))
   print(result)

   Copied!

   Expected output

   picoCTF{N0t_sO_coNfus1ng_sn@ke_30a...}

   What didn't work first

   Tried: Use zip(input_list, key_list) without itertools.cycle, then wonder why the decoded output is truncated and missing the end of the flag.

   zip stops at the shorter sequence, which is the five-character key. Only the first five bytes get decrypted and the rest is silently dropped. itertools.cycle turns the key into an endless repeating stream so zip runs the full length of the ciphertext.

   Tried: XOR the ciphertext integers directly against the key string characters without calling ord(), getting a TypeError and assuming the key extraction step was done incorrectly.

   Python's ^ works on integers, not characters, so convert the key string to code points first. A TypeError about int and str means that conversion was skipped, not that the key is wrong.

   Learn more

   XOR (exclusive OR) is the simplest symmetric cipher. XOR has a beautiful property: applying the same key twice returns the original value (m XOR k XOR k = m). This makes XOR decryption identical to encryption: just XOR the ciphertext with the same key and you recover the plaintext.

   When the key is shorter than the message, it is typically repeated cyclically; this is called a repeating-key XOR or Vigenere-like XOR. zip in Python pairs elements from two sequences and stops at the shorter one, which is the gotcha called out above. itertools.cycle(key_list) creates an infinitely repeating keystream so the zip stops at the ciphertext length instead.

   Repeating-key XOR was used in real cryptography before modern ciphers (the Vigenere cipher is a letter-based variant). It is broken by known-plaintext attacks (if you know any bytes of the plaintext, you immediately recover the corresponding key bytes) and by frequency analysis when the key is short relative to the message. AES in CTR mode is essentially XOR with a secure, non-repeating keystream; the security comes entirely from the quality of the keystream, not the XOR operation itself.

Flag

The decrypted string from the XOR routine is the final flag.