CSAW 2013 Exploit 200

Credit to Ryan

The first thing we did for this challenge was to look at the program headers:

From the headers we can see that the stack is given read, write, and execute permission therefore assuming the stack has enough space and we can overflow the buffer, we should be able to place and execute shell code on the stack. Looking at the assembly in IDA pro we see a few interesting lines.

From the assembly we can calculate what the stack will look like at run time:

As we can see the assembly the program is going to do the following:

1.      Create a random canary value and save it into VAR_C

2.      Send the address that tops to the top of BUF

3.      Send the canary value

4.      Send the following string “Welcome to CSAW CTF.  Exploitation 2 will be a little harder this year.  Insert your exploit here:”

5.      Receive 4096 bytes and store them in BUF

6.      If the canary value has not been changed return else exit the program

So the program is reading up to 4096 bytes into a 2048 byte buffer. We have a known address that points to the top of the buffer and we have the canary value. So we need to write an exploit program that will send the shellcode + canary value + buf address to get the flag.

Flag = 53666e040caa855a9b27194c82a26366

Link to solution code: https://github.com/IAryan/CTFSolutions/tree/master/CSAW/2013/Exploit_200

key{53666e040caa855a9b27194c82a26366}

Randy - 200 - bkpCTF 2013

This was a very interesting challenge. To start we downloaded and ran the executable on my Ubnutu VM.

After running the executable we assumed that the challenge was to find the password that would output a ": )".The next step was inspect the program in IdaPro and see if our assumptions were true. Some findings from examining the executable in IdaPro included:
The program fires up prints “Password” to the screen, then waits for user input. Once the user has entered the password the first check the executable does is to verify that the length of the password is 28 characters long.

Then the executable makes a second call to _strlen once again to verify that the length of the password is 28 characters long.


The program then calls the keygen function and falls into the call to the wrong function if keygen returns zero and the call to the valid function if keygen returns one. It looks like the function that will need to be reversed is the keygen function.


After some inspection and remote debugging we were able to figure out some important information about the keygen function. The keygen function works as follows:

1. Pull eight bytes from the user input and store the result in RAX
2. Use the bottom four bytes of RAX as input to _srandom
3. Call the _random function, and compare the return value to a number
4. Increment r12 to grab the next four bytes of the user input

This entire algorithm is repeated a total of seven times. The first seven numbers that are compared after each reseeding of the random function were:

1. 0x7358837a
2. 0x34d8c3b53. 0x1f49456c
4. 0x1fea6614
5. 0x4e81abc76. 0x683d3f5d
7. 0x28c9a8feTherefore to find the key all we need to do is write a program that generates all possible four character printable ASCII values. Use those values as input to srandom, call random, and finally compare the result to each of the previous seven numbers to find a match. This will tell us what four characters were used as the seed at that particular point in the program. Once all seven seeds are found we should have the flag:). The solution program that we used is as follows:


Link to solution code: https://github.com/IAryan/CTFSolutions/blob/master/randySolution.c



The output of the bruteforce program reveals the flag: n0t s0 r4nd0m0 4ft3r a11!!!! 

Solution write-up by Ryan