This is a walk-through of how I solved the KEYGENME reverse engineering challenge at the Google CTF 2018 qualifier.
I bet you can't reverse this algorithm!
The challenge contained an executable binary called main
and a server
This is a walk-through of how I solved the KEYGENME reverse engineering challenge at the Google CTF 2018 qualifier.
I bet you can't reverse this algorithm!
The challenge contained an executable binary called main
and a server
The challenge binary spawned 4000 worker processes, each process listened on a separate udp port (hence the name) from localhost:6000 to localhost:9999. The parent process listened on localhost:5999. The processes used these ports to send direct messages to each other in synchronous manner.
Six message types were used among the processes. Message type 3, 4, and 5 were used to implement some kind of algorithm that computed something very inefficiently. The goal of the challenge was to find out what this algorithm
run go.sh and check your flag...
According to the go.sh file the engineTest binary could be run with four arguments called cp, ip, /dev/stdin (dv for short), and op. The cp, ip and op files were provided, they contained some kind of binary data, probably a bunch of 64bit numbers based on their hexdump.
We permutate the opcode of python2.7, and use it to encrypt the flag.. Try to recover it!
The provided pyc file could be parsed with the marshal module, yielding a code object representing a python module. Examining its co_{name,argcount,...} attributes showed that it had 3 names ('rotor', 'encrypt', 'decrypt') and four