Writeup - Snek (LACTF 2023)
LACTF 2023 - Snek Writeup
- Type - rev
- Name - snek
- Points - 487
Description
1 | snek |
Writeup
The snek.py file provided was a oneliner that looked like below (with a 15,000 char payload):
1 | #!/usr/local/bin/python3 |
Running it showed the following output:
1 | $ python3 snek.py |
It seems that the code was running while the pickle library was in the process of loading this payload. Normally, you can set the pickle.loads equal to a variable and interact/view that variable afterwards, but this was not possible here. If you tried to exit the snake game early, it would throw an exception and the output variable would never capture the fully loaded pickle. Instead, I decided to go a different route and disassemble the pickle object directly using pickletools.
Pickletools Disassembly
I first wrote the raw bytes payload in snek.py to a file called snek.pickle, then ran python3 -m pickletools snek.pickle. This gave a large output (1000 lines), a preview of which can be seen below (full output here):
1 | 0: \x80 PROTO 5 |
The output consisted of printing out the pickle opcodes and values in the format line: rawopcode OPCODENAME opcodevalue. I luckily found a very good documentation source for pickle opcodes at docs.juliahub.com. Since the output was long and complicated, I decided to build my own interpreter that would correctly process each opcode, the stack, the memo list, etc. This would allow me to simulate the same behavior, but inspect opcode calls as they were being made.
My full interpreter can be downloaded here. It reads a file called instructions.txt, which is just the pickletools output with only OPCODENAME opcodevalue (no line: rawopcode). It also initializes a stack, where values (of type string, int, dict, function, class, etc.) are kept and processed, and a memo list, which is more of the long-term storage. I won’t go over all 31 opcodes I implemented, but rather some of the important ones.
MEMOIZE- the value at the top of the stack is copied into the memo list, where it can be accessed later on even if removed from the stack.GET- retrieve the item stored in the memo list at the index provided in opcodevalue.GLOBAL- a global variable (typically function) is provided in the opcode value as a string, and is pushed onto the stack (i.e. string'builtins str.join'is provided,stack.append(eval('str.join'))is run to push function onto the stack.STACK_GLOBAL- the top two stack items are popped and evaled likesecond.first, with new function being pushed onto stack again (i.e.'functools', 'partial'becomeseval('functools.partial')).REDUCE- this was the most import opcode as this is where functions were actually run with arguments. Each time this opcode is called, my interpreter prints out the stack, what’s being evaluated, and what the output is.- Strings were dynamically created using this strategy, with evals like
str.join('', ['p', 'a', 'r', 't', 'i', 'a', 'l'])to create'partial', etc.
- Strings were dynamically created using this strategy, with evals like
You will notice that there are 3 hard-coded parts in the implementation of this opcode where I manually set the value of some data. This is due to the fact that getting the representation of certain classes only works once, and it just prints out a null string afterwards. For example:
1 | b = reversed(b'abc') |
After dynamically creating a bunch of strings that turn into function calls, there are two large binary strings located in the text. The first one (larger binary of the two) is reversed and is actually a nested pickle object. It’s dynamically loaded and executed, and returns a large list of tuples and strings used in the game. The second binary string is ANDed with 255, changing only the last bit on some bytes.
At the end of the pickle loading, a single Python code object is created using the data from before. The second binary string is the binary code for this object, the tuples and strings from the first binary string become the consts and names for the code object, and the other stuff is placed onto the stack early on in execution. This code object is what actually ran the snek game, opening the way for part 2.
The resulting code object looks like this:
1 | code( |
Reversing the Code Object
Python CodeType objects can normally be placed into a PYC file (compiled Python file), which can in turn be transformed into Python source code using a tool like uncompyle6 (in Python) or pycdc (in C++). However, both tools didn’t work for me since uncompyle6 doesn’t like processing code after Python 3.8, and pycdc didn’t recognize FrozenSets or something idk. Therefore, I resorted to manual code decompilation using Python’s dis library.
1 | from types import CodeType |
After getting the disassembly from above, I outputted it to a text file and put it in my team’s thread. Since it was late, I went to bed, and a teammate had manually decompiled the code for me (thank you @crazyman). After their decompilation, I took some creative liberties and started renaming variables/fixing random inaccuracies I found/adding debug statements along the way until it functioned almost the same as snek.py. The main differences were it outputted the coordinates of the fruit I had eaten, and it only printed out the last frame and not each successive movement. This file can be found here.
Beating the Game
At this point, I could understand what the point of the game was and how to win. There were 10 levels of fruit; after eating one fruit, you move to the next level. For example, after eating your first fruit, all the fruit on the screen disappears and reappears as defined in the second FrozenSet. Once you’ve eaten a fruit from each of the 10 levels, a check is ran on the fruits you ate. If this check doesn’t match the key value 140447092963680462851258172325, then the game exits with a sad snek. If it DOES match, then you get the flag! The check is made by initializing total=0, then running ((total^1337)*(400)+(x*20 + y)) with each x and y coordinate of the fruit from each level.
This meant that we had to determine exactly which 1 of the 50 fruits from each of the 10 levels had to be eaten to achieve our key. Luckily, my teammate @sahuang was able to whip up a quick Python script that easily determined this based on the hard-coded fruit coordinates and the key provided. The code for the script can be found here. The output can be seen below:
1 | $ python3 find_path.py |
We had our path! I just needed to code a path that the snek would traverse to get the fruit at (11,0), then the fruit at (0,3), etc., without eating any other fruits on the way. I wrote up the script to do this using pwntools, and it worked great! Solve script found here, or below:
1 | from pwn import * |
Flag: lactf{h4h4_sn3k_g0_brrrrrrrr}