Hex blog

Some functions are neater than the decompiler thinks

2008-04-09T21:22:07Z

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?

]]> This happens because called functions usually spoil some registers. The calling conventions on x86 stipulate that only the esi, edi, ebx, and ebp registers are saved across calls. In other words, other registers may change their values (or be spoiled) by a function call. Since the decompiler assumes that functions obey the regular calling conventions, it separates edx before the call and after the call into two variables. The first variable gets optimized away and is replaced by a1. The second variable (v3) becomes uninitialized.

In fact, there are three possible cases. The edx register could be:

unmodified
used to return a value
spoiled

by the called function. The decompiler chose the default case (#3). Let's check if it was right. Here's the disassembly of sub_2A795:

As we see, the edx register is not referenced at all, so we have the case #1. If the decompiler could find it out itself, without our help, our life would be much easier (maybe it will do so in the future!) Meanwhile, we have to add the required information ourselves. We do it using the Edit, Functions, Set function type command in IDA. The callee does not spoil any registers:

The decompiler produces different pseudocode:

Since it knows that edx is not modified by the call, it creates just one variable for both edx instances (before and after the call).

Were the called function returning its value in edx (the case #2), we would set its type like this:

(this prototype means: function with one argument on the stack, the argument will be popped by the callee; the result is returned in edx)
The decompiler would create two separate variables for edx, as in the case #3. The first one would be optimized away, but the second one would be initialized with the returned value:

As you see, the type information plays very important role in decompilation. In order to get a correct output, a correct input (or assumptions) must be given. Otherwise the decompiler works in the "garbage in - garbage out" mode.

Always pay attention to the types, it is a good thing to do.

Symbian debugger

2008-04-08T18:02:06Z

It works! There are lots of limitations but it is alive, handles breakpoints, exceptions, and even some limited tracing is available. It is possible to launch processes and attach to them. Here is just one screenshot:

Expect many limitations in the first version (no hardware bpts, limited multithread support, etc). One of the most annoying shortcomings is that the memory layout is not determined automatically - we had to introduce 'manual memory regions' window to overcome this.

Since it is a new beast and many aspects need polishing, beta testers are welcome!

Symbian AppTRK

2008-03-29T01:06:06Z

Things are quite easy with the Symbian TRK! Today I decided to write a small program to interact with it and everything worked extremely smoothly. My driver program can download a SIS file to the phone, automatically install and run it. It reacts to debugging events and gracefully closes the connection when the application terminates. Below are just a few pictures for the curious.

]]> Here's the applications folder of the phone:

The TRK comes with the Pro version of the Carbide development environment. HelloWorld is just a sample application (maybe I spent more time on it than on the driver). The TRK kernel can connect to the main computer over USB or Bluetooth. Since my computer does not have a Bluetooth connection, I use a USB cable. The port number and baud rate seem to be irrelevant but they are displayed anyway:

At the main computer the connection is visible as a serial (COM) port. Connecting to the phone and sending bytes forth and back is quite easy: just open the serial port with CreateFile and use regular read/write system functions. Currently the driver is just a text-mode program and prints the communication packets on the screen:

Finally, here's the helloworld application. It has been installed and ran by the driver program:

There is still a lot to do, but the foundation already exists. All this stuff is quite stable (IMHO much stabler than WinCE, probably because of a better memory protection).

We will have to modify the debugger in IDA to be able to work with TRK. IDA expects the application memory and registers to be available at all times but Symbian TRK is irresponsive while the application is running. Many other debugger servers behave the same way, so it is a good idea to support this mode.

If things go as well as today, we will have a Symbian debugger pretty soon!

Hello Symbian!

2008-03-26T10:30:21Z

