Ctrlk

babycrypto

Crypto, 300 points.

Description

Start with this one! nc 13.233.66.116 5000

#!/usr/bin/python3 -u
import os
from binascii import hexlify, unhexlify

flag = open("./flag","rb").read()

class bb(object):
  def __init__(self, key):
    self.meh = [x for x in range(256)]
    j = 0
    for i in range(256):
      j = (j + self.meh[i] + key[i%len(key)])&0xff
      self.meh[i], self.meh[j] = self.meh[j], self.meh[i]
    self.cat = 0
    self.mouse = 0

  def crypt(self, string):
    out = []
    for c in string:
      self.cat = (self.cat+1)&0xff
      self.mouse = (self.cat+self.meh[self.cat])&0xff
      self.meh[self.cat], self.meh[self.mouse] = self.meh[self.mouse], self.meh[self.cat]
      k = self.meh[ (self.meh[self.cat]+self.meh[self.mouse])&0xff ]//2
      out.append((c+k)&0xff)
    return bytearray(out)


cipher = bb(os.urandom(32))

while True:
  print("Commands: \n(e)ncrypt msg or (p)rint flag")
  choice = input()

  if choice == 'e':
    message = input()
    print(hexlify(cipher.crypt(unhexlify(message))))
  elif choice == 'p':
    print(hexlify(cipher.crypt(flag)))
  else:
    print("meh!")

Solution

So I'm not sure about this task's title and description since only 4 teams managed to solve it, and I'm also not sure why there were only 4 solves since it was pretty simple.

We are given a service which runs the given Python script. We are able to encrypt messages and print an encrypted version of the flag:

It looks like the service initializes some kind of cryptographic stream with a random 32-byte key.

The algorithm looks a lot like RC4, except for two (not so) small details: addition is used instead of XOR, and the keystream byte is divided by 2 before being used.

Knowing about RC4 was not needed to solve this challenge, you just have to understand that the random key is used to produce a pseudo-random infinite stream of bytes that is used to encrypt plaintexts, here using addition modulo 256 instead of XOR.

Asking for the flag twice will encrypt it twice, but the keystream will be at a different position so the output is different.

Obviously, the weakness lies in the division by 2 of k in the crypt method. What this means is that k can only take values in 0, ..., 127 before it is added to our plaintext byte.

Since we know the flag will be a readable ASCII string, this reduces the amount of possibilities for a plaintext character. For instance, if we consider this encrypted version of the flag:

...it starts with 0xBA, and if we note p[0] the first character of the flag, we have p[0] + k = 0xBA.

As k can only take values between 0 and 127, we know p[0] can only take values between 0x3B and 0xBA, and since we assume it is readable ASCII, we know p[0] is somewhere between 0x3B and 0x7F.

Now we can do this for every byte of the plaintext but there's still too many possibilities... We cannot retrieve the flag like that.

Of course, the idea was to exploit the fact that we can encrypt the flag several times. For each byte, the higher its encrypted value is, the smallest the space of possibilities for the associated plaintext character is.

Therefore, each time we ask for a new encrypted flag, there is a probability that we're reducing the number of flag candidates. If we're asking for enough encrypted flags, we can thus reconstruct it with a high probability.

Here's the exploit:

The flag is retrieved in about 400 requests:

Enjoy!

PreviousByte Bandits CTF 2019NextSecurinets Prequals 2019

Last updated