khallenge 2008, Challenge 1
I posted up a link the other day about the F-secure 2008 Reversing challenge, or khallenge. I got a little side tracked with things to do around the house Pre Vegas, and the prerequisite quality time so my bride isn’t completely pissed at me. I took a quick look at it Friday before leaving work but completely dropped it until this evening. When you first load it up in Ida Pro and browse through it you will see there is a lot of XOR’ing of 8 bit registers with Bytes. When you jump to the bytes in IDA, some of them already have values (initialized) and others don’t.
This challenge is going to be much easier utilizing dynamic, versus static analysis so it’s off to Olly or Immunitydbg we go! From either Ida Pro, or your debugger of choice you can see after the printing of the message, printing of the input request, and subsequent scanning thereof there is a loop followed by a comparison.
If you happen to have Hex-Ray’s, you can cheat a little, hit F5 and get some pseudo code. Otherwise, you have to figure out this is a compiler optimized strlen function. Although it’s not necessarily important it may trip you up. All it’s doing is scanning the string byte by byte looking for the terminating zero (text cl,cl).
After our compiler optimized strlen, we see a cmp eax, 4. This is testing that our input is 4 bytes long. If not, we jump to a “sorry…” message. So, we can conclude our input is 4 bytes long, or 4 chars.
Next we get into a crap load of XOR’s with bytes, and registers. There’s a lot going on here so it’s really important to:
- Keep a piece of paper handy
- Set a break point at every address within the algorithm
- Put in well crafter input (such as 1234, abcd)
Point number 3 was something I completely neglected. Working with MC for so long I got used to putting a stream of A’s, as my input I did the same here. It hindered me more than anything because I couldn’t differentiate the input at first. I left my comments in the screen shot for you to follow down (and for my own sanity while I was working on it).
I used the input “abcd” which allowed me to follow the data movements since it was not sequential. Our first instruction moved a PTR to EDX, when we press F9 in ImmunityDBG we see the value 63 or “c” loaded in the EDX register. Our next instruction moves the value in input1 (“a”) to the EAX register.
We see 3 XOR Operations, 2 with AL and one with DL. As we follow the program through the debugger we discover that only the last XOR is valid. Going back to Ida Pro we jmp to the byte definition for the last XOR to find out it’s value. As it turns out the byte is initiated with a value of 0×70 The instruction that follow from:
1 2 3 4 | 690010B3 |
Are crap instructions. I mean, they do something but they are overwritten starting in the next instruction.
We pick back up with:
1 | 690010CD |
Again we used Ida Pro to find the value of the byte ptr, it turns out to be 0×2e.
After this we move the 3rd byte into EDX, and the 4th into EAX. The second byte, still loaded in CL is XORED with 0×2e, the 3rd byte Xored with 0×76, and the 4th xored with 0×68.
After all the Xoring madness stop’s, we find outselfs at a cmp instruction. We need the second argument to somehow turn out a value 0×61 after being xored with 0×2e. Following the Code down, we see other comparison’s. We just need to figure out what byte ptr’s they are referring to by looking back at the instructions.
Easy, Inverse XOR the values to arrive at X. Really the hardest part is following the byte ptr’s around and keeping track of what is being compared.
We arrive at
Arg 1: x = 0×70 ^ 0×32, x = 0×42 or “B”
Arg 2: x = 0×61 ^ 0×2e, x = 0×4F or “O”
Arg 3: x = 0×30 ^ 0×76, x = 0×46 or “F”
Arg 4: x = 0×79 ^ 0×29, x = 0×50 or “P”
When we restart the debugger and enter “BOFP” we are quickly directed (after removing our breakpoints) to:
This gives us the Email address to send an email to in order to receive challenge 2! Unfortunately I didn’t get this knocked out till a little while ago!
