SQL injection is a red herring as every input is escaped properly.
So it should be a mt_rand “vulnerability”.
If we register a new account and call multiple reset calls with our new user then we get a lot of tokens. These tokens should be “unxored” with our IPv4 address, so we can the clean mt_rand() results.
Then if we can predict the new mt_rand() result and send in to verify as admin then we will get the admin password.
The only problem is that there were a lot of players and had to get consecutive mt_rand values. So we used Keep-Alive which solved this problem (we used the same thread, so the internal state of Mersenne Twister is not changes).
Mersenne Twister usually can be calculated backwards, but the problem is PHP throws out the LSB bit, so this won’t work.
On the other hand bruteforcing the seed is difficult as the we dont have the first outputs of the MT generator.
But it turned out that untwister (https://github.com/altf4/untwister) on one of my teammate’s barebone server (with 32 CPUs) can bruteforce the seed in 20 minutes… :)
So I generated the next value and called verify with that value and logged in as admin with the new admin password.
This challenge was solved by one of my teammates, gym and me and the write up was written by gym.
In this challange we were provided with a flag.puzzle data file and a x86_64 binary called encrypt. After loading the binary into IDA we can see that it “encrypts” a file with a XOR key (received as command line argument) but in an unusual manner. First, it splits the input into 20 equally sized blocks and each block is XORed with the same byte. In the case of the flag file these blocks are 57 bytes long (except the last one).
First, we decoded the first block with all the possible keys and printed the output to check if there was any plain text output or known file header. Scrolling throught the results we spot a PNG header thus we realised that the encoded file was a PNG image.
After this, we made a regex for all the possible PNG headers and brute forced all blocks and searched the output for these headers. This way we managed to decrypt the first, second and the last blocks.
The next step was to find a structure in the png image bytes that we could use to verify if the brute forced data is correct. In the PNG file format before each scanline there is a filter byte with the possible values 0-4. The PNG header told us that the image size is 912x912 and color mode is 0x3 with the bit depth of 1. This meant that a scanline is 114 (912/8) bytes long so each 115th byte (starting with the first) had to be less than four (it turned out fast it should be always the value 0).
So we bruteforced the following blocks inflated the compressed data and checked against the above mentioned property. This way we succesfully decoded the 4th block, however the rest of the block resulted with many false positives.
So we dumped all the uncompressed image data that passed the check into bitmap images and manually selected the correct one (we could automatize this, but it could be checked very easily manually too as the QR code is started to take form line by line).