Book Review: The IDA Pro Book

Chris Eagle’s long-awaited The IDA Pro Book has a very straightforward title, but it is perhaps the most descriptive title possible for this book.  It is simply the IDA Pro book.  The book weighs in at 640 pages and really does an excellent job of covering everything from the basic usage of IDA to using the SDK to extend IDA’s capabilities.  While IDA Pro comes with documentation, it is nowhere near as comprehensive or easy to read.

Chris Eagle is clearly an excellent educator, as he makes the sometimes very dense and technically involved material easy to read and understand and also chooses his examples well.  One of my personal favorites is an extended example on writing an IDA processor module for Python bytecode.  The bytecode’s simple stack language made it easy to focus on the specifics of writing IDA processor modules without getting bogged down in architectural details.  The amount of material spent on how to extend IDA is also unique to this book.

This book does not cover the basics of the x86 architecture and x86 assembly, so it is assumed that the reader is already familiar with it.  The book also does not spend too much time on showing how to identify high-level language constructs (functions, C++ virtual methods, switch tables, loops, etc) in assembly.  After all, this is a book on how to use IDA, not a book on how to read disassembly.  For an extensive treatment on how to read disassembly, check out Kris Kaspersky’s Hacker Disassembling Uncovered or Eldad Eilam’s Reversing: Secrets of Reverse Engineering.