Yesterday I created my first Symbian program :) Sure enough, it was a "hello world" and to tell the truth I did not write it myself. But it still took me 3 (three) hours to get it running on Nokia E51. The good side is that I learned a lot about possible failures with Symbian applications (there are quite many of them, some of them with cryptic error messages like "install failed").

]]> The main reason why it took so much time is that I used a sample file from Examples/Basics/HelloWorld in the SDK. I have no idea why this file is included in the SDK, because it is incomplete and even manually adding a .pkg file does not help. My manual pkg file had all types of problems (wrong vendor id, secureid, uid, install directory, etc). I tested all combinations trying to make the application to install (this site was very helpful). Finally I installed it on the device. "I did i!" I congratulated myself - and immediately noticed that the installed application is nowhere. The installer claims that it is on the device, I can see the \sys\bin\hellworld.exe file on the disk, but there is no icon to click on and no other means to launch it. That was disappointing, to tell the least.

If you think about it, this is an expected outcome. The sample application consisted of a single cpp file, no resources, to icons, nothing. I guess Symbian does not display an icon for an application if it was not linked into the sis file (a sound approach, if you ask me).

My problems ended when I located another helloworld in S60Ex\helloworldbasic. With all skills I learned with the other helloworld, it took me only a few moments to build, download, and run it. Don't ask me why there are 2 different helloworlds but I'm glad that I went through this. Here are some good side effects of this failed endeavor:

the EFD utility displays detailed information about the latest (S60 9.1 3d edition) SIS files
IDA can disassemble them

I also found that Symbian supports on-device debugging on new devices. The Target Resident Kernel (TRK) from Metrowerks is used as a debugger server. The TRK seems to be documented. The obvious idea is to connect it to IDA and debug Symbian applications (and maybe even system software!) I'm not sure that this will work but it is worth trying.

New Hex-Rays Demo

2008-03-12T17:36:55Z

This has been online for a while now, I just had no time to announce it properly: a new thorough demo of the decompiler by ccso.com, our US distributor:

This demo is not just a teaser like the previous one. It is much deeper and shows many decompiler aspects in detail: it starts with the plugin configuration, shows a couple of simple decompilation cases, and then moves on to more complex functions. If you wondered how to improve the resulting pseudocode and handle typical cases, this video is for you!

Pythonic way

2008-03-06T23:22:10Z

A brilliant blog post by Ero Carrera: IDAPython in action:

http://blog.dkbza.org/2008/03/digging-up-system-call-ordinals.html

Just note how concise and powerful is the script!

Tricky jump tables

2008-03-04T15:25:57Z

Just a quick post to announce that we have published a small plugin to specify jump table information. When IDA misses them, the flow charts are virtually useless - they fall apart into several loosely connected components and the logic is completely hidden. This plugin is especially useful for rarely used processors with unusual switch idioms.

The plugin and its source code can be found on our forum.

Easy structure types

2008-02-18T12:45:36Z

I'm happy to tell you that a new build of the decompiler is ready! It introduces new easily accessible commands to manipulate structure pointers. First, a variable can be converted into a structure pointer with one click. Also, new the structure types can be build on the fly by the decompiler. As usual, any type or name can be modified any time. All this makes using the decompiler really agreeable. Please watch a short demo:

]]> This text is replaced by the Flash content.

Another nice improvement is how the decompiler handles zero offset fields in structure types. Below are two screenshots. Before:

After:

Please note that all casts has gone. They have been replaced by direct references to the first field of the structure type. Needless to say, the second text is much clearer than the first one.

As usual, all discovered and reported bugs have been fixed. If you have an old version, please update (especially before sending us bug reports).

Thank you!

MRXDAV.SYS and Hex-Rays Decompiler

2008-02-13T01:18:29Z

I wanted to present you a new plugin today. It was about switch idioms (jump tables). I spent a few hours trying to find a problematic x86 sample file but could not locate anything impressive. All jump tables were nicely recognized. This certainly does not mean that IDA handles them perfectly, but rather that my search methods must be improved.

Anyway, things were going nowhere and I decided to make a micro-break. It really helps to unblock the thought process (sometimes my entire working day consists of innumerable micro-breaks :)

]]> I remembered that it is time to install security updates so I quickly downloaded them and looked into the details. This one looked interesting.

Sometimes I use the decompiler to find out the differences between programs: decompile two files and use a text comparison on the pseudocode. This simple approach works ok for short files: I found out the modified functions. There were two of them, the most interesting one named MRxDAVPrecompleteUserModeQueryDirectoryRequest() (what a name!)

