When IDA introduced debugging facilities years ago, the task of analyzing hostile code became more enriched: no more looking at static code and figuring out what it does, instead just run the malware in a virtual machine and debug it remotely, even debug just a small code snippet from the database (Bochs based debugger plugin).
I’m happy to inform you that we are entering the beta stage of IDA v5.4!
In addition to numerous small and not that small improvements, the new version will have three debugger modules: bochs, gdb, and windbg, selectable on the fly (the active debugger session will be closed, though ;))
- With the bochs debugger, we offer three different worlds: run-any-code-snippet facility, windows-like-environment for PE files, and any-bochs-image bare-bone machine emulation mode. You can read more about this module in our blog: http://hexblog.com/2008/11/bochs_plugin_goes_alpha.html
- With gdb, x86 and arm targets are supported. Among other things, it is possible to connect IDA to QEMU or debug a virtual machine inside VMWare. We tried it iPhone as well. However, while it works in some curcimstances, there were some problems on the gdbserver side.
- With windbg, user and kernel mode debugging is available. The debugger engine from Microsoft, which is currently the only choice for driver and kernel mode debugging, can be used from IDA. It can automatically load required PDB files and populate the listing with meaningful names, types, etc. Speaking of PDB files, IDA imports more information from them: local function variables and types are retrieved too, c++ base classes are handled, etc.
The gdb and windbg debugger modules support local and remote debugging. We tried to make the debugger modules as open as possible: target-specific commands can be sent to all backend engines in a very easy and user-friendly way.
As usual, better analysis and many minor changes have been made. If you spend plenty of time analyzing gcc generated binaries, you’ll certainly appreciate that IDA handles its weird way of preparing outgoing function arguments. Now it can trace and find arguments copies to the stack with mov statements.
The new IDA will support Python out of box, thanks to Gergely Erdelyi, who kindly agreed the Python plugin to be included in the official distribution. In fact, the main IDA window will have a command line to enter any python (or other language) expressions and immediately get a result in the message window.
We will prepare the detailed list of improvements later this week.
If you analyze MIPS binaries, you may find useful the following addition to IDA:
This is MIPS emulator for Linux. It can generate an IDC script after emulation, which then can be applied to the database and make it more readable.
The last week Elias ran a sample malware in the Bochs emulator and I was curious to see what it exactly does. So I took the unpacked version of the malware and fed it into the decompiler. It turned out to be a pretty short downloadler (different AV vendors give it different names: Lighty after the compression method, or FraudLoad, or FakeAlert, etc). Such simple code is very easy to decompile. I renamed some functions and added some
comments to it. The final text looks like this:
The next version of IDA will be released with a bochs debugger plugin, and what is nice about is that you will be able to use it easily by just downloading bochs executables and telling IDA where to find it.
Background Intelligent Transfer Service (BITS) is a component of modern Microsoft Windows operating systems that facilitates prioritized, throttled, and asynchronous transfer of files between machines using idle network bandwidth.
The web page ends with a list of third-party applications that use BITS. However, as any technical method, it can be used for evil purposes as well. Eric Landuyt analyzed a malware that exploits it for bad:
I liked the “proof of concept” WinDbg script that runs the malware in a controlled manner. Breakpoints with actions are very powerful, indeed.
Nice work, Eric!
This is not the first book about IDA Pro. However, this is the first
book I recommend to anyone using IDA Pro because of the following points:
- Comprehensive: it describes all major IDA features
by starting at the beginning and going all the way to the end.
Experienced users may be tempted to skip the first few chapters; resist this
temptation and you will discover something new (I did 🙂
- Accurate: it is very difficult to be detailed and precise when describing
such a complex product. Chris does it excellently well.
- Real: handles real world malware, packers, and obfuscated code
- No fillers: it is direct and concise
- Profound: this is not just a collection of recipes or tricks, but will give
you a better understanding of the IDA architecture, thus saving you
from unnecessary frustration. Knowing the limitations of your tool is just as
important as knowing its capabilities.
It comes tons of code snippets, scripts, and sample modules. Programming for IDA Pro is covered
too: from simple plugins to processor modules.
If you want to use IDA efficiently, get your copy from No Starch Press!
UPD for numerologists: the book has exactly 640 pages, no less, no more!
I’m happy to tell you that Mr. Elias Bachaalany has joined our development team!
He is one of keenest and most knowledgeable IDA users. Elias bought his first copy of IDA long ago while he was a student. Immediately after that he contacted us with tons of questions, suggestions, ideas how to improve things, etc. While we addressed most his questions, we could not handle everything. Then he designed and implemented many free and open source scripts and plugins for IDA.
We are lucky to have him in our team. I’m sure that very soon we will see new nice features in IDA Pro created by Elias. Stay tuned!
Sometimes names just do not reflect the nature of things. Sometimes it is our fault to attribute a wrong meaning to names. I do not know which of the above holds for Windows ASLR. After Alex Sotirov and Mark Dowd’s talk at Blackhat I know that ASLR is not that random despite of its name.
The ASLR abbreviation contains “randomization”, which is enough (at least for me) to deduce that EXEs and DLLs get loaded at randomly chosen addresses. I was wrong to think that this makes it hard for the attacker to guess the loaded addresses. As it turns out, binaries get loaded to somehow predictable addresses.
While I understand that there were some technical difficulties and compatibility issues, the implementation choices made for ASLR effectively weakened it a lot to the point that it failed to deliver the promised.
Another revelation of this talk was that IE happily loads any .NET DLL provided by the web server using the plain old LoadLibrary function. The ramifications of this are enormous because the system is essentially accepting raw binary data (a file of the PE file format) and runs it on the user’s computer. No need to talk about GS, SafeSEH and any other protections mechanisms after this.
The outcome of these two choices is also predictable, as Alex and Mark demonstrated to us: anyone visiting a malicious web site with IE can be easily owned.
There were other interesting talks at Blackhat, no way I can mention all of them here. Just one more pointer: I was amused and amazed by Hovav Scacham’s Return-Oriented Programming. As it turns out, pieces of “good” code in standard libraries can be used to build a turing-complete machine. This machine is programmable by the attacker using a byte code which does not require the X (execute) bit in the page permissions. This defeats W^X or DEP protections.
My talk on decompilers was received well. If you missed it, find the white paper here.
Heading to DEFCON now, for more interesting talks!