I was able to pick up a pre-released copy of The IDA Pro book at Defcon in the vendor area, thanks to Adam from No Starch. This book is not an introduction to reverse engineering, its a hard core manual for IDA Pro. IDA Pro is a critical weapon in any reverser’s arsenal, so proficiency in this tool is paramount to your success in reverse engineering. If you are new to IDA Pro you need this book, even if you’ve been working with IDA for a while you will more than likely learn quite a few things after reading it. Unlike the two other books I’ve read on IDA Pro this book has no fluff or filler, its solid information! The funny thing when comparing it to the other two IDA books is its thicker than both combined, and contains an exponentially larger amount of information.

The author takes time to explain things in a very clear manner as you walk through from an introduction to the tool to more advanced usage such as customizing, extending IDA, debugging, and dealing with obfuscated code. The author answered questions I had been spent weeks asking and searching the Internet for.

Likes:

Just about everything. The author walks you through plenty of code and discusses scenarios where you could apply the information he is giving you. The fact that he took his time to elaborate on why, and when you might use a piece of information is unlike many authors whom will give you information and leave the reader wondering “What would I use that for”.

This book does not just talk about Win32 and Portable Executable format, ELF binaries have a continual guest appearance throughout the book, and firmware/binaries are mentioned in numerous chapters.

Side bar elaboration is kept to a minimum, I often find in texts that an author will go on about background information that does not add anything significant to what I am reading. Chris Eagle keeps this to a minimum adding small side bars when necessary but only take up a small amount of real estate.

Dislikes

My only dislike of this book was the use of PE format as the example in chapter 18 – Binary Files and Ida Loader modules. Despite the use of a well known format chosen for this example the concepts were clearly displayed. I think it would have made it more interesting if the author had used a lesser known format, or do as the author of “Reversing, Secrets of Reverse Engineers” did and create his own binary.

Finally back in SA after a week of debauchery out in Las Vegas with my crew from LSO. Times were good this year, between Carnal0wnage getting the hook up, Tebo, and Adam knowing everyone, and Dean and mines taste of elegance and high class women it was an awesome time. We got into a crap load of the parties which were fine and great but they mostly lacked women. Dean and I spent many nights in the lounges of the Bellagio getting drunk and talking about various things. This was the first time I actually met all those dudes so it was really cool!

I’m still tossed up about the talks though; I did not feel they were that great this year. There were a few that caught my attention and were well spoken. Penetration testing is dead, Malware RCE, Vulncatcher just to name a few at defcon. Blackhat as usual was only two day’s but it felt like it lasted forever. Although a few good talks popped up nothing shot out at me as being new. Of course, you had all the hype about the Kaminski bug, and he got a little butt hurt when they gave him a pwnie for the most hyped bug. I was two rows back for that, it was amusing.

Dean and I met a few people one evening and I turned into a 5:30 a.m bedtime when I finally departed and went back to my hotel. Hopefully that will turn into a few consulting gig’s.

We all came back pumped full of motivation, me included. I picked up a copy of “The Ida Pro Book” by Chris Eagle and I’m reading through it during the day. After talking with one of the immunitysec guy’s he suggested we split our stuff up and not do the same thing each day otherwise we might burn out on it. So I’ve been playing with different stuff, going to attempt to avoid burn out over the next course of the year while still growing in my ability to do shit.

For the next few weeks, I’ll be busy as all hell. Got a bunch of stuff to read and catch up on. I’ve Got some presentations to make, potentially a chicon presentation to create, 3 more classes left for my Masters degree. I made an entire list of things on the plane, basically born from talks at blackhat, or discussions in the hallway. I’ll try to post up!

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  . 0FB615 0331006&gtMOVZX EDX,BYTE PTR DS:[69003103
 
To:
690010C7  . 3005 D9300069  XOR BYTE PTR DS:[690030D9],AL              XOR 0x20, arg 2

Are crap instructions. I mean, they do something but they are overwritten starting in the next instruction.

We pick back up with:

1

690010CD  . 8A0D D5300069  MOV CL,BYTE PTR DS:[690030D5

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!

 Subscribe in a reader

http://twitter.com/phn1x

Yea yea I know, I’m becoming a social networking whore!