Each year, the Information Systems and Security Laboratory (ISIS Lab) of the Polytechnic Institute of New York University hosts a Cyber Security Awareness Week, bringing together students and researchers to discuss the latest in cybersecurity. Cybersecurity has always been the core focus at Digital Operatives and we are looking forward to this year's events in November. The 2013 CSAW Capture the Flag Qualification Round was held this past weekend with over 1300 participating teams. Like most Jeopardy-style CTFs, CSAW had several categories of problems, with Reverse Engineering as one of them. A small team from Digital Operatives participated in this competition; below are write-ups for the Reversing problems. Congratulations to the winning teams and great job to the organizers of the competition!
Contents
Reversing 100: DotNetReversing.exe
We are prompted for a passcode and, upon attempting "a", the program crashes with a System.FormatException by attempting to parse the input as a number.
Upon opening the program in IDA Pro, it is quite clear where the branch between success and failure is, and because we know the program is looking for a numerical input, the constants just above this branch stand out.
We see that the program takes 0xC5EC4D790 and 0xF423ABDB7 and XORs them.
The result is 0x31cfe6a27, or 13371337255 in base ten, so we try this as input and get the flag!
Flag: I'll create a GUI interface using visual basic...see if I can track an IP address.
Reversing 100: csaw2013reversing1.exe
When the program is run, it displays a jumbled mess as the flag. Something clearly went wrong.
IDA Pro shows that the program only goes into its decryption routine if a debugger is attached.
We simply run the program with IDA as a debugger and allow it to display the decrypted flag.
Flag: this1isprettyeasy:)
Reversing 150: bikinibonanza.exe
This program gives various failure messages when we enter a string, including misleading messages about adding or subtracting 3 to our string input.
Because the program is in .NET IL, we open it with Red Gate's .NET Reflector and find the relevant procedures. The code takes the string "NeEd_MoRe_Bawlz" and the current hour (plus one), feeds them into another procedure, and compares the result with our input. If they match, the program will display the flag.
The procedure that operates on the hour and fixed string calls another procedure that substitutes the values, then finally calculates an MD5 sum over the string.
We convert this code into Python so that we can run it over all 24 hours and get the valid inputs.
#!/usr/bin/python
import md5
key_string = "NeEd_MoRe_Bawlz"
def substitute(num2, num1):
s = [ 2, 3, 5, 7, 11, 13, 0x11, 0x13, 0x17, 0x1d, 0x1f, 0x25, 0x29, 0x2b,
0x2f, 0x35, 0x3b, 0x3d, 0x43, 0x47, 0x49, 0x4f, 0x53, 0x59, 0x61, 0x65,
0x67, 0x6b, 0x6d, 0x71 ]
return s[num1] ^ num2
def get_key(text1, num1):
t = ''
for num2 in xrange(len(text1)):
ch = text1[num2]
for num in xrange(num1):
ch = chr(substitute(ord(ch), num+1))
num += 1
t += ch;
return md5.new(t).hexdigest()
for i in xrange(24):
print get_key(key_string, i)
reversing-150.py
Finally, we feed the correct input for the computer's hour into the program and get the flag.
Flag: 0920303251BABE89911ECEAD17FEBF30
Reversing 200: csaw2013reversing2.exe
We initially run the program and nothing happens, so we'll open it in IDA Pro. We simply start the binary in IDA's local debugger and guide the program to branch to the correct code, then examine memory just before the program terminates.
Alternatively, we could increment esi before allowing the call to MessageBoxA for the flag.
Flag: number2isalittlebitharder:p
Reversing 300: crackme
IDA Pro reveals that the file is an ELF that prompts for a key, hashes it, and succeeds if the hash equals 0xef2e3558.
The hash algorithm is a modified Bernstein hash with 1337 used as the start value instead of 5381.
unsigned int hash(char* s) {
unsigned int h = 1337;
while(*s) {
h = 33*h + *(s++);
}
return h;
}
We code up the algorithm and run it through Digital Operatives' constraint solver to generate matching strings.
~}?Jyjx
t~6pKpl
gt7_En;
*,2>bds
2k{].?=
GJJ4GSv
Piqqtoa
...
We send it off to the server and get the flag!
Flag: day 145: they still do not realize this software sucks
Reversing 400: keygenme32.elf
This file is an ELF; running it with no arguments gives:
usage: ./keygenme32.elf <username> <token 1> <token 2>
Analysis in IDA Pro shows this program creates a virtual CPU, executes an instruction stream with our provided username, then compares the two tokens to two of the registers within the virtual CPU via a check() function.
Rather than reversing the entire CPU instruction set, we write a GDB script to pull the values from the virtual CPU's registers and then derive the correct tokens.
break *0x804a2a2
run
file ./keygenme32.elf
x/xw $ebp+8
x/xw $ebp+12
kill
quit
script.gdb
#!/usr/bin/python
import socket
import re
import subprocess
server = '128.238.66.219'
port = 14549
prompt_pattern = re.compile('give me the password for (.*)')
gdb_pattern = re.compile('0x........:\t(0x........)')
gdb_command = ['gdb', '--batch', '-x', './script.gdb', '--args',
'./keygenme32.elf', 'WILL_BE_REPLACED', '0', '0']
# connect
s = socket.socket()
s.connect((server,port))
while True:
# get the prompt
prompt = ''
while prompt.find('give me the password for') == -1 and \
prompt.find('key') == -1:
prompt += s.recv(65536)
if prompt.find('key') != -1:
print prompt
s.close()
exit(0)
prompt = prompt.split('\n')
prompt = filter(None, prompt)
print repr(prompt)
prompt = prompt[-1]
name = prompt_pattern.match(prompt).group(1)
# place the name in the command
gdb_command[6] = name
# run it
p = subprocess.Popen(gdb_command, stdout=subprocess.PIPE)
output = p.communicate()[0]
print 'got output: '+output
# get values
output = output.split('\n')
output = filter(None, output)
token1 = gdb_pattern.match(output[-3]).group(1)
token2 = gdb_pattern.match(output[-2]).group(1)
# transform
token1 = int(token1, 16)
token1 ^= 0x31333337
token2_1 = token2[2:4]
token2_2 = token2[4:6]
token2_3 = token2[6:8]
token2_4 = token2[8:]
token2 = int('0x' + token2_3 + token2_1 + token2_2 + token2_4, 16)
# send the reply
reply = '%d %d\n' % (token1, token2)
print 'sending: '+reply
s.send(reply)
reversing-400.py
We run the Python script and get the flag!
Flag: r3vers1ng_emul4t3d_cpuz_a1n7_h4rd!
Reversing 500: Noobs First Firmware Mod
We are given a modified U-Boot firmware. After setting up QEMU within an Ubuntu server virtual machine, we can use IDA Pro's Remote GDB Debugger to step through the code and analyze. One of the first things U-Boot does is relocate itself from 0x00010000 to 0x07fd7000. We can compensate for this in IDA by rebasing the program:
RebaseProgram(0x07fc7000, MSF_FIXONCE);After digging around, we find a new command has been created, csaw, corresponding to the internal do_csaw function shown below.
The function, as hinted, has a bug in it: it attempts to copy from an empty/invalid memory address, 0x80002013. There is one other reference to this address, in the smc_init function, which tries to copy the string "SUPERSEXYHOTANDSPICY" there. (The full string in the binary is actually "key!=SUPERSEXYHOTANDSPICY".)
Thus, we replace the two invalid addresses in do_csaw with the appropriate ones. The remainder of do_csaw is supposed to extract characters from this string to construct the key, but again there is a bug — one of the pointers for the memcpy in its extraction loop is not incremented. We code up some debugger hooks in IDC to do the work for us.
#include <idc.idc>
static fix_r5_and_r11()
{
SetRegValue(0x7feac27, "R5");
SetRegValue(0x7feac4f, "R11");
return 0;
}
static increment_r10()
{
SetRegValue(GetRegValue("R10") + 1, "R10");
return 0;
}
static main()
{
AddBpt(0x7fd8df0);
AddBpt(0x7fd8e10);
AddBpt(0x7fd8e34);
SetBptCnd(0x7fd8df0, "fix_r5_and_r11()");
SetBptCnd(0x7fd8e10, "increment_r10()");
}
reversing-500.idc
Flag: SPREYOADPC
Reversing 500: Impossible
We get a file, impossible.nds. Analyzing strings in it reveals it is a Nintendo DS game file. We load it up in no$gba and notice there are lots of debug strings printed, including "RENDER SHIP" and "RENDER WTF". By placing read-access breakpoints on those strings, we can get context of the game state while tracing through each frame render. An analysis of the registers leads us to an area of memory containing game time, score, and enemy HP, shown below.
Killing the enemy by modifying its HP causes the game to render a screen with the key, at which point we search the emulator memory for "key" and find the whole string.
Flag: ou6UbzM8fgEjZQcRrcXKVN
0 comments:
Post a Comment