To search

w3pwnz

w3pwnz, therefore we are

Tag - reverse

Entries feed Comments feed

Saturday, October 26 2013 03:30

Hack.lu CTF 2013 - FluxArchive Part 1 & 2

You can download this challenge here.

Our target is a x64 ELF binary that archives files somehow, with some kind of encryption. Here is our target's usage:

Usage: ./archiv <command> <archiv> <password> <file>
commands:
-l <archiv> <password> - lists all files in the archiv.
-a <archiv> <password> <file> - adds a file to the archiv (when archiv does not exist create a new archiv).
-x <archiv> <password> <filename> - extracts the given filename from the archiv.
-d <archiv> <password> <filename> - delete the given filename from the archiv.

We don't know how files are encrypted and what is the password for the provided archive. In the first part we will only find what the password is, then we will go deeper into what this binary does in part 2.

Part1 - RE400: Bruteforce with LD_PRELOAD

These funny humans try to exclude us from the delicious beer of the Oktoberfest! They made up a passcode for everyone who wants to enter the Festzelt. Sadly, our human informant friend could not learn the passcode for us. But he heard a conversation between two drunken humans, that they were using the same passcode for this intercepted archive file. They claimed that the format is is absolutely secure and solves any kind of security issue. It's written by this funny hacker group named FluxFingers. Real jerks if you ask me. Anyway, it seems that the capability of drunken humans to remember things is limited. So they just used a 6 character passcode with only numbers and upper-case letters. So crack this passcode and get our ticket to their delicious german beer!

Here is the challenge: https://ctf.fluxfingers.net/static/downloads/fluxarchiv/hacklu2013_archiv_challenge1.tar.gz

Let's see what's going on with IDA, we quickly see this code:

rev400.png

The checkHashOfPassword function is only storing the SHA-1 in the static variable hash_of_password, and we can see from the code above that encryptDecryptData and verifyArchiv both only have one argument: the archive FILE pointer.

Ok, that's enough for me. I get lazy (more than usual :o), and decide to bruteforce from within the archiv process itself. That way we don't have to reverse the remaining functions (though, that was not complicated...), and the bruteforce will be efficient enough! To do that, I only load a shared library with LD_PRELOAD, "hook" the strcmp function and launch my bruteforce there.

#include <stdio.h>
 
int strcmp(const char *s1, const char *s2)
{
	const char *charset = "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
	char password[7] = {0};
	size_t i0, i1, i2, i3, i4, i5 = 0;
 
	void (*checkHashOfPassword)(char *) = (void*) 0x0000000000402A01;
	int (*encryptDecryptData)(FILE *) = (void*) 0x0000000000401B9A;
	int (*verifyArchiv)(FILE *) = (void*) 0x0000000000402A4E;
 
	FILE *f =  fopen("FluxArchiv.arc", "r");
 
	for (i0 = 0, password[0] = charset[i0]; password[0]; password[0] = charset[++i0]) {
		printf("passwd[0] = %c\n", password[0]);
		for (i1 = 0, password[1] = charset[0]; password[1]; password[1] = charset[++i1]) {
			printf("  passwd[1] = %c\n", password[1]);
			for (i2 = 0, password[2] = charset[0]; password[2]; password[2] = charset[++i2])
				for (i3 = 0, password[3] = charset[0]; password[3]; password[3] = charset[++i3])
					for (i4 = 0, password[4] = charset[0]; password[4]; password[4] = charset[++i4])
						for (i5 = 0, password[5] = charset[0]; password[5]; password[5] = charset[++i5]) {
 
							checkHashOfPassword(password);
							//encryptDecryptData(f); // Useless actually, only used to check the MAGIC_VALUE
 
							if (verifyArchiv(f)) {
								printf("Password found: %s\n", password);
								return 0;
							}
						}
		}
	}
 
	fclose(f);
 
	return 0;
}

Now let's compile, execute and wait for the password. It takes less than 10 minutes.

awe@awe-laptop ~/hacklu/reverse/FluxArchiv1 % gcc -O3 -shared -fPIC -o hooker.so hooker.c -ldl
awe@awe-laptop ~/hacklu/reverse/FluxArchiv1 % time LD_PRELOAD=./hooker.so ./archiv -l FluxArchiv.arc BADGER
################################################################################
FluxArchiv - solved security since 2007!
Written by sqall - leading expert in social-kernel-web-reverse-engineering.
################################################################################
 
passwd[0] = A
  passwd[1] = A
  passwd[1] = B
  passwd[1] = C
* snip *
  passwd[1] = U
  passwd[1] = V
  passwd[1] = W
Password found: PWF41L
Given password is not correct.
zsh: exit 1     LD_PRELOAD=./hooker.so ./archiv -l FluxArchiv.arc BADGER
LD_PRELOAD=./hooker.so ./archiv -l FluxArchiv.arc BADGER  537.34s user 49.71s system 99% cpu 9:47.70 total

So now we can extract the archive files, etc. However, PWF41L was actually the flag.

Part2 - RE500: Extraction of deleted entries

These sneaky humans! They do not just use one passcode, but two to enter the Festzelt. We heard that the passcode is hidden inside the archive file. It seems that the FluxFingers overrated their programming skill and had a major logical flaw in the archive file structure. Some of the drunken Oktoberfest humans found it and abused this flaw in order to transfer hidden messages. Find this passcode so we can finally drink their beer!

(only solvable when FluxArchiv (Part 1) was solved)

Here is the challenge: https://ctf.fluxfingers.net/static/downloads/fluxarchiv/hacklu2013_archiv_challenge1.tar.gz

From the description, we quickly guess that there are issues with the archive deletion mechanism. First let's analyse the deleteArchive function. And well hmm, it doesn't behave like intended. That's because the author messed up the functions name. That can be quickly fixed by following the CFG backwards from the printed messages. We then have these functions / addresses:

Function name Segment Start
doRC4 .text 0000000000400E0C
createHashOfPassword .text 0000000000400E96
createFileEntry .text 0000000000400F05
real_addArchive .text 0000000000401043
findNextFreeChunk .text 0000000000401406
encryptDecryptData .text 0000000000401B9A
writeFileToArchiv .text 0000000000401CA7
real_searchArchive .text 0000000000401FED
real_deleteArchive .text 000000000040227D
real_extractArchive .text 00000000004025C8
checkHashOfPassword .text 0000000000402A01
verifyArchiv .text 0000000000402A4E
main .text 0000000000402B65

Let's analyse the real_deleteArchive function. It takes 2 parameters: the archive stream pointer and the offset for the entry we want to delete (which is returned from a previous call to real_searchArchive). Here is what the function does, from its CFG:

rev500_CFG.png

# PURPLE: go to the initial offset, read next_chunk (which will be used to calculate the offset for the next chunk)
f.seek(init_offset)
next_chunk = unpack("<Q", doRC4(f.read(8)))
 
# YELLOW: read max_chunks (total number of chunks)
max_chunks = unpack("<Q", doRC4(f.read(8)))
 
# DARK GREEN: overwrite next_chunk in the file with junk
next_offset = next_chunk << 4
next_offset = next_offset + (next_offset << 6) + 0x20
fseek(next_offset)
f.write(doRC4("\x00" * 8))
f.write(doRC4("\x00" * 8))
 
# RED: overwrite the MD5sum with junk
f.write(doRC4("\x00" * 16))
 
# BLUE: overwrite the file name with junk
f.write(doRC4("\x00" * 0x60))
 
# LIGHT GREEN: 
for chunk_index in range(max_chunks):
    # GREY: go to the next chunk offset, read next_chunk
    f.seek(next_offset)
    next_chunk = unpack("<Q", doRC4(f.read(8)))
 
    # ORANGE: overwrite the next_chunk in the file with junk
    f.seek(next_offset) ; f.write(doRC4("\x00" * 8))

So, they delete all metadatas associated to the file, but not the file content itself. We should be able to recover a file then! We miss some informations though:

  1. What is the size of each chunk?
  2. How many chunks do we have to read? That's overwritten, so we don't know.
  3. How are the next_chunk allocated? Is that sequential, random, ...? That's overwritten too.

We can't know the file name and we won't be able to verify the MD5 sum, but we don't care of these details. From the real_addArchive function we can get all we needed to know. It does the opposite, and shows us that for each chunk of the original file, 0x408 bytes are written, then the next_chunk value is simply incremented.

We can't know what the size of the file is, so we will assume max_chunks = 0xFF. Because can't know the initial value of next_chunk either, we will have to bruteforce, from 0 to 0xFF. We will create one file per initial next_chunk value. Because we choose a max_chunks which is overlong, we will have some garbage at the end of each file, but most file formats don't really care about that anyway.

#!/usr/bin/env python2
 
import Crypto.Cipher.ARC4 as RC4
import hashlib
 
def decryptRC4(s):
    return RC4.ARC4Cipher(hashlib.sha1("PWF41L").digest()).decrypt(s)
 