The MS08-007 vulnerability is a classic buffer overflow: two unicode strings get concatenated into a buffer of a fixed size. The application checks the size before copying, so in theory there shouldn't be any problems. I think that by looking at the following two screenshots you can tell why it didn't work quite well. Before:

The old version was checking that the sum of the input string lengthes is acceptable. Unfortunately, the case of integer overflow is not handled.

After:

The new version checks three things: the length of each input string and their sum all must be acceptable.

A single highlight of 0x208 is enough to notice the difference. In the old version, only tot2 is checked against the limit.

Well, my micro-break turned into a blog post. Back to the plugin: I'll find a nice sample file for jump tables and post a short video here. Stay tuned.

Debugger and process memory

2008-02-03T16:02:35Z

Just a small note about the debugger plugins and events. Many users who try to develop a plugin for the debugger notice that IDA behaves slightly differently in the notification callbacks than anywhere else.

For example, IDA might claim that EIP points to an address without a segment, or none of exported names of a loaded DLL are available.

]]> We tried to save the end user from this problem: the database gets synchronized as soon as the process is suspended. This is the expected behavior, so far so good.

Alas, we can not provide plugin writers with the same virtual reality: there are two distinct entities, the process memory and the program segmentation. The latter is stored in the database and it can go out of sync with the former. As a plugin writer, you have the following choices:

Bypass the database and talk directly to the debugger module using the dbg->read_memory() and dbg->write_memory() functions.
Advantages: no synchronization issues
Disadvantages: only memory read/write functions are available, names, functions, and other high level abstractions are not; also, direct calls are not cached.
Explicitly synchronize the database with the process memory.
Advantages: all high level abstractions are available, repetitive "read memory" requests will be cached by the kernel (especially useful for remote debugging); breakpoints in the process memory are hidden
Disadvantages: slow
Do not synchronize.
Advantages: fast
Disadvantages: occasionally a call to an IDA function might fail (e.g. getseg() might return NULL for a valid address); nevertheless, this approach can be used if you know in advance that the memory config won't change or the changes are irrelevant to your analysis

Feel free to use the best method depending on your needs. When you need to force a synchronization, use this:

        invalidate_dbgmem_config();
        isEnabled(any_address);

Or maybe a better approach exists?.. ;)

Jump tables

2008-01-31T10:21:45Z

It is an endless story: regardless of how many different jump table types IDA supports, there will be a new unhandled twist. Be it the instruction scheduler, which rearranged the instructions in an unexpected manner, or the compiler, which learned a new optimization trick, it is the same for IDA: jump tables are missed and functions boundaries are wrong. What's worse, the graph view, so loved by IDA users, displays a trimmed graph without jump tables, virtually useless for any analysis.

That's why we strive to add support for new jump tables to IDA, and since it can not be done for all of them, we focus on compiler generated jump tables for popular processors. Take ARM, for example. The ARM processor module have been improved a lot in v5.2, but yet we received a report with a bunch of new patterns. So expect even better support for ARM in the near future :)

If you are interested in improving the jump table handling for a rarely used processor, here are the explanations how to do it. ]]> First, you'll need to hook to the emulation step of the analysis.This way your plugin will be called by the kernel as soon as the instructions that handles the jump table are analyzed. You can do it in many ways, I present 2 of them here:

