x64 decompiler not far away

Just a short post to show you the current state of the x64 decompiler. In fact, it already mostly works but we still have to solve some minor problems. Let us consider this source code:

struct color_t
{
  short red;
  short green;
  short blue;
  short alpha;
};

extern color_t lighten(color_t c);

color_t func(int red, int green, int blue, int alpha)
{
  color_t c;
  c.red = red;
  c.green = green;
  c.blue = blue;
  c.alpha = alpha;
  return lighten(c);
}

After compilation we get the following binary code:

.text:0000000000000000 ?func@@YA?AUcolor_t@@HHHH@Z proc near
.text:0000000000000000
.text:0000000000000000
c = color_t ptr -18h
.text:0000000000000000 var_10 = qword ptr -10h
.text:0000000000000000 arg_0 = dword ptr 8
.text:0000000000000000 arg_8 = dword ptr 10h
.text:0000000000000000 arg_10 = dword ptr 18h
.text:0000000000000000 arg_18 = dword ptr 20h
.text:0000000000000000
.text:0000000000000000
mov [rsp+arg_18], r9d ; $LN3
.text:0000000000000005 mov [rsp+arg_10], r8d
.text:000000000000000A mov [rsp+arg_8], edx
.text:000000000000000E mov [rsp+arg_0], ecx
.text:0000000000000012 sub rsp, 38h
.text:0000000000000016 movzx eax, word ptr [rsp+38h+arg_0]
.text:000000000000001B mov [rsp+38h+c.red], ax
.text:0000000000000020 movzx eax, word ptr [rsp+38h+arg_8]
.text:0000000000000025 mov [rsp+38h+c.green], ax
.text:000000000000002A movzx eax, word ptr [rsp+38h+arg_10]
.text:000000000000002F mov [rsp+38h+c.blue], ax
.text:0000000000000034 movzx eax, word ptr [rsp+38h+arg_18]
.text:0000000000000039 mov [rsp+38h+c.alpha], ax
.text:000000000000003E mov rcx, qword ptr [rsp+38h+c.red] ; c
.text:0000000000000043 call ?lighten@@YA?AUcolor_t@@U1@@Z ; lighten(color_t)
.text:0000000000000048 mov [rsp+38h+var_10], rax
.text:000000000000004D mov rax, [rsp+38h+var_10]
.text:0000000000000052 add rsp, 38h
.text:0000000000000056 retn
.text:0000000000000056 ?func@@YA?AUcolor_t@@HHHH@Z endp

Please note that the c, which is a structure, is passed by value in 2 registers: rcx and rdx. We had to rework quite many things in the decompiler to support such variables (we call them scattered variables). However, the output was worth it:

color_t __fastcall func(__int16 cx0, __int16 dx0, __int16 r8_0, __int16 r9_0)
{
  color_t c;

  c.red = cx0;
  c.green = dx0;
  c.blue = r8_0;
  c.alpha = r9_0;
  return lighten(c);
}

There is still some work to be done, but it seems we solved most problematic issues. Stay tuned, there will be more decompiler news soon!

 

Interacting with IDA through IPC channels

I’m happy to present you a guest post by David Zimmer <dzzie@yahoo.com>. The approach he describes can be used to develop plugins more conveniently (but not limited to that):


In this article we are going to discuss a mechanism that can be used to interact with IDA through external applications.

The reason this technique was developed was to provide a convenient way for utility applications to query information from IDA databases, and automate its interface.

Over the years, several methods have been tried such as pipes, and sockets. In the end, the easiest Inter-Process Communication (IPC) technique I have found is the Windows specific SendMessage API along with the WM_COPYDATA message. This technique was chosen for its simplicity, reliability, and its inherently synchronous nature.

With this technique, the IDA server plugin creates a window and watches for command messages to come in.


(abbreviated C source to CreateWindow and receive messages)

The plugin contains its own text based API which can be used to automate actions and return queried data back to the calling process. Example commands and data transfer routines are shown below:


(hwnd arguments specify which window handle receives data callback)

There are several advantages to this technique. Traditional plugin development usually requires compiling your code and launching the plugin from the host application.
Debugging often entails wading through runtime debug logs, inferring problems through observed behavior, and chasing crashs in a debugger.

This technique allows you to debug your executable in the development IDE as normal, harnessing all of its powerful capabilities such as edit and continue, call stack viewing, variable watches, breakpoints etc.

Complex projects can be run directly while you iron out interface behaviors and are not dependant upon the host. Datasets can even be loaded from test files so that many routines can be debugged independently of IDA.

One project where this technique was put to good use was an experiment to see if a Javascript IDE could be created for IDA automation tasks. The desire was for a scriptable interface that supported intellisense, function prototype tool tips, and syntax highlighting.


 

With a project such as this, coding for the IDE behaviors is a major part of the development task. To develop such an application strictly as a plugin would be a daunting endeavor. Developing it as a standalone application was a great advantage where it could be run directly from the Visual Studio IDE without any intermediate steps.