f = open("FluxArchiv2.arc", "rb")
 
for bf in xrange(0xFF):
    print '[*] Trying with offset %02x' % bf
    o = open("output/out_%02x" % bf, "w+")
 
    try:
        next_chunk = bf
        max_chunks = 0xFF
 
        for chunk_index in xrange(max_chunks):
            next_offset = next_chunk << 4
            next_offset = next_offset + (next_offset << 6) + 0x20
 
            f.seek(next_offset)
            f.read(8) # Skip overwritten next_chunk
 
            content = decryptRC4(f.read(0x408))
            o.write(content)
 
            next_chunk += 1
    except:
        pass
    finally:
        o.close()
 
f.close()

Now we go to output/, do a file *, find the documents we extracted previously from the part 1, but no new image file with the flag as I expected :( So, it is probably simply a text file...

head -n1 *|less
# Output: *snip*
# ==> out_9d <==
# <B7>9<AF>       <B0><FB><91>0<D8>fB^Sȑ
# 
# ==> out_9e <==
# Another one got caught today, it's all over the papers.  "Teenager
# 
# ==> out_9f <==
# els threatened by me...
# 
# ==> out_a0 <==
# e electron and the switch, the
# *snip*
less out_9e
# Output:
# Another one got caught today, it's all over the papers.  "Teenager
# Arrested in Computer Crime Scandal", "Hacker Arrested after Bank Tampering"...
# Damn kids.  They're all alike.
# *snip*
# 
# +++The Mentor+++
# 
# Flag: D3letinG-1nd3x_F4iL
# * snip*

The flag is D3letinG-1nd3x_F4iL.

Thursday, October 18 2012 16:01

HackYou CTF - Reverse100, Reverse200, Reverse300 Writeups

Reverse 100 - Open-Source



Download file code.c.
Simply read the source...

% ./code `python2 -c 'print 0xcafe'` 25 h4cky0u
Brr wrrr grr
Get your key: c0ffee

Flag: c0ffee

Reverse 200 - LoseYou



Download file rev200.zip.

Extract the archive to obtain task2.bin and task2.exe.
I decided to study task2.bin.
The routine to reverse is sub_80483DC.
We quicky notice this:

hackyou_reverse200.png

That's very basic, eax will contain our guessed number, ecx will contain the randomly generated number.
All we need to do is to break on the "cmp eax, ecx" at 08048503 and set eax to ecx.

(gdb) b *0x08048503
Breakpoint 1 at 0x8048503
(gdb) r
Starting program: /tmp/task2.bin 
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Welcome to the LoseYou lottery!
Generating random.....
Make your guess (number 0 or 1): tg
 
Breakpoint 1, 0x08048503 in ?? ()
(gdb) set $eax=$ecx
(gdb) c
Continuing.
You... you... win??? so lucky! Grab the flag:
::: oh_you_cheat3r :::
[Inferior 1 (process 27619) exited normally]
(gdb)

Flag: oh_you_cheat3r

Reverse 300 - ashtree



Download file rev300.zip.
Once again I decided to study the ELF version: task3.bin.

Step 1 - Unpack

The binary seems to be packed by a modified UPX (at least, UPX string is replaced by LOL...).
Let's trace execution:

% strace ./task3.bin 
execve("./task3.bin", ["./task3.bin"], [/* 34 vars */]) = 0
[ Process PID=5640 runs in 32 bit mode. ]
getpid()                                = 5640
gettimeofday({1350215641, 677903}, NULL) = 0
unlink("/tmp/upxCRBOGQOAFQI")           = -1 ENOENT (No such file or directory)
open("/tmp/upxCRBOGQOAFQI", O_RDWR|O_CREAT|O_EXCL, 0700) = 3
ftruncate(3, 9036)                      = 0
old_mmap(NULL, 9036, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0xf775a000
old_mmap(0xf775d000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf775d000
munmap(0xfffffffff775a000, 9036)        = 0
close(3)                                = 0
open("/tmp/upxCRBOGQOAFQI", O_RDONLY)   = 3
getpid()                                = 5640
access("/proc/5640/fd/3", R_OK|X_OK)    = 0
unlink("/tmp/upxCRBOGQOAFQI")           = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
execve("/proc/5640/fd/3", ["./task3.bin"], [/* 41 vars */]) = 0
[...]

The binary is unpacking itself into a file "/tmp/upxCRBOGQOAFQI", which is a randomly generated name. Then it is unlinked and executed by execve().

The unlink() function is guaranteed to unlink the file from the file system hierarchy but keep the file on disk until all open instances of the file are closed.

Once the execution is over, the file is deleted, so we need to find the file name, and copy the file elsewhere before it's unlinked. Let's toggle a breakpoint before execve() then.

(gdb) b *0x004024dd
Breakpoint 1 at 0x4024dd
(gdb) r
Starting program: /tmp/task3.bin 
 
Breakpoint 1, 0x004024dd in ?? ()
(gdb) x/s $ebx
0xffffd494:	"/proc/12767/fd/7"
(gdb)
% file /proc/12767/fd/7
/proc/12767/fd/7: broken symbolic link to `/tmp/upxC5RF3NOAMO5 (deleted)'

Ok! Now we can work on the unpacked binary.

Step 2 - Keygen

Our routine is sub_8048617.
Several conditions must be met:

  • - argv[1] = username
  • - argv[2] = password
  • - username != 'hackyou'
  • - len(password) == 14
  • - password[4] == '-' and password[8] == '-'
  • - sub_804838C(username, password) == True
  • - sub_804844B(username, password[5:]) == True
  • - sub_804850A(username, password[10:]) == True

Although our username must not be 'hackyou', if you take a look at sub_80485F0, the goodboy message, you'll notice it prints "Great! Now submit the license key for 'hackyou'".
sub_804838C, sub_804844B and sub_804850A all proceed in the same way, which finally compares individually 4 bytes of the given password parameter:

hackyou_rev300_ida.png

Our password character is in edx, the expected one is in eax. Lazy as i am, i didn't go much deeper :)

All we need now is to break on:

.text:0804842B                 cmp     eax, edx

... dump eax, and fix edx so that it will be equal to eax. Same for the two last routines. Let's create a basic pythonGDB script to do the work for us.

import gdb
 
passwd = ""
passwd_len = 0
 
def callback_username_condition():
    gdb.execute("set $eax=1")
 
def callback_compare_password():
    global passwd, passwd_len
 
    gdb.execute("set $edx=$eax")
 
    if passwd_len in (4, 9):
        passwd += '-'
        passwd_len += 1
 
    passwd += chr(gdb.parse_and_eval("$eax"))
    passwd_len += 1
 
    print "[+]", passwd
 
class HitBreakpoint(gdb.Breakpoint):
    def __init__(self, loc, callback):
        super(HitBreakpoint, self).__init__(
            loc, gdb.BP_BREAKPOINT, internal=False
        )
        self.callback = callback
 
    def stop(self):
        self.callback()
 
        return False
 
HitBreakpoint("*0x08048665", callback_username_condition)
HitBreakpoint("*0x0804842B", callback_compare_password)
HitBreakpoint("*0x080484EA", callback_compare_password)
HitBreakpoint("*0x080485A9", callback_compare_password)

And run it...

(gdb) source script.py 
Breakpoint 1 at 0x8048665
Breakpoint 2 at 0x804842b
Breakpoint 3 at 0x80484ea
Breakpoint 4 at 0x80485a9
(gdb) r hackyou 0123-4567-8910
Starting program: /tmp/unpacked_rev300 hackyou 0123-4567-8910
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[+] k
[+] ke
[+] kec
[+] kecc
[+] kecc-h
[+] kecc-ha
[+] kecc-hac
[+] kecc-hack
[+] kecc-hack-y
[+] kecc-hack-yo
[+] kecc-hack-yo0
[+] kecc-hack-yo0u
Great! Now submit the license key for 'hackyou'
[Inferior 1 (process 14524) exited with code 01]
(gdb)

Flag: kecc-hack-yo0u

Sunday, March 25 2012 23:33

NDH2k12 Prequals - New email from our contact - strange binary file #2

From: Jessica <jessica@megacortek.com>
To: w3pwnz <w3pwnz@megacortek.com>
Subject: New email from our contact
Attachments : executable2.ndh
Thank you again for your help, our technical staff has a pretty good overview
of the new device designed by Sciteek. Your account will be credited with $500.

You did work hard enough to impress me, your help is still more than welcome,
you will get nice rewards. Our anonymous guy managed to get access to another
bunch of files. Here is one of his emails:

---
Hi there, see attached file for more information. It was found on
http://sci.nuitduhack.com/EgZ8sv12.
---

Maybe you can get further than him by exploiting this website.
We also need to get
as much information as possible about the file itself. If you succeed, you will
be rewarded with $2500 for the ndh file and $1000 for the website. Please use
"Sciteek shortener" and "strange binary file #2" titles.

Regards,
Jessica.


This challenge was another crackme. I called it "VMception", and it was a little harder than the other one =)

First we noticed the string "password is wrong:" (0x8737), and another a little stranger "Unhandled exception occured during execution. Exiting" (0x874b) and search for their references :

0x85f6: movl r0, #0x874b		; <-- unhandled exception
0x85fb: call 0xfb7a
0x85ff: end
------
0x8672: movl r0, #0x8737		; <-- password is wrong
0x8677: call 0xfafe
0x867b: end

The entry point of the crackme is a "jmpl 0x0624", corresponding to the following routine :

0x8627: movl r0, #0x867c		; <-- source = 0x867c
0x862c: movl r1, #0x86e8
0x8631: sub r1, r0			; <-- 0x86e8 - 0x867c = 0x6C = 108
0x8635: call 0xfc64			; --> 0x829d (memcpy_to_0x000a)
0x8639: movl r0, #0x0000	
0x863e: movl r1, #0x0035
0x8643: movl r2, #0x0000
0x8648: movl r3, #0x0000
0x864d: call 0xfc67
0x8651: call 0xffab			; --> 0x8600 (ask password)
0x8655: call 0xfed8			; --> 0x8531 (VMception)
0x8659: movl r0, #0x0000		; <-- 0x0000 = buffer password
0x865e: call 0xfca9	
0x8662: test r0, r0
0x8665: jz 0x000a			; --> goto password_is_wrong if r0 = 0
0x8668: movl r0, #0x872a
0x866d: call 0xfb90			; --> pwned \o/ 
0x8671: end

The first action is to copy 0x6c bytes of data from 0x867c to 0x000a :

niklos@box:~/ndh/jessica4# vmndh -file executable2.ndh -debug
[Console]#> x/x 0x867c:0x6c
0x867c: 0a 06 06 00 00 0b 02 07 4d 06 00 07 02 07 78 07
0x868c: 00 07 09 02 02 07 61 06 01 07 02 07 02 07 01 07
0x869c: 09 02 02 07 72 06 02 07 02 07 43 07 02 07 09 02
0x86ac: 02 07 31 06 03 07 02 07 45 07 03 07 09 02 02 07
0x86bc: 30 06 04 07 02 07 03 07 04 07 09 02 02 07 4c 06
0x86cc: 05 07 02 07 7f 07 05 07 09 02 02 07 64 06 06 07
0x86dc: 02 07 0f 07 06 07 09 02 02 00 01 0b

So far, we've got no idea of what the hell it could be, except that's probably vicious... We need to go deeper :)
Then, a 8bytes password is read, and stored in 0x0000 (which is quite surprising when you forget that you're in a very simple virtual machine). Next is a quite big routine, but quite easily understandable :

0x8531: push r2
0x8534: call 0xfdf9			; --> 0x8331 (code = get_next_ element)
0x8538: cmpb r0, #11		; --> code == 0xb
0x853c: jnz 0x0003
0x853f: jmpl 0x008f 			; --> goto 0x85d1 (BREAK)
0x8542: cmpb r0, #01		; --> code == 0x01		
0x8546: jnz 0x0007
0x8549: call 0xfeec
0x854d: jmpl 0xffe4
0x8550: cmpb r0, #02		; --> code == 0x2
0x8554: jnz 0x0007
0x8557: call 0xff0e
0x855b: jmpl 0xffd6			; --> loop
 
[...]
 
0x85c0: cmpb r0, #0a			; --> code == 0xa
0x85c4: jnz 0x0007
0x85c7: call 0xff5d
0x85cb: jmpl 0xff66			; --> loop
0x85ce: jmpl 0x0025			; --> 0x85f6 (unhandled_exception)
 
.label BREAK:
[...]
0x85f5: ret

First, this routine get an opcode from the buffer we previously copied in 0x000a, by calling 0x8331. Then, there's a switch/case test on this code, with a registered action for each from 0x00 to 0x0a, and 0x0b is the code signifying the end of the routine.

We now have a better understanding of the crackme : VMception : a VM inside a VM, and the buffer in 0x000a contains our program (we already see that most bytes are in [0x0 - 0xa] and it ends by 0xb.

Now comes the fun part when you trace the program opcode by opcode to understand the corresponding subroutines...
Here is what you can say then :

  • The password is actually 7bytes long, since the 8th byte is overitten (by a value used to check a byte of the password btw)
  • The password is checked one char at the time, and a single check use several opcodes
  • Opcodes used to do a single check are : 0x2 (routine 0x8469) 0x6 (routine 0x83a4), 0x7 (routine 0x8495), and 0x9 (routine 0x84fe)
  • The program-counter is stored at 0x9 (just before the program itself)

Let's check the subroutines of opcodes 0x02, 0x6, 0x7 and 0x9, starting with 0x2 :

[...]
0x8472: call 0xfebb		; --> 0x8331  (get_next_element = always 7)
0x8476: mov r1, r0	
0x847a:  call 0xfeb3		; --> 0x8331 (get_next_element = X, a value outside [0,a], like 0x4d, 0x78, ...)
0x847e: mov r2, r0
0x8482: mov r0, r1
0x8486: mov r1, r2
0x848a: call 0xfe90		; --> 0x831e (write_r0_at_r1 : writes the )
[...]
0x8494: ret

So this routine retrieves a value that is not an opcode, and stores it at 0x7.
Now 0x6 :

[...]
0x83b0: call 0xff7d		; --> 0x8331 (get_next_element = index i in the password of the char to be tested)
0x83b4: mov r3, r0
0x83b8: call 0xff75		; --> 0x8331 (get_next_ element = always 7)
0x83bc: call 0xff4b		; --> 0x830b (return *R0 == get [0x07])
0x83c0: mov r2, r0
0x83c4: mov r0, r3
0x83c8: call 0xff3f		; --> 0x830b (return *R0 = get password[i], the value of the char to be tested)
0x83cc: xor r0, r2		; --> XOR
0x83d0: mov r1, r0		
0x83d4: mov r0, r3		
0x83d8: call 0xff42		; --> 0x831e (write_r1_at_r0 = write the xored value at password[i])
[...]
0x83e4: ret

This one takes the previous value at 0x7 and XOR the current byte of the password with it.
Now 0x7 :

[...]
0x849e: call 0xfe8f		; --> 0x8331 (get_next_element = index i in the password of the char to be tested)
0x84a2: call 0xfe65		; --> 0x830b (return *R0 = get password[i], the value of the char to be tested)
0x84a6: mov r1, r0		
0x84aa: call 0xfe83		; --> 0x8331 (get_next_ element = always 7)
0x84ae: call 0xfe59		; --> 0x830b (return *R0 == get [0x07])
0x84b2: mov r2, r0	
0x84b6: cmp r1, r2		; --> CMP password[i], [0x7]
0x84ba: movl r1, #0x00	; --> R1 = 0
0x84bf: jnz 0x0002
0x84c2: inc r1			; --> R1 = 1
0x84c4: movl r0, #0x08	; --> R0 = 8
0x84c9: call 0xfe51		; --> 0x831e (write_r0_at_r1 = writes the result of CMP at 0x8)
[...]
0x84d3: ret

This routine compares the current byte of the password with some value stored in 0x7.
And finally 0x9 :

[...]
0x8504: call 0xfe29		; --> 0x8331 (get_next_element = always 0x2)
0x8508: mov r1, r0		
0x850c: movl r0, #0x0008	; --> R0 = 8
0x8511: call 0xfdf6		; --> 0x830b (return *R0 = get [0x08])
0x8515: test r0, r0
0x8518: jnz 0x0008
0x851b: mov r0, r1
0x851f: call 0xfe30		; --> IF [0x08] == 0 THEN : 0x8353 (change_program_counter by 0x2)
[...]
0x8527: ret

This one changes the program counter by 0x2 if the previous comparison fails.

We now know how one byte of the password is checked :

  • 0x02 : store next element at 0x7
  • 0x06 : XOR password[i] and [0x7]
  • 0x02 : store next element at 0x7
  • 0x07 : compare xored value and [0x7] and write the result at 0x8
  • 0x09 : f*ck up program counter if [0x8] is 0

So with 3 breakpoints in routines of opcodes 0x6, 0x7 and 0x9, we can get the xor keys and the xored values :

niklos@box:~/ndh/jessica4# vmndh -file executable2.ndh -debug
[Console]#> bp 0x83c0
Breakpoint set in 0x83c0
[Console]#> bp 0x84b6
Breakpoint set in 0x84b6
[Console]#> bp 0x8515
Breakpoint set in 0x8515
[Console]#> run
[...]
[SYSCALL output]: Please enter Sciteek admin password:
AAAAAAA
[...]
[BreakPoint 1 - 0x83c0]
0x83c0 > mov r2, r0
[Console]#> info reg
[r0]: 004d		; --> first xor key is 0x4d
[...]
[Console]#> run
[BreakPoint 2 - 0x84b6]
0x84b6 > cmp r1, r2
[Console]#> info reg
[r0]: 0078		; --> first xored value is 0x78
[Console]#> run
[...]
[BreakPoint 3 - 0x8515]
0x8515 > test r0, r0
[Console]#> set r1=1	; --> set the result of the comparison to 1
r1 = 0x0001
[Console]#> run

[...]

And so on for the 7 bytes of the password :)

Now we xor all this and get the password :

>>> a = [0x4d, 0x61, 0x72, 0x31, 0x30, 0x4c, 0x64]
>>> b = [0x78, 0x02, 0x43, 0x45, 0x03, 0x7f, 0x0f]
>>> print ''.join([ chr(a[i] ^ b[i]) for i in range(len(a)) ])
5c1t33k

Bazinga \o/

NDH2k12 Prequals - unknown binary, need your help - Strange binary file

From: Jessica <jessica@megacortek.com>
To: w3pwnz <w3pwnz@megacortek.com>
Subject: unknown binary, need your help
Attachments : executable1.ndh
Hello again,

Thank you very much for your help. It is amazing that our technical staff and
experts did not manage to recover any of it: the password sounds pretty weak.
I will notify our head of technical staff.

Anyway, I forwarded them the file for further investigation. Meanwhile, we got
fresh news from our mystery guy. He came along with an intersting binary file.
It just looks like an executable, but it is not ELF nor anything our experts
would happen to know or recognize. Some of them we quite impressed by your skills
and do think you may be able to succeed here. I attached the file, if you discover
anything, please send me an email entitled "Strange binary file".

This will be rewarded, as usual. By the way, your account has just been credited
with $100.

Regards,
Jessica.


We first noticed the two strings "Good password" and "Bad password" at the end of the file. An easy way to attack a crackme is to search for string references in the code. The disassembly from vmndh tells us that the "Bad password" string is loaded in 0x8480, and referenced from

0x82d4:
0x82d4: movl r0, #0x8480
0x82d9: call 0xffdd
0x82dd: ret


This is the "bad boy" case, and whatever "call 0xffdd" is, it must be the impression routine. There were two methods to get the actual adresses of the calls: check them in the debugger, or patch the disassembled output to translate relative calls into absolute ones. This is what patch.py does.

With it, we can see that the address 0x82d4 is called 9 times between 0x82e8 and 0x83e1, just after "jz" instructions.

A first test is made, that checks the length of the input:

0x82e8: mov r7, r0
0x82ec: movl r6, #0x840d
0x82f1: call 0x8003
0x82f5: cmpb r0, #09        ; 9 bytes (8 without "\x0a")
0x82f9: jz 0x0005
0x82fc: call 0x82d4         ; -> bad boy
0x8300: end


After that, each time the bytes pointed by r7 and r6 are xored together and compared to a hardcoded value. Then r7 and r6 are incremented:

0x8301: mov r0, [r7]
0x8305: mov r1, [r6]
0x8309: xor r0, r1
0x830d: cmpb r0, #78
0x8311: jz 0x0005
0x8314: call 0x82d4
0x8318: end
0x8319: inc r7
0x831b: inc r6


Let's load the program in the debugger and put a breakpoint at 0x8301, to see what these registers point to:

[BreakPoint 1 - 0x8301]
0x8301 > mov r0, [r7]
[Console]#> info reg
[r0]: 0061	[r4]: 0000
[r1]: 0000	[r5]: 0000
[r2]: 7fda	[r6]: 840d
[r3]: 001f	[r7]: 7fda
 
[bp]: 7ffa	[zf]: 0001
[sp]: 7fd8	[af]: 0000
[pc]: 8305	[bf]: 0000
[Console]#> x/x 7fda:8
0x7fda: 61 62 63 64 65 66 67 68     <- our input
[Console]#> x/x 840d:8
0x840d: 02 05 03 07 08 06 01 09     <- the key


According to the cmpb instructions, the result must be 78 44 73 6b 61 3e 6e 5e. The correct input is therefore

>>> format(0x7844736b613e6e5e ^ 0x0205030708060109,"x").decode("hex")
'zApli8oW'

Let’s use it:

~/ndh2012$ nc sciteek.nuitduhack.com 4001
Sciteek protected storage #1
Enter your password: zApli8oW
<PSP version="1.99">
<MOTD>
<![CDATA[
Welcome on SciPad Protected Storage.

The most secure storage designed by Sciteek. This storage protocol
allows our users to share files in the cloud, in a dual way.

This daemon has been optimized for SciPad v1, running SciOS 16bits
with our brand new processor.
]]>
</MOTD>
<FLAG>
ea1670464251ea3b65afd624d9b17cd7
</FLAG>
<ERROR>
An unexpected error occured: PSP-UNK-ERR-001> application closed.
</ERROR>
</PSP>

NDH2k12 Prequals - Any idea how to use this file? - Unknown file extension

After decrypting the secret message, we got a new email, from Piotr this time, a supposed technical operative.

From: Piotr <piotr@megacortek.com>
To: w3pwnz <w3pwnz@megacortek.com>
Subject: Any idea how to use this file?
Attachments : webApp.ndh
Hi

Great job there! You seem to be quite a great cryptograph, wow. Your account has been credited with $100. Btw, I'm Piotr, from the technical staff. Maybe Jessica told you about me, we will interact directly about complex questions.

Anyway, our anonymous contact at Sciteek has sent us another binary file with that strange extension, will you be able to break it? If you manage so, please contact me directly with the subject "Unknown file extension", $1700 dollars to earn!

KR
Piotr


As you can see, he asks us to study a file which format and extension are unknown.
The file is pretty small (897 bytes), and contains some strings :

# strings webApp.ndh
.NDH{
Welcome on Sciteek' SciPad secure shell !
Please enter your passphrase:
Nope. It is not the good password
sciteek.nuitduhack.com:4000
LxTBh9pv.txt


We can easily recognize the other strings as coming from the pseudo-assembly code decrypted. A quick look at it shows a blatant 10-bytes read while the function frame is only 8-bytes long. We can quickly check this buffer overflow on the online service:

# nc sciteek.nuitduhack.com 4000
Welcome on Sciteek' SciPad secure shell !
Please enter your passphrase: 0123456789
[!] Segfault 0x3938 (opcode unknown)


From the plain ASM, we also spot a debug function whose job is to display the “esoasoel.txt” file, obvious candidate for our BoF. From there on, two options: bruteforcing the possible return addresses or reversing the file format to find the actual offset of the debug function.

Step 1 : The Easy Way


The address space is only 16-bits long and we haven’t enough place for a shellcode anyway: we chose to bruteforce it - at the time, we did not have the NDH virtual machine from the rar archive to directly get the correct offset. The only trick here is to think about injecting 9 bytes instead of 10 to get the heavy-weighted one:

$ perl -e 'print "A"x9' | nc sciteek.nuitduhack.com 4000
Welcome on Sciteek' SciPad secure shell !
Please enter your passphrase: [!] Segfault 0x8241 (opcode unknown)


The assembly suggests that the debug function we are looking for is farther ahead in the code segment than the call :ask_password, so we launched a bruteforce from 0x8200 to 0x83ff included.
Finally, Ezekiel 25:17 pops up:

# python -c "print 'A'*8+'\xdb\x82'" | nc sciteek.nuitduhack.com 4000

Welcome on SciPad Shell, root.

The path of the righteous man is beset on all sides by the inequities of the selfish and the tyranny of evil men. 
Blessed is he who, in the name of charity and good will, shepherds the weak through the valley of darkness, for he is truly his brother's keeper and the finder of lost children. 
And I will strike down upon thee with great vengeance and furious anger those who would attempt to poison and destroy My brothers. 
And you will know My name is the Lord when I lay My vengeance upon thee.

- God (f98eb53e7960c9a663c60a916b6de70e)

Be careful, this service is not protected by any option, to avoid exploitation please use the new version of this shell available on sciteek.nuitduhack.com:4004. 
This service runs in a vm with stack layout randomization which is more secure

Something's fucked up ('cause our developers drink too much beer).
Try later. Or not.


Step 2 : The hard way, ‘cuz you’re a grown up and all.


First we have to study the binary. So hex editor it is.
ndh_webapp_hdr

The first four bytes indicate the file type, here NDH. The two following bytes indicate the size of the code and data section : the end offset is 0x37F, and 0x37F - FILE_TYPE_FIELD_SIZE (4) = 0x37B.

The data section is localized at the end of the file :

ndh_webapp_datas

We recognize the strings from the pseudo ASM code with a little difference : the name of the text file.

Now we have to find the function that displays the file content. Thanks to the Scios Instruction Set we extracted from the audio file, we know that the binary is mapped at the 0x8000 address. We manually compile the following statement :

.LABEL TEMP_ROUTINE
  MOVL R0, :FLAG_FILE
  CALL :DISP_FILE_CONTENT
  END


MOVL R0, :FLAG_FILE give us the following opcodes :

MOV    REG_DIRECT16 FLAG    R0    FILE NAME ADDR LITTLE ENDIAN
04     02                   00    6e 83


The filename address is calculated by adding the filename offset in the file (0x374 - HDR_SIZE(6)) to the memory base address (0x8000) which give us 0x836E.
We can’t fully compile the next statement, because we don’t know where is the DISP_FILE_CONTENT function, however we know the compiled statement will be something like that :

CALL    DIRECT16 FLAG    FUNCTION ADDRESS
19      04               XX XX


Consequently, we can look for the followings bytes in the binary :

04 02 00 6E 83 19 04


ndh_webapp_displayfile

And we find them at the file offset 2E1 that we translate into memory address :

0x8000 + 0x2E1 - 0x6 (HDR_SIZE) = 0x82DB.


No surprise here, this is the address we found by bruteforcing the BoF. Well, that’s it.

NDH2k12 Prequals - What is it about this file? - Binary file ndh

BinaryFileNdh.png

File: 11925.ndh

Once again it is a VM file. We quickly take a look at the hexdump to find the remote port used (4004).

% tail 11925.ndh|hexdump -C
00000000  00 16 b7 0e 00 02 02 04  00 00 02 03 04 03 03 03  |................|
00000010  02 03 01 1a 01 03 00 01  03 01 04 00 01 00 19 04  |................|
00000020  7c fe 04 00 03 00 04 00  02 01 04 01 01 01 04 01  ||...............|
00000030  00 04 30 03 01 03 00 1a  01 03 00 01 03 03 0e 00  |..0.............|
00000040  03 03 18 00 03 02 10 0d  00 1e 0a 00 04 06 00 01  |................|
00000050  0a 03 0a 00 16 ec 03 03  03 00 1a 04 00 01 00 04  |................|
00000060  01 00 05 30 1a 04 00 02  01 04 00 01 00 04 01 00  |...0............|
00000070  02 30 1a 04 00 03 02 04  00 02 01 04 00 01 00 04  |.0..............|
00000080  01 00 03 30 1a 01 03 03  04 00 03 02 04 00 02 01  |...0............|
00000090  04 00 01 00 04 01 00 11  30 03 03 1a 01 03 01 01  |........0.......|
000000a0  03 02 01 03 03 01 03 04  01 03 05 04 02 01 00 00  |................|
000000b0  19 04 b1 ff 18 02 00 ff  ff 11 0f 00 0e 00 00 00  |................|
000000c0  03 05 03 04 03 03 03 02  03 01 1a 04 00 03 00 04  |................|
000000d0  02 01 00 00 04 02 02 02  00 19 04 a8 ff 04 00 04  |................|
000000e0  00 0a 04 04 00 00 03 04  02 01 00 00 04 02 02 00  |................|
000000f0  00 19 04 90 ff 07 00 08  04 04 00 05 08 04 00 00  |................|
00000100  03 04 00 01 08 04 00 02  04 19 04 66 ff 06 00 04  |...........f....|
00000110  05 0b 04 04 07 04 00 04  00 00 05 19 04 f5 fe 04  |................|
00000120  01 00 01 0a 04 07 00 04  05 06 00 08 04 03 05 03  |................|
00000130  04 03 03 03 02 03 01 1a  04 02 00 10 83 19 04 d3  |................|
00000140  fe 07 01 08 32 04 00 05  08 04 02 00 00 00 04 00  |....2...........|
00000150  01 05 04 01 02 36 19 04  19 ff 04 02 00 11 11 04  |.....6..........|
00000160  00 01 05 04 02 02 32 00  19 04 5b fd 06 01 08 32  |......2...[....2|
00000170  1a 04 02 00 11 11 04 02  01 5e 83 04 02 02 00 01  |.........^......|
00000180  19 04 d7 fd 11 0d 00 0a  07 04 02 00 51 83 19 04  |............Q...|
00000190  0a ff 16 09 04 02 00 42  83 19 04 77 fe 1a 0e 00  |.......B...w....|
000001a0  07 07 19 04 92 ff 19 04  c7 ff 1c 50 61 73 73 77  |...........Passw|
000001b0  6f 72 64 20 28 72 65 71  75 69 72 65 64 29 3a 20  |ord (required): |
000001c0  00 73 63 69 74 65 65 6b  2e 6e 75 69 74 64 75 68  |.sciteek.nuitduh|
000001d0  61 63 6b 2e 63 6f 6d 3a  34 30 30 34 00 42 61 64  |ack.com:4004.Bad|
000001e0  20 70 61 73 73 77 6f 72  64 2e 0a 00 62 6b 46 53  | password...bkFS|
000001f0  6d 4a 6c 58 2e 74 78 74  00 5a 6f 6d 66 67 53 63  |mJlX.txt.ZomfgSc|
00000200  69 50 61 64 57 69 6c 6c  52 30 78 78 44 34 46 75  |iPadWillR0xxD4Fu|
00000210  63 6b 31 6e 77 30 52 4c  64 21 21 21 0a 00        |ck1nw0RLd!!!..|
0000021e

There are some weird strings at the end, we look closer...

% strings 11925.ndh             
.NDH
Password (required): 
sciteek.nuitduhack.com:4004
Bad password.
bkFSmJlX.txt
ZomfgSciPadWillR0xxD4Fuck1nw0RLd!!!

It looks like a flag! There is no way that can be true!

% nc sciteek.nuitduhack.com 4004
Password (required): ZomfgSciPadWillR0xxD4Fuck1nw0RLd!!!
You are now authenticated

Yeah well, it was actually that simple, we got the flag, and a nice facepalm because we also reversed it, which was useless here...

Flag: ZomfgSciPadWillR0xxD4Fuck1nw0RLd!!!

Btw, meanwhile, we developped a small disassembler in python. We cracked the rar file and accessed the VM source when we just finished. FU.
We used the instruction set unlocked with the .wav challenge ;)

#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
import sys
from struct import pack, unpack
 
START  = 0x6
STOP   = 0xFFFF
BASE_ADDR = 0x8000
 
OPCODES = { 0x06 : 'ADD',   0x0d : 'AND',   0x19 : 'CALL',      0x18 : 'CMP',   0x0b : 'DEC',
            0x09 : 'DIV',   0x0a : 'INC',   0x1b : 'JMPL',      0x16 : 'JMPS',  0x11 : 'JNZ',
            0x10 : 'JZ',    0x1e : 'JA',    0x1f : 'JB',        0x04 : 'MOV',   0x08 : 'MUL',
            0x02 : 'NOP',   0x0f : 'NOT',   0x0c : 'OR',        0x03 : 'POP',   0x01 : 'PUSH',
            0x1a : 'RET',   0x07 : 'SUB',   0x30 : 'SYSCALL',   0x17 : 'TEST',  0x1d : 'XCHG',
            0x0e : 'XOR'
          }
 
NOFLAG  = ( 'DEC', 'INC', 'JMPL', 'JMPS', 'JNZ', 'JZ', 'JA', 'JB', 'NOP', 'NOT', 'POP', 'RET', 'SYSCALL', 'TEST', 'XCHG' )
 
SPECIAL = ( 'CALL', 'PUSH' )
 
FLAGS   = { 0x00 : 'REG_REG',               0x01 : 'REG_DIRECT8', 
            0x02 : 'REG_DIRECT16',          0x03 : 'REG',
            0x04 : 'DIRECT16',              0x05 : 'DIRECT8',
            0x06 : 'REGINDIRECT_REG',       0x07 : 'REGINDIRECT_DIRECT8',
            0x08 : 'REGINDIRECT_DIRECT16',  0x09 : 'REGINDIRECT_REGINDIRECT',
            0x0a : 'REG_REGINDIRECT'
          }
 
"""
REG_REG                                 => op entre 2 registres
REG_DIRECT8                             => op entre 1 reg et 1 octet
REG_DIRECT16                    => op entre 1 reg et 2 octets
REG                                             => op sur un reg
DIRECT16                                => 2 octets
DIRECT8                                 => 1 octet
REGINDIRECT_REG                 => op entre [reg] et reg
REGINDIRECT_DIRECT8             => op entre [reg] et 1 octet
REGINDIRECT_DIRECT16    => op entre [reg] et 2 octets
REGINDIRECT_REGINDIRECT => op entre [reg] et [reg]
REG_REGINDIRECT                 => op entre reg et [reg]
"""
 
# opcode = 1 byte
# flag = 1 byte
# reg = 1 byte
# DIR8 / DIR16 = 1/2 bytes
 
def get_reg( num ) :
    if num >= 0 and num <= 9 :
        if num == 9 :
            return 'BP'
        elif num == 8 :
            return 'SP'
        else:
            return 'R' + str(num)
    else :
        return '#FAIL' + str(num) # <- c'est moche
 
def reg_reg(reg1, reg2):
    print("%s, %s" % (get_reg(reg1), get_reg(reg2)))
 
def reg_direct8(reg, direct):
    print("%s, BYTE %xh" % (get_reg(reg), direct))
 
def reg_direct16(reg, direct):
    print("%s, SHORT %xh" % (get_reg(reg), direct))
 
def direct16(direct):
    print("SHORT %xh" % direct)
 
def direct8(direct):
    print("BYTE %xh" % direct)
 
def reg(reg):
    print(get_reg(reg))
 
def regindirect_reg(reg1, reg2):
    print("[%s], %s" % (get_reg(reg1), get_reg(reg2)))
 
def regindirect_direct8(reg, direct):
    print("[%s], BYTE %xh" % (get_reg(reg), direct))
 
def regindirect_direct16(reg, direct):
    print("[%s], SHORT %xh" % (get_reg(reg), direct))
 
def regindirect_regindirect(reg1, reg2):
    print("[%s], [%s]" % (get_reg(reg1), get_reg(reg2)))
 
def reg_regindirect(reg1, reg2):
    print("%s, [%s]" % (get_reg(reg1), get_reg(reg2)))
 
def extract(code):
    flag = ord(code[0])
    size = 3 # flag = 1 byte, lval = 1byte, rval = 1+ byte
 
    lval = ord(code[1])
    rval = ord(code[2])
 
    if "DIRECT16" in FLAGS[flag]: # rval = 2 bytes
        size += 1
        rval = int(unpack("<H", code[2:4])[0])
 
    globals()[FLAGS[flag].lower()](lval, rval)
 
    return size
 
# NOFLAGS
 
def disass_DEC(code):
    print get_reg( ord(code[0]) )
    return 1
 
def disass_INC(code):
    print get_reg( ord(code[0]) )
    return 1
 
def disass_JMPL(code):
    print hex( unpack('<h', code[0:2])[0] )
    return 2
 
def disass_JMPS(code):
    print hex(ord(code[0]))
    return 1
 
def disass_JNZ(code):
    print hex( unpack('<h', code[0:2])[0] )
    return 2
 
def disass_JZ(code):
    print hex( unpack('<h', code[0:2])[0] )
    return 2
 
def disass_JA(code):
    print hex( unpack('<h', code[0:2])[0] )
    return 2
 
def disass_JB(code):
    print hex( unpack('<h', code[0:2])[0] )
    return 2
 
def disass_NOP(code):
    print
    return 0
 
def disass_NOT(code):
    print get_reg( ord(code[0]) )
    return 1
 
def disass_POP(code):
    print get_reg( ord(code[0]) )
    return 1
 
def disass_RET(code):
    print
    return 0
 
def disass_SYSCALL(code):
    print "R0 (R1..R4)"
    return 0
 
def disass_TEST(code):
    print get_reg(ord(code[0])) + ', ' + get_reg(ord(code[1]))
    return 2
 
def disass_XCHG(code):
    print get_reg(ord(code[0])) + ', ' + get_reg(ord(code[1]))
    return 2
 
# SPECIALS
 
def disass_CALL(code):
    flag = ord(code[0])
    if FLAGS[flag] is 'REG' :
        print get_reg(ord(code[1]))
        return 2
    elif FLAGS[flag] is 'DIRECT16' :
        #print hex( unpack('<H', code[1:3])[0] )
        offset = unpack('<h',code[1:3])[0]
        print hex( cursor + 3 + 6 + offset ) #3 pour l'instruction, 6 pour le header
        return 3
    else:
        print "<Warning : invalid flag %x>" % flag
 
def disass_PUSH(code):
    flag = ord(code[0])
    if FLAGS[flag] is 'REG' :
        print get_reg(ord(code[1]))
        return 2
    elif FLAGS[flag] is 'DIRECT8' :
        print hex(ord(code[1]))
        return 2
    elif FLAGS[flag] is 'DIRECT16' :
        print hex( unpack('<H', code[1:3])[0] )
        return 3
    else:
        print "<Warning : invalid flag %x>" % flag
 
def die( txt ) :
        print txt
        sys.exit()
 
def get_opcodes_str(code):
    return " ".join("%02x" % ord(code[i]) for i in range(5))
 
def main( argc, argv ) :
 
    f = open( argv[1], 'rb' )
    data = f.read()
    f.close()
 
 
    if "-raw" in argv:
        code = data
    else:
    	if data[:4] != '.NDH' :
        	die( 'Bad ndh header' )
        code = data[START:STOP]
 
    #if data[:4] != '.NDH' :
    #    die( 'Bad ndh header' )
 
    #code = data[START:STOP]
    global cursor
    cursor = 0
 
    while cursor < len(code) :
        opcode = ord(code[cursor])
        cursor += 1
 
        if opcode not in OPCODES :
            print "Warning : skipping unknown opcode %02x" % opcode
            continue
 
        offset = "0x%04x | " % (START + cursor - 1)
        addr = '[' + hex(BASE_ADDR + cursor - 1) + '] '
        opcodes_dump = get_opcodes_str(code[cursor - 1:]) + "\t\t"
 
        sys.stdout.write(offset + addr + opcodes_dump + ' ' + OPCODES[opcode] + ' ')
 
        if OPCODES[opcode] in NOFLAG or OPCODES[opcode] in SPECIAL :
            cursor += globals()[ 'disass_' + OPCODES[opcode] ]( code[cursor:] )
        else :
            cursor += extract( code[cursor:] )
 
if __name__ == '__main__' :
        sys.exit( main( len( sys.argv ), sys.argv ) )

Monday, February 13 2012 22:59

IFSF CTF - Write-up challenge 10

A l'occasion du IFSF CTF j'ai participé aux qualifs avec la team de Zenk-Security, qui a fini 10ème. http://ctf.forbiddenbits.net/?scoreboard.

Je n'ai pas eu trop le temps de participer mais le peu que j'ai fait a été fun (je n'ai pas eu affaire à du guess).
Je présente donc ci-dessous ma solution pour le challenge 10, un binaire DOS, 16 bits. Le binaire: 10.exe

Il s'exécute sans souci sur un Windows XP 32 bits.

Pour le désassembler, IDA bug, et les autres habituels tels que Olly ne prennent pas le 16-bit.
On utilise « Turbo Debugger for DOS », que l'on retrouve ici:

http://www.woodmann.com/collaborative/tools/images/Bin_Turbo_Debugger_2009-6-17_13.16_tdbg55.zip

Le binaire n'a aucun symboles, pas d'appels vers des libs Win etc, juste des interruptions.
On va donc chercher à quel moment il lit les données, pour commencer.
On lit http://en.wikipedia.org/wiki/BIOS_interrupt_call, on se rend compte qu'il nous faut une interruption 16h, qui est celle communiquant avec le clavier. On s'attend à avoir AH set à 0 avant l'interruption.

On trouve alors ce que l'on cherche, en 0x025D:

xor ax, ax
int 16
ret

On va donc break sur le ret, en 0x0261, pour revenir dans la fonction qui a demandé à lire le char, pour étudier celle-ci.
Après un run, avoir entré un char (on n'entre que des 'a'), et step, on retombe juste en dessous, en 0x026F:

0x026F:   
       mov si, [0114]
       mov bl, 09
 +> call [0104]                 ; call 0x25D / read char
 |     test al, al
 |     je 028B    ----+
 |     cmp al, 0D     |
 |     je 028B     ---+
 |     rol al, 03        |
 |     xor al, 19       |
 |     mov [si], al    |
 |     inc si              |
 |     ...                   |
 |     test bl, bl       |
 |     je 028B   ----+
 +-   jmp 026B      |
       ret         <---+

Cette fonction lit 9 char, sauf si elle reçoit un 0x0 ou 0xD ( '\r' ).
Cela nous donne une fonction similaire à la suivante en C:

void get_input(void)
{
    char s[10] = 0; // &s = 0x138 ( si )
    char c;
    int bl = 9;
    int i = 0;
 
    while (1)
    {
         c = getchar(); // al = c
 
         if (c == 0x00 || c == '\r')
             return s;
 
         if (bl-- == 0)
             return s;
 
          asm volatile("rol $0x03, %%al\r\n
                               xor $0x19, %%al\r\n"
                               : "=a"(c)
                               : "a"(c)
                               : "ax"); // Probablement n'importe quoi niveau input / output / clobber :D
 
          s[i++] = c; // mov [si], al ; inc si
    }
}

On retient surtout que notre chaîne est stockée « cryptée » en mémoire, avec un rol / xor appliqué sur le char reçu.
Entrer 'a' écrit 0x12 en mémoire.

On break sur le ret, en 0x28b, puis on step pour arriver sur:

call [010A] ; Affiche "Authorization code :"
call [0106] ; Lit le code
call [010E] ; ? Check code ?
ret

On suit donc l'exécution, on tombe sur:

mov bx, [0x114]
mov si, [0x116]
mov cx, 0x9
xor dx, dx
xor ax, ax
mov al, [bx]
xor al, [si]
test al, al
jz 0x145

Cette partie compare 2 chaînes, et on retrouve notre chaîne « cryptée » 0x12 * 9.


debug_dos

Elle est comparée à celle pointée par si (0148): 0xA0 0x8B 0x98 0x7B 0x63 0x90 0x98 0x90 0x63

On sort python pour inverser le xor / rol et:

>>> def ror(byte, count):
...     while count > 0:
...         byte = (byte >> 1 | byte << 7) & 0xFF
...         count -= 1
...     return byte
... 
>>> l = [0xA0, 0x8B, 0x98, 0x7B, 0x63, 0x90, 0x98, 0x90, 0x63]
>>> ''.join(chr(ror(0x19 ^ i, 3)) for i in l)
'7R0LO101O'

On a notre flag: 7R0LO101O.

Thursday, April 7 2011 20:50

NDH2k11 Prequals - Rce100

A priori, c'est un binaire win32 normal, apparemment packé mais PeiD ne trouve pas de signature.

On commence par l'ouvrir sous OllyDbg v2, la version 1 ayant du mal à l'analyser. On tombe directement sur l'instruction PUSHAD, qui fait penser à un packer UPX-like. Une recherche de la commande POPAD confirme cette intuition, et il suffit de mettre un breakpoint à l'adresse 00466F1B puis F9 pour unpacker l’exécutable.

rce100_pic1

Une analyse de la table des appels inter-modulaires ne nous révèle pas d'appels intéressants concernant une éventuelle comparaison de serial, on va donc breaker sur les appels à SendMessageA (sauf celui avec WM_MOUSELEAVE) pour intercepter les évènements de clicks et autres sur la fenêtre.

rce100_pic2

On run avec F9, et on entre un serial bidon (abcdef). On est interrompu après avoir entré le premier caractère car Olly a breaké sur un appel à SendMessageA. Après être entré dans le CALL suivant l'appel et quelques F8 plus tard on tombe sur une boucle qui semble compter le nombre de caractères entrés dans la textbox (en 4042F5)

rce100_pic4

Enfait la fonction dans laquelle on se trouve est chargée de dessiner la textbox avec les caractères qu'on a entrés, donc useless pour ce qu'on veut faire. Néanmoins, elle permet de récupérer l'adresse mémoire de l'emplacement de la chaîne, contenue dans EDX à ce moment là (soit 9866E8 ici).

On note cette adresse précieusement, elle servira plus tard :)

Maintenant on enlève le breakpoint en 404657 sinon on va être interrompu après chaque nouveau caractère entré dans la textbox, et on tape notre serial bidon : abcdefg, puis on clique sur Login. Olly break une fois de plus sur un appel à SendMessageA. Pour trouver la routine de vérification, on place un breakpoint mémoire à l'adresse du serial 9866E8, puis F9 pour relancer le programme. Olly break en 403F76.

rce100_pic5

Quelques F8 plus loin, on tombe sur cette fonction :

rce100_pic6

On remarques quelques lignes plus haut le CALL 0041EC50, puis la comparaison entre EAX et un une constante hexadécimale. Regardons cette fonction de plus près :

rce100_pic7

On voit ici que cette fonction génère un hash avec les caractères du serial, il reste donc plus qu'à recoder la fonction en C et lancer un bruteforce jusqu'à obtenir le bon checksum. Pour viser large on prend comme charset la plage ascii 48;122.

#include <stdio.h>
#include <stdlib.h>
 
#define MIN 48
#define MAX 122
 
void bf(char* input,int lenght)
{
	int i;
	int eax;
	int esi = 0xdeadbeef;
	for(i=0;i<lenght;i++)
	{
		eax = input[i];
		esi = esi*0x38271606;
		eax = eax*0x5b86affe;
		esi = eax - esi;
	}
 
	if(esi==0xc4b1801c)
	{
		printf("Password : %s",input);
		exit(0);
	}
}
 
void construct(char* input,int i,int j)
{
	if(i==j)
	{
		bf(input,j);
	}
	else
	{
		int k;
 
		for(k=MIN;k<=MAX;k++)
		{
			input[i]=k;
			construct(input,i+1,j);
		}
	}
}
 
int main()
{
 
	char pass[1024];
 
	int i;
 
	for(i=1;i<20;i++)
	{
		construct(pass,0,i);
		printf("Lenght : %d\n",i);
	}
 
	return 0;
}

Après quelques secondes, on trouve pWn3D.

Tuesday, April 5 2011 16:40

NDH2k11 Prequals - Rce200

Deuxième épreuve de Reverse qui avait pour support une application Android.

Fichier : "RCE200.apk"

Fort de la lecture des slides de Virtualabs concernant le reverse d'application Android, nous savions que les sources Java de l'application étaient disponibles grâce à 2 outils : Dex2Jar (Transformer le .apk en .jar contenant des .class (Bytecode Java)) et JD-GUI (Permet l'affichage des .class en .java).

Nous découvrons que l'application se compose de 4 fichiers :
- "ReverseMe.java"
- "a.java"
- "b.java"
- "c.java"

Tout d'abord, je tiens à préciser que j'ai pas utilisé de device Android pour résoudre cette épreuve ni utilisé d'émulateur, seule la lecture des sources m'a permis de choper le flag.
Allez, c'est parti pour de l'analyse !

Commençons par le fichier "c.java"

package ndh.prequals.rce;
 
public final class c
{
  private static byte[] a = { 90, 5, 88, 88, 13, 13, 90, 90, 10, 4, 9, 11, 93, 90, 11, 15, 93, 95, 5, 93, 5, 8, 8, 88, 90, 95, 9, 14, 90, 8, 13, 94 };
  private static byte[] b = { 91, 83, 83, 91, 80, 89, 99, 79, 88, 87 };
  private static byte[] c = { 113, 120, 9 };
  private static byte[] d = { 93, 82, 88, 78, 83, 85, 88, 18, 79, 76, 89, 89, 95, 84, 18, 93, 95, 72, 85, 83, 82, 18, 110, 121, 127, 115, 123, 114, 117, 102, 121, 99, 111, 108, 121, 121, 127, 116 };
  private static byte[] e = { 111, 116, 125, 17, 13 };
 
  public static String a()
  {
    return a(a);
  }
 
  private static String a(byte[] paramArrayOfByte)
  {
    byte[] arrayOfByte = new byte[paramArrayOfByte.length];
    int i = 0;
    while (true)
    {
      int j = paramArrayOfByte.length;
      if (i >= j)
        return new String(arrayOfByte);
      int k = (byte)(paramArrayOfByte[i] ^ 0x3C);
      arrayOfByte[i] = k;
      i += 1;
    }
  }
 
  public static String b()
  {
    return a(b);
  }
 
  public static String c()
  {
    return a(c);
  }
 
  public static String d()
  {
    return a(d);
  }
 
  public static String e()
  {
    return a(e);
  }
}

Les attributs a,b,c,d,e sont des strings, mis sous forme de tableau de Byte.
On voit très clairement que la fonction private static String a(byte paramArrayOfByte) {} effectue un XOR chaque caractère de la chaine d'entrée et la clé 0x3C.

Réflexe: passer les strings a,b,c,d,e dans la fonction a() histoire de voir quelles nouvelles chaines on obtient (chars imprimables ou non).

Résultat:

a="f9dd11ff6857af73ac9a944dfc52f41b"
b="google_sdk"
c="MD5"
d="android.speech.action.RECOGNIZE_SPEECH"
e="SHA-1"

Tiens tiens, "MD5", "SHA-1" ça sent le hash là dedans garçon !

Au passage, on remarque avec lucidité que la string a fait 32 caractères, on essaie donc de voir si ce n'est pas le hash MD5 d'une quelconque chaine.

Et là bingo, passcracking.ru nous indique que c'est le hash MD5 de "salope".

Élégant non ?

Comme je l'ai dit plus haut je n'avais pas de device Android durant cette épreuve. A ce moment de l'épreuve, je ne savais pas donc pas que la saisie de notre input se faisait via une méthode de Speech-to-Text. La chaine "android.speech.action.RECOGNIZE_SPEECH" m'a mis sur la piste.

Passons au fichier "a.java"

package ndh.prequals.rce;
 
import android.os.Build;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
 
public final class a
{
  public static String a(String paramString)
  {
    try
    {
      MessageDigest localMessageDigest = MessageDigest.getInstance(c.e()); //c.(e)="SHA-1"
      byte[] arrayOfByte = paramString.getBytes();
      localMessageDigest.update(arrayOfByte);
      localObject1 = localMessageDigest.digest();
      StringBuffer localStringBuffer1 = new StringBuffer();
      int i = 0;
      int j = localObject1.length;
      if (i >= j)
      {
        localObject1 = localStringBuffer1.toString();
        return localObject1;
      }
      String str;
      for (Object localObject2 = Integer.toHexString(localObject1[i] & 0xFF); ; localObject2 = str)
      {
        if (((String)localObject2).length() >= 2)
        {
          StringBuffer localStringBuffer2 = localStringBuffer1.append((String)localObject2);
          i += 1;
          break;
        }
        str = "0" + (String)localObject2;
      }
    }
    catch (NoSuchAlgorithmException localNoSuchAlgorithmException)
    {
      while (true)
        Object localObject1 = null;
    }
  }
 
  public static boolean b(String paramString)
  {
    try
    {
      MessageDigest localMessageDigest = MessageDigest.getInstance(c.c());//c.(c)="MD5"
      byte[] arrayOfByte1 = paramString.getBytes();
      localMessageDigest.update(arrayOfByte1);
      byte[] arrayOfByte2 = localMessageDigest.digest();
      StringBuffer localStringBuffer1 = new StringBuffer();
      String str1 = c.b();
      String str2 = Build.PRODUCT;
      if (str1.equals(str2))
        StringBuffer localStringBuffer2 = localStringBuffer1.append(65);
      int i = 0;
      int j = arrayOfByte2.length;
      if (i >= j)
      {
        String str3 = localStringBuffer1.toString();
        String str4 = c.a();
        bool = str3.equals(str4);
        return bool;
      }
      String str5;
      for (Object localObject = Integer.toHexString(bool[i] & 0xFF); ; localObject = str5)
      {
        if (((String)localObject).length() >= 2)
        {
          StringBuffer localStringBuffer3 = localStringBuffer1.append((String)localObject);
          i += 1;
          break;
        }
        str5 = "0" + (String)localObject;
      }
    }
    catch (NoSuchAlgorithmException localNoSuchAlgorithmException)
    {
      while (true)
        boolean bool = false;
    }
  }
}

Une analyse rapide des méthodes a() et b() de cette classe nous indique que:
- a() nous renvoi le hash SHA-1 de la chaine passée en paramètre
- b() compare le md5 du mot prononcé avec c.a() ( c.a()="f9dd11ff6857af73ac9a944dfc52f41b"=md5("salope") )


Voici le contenu du fichier "b.java"

package ndh.prequals.rce;
 
import android.content.Intent;
import android.view.View;
import android.view.View.OnClickListener;
 
final class b
  implements View.OnClickListener
{
  b(ReverseMe paramReverseMe)
  {
  }
 
  public final void onClick(View paramView)
  {
    ReverseMe localReverseMe = this.a;
    if (paramView.getId() == 2131034114)
    {
      String str = c.d();
      Intent localIntent1 = new Intent(str);
      Intent localIntent2 = localIntent1.putExtra("android.speech.extra.LANGUAGE_MODEL", "free_form");
      Intent localIntent3 = localIntent1.putExtra("android.speech.extra.PROMPT", "Enter password");
      localReverseMe.startActivityForResult(localIntent1, 1234);
    }
  }
}

Cette classe gère la partie graphique, met en place les Listeners et gère l'évenement onClick (qui correspond au click tactile de l'utilisateur, pour valider sa saisie)

Donc pas grand chose à tirer de cette classe.

Et enfin, voici la classe la plus intéressante "ReverseMe.java"

package ndh.prequals.rce;
 
import android.app.Activity;
import android.content.Intent;
import android.content.pm.PackageManager;
import android.os.Build;
import android.os.Bundle;
import android.widget.Button;
import android.widget.TextView;
import java.util.ArrayList;
import java.util.List;
 
public class ReverseMe extends Activity
{
  private a a = null;
  private TextView b = null;
 
  protected void onActivityResult(int paramInt1, int paramInt2, Intent paramIntent)
  {
    if ((paramInt1 == 1234) && (paramInt2 == -1))
    {
      ArrayList localArrayList = paramIntent.getStringArrayListExtra("android.speech.extra.RESULTS");
      if ((!localArrayList.isEmpty()) && (a.b((String)localArrayList.get(0))))
      {
        TextView localTextView = this.b;
        String str = a.a((String)localArrayList.get(0));
        localTextView.setText(str);
      }
    }
    super.onActivityResult(paramInt1, paramInt2, paramIntent);
  }
 
  public void onCreate(Bundle paramBundle)
  {
    super.onCreate(paramBundle);
    setContentView(2130903040);
    Button localButton = (Button)findViewById(2131034114);
    TextView localTextView = (TextView)findViewById(2131034113);
    this.b = localTextView;
    PackageManager localPackageManager = getPackageManager();
    String str1 = c.d();
    Intent localIntent = new Intent(str1);
    if (localPackageManager.queryIntentActivities(localIntent, 0).size() != 0)
    {
      String str2 = c.b();
      String str3 = Build.PRODUCT;
      if (!str2.equals(str3))
      {
        b localb = new b(this);
        localButton.setOnClickListener(localb);
      }
    }
    a locala = new a();
    this.a = locala;
  }
}

La méthode onCreate() va juste instancier les élements graphiques de l'application.

La méthode onActivityResult() gère les interactions entre les éléments de cette application, donc entre ce que l'on va prononcer et le fait de réussir ou non l'authentification.

Rapide commentaire des principales instructions de la méthode onActivityResult().

ArrayList localArrayList = paramIntent.getStringArrayListExtra("android.speech.extra.RESULTS");
/* Récupère ce que l'utilisateur a prononcé et le met dans localArrayList */
 
 
if ((!localArrayList.isEmpty()) && (a.b((String)localArrayList.get(0))))
/* Si localArrayList n'est pas vide et que l'utilisateur a prononcé "salope" .... */
 
String str = a.a((String)localArrayList.get(0));
localTextView.setText(str);
/* ...alors le hash SHA-1 de "salope" est affiché. */

Le flag de cette épreuve était donc "913beccad686975f8c686d9b3b1ee6bb97c22d6f"

Épreuve originale, accessible et fun !

Que demande le peuple ?

NDH2k11 Prequals - Rce300

L'épreuve qui nous a donné le plus de mal, est sans doute la RCE300. C'était la dernière épreuve qu'il nous restait, et toute la team s'y est attaqué afin de finir ces préquals :p

On nous fournissais un fichier crackme.nds, avec pour seule indication qu'il s'agissait d'une application pour nintendo DS !

L'intéressant ici était de se documenter sur le format, et d'arriver à se faire un environnement de débug + reverse :)

Au final, nous avons utilisé les outils suivants :

Avec ça on est paré, on peut donc maintenant lancer DeSmuME en mode dev avec la commande :

DesMume_dev.exe --arm9gdb=5555 crackme.nds

Pour y attacher ensuite un gdb, avec la commande :

target remote localhost:5555

rce300_gdb_desmusme.png

On utilise ensuite IDA, avec le loader permettant de charger le *.nds :

rce300_ida_nds.png

Au passage il est bon de noter que la DS utilise un processeur ARM, il va donc falloir se documenter un peu sur l'ARM, ici, ici, ici et ici.

En cherchant la chaîne password, on tombe sur une première routine intéressante : sub_20002B8. Dans laquelle on voit clairement l'affichage du prompt et la demande de serial (on devine que sub_2003888 est un printf() et que sub_2003ACC est un scanf()) : rce300_ida_printf_scanf.png

On voit ensuite que si on entre un serial, le chemin emprunté passe par 2 boucles qui ont la même structure :

  • Multiplication de R0 par une constante
  • Appel de sub_2003530 (qui prend en paramètre R0, et le caractère courant du serial entré dans R1, et qui renvoie R0 modifié)
  • Xor de R0 par une constante
  • En fin de boucle : comparaison de R0 à une checksum : granted si les 2 checksums matchent, denied sinon !

gdb_ida_checksums.png

On voit que :

  • La première checksum est 0x33E0D2F1
  • La deuxième checksum est 0xBCFA8D3F

Et enfin, on analyse la fonction sub_3530, qui était assez impréssionnante : rce300_ida_sub3530.png

Plusieurs hints avaient été données sur l'IRC #ndhprequals, notamment qu'il fallait faire un brute-force, et qu'il fallait se limiter au charset alphanumérique et à une longueur de 6 caractères. En refaisant l'alogrithme en C (le plugin hex-rays pour IDA peut grandement aider...) on est alors capable de faire un rapide bruteforce, qui au bout de quelques dizaine de minutes nous a sorti le serial valide "DsLrox" ! \o/

Voilà donc une épreuve vraiment sympathique, dont le plus intéressant pour moi a été de découvrir comment mettre en place un environnement de débug comme celui ci. Et ce fut également un bel exemple de travail en équipe ;)