hook to processor events and intercept the custom_emu event.
hook_to_notification_point(HT_IDP, my_handler, NULL); ... static int my_handler(void *, int code, va_list va) { if ( code == processor_t::custom_emu ) { // check the instruction (see 'cmd' structure) // and create switch_info_ex_t } }
you may also replace ph.is_switch() pointer by your function. This callback is used only for indirect jump instructions, so your handler will be called only for them.

The task of recognizing an instruction sequence has not been formalized yet, so you are basically at your own here. Check the processor module samples in the SDK, or implement your own pattern matcher. In the SDK there is a file named jptcmn.cpp, it contains an instruction sequence matcher used by a few IDA modules. But I have to admit that it is quite difficult to use and does not handle everything. However, it still can overcome some instruction shuffling and register substitutions. Please check the samples in the SDK to see how it is used.

After recognizing a jump table, the IDA kernel should be informed about it. The structure that holds the jump table information is called switch_info_ex_t. The following details are stored:

jumps: The address of the jump table
Element size for the jump table
ncases: Number of elements
defjump: The address where the execution continues if the control variable is out of range (default jump address)
startea: The address of the beginning of the switch idiom

and lots of flags and additional information about the table, like if the table elements are signed or unsigned, if a separate value table is present, if the jump table has a custom structure, etc. The switch_info_ex_t structure is quite complex but it can be used to describe virtually any jump table.

In the simplest case, a plain 32-bit jump table with elements that contain target addresses, the structure is filled like this:

  switch_info_ex_t si;
  si.set_jtable_element_size(4);// 32-bit jump offsets
  si.ncases  = n;               // we specify the table size
  si.jumps   = jump_table_ea;   // the table address
  si.startea = cmd.ea;          // address of the first instruction
                                // related to the jump table

If we have more information about the jump table, we can add it to the structure. If we know the default jump address:

  si.flags |= SWI_DEFAULT;
  si.defjump = default_jump_ea;

If we know the input register used by the table jump:

  si.set_expr(regnum, reg_dttyp);

If a delta is subtracted from the input value before using it:

  si.lowcase = delta;

If the table entries are shifted to the left before used:

  si.set_shift(shift_amount);

If there is a separate value table:

  si.flags |= SWI_SPARSE;
  si.set_vtable_element_size(value_size);

If the value table are used as indexes into the jump table:

  si.flags2 |= SWI2_INDIRECT;

Finally, if the jump table has a special structure, then you can set:

  si.flags |= SWI_CUSTOM;
  si.custom = value_of_your_choice;

Naturally, the more information you put into switch_info_ex_t, the better the analysis will be. The prepared structure must be stored into the database:

  set_switch_info_ex(ea, &si);
  setFlbits(ea, FF_JUMP);

For regular jump tables, the kernel will handle the rest. For custom tables, the kernel will generate the create_switch_xrefs and calc_switch_cases events. Your module must intercept them and either create cross references or calculate the requested information.

One more trick: you may also intercept the processor_t::is_insn_table_jump event to prevent the kernel from creating jump tables when it should not. The kernel has some heuristic rules to create jump tables. If they create wrong jump tables, you can intercept their creation at this event.

This was a very short introduction to the jump tables in IDA Pro. Feel free to post your questions in the forum, I'll be glad to answer!

3 feb: minor edits

Better user interface for decompiler

2008-01-02T15:24:58Z

We are glad to release a new version of the Hex-Rays decompiler! Highlights of this build:

improved usability
support for unusual calling conventions
better handling of obfuscated code

The most important improvement is the user interface. Now the decompiler is at your fingertips at all times, the same way as the graph view. Remember that you can toggle graph-text views in IDA with one keyboard hit? For the decompiler you can use the Tab key: it toggles between the disassembly and pseudocode views.

For those of you who prefer to see both the decompiler output and disassembler output in the same window, we added the "copy to disassembly" command. It just does what its names says: copies the pseudocode text to the disassembly window. You can see both outputs simultaneously: mapping of low level assembly idioms to high level constructs is made as transparent as possible.

With this build, you will be able to open multiple pseudocode windows. This will be especially useful for long functions: just open a separate window for each called function by Ctrl-double clicking on function names. The long function will stay intact in its own window and you won't lose time by reanalyzing it upon each return.

One more command to handle code complexity: ability to hide parts of code. The new hide/unhide command allows you to collapse a multiline statement into just one line. Collapsing unimportant sub-statements reveals the global structure of the decompiled function.

We also added other things to make the life easier: the command to jump to xrefs, better status line information, support for the __spoiled keyword, and more heuristic rules to the analyzer.

Here's a short video:

The detailed list of changes can be accessed here

Nice analysis!

Decompiler output ctree

2007-11-27T23:28:00Z

The upcoming version of the decompiler SDK adds some nice features.
First, we created a reference manual. It is in doxygen format: cross references make it really easy to browse. Second, the SDK is compatible with both IDA v5.1 and v5.2. Third, we added functions to retrieve and modify all user-defined attributes like variable names, types, and comments. Fourth, we added more sample plugins. And fifth, our forum is open. All your decompiler and SDK related questions can be asked there.

Since the "show, don't tell" rule applies to everyone, here's a short video demonstrating one of the new sample plugins (it displays the decompiler output as a graph):

Hopefully the new version will be available this week, as soon as the regression tests are over.

Hex-Rays SDK is ready!

2007-10-30T21:08:26Z

A binary analysis tool like a decompiler is incomplete without a programming interface. Sure, decompilers tremendously facilitate binary analysis. You can concentrate of the program logic expressed in a familiar way. Just add comments, rename variables and functions to get almost the original source code, almost perfect. However, quite often there is a small ugly detail and the output falls short of being satisfactory.

]]> It can be because of an awkward expression

    (result = _putwc_lk(a3, (FILE *)result), result != -1)