One other advantage to this technique is that it opens up plugin development to include higher level languages that do not have native support for the IDA API*. Languages such as C#, Delphi, and VB6 can easily interact with IDA through this mechanism. These languages have excellent rapid GUI development capabilities and a wealth of complex components already available to them. This technique is even open to Java developers through the JNI.

Once the intermediate API and the client access library is written, creating utilities to integrate with IDA becomes a pretty quick process. Another example project that has come in handy is a Wingraph32 replacement that was coded in about a day.

The interface shown below automatically syncs the IDA disassembly when graph nodes are clicked and can perform several renaming operations.


 

There are some limitations to this technique as well. The particular implementation detailed in this article is Windows specific. It also requires both applications to be running on the same machine.

Another consideration is that the data is crossing process boundaries which can be a performance hit depending on what is being transferred and how often it is being invoked. For example, extracting or patching large blocks of data would best be optimized by reserving the use of the SendMessage API as the command channel, and utilizing files or shared memory for the data transfer. This will likely be an optimization included in future revisions.

The example IDASRVR project linked to below currently supports 36 API and uses a simple text based command protocol. Sample code is provided in C and C#. Client libraries are also available for C# and VB6 in the associated projects below.

Sample Projects:

IDASrvr – IDA IPC Server example

IDA_Jscript – Javascript IDE PoC for IDA (VB6)

GleeGraph – C# Wingraph32 replacement

* You can create C# and VB6 in process plugins for IDA through COM.
This was my first approach, and was used in my
IDACompare plugin.

Challenging job for software developers

We should permanently and prominently publish this ad on our site 🙂

We are looking for strong software engineers to join our team and participate in the development of unique software security tools. The candidates must know low-level details of modern software as well as high-level data structures and algorithms.

Requirements:

  • strong knowledge of C/C++
  • knowledge of the x86 assembler and unwillingness to use it in development
  • cross platform development (Windows/Linux/Mac) is a plus
  • knowing the graph theory and how compilers work is a plus
  • ability and willingness to write secure yet fast code
  • good problem solving and communication skills

If you want a challenging job in a friendly environment, please apply by sending your resume to info@hex-rays.com
Thanks!

IDA Pro 6 licenses

As many of you already know, IDA6 copies ship separately for Windows/Linux/Mac. Before we were giving the Linux/Mac versions for free because there was no GUI for them. Now we have full fledged GUIs for all platforms (and our development/techsupport costs increased because of that), so we separated the licenses. We could simply have increased the price of the whole package but since the absolute majority of our users stick to one platform, it is fairer to separate licenses. This way only the customers who really use multiple platforms pay extra. We believe this is the fairest solution for everyone.
Continue reading IDA Pro 6 licenses

Hex-Rays against Aurora

As everyone knows, Google and some other companies were under a targeted attack a few days ago. A vulnerability in the Internet Explorer was used to penetrate the computers.
An IDA user very kindly sent us the following link
http://www.avertlabs.com/research/blog/index.php/2010/01/18/an-insight-into-the-aurora-communication-protocol/

Continue reading Hex-Rays against Aurora

Hex-Rays Plugin Contest

We are glad to announce the results of our first plugin contest! For the contest rules, please check this page:
http://www.hex-rays.com/contest.shtml
Or you may directly go to the contest results and check out some cool plugins:
http://www.hex-rays.com/contest2009
It was our first contest, but we are happy with the results and will repeat it in the near future.
Have fun!

Hex-Rays is hiring

We are looking for someone to join our team and participate in the development of unique software security tools. The candidates must know low-level details of modern software as well as high-level data structures and algorithms.
Requirements:
* strong knowledge of C/C++
* experience with Qt and GUI development is a big PLUS
* knowledge of x86 assembler and unwillingness to use it in development
* cross platform development (Windows/Linux/Mac) is a plus
* knowing the graph theory and how compilers work is a plus
* ability and willingness to write secure yet fast code
* good problem solving and communication skills
To apply, please send your resume to info@hex-rays.com
Code samples and links to implemented projects are welcome.

Javascript for IDA Pro

Just a quick post to share the joy of having more expressiveness and freedom in IDA Pro. A few days ago we implemented a JavaScript plugin. This means that there is yet one more languauge to write scripts in IDA, and a very powerful one.

All usual methods of accessing the language work: you may execute scripts, standalone statements, or even completely replace IDC with JavaScript.

All IDC functions are availalble in JavaScript (in fact, we just exported them one-to-one). In the future, we will export IDA objects into JavaScript and this will make programming it even easier.

Download the plugin here:
http://hexblog.com/ida_pro/files/js.zip

If you notice anything unusual, send us a note, thank you!

Elias will blog more about the plugin in the coming days, and maybe present something handy, as he already did in the past 😉

P.S. I subscribed to twitter a few days ago – it is so dynamic. Will probably switch to it, at least partially