Every time I use Immunity Debugger I can’t help thinking how I could live until now without it.
I’m not going to write a love song in this post, but instead enumerate some of the reasons which make ID one of the best RE tools, ever.
At a first glance, Immunity Debugger is “just like Olly but the colors are better” [Dino Dai Zovi said that]. A second look at it confirms although what muts (from Offensive Security) stated: “This is light years from Olly… light years…”
Without any doubt, the most impressive aspect of ID is its ability to run PyCommands, that is, python plugins using the internal immunity library. It’s so easy as write a bit of python code, place it into the PyCommands directory and you are ready to go.
You can execute your bright new PyCommand by writting in Immunity’s command line toolbar (located at the bottom):
The syntaxis is rather “friendly” and the API is well documented. Moreover, the standard collection of scripts ID is delivered with are more than enough to accomplish most of the daily tasks :)
Below a short description of just some of them:
This command walks through the command and logs jumps to API (Win32) functions. It’s very useful to perform a quick and dirty code coverage. Although there is a nag: it will follow the logic of the code, that is, non-linear and it will log every occurrence, that is, the same Win32 API call will appear several times.
Anyway, nothing that a bit of grep couldn’t fix :)
Here an example:
How neat is that?
This illustrates the power of the immunity library. The command finds the packer using the PEiD engine, but it’s actually nothing more than a convenient wrapper for the function imm.findPacker()
This is another neat feature and is not the only one regarding heap analysis (a.k.a. pain in the ass)
It’s used to, among other things, dump a certain heap region.
And this all, accomplished with just a few Python lines.
This one is specially cool. It patches the loaded binary in order to avoid most of the antidebugging tricks out there.
Here a list, from a comment inside the source code itself:
o IsDebuggerPresent (With Poly-patch code, as too easy to detect Xor EAX, EAX)
o PEB.Ldr 0xFEEEFEEE filling
o GetTickCount (With poly-patch code, as too easy to detect Mov EAX, xxxxxxxx)
o ZwQuerySystemInformation (Used by CreateToolHelp32Snapshot / Process32First / Process32Next and others)
Poly-patch is a patching method using custom functions which randomly use different patching schemes, in order to increase the entropy of the patched sections.
This one is worth mentioning for two reasons. One, implements a neat feature, allowing you to see SSL encrypted traffic in clear text, hooking the encryption/decryption functions. Two, precisely because of the way it operates, the code is a perfect example of advanced hooking for reading and modification of function arguments.
If you are interested in learning about how to implement hooking in Python or just need a refresh, this code is highly recommendable. (I have just read the last sentence… and it sounds really nerdy, but do it! ;))
This helps to identificate zones of the code where standard cryptographic methods have been used, using some kind of binary signatures. Probably you won’t need it, but if one day you need to find out this kind of information, you’ll be so happy to have this command that you’ll send a Gift basket to the developer for Christmas every year ;)
That should do for now, more to come in part 2!