From simple to complex

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:

Continue reading From simple to complex

BITS used as a covert channel

The idea to use BITS to download files from the internet is not new. If you check the corresponding page from Wikipedia, you will find that
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:
http://www.datarescue.com/laboratory/trojan2008/index.html
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!

The IDA Pro book





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!

Mr. Bachaalany joins Hex-Rays

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!

Blackhat USA 2008

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!

Apple’s variant of ptrace()

Have you ever tried to create a debugger for Mac OS X? It is an adventurous enterprise with lots of unexpected (should I say unforeseeable?) problems. This guy tried and described his adventures in this entertaining post:
http://www.matasano.com/log/1100/what-ive-been-doing-on-my-summer-vacation-or-it-has-to-work-otherwise-gdb-wouldnt/
His post reminded me of all problems we faced with the first version of the IDA debugger for iMac. They also reminded me of even more convoluted puzzles with the iPhone debugger because ptrace() is broken beyond any hope there (one simple rule: use only PT_TRACEME).
Anyway, if anyone wants to repeat our steps, we are giving away the source code of all debugger modules with the new IDA v5.3: iMac and iPhone debugger codes included. They can certainly help you to avoid some headache and frustration!

Recon2008

The last week I attended the Recon conference. It was a very enjoyable event, very nicely organized and handled, in a charming city (Montreal). Since I haven’t seen many conferences yet, I can not really compare it to others but I think it was really great: real RE stuff with no superficial talks. You can find the slides and videos on the conference site. The following blogs describe the event in more detail:
http://dvlabs.tippingpoint.com/blog/
http://blog.trailofbits.com/2008/06/16/recon-2008-review/
There were quite a few interesting talks, I especially liked the ones about iMac and iPhone (other talks disclosed new ideas too, it is just that I’m currently working on Apple products ;))
Thanks to the conference organizers for making such an event possible! David, Hugo, Guillaume did an excellent job. Now waiting for the next recon, which will normally be held in 2010.

Testing debuggers

Software programs must be tested before put in use. When there is a single program, things are relatively simple. Running it on multiple platforms is more challenging because it requires testing all of them. But the real nightmare starts when there are multiple programs running on multiple platforms and going to a high abstract level is not an option.
This is the case with IDA debuggers. The current version supports five different variants: Win32/Win64/WinCE/Linux/iMac but the upcoming v5.3 adds Symbian and iPhone to the list.
We can not use a high level language for debuggers because the very nature of the information is low level: bits and bytes, registers and memory cells. The core of the debugger operates with some abstractions but this does not make it really impervious to low level details: each platform has its peculiarities. It is more of a disadvantage than a bonus: changing anything in debugger core could introduce a bug in any of the supported platforms, something hard to reproduce and fix.
Given all the above, we decided to spend some time on a test system. And here is the result: custom made, hardcore command line, user agnostic (or unfriendly?) but it does the job. It generates megabytes of logs and can check all debuggers: local or remote, 32 or 64 bit, single or multithreaded.
Below is a link to a short video. I’m sorry for the window size, it is really difficult to fit all windows into a small area.


One more thing I wanted to tell you: we have the iPhone debugger ready for beta testing. It was a hard job to create it, especially with the broken ptrace on iPhone. I’m still curious to know more about its implementation and limitations…
If you want to participate in beta testing of the iPhone debugger, just send us a message.

Some functions are neater than the decompiler thinks

The decompiler makes some assumptions about the input code. Like that call instructions usually return, the memory model is flat, the function frame is set properly, etc. When these assumptions are correct, the output is good. When they are wrong, well, the output does not correspond to the input. Take, for example, the following snippet:

The decompiler produces the following pseudocode:

Apparently, the v3 variable (it corresponds to edx) is not initialized at all. Why?

Continue reading Some functions are neater than the decompiler thinks