which could be represented more concisely:

    ((result = _putwc_lk(a3, fp)) != -1)

It can also be an inline function

      while ( v16 )
      {
        *(_BYTE *)v17++ = 0;
        --v16;
      }

which could be collapsed:

      memset(ptr, 0, count);

It can be a while-loop

    v7 = 48;
    v4 = wcstok(&Str, L".");
    if ( v4 )
    {
      do
      {
        v9 = (unsigned __int16)j___wtol(v4) << v7;
        v6 |= v9;
        v5 |= *((_DWORD *)&v9 + 1);
        v4 = wcstok(NULL, L".");
        v7 -= 16;
      }
      while ( v7 >= 0 && v4 );
    }

which could be converted into a for-loop:

    for ( shift=48, ptr=wcstok(&Str, L".");
          shift >= 0 && ptr;
          ptr=wcstok(NULL, L"."), shift-=16 )
    {
      v6 |= (ushort)wtol(ptr) << shift;
      v5 |= codepage;
    }

All these transformations improve the readability but the decompiler can not perform them automatically: they change the meaning of the program. Only the user who knows that these transformations can be safely applied should activate them.

We could add extensive set of manual transformation commands to the decompiler (we might do it one day), but there are really too many of them. Besides, some transformations can be applied only in some particular circumstances proper to a particular version of a compiler used with particular command line options. In short, there is no way we can predict all possible transformations and implement them.

Hex-Rays SDK allows you to manipulate the decompilation result as you want. You can play with the output data structure (called ctree), modify it, rename variables, and change their types. Watch such a plugin in action:

This plugin introduces a new command to swap if branches. I personally prefer to have the shorter if branch first: shorter means simpler. Having simplest problems to be solved first is a good approach in programming, it frees one's mind for complex problems and makes the unsolved part of the problem shorter (thus hopefully simpler ;)

Other things you can do with the current SDK:

Decompile any function
Modify the pseudocode
Change local variable names and types
Introduce your own interactive commands
Install callbacks to react to decompiler events

The above functionality it enough to implement the Inliner, Exporter, Transformer, and Vizier(partially) plugins mentioned here.

In the future we will add support for other plugin types. The decompiler will handle other target processors and data flow analysis functions will be exported. This will allow you to write more complex analysis and transformation rules.

What about writing your own vulnerability scanner based on Hex-Rays? ;)
It is quite difficult today but will be within reach very soon.

IDA and Microcontrollers

2007-10-15T13:52:30Z

If you ever used IDA to analyze embedded stuff, you would immediately notice its pc-centric nature. While any embedded SDK targets specific devices with real-world part numbers, IDA just provides you with a universal analysis framework. You are supposed to know how the device works, its idiosyncrasies, programming model, memory organization, and all other practical stuff. If there is an automatic way to determine the entry point or interrupt vectors, IDA will use it but in general you will have to find out the correct parameters yourself.

The following tutorial fills the gap for C166 (and explains many other things!):

http://andywhittaker.com/ECU/DisassemblingaBoschME755/tabid/96/Default.aspx

Thanks, Andy!