- Event: starctf2018
- Category: crypto
- Points: 606/625
- Solves: 14/13
This is a writeup for 2 very similar tasks named
The second one is a harder version, but required knowledge of cryptography concepts is the same. The difference is only that it involves more logical thinking.
Reverse engineering ssss.py
There are AES, HMAC, sha256 and Argon2 in the code but it is not as complicated as it seems to be. Only AES is crucial here, the rest isn’t important.
dorecv send the data.
If a secret value (
self.k ) is not set, the data is sent to the user as is.
When this value is set, the message is encrypted using AES 128 in counter mode (CTR).
The counter (
self.r) is incremented every time before initializing AES class -
But encryption in this mode works in a way that the data is split into blocks of 16 bytes. Every block is encrypted independently with the same key. The counter is incremented by 1 for each block. The counter repeats in the program, which is a serious mistake.
The server receives 3 commands depending on the first character of the data sent by us:
"\x00" we can “register” our 16-byte value, in response we get hash from this value, and HMAC appended to it.
Some internal values are set.
"\x01" we can turn on encryption.
We do it by sending the data received from the
The server only checks whether HMAC is correct and sets
self.k to the value we cannot know.
This value is used as a key for AES encryption inside
From this point all data sent and received is encrypted.
We can see that in
"\x02" command, we can gain a flag easily, we only need to know how to encrypt and decrypt messages without the key.
Breaking CTR encryption with repeating key
Whenever it is needed to break some block cipher cryptography, I recommend to look at wikipedia. To be honest AES CTR isn’t a block cipher, but the keystream is generated block by block.
Below we can see a diagram of the algorithm (from wikipedia).
This is an algorithm for encrypting and decrypting data, it will look the same for every block cipher function. In our case it is AES. You can see that during encryption/decryption, keystream for each block is computed. When it is xored with plaintext, it gives ciphertext. The function in the block takes as an input a secret key and a counter. It always produces the same output for the same counter and secret key.
When we know the keystream, we can decipher the message.
Note that there is a place in the script (in command
"\x01") where the program sends to us encrypted known message -
msg = '\x02' + menu.
When the ciphertext and plaintext is known, we can obtain the keystream!
Just xor ciphertext with plaintext.
To read the flag, we need to obtain more bytes of keystream.
This can be made by setting a variable (
set command) and reading it.
After obtaining keystream for enough counter values, it is possible to read the flag (xor the keystream with received ciphertext).
The script of solution can be found here
The idea of solving the second task is the same. The code was changed a little bit and solution involves more logical thinking.
There are 2 crucial changes:
- 12 captchas before getting the flag, that means that it is needed to get longer keystream
- It is no longer possible to set a big variable in
We have to find out another way to obtain the keystream.
Interesting snippet of the code is here:
This part of the code is triggered after sending inproperly constructed
In this place we gain one block of the keystream for next counter.
To do this we exchange messages with the server.
When only one block of the keystream is left, we need to send encrypted command
Then we receive ciphertext for known message -
We xor it with with this message and the result is a block of the keystream for next counter.
Full code is here