There are several skill levels of IDA Pro users.  The casual (can follow strings or imports references to interesting functions), experienced (can use custom structures to make code easier to read), advanced (can turn assembly into C pseudocode manually), and professional (can write custom IDC scripts and plugins to automate repetitive and/or difficult tasks).  This book makes getting to the higher levels much easier and should really be considered an essential purchase along with an IDA license for any serious user.


  1. I like your progression of IDA skills, though I actually think of it almost in the opposite order. Also, I’m actively procrastinating reversing something at the moment, so it seems fitting that I should posture about reversing on your blog instead of actually doing it. :>

    Anyway, I started by converting everything back to C from assembly, but Thomas basically relentlessly mocked me until I developed a complex about it. He also mocked me for using gdb, which was apparently tragically unhip. In case you were curious, the cool kids apparently use adb, which I believe is sort of like a combination of a 1982-era RPN HP calculator and being stabbed in the face.

    I currently fall into the category of the guy who tries to use all the features I can. I basically need all the magic help I can get, and also having stuff to play with in the periphery of the idb is a good way to pretend that I’m working without having to do a whole lot of actual reversing. I do however draw the line at using the debugger, as that would probably run dangerously close to making me productive in C++ code.

    Mark is a better reverser than I (lol, most unnecessary sentence ever), but he doesn’t really use much of the built-in stuff, and just annotates the idb with comments. I tried to get him to use the struct interface once but he was deeply suspicious that it was some sort of elaborate trap to make him bad at computers.

    Neel is better than both of us, and I don’t think he even uses comments. He just sees it. It actually makes me angry to think about it.

    IIRC, Thomas seemed to prefer deadlisting with objdump to IDA for some reason, though it was a really long time ago. Also, he probably did that just to mess with me. Pretty sure he was secretly using gdb when I wasn’t looking.

    Anyways, thought I’d share. :> I have a terrible dark expensive shameful secret, which is known as Hex-Rays. I swear to god it’s awesome. I think basically everyone should be given a copy on their 30th birthday, as it can definitely help you buy a couple of months before your inevitable descent into technical mediocrity and male pattern baldness.

  2. @JohnMcDonald
    Heh, I guess the progression that I listed betrayed how I learned IDA and reverse engineering (although I am hesitant to admit that I have yet to actually write any IDC scripts or plugins). Yes, I am the sunday afternoon kind of IDA user these days…

    Adb rocks! I learned how to write SPARC overflows using it and the Solaris crash dump analysis book. You had to scroll up to see all the registers w/ gdb but adb displayed them nicely in a way that fit a 80×24 terminal perfectly. At DEFCON someone asked me why I didn’t use gdb and honestly I didn’t know at the time that you could step by single instructions in gdb, so I had always used adb.

    I so crave Hex-Rays. While I can convince my employer that I need an IDA Pro Advanced license, I have yet to be able to justify paying for licenses for the more fun toys like Hex-Rays and Bin Navi (sorry Halvar!). I prematurely signed up for technical mediocrity already, so I don’t have to worry about being lame and using Hex-Rays. Do you wanna see my Excel macros to score vulnerabilities and make pretty pictures?

  3. Damn, I guess I really did miss out on the whole adb thing. All I remember is $ r and $ q I think. You weren’t kidding about learning how to write SPARC overflows, as I stumbled on this the other day:

    I’m impressed. That took forever for me to sort out, and it’s clearly pretty important. I had always meant to go actually study the kernel code that performed the stack flush/return to userland setup of the register windows before I tried to explain it publicly. Never got around to it, and I likely would have failed if I tried. Probably pretty hard. :>

    That’s funny that by that time the loading down the machine thing was a known idiom. I did it in a few exploits but never felt comfortable really telling anyone about it because I wasn’t 100% on the details. I did offer a sort-of explanation of inducing load to flush register windows in the header of this one:

    I made a really stupid mistake in there with memset(), so I hope my reasoning was correct and not just a lucky artifact of my larger C fail. ;>

    How bout if I pretend that you preferred adb solely for aesthetic reasons, you’ll overlook the conspicuous omission of register window flushing semantics from my sparc overflow paper? :>

    Hexrays is great, but yeah, I don’t know if it’s $2300 great unless you can spend someone else’s money on it. :> There haven’t been any updates in a little while, but the recent-ish IDA addition of the local type database was a huge step for making it more effective.

    I think in reality, IDA is probably worth a lot more than he charges for it, so maybe this is his way of making up for his lost millions. ;>

  4. One last thing – I had a theory that you could also get a context switch / flush from a page fault if it accessed memory/code it hadn’t touched before and needed to pull off disk. (or writing to a copy-on-write page maybe) I never got around to testing it though, so I might have been massively wrong.

  5. Thanks🙂. But to be fair, I only understood that stuff after trying to figure out what the hell you meant in that exploit. And I even got it wrong publicly also, I made some patently false statements that you can probably find if you look hard enough. I really only started writing SPARC stuff in early 2000, and that was just lame locals and remotes in crappy web servers, not remotes in BIND (!!@#$). By then, you had already done most of the hard work.

    I ran into similar issues on PowerPC. The problem there isn’t register windows, it’s the separate data and instruction cache. I’ll probably write a big blog post on this eventually, but the short version is that with a write-back separate instruction cache, your shellcode isn’t where you expect it to be. When you jump to the overwritten return address, the CPU fetches instructions directly from RAM and your shellcode is not written to RAM until it is expired from the data cache. So in order to run your shellcode, you have to cause a trap, system call, or page fault.

    So your theory is totally correct. In my first exploit for DaveG’s OSX AFP bug, I got lucky b/c I could usually trigger a page fault, but it wasn’t deterministic. I described this problem to dvorak @ DEFCON one year and he asked me, “why not just force it to execute a system call?” And I thought, duh, that’s way easier. My next version did a ret-into-libc to execute getuid() and then jumped into my shellcode. That made the exploit 100% reliable🙂.

    Thanks for the great comments, btw.

  6. Yeah, I think I dialed in an appropriate level of vagueness for that comment, as I was pretty curious what the hell I meant too. ;> I think getting stuff like you mentioned wrong comes with the territory when you’re pushing into undocumented stuff. God, a 15-minute conversation with a kernel engineer at Sun probably would have saved us a lot of pain. :>

    Just checked out your PowerPC post. Very cool.. I had no idea it was that nuanced, especially with the different designs of L1 cache across the different chips. Mark and I were musing the other night that Intel becoming the dominant PC platform is actually something of a slightly lucky draw for exploitation, as there’s so many little details that roughly work out in your favor. Not to say that it’s really materially easier by any means, as it’s clearly still a challenge. That said, there is a slight confluence of events that you probably wouldn’t notice (or care about ;>) unless you’d spent too much time banging your head against other architectures. (thinking alignment, caching, stack semantics and direction, variable length instructions/fluid instruction boundaries, delay slots, lil endian for partial overwrites, read/exec, and other small random details I’m probably forgetting or otherwise cut both ways).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 5,896 other followers

%d bloggers like this: