1 of 7

Introduction to Decompilation vs. Disassembly

A decompiler represents executable binary files in a readable form. More precisely, it transforms binary code into text that software developers can read and modify. The software security industry relies on this transformation to analyze and validate programs. The analysis is performed on the binary code because the source code (the text form of the software) traditionally is not available, because it is considered a commercial secret.

Programs to transform binary code into text form have always existed. Simple one-to-one mapping of processor instruction codes into instruction mnemonics is performed by disassemblers. Many disassemblers are available on the market, both free and commercial. The most powerful disassembler is our own IDA Pro. It can handle binary code for a huge number of processors and has open architecture that allows developers to write add-on analytic modules.

Decompilers are different from disassemblers in one very important aspect. While both generate human readable text, decompilers generate much higher level text which is more concise and much easier to read.

Compared to low level assembly language, high level language representation has several advantages:

Comparisons of ARM disassembly and decompilation

Here are some side-by-side comparisons of disassembly and decompiler for ARM. Please maximize the window too see both columns simultaneously.

The following examples are displayed on this page:

Simple case
64-bit arithmetics

Simple case

Let's start with a very simple function. It accepts a pointer to a structure and zeroes out its first three fields. While the function logic is obvious by just looking at the decompiler output, the assembly listing has too much noise and requires studying it.

The decompiler saves your time and allows you to concentrate on more exciting aspects of reverse engineering.

64-bit arithmetics

Sorry for a long code snippet, ARM code tends to be longer compared to x86 code. This makes our comparison even more impressive: look at how concise is the decompiler output!

Conditional instructions

The ARM processor has conditional instructions that can shorten the code but require high attention from the reader. The case above is very simple, just note that there is a pair of instructions: MOVNE and LDREQSH. Only one of them will be executed at once. This is how simple if-then-else looks in ARM.

The pseudocode shows it much better and does not require any explanations.

A quiz question: did you notice that MOVNE loads zero to R0? (because I didn't:)

Also note that in the disassembly listing we see var_8 but the location really used is var_A, which corresponds to v4.

Conditional instructions - 2

Look, the decompiler output is longer! This is a rare case when the pseudocode is longer than the disassembly listing, but it is a for a good cause: to keep it readable. There are so many conditional instructions here, it is very easy to misunderstand the dependencies. For example, did you notice that the first MOVEQ may use the condition codes set by CMP? The subtle detail is that CMPNE may be skipped and the condition codes set by CMP may reach MOVEQs.

The decompiler represented it perfectly well. I renamed some variables and set their types, but this was an easy task.

Complex instructions

Conditional instructions are just part of the story. ARM is also famous for having a plethora of data movement instructions. They come with a set of possible suffixes that subtly change the meaning of the instruction. Take STMCSIA, for example. It is a STM instruction, but then you have to remember that CS means "carry set" and IA means "increment after".

In short, the disassembly listing is like Chinese. The pseudocode is longer but requires much less time to understand.

Compiler helper functions

Sorry for another long code snippet. Just wanted to show you that the decompiler can handle compiler helper functions (like __divdi3) and handles 64-bit arithmetic quite well.

Immediate constants

Since ARM instructions cannot have big immediate constants, sometimes they are loaded with two instructions. There are many 0xFA (250 decimal) constants in the disassembly listing, but all of them are shifted to the left by 2 before use. The decompiler saves you from these petty details.

Also a side: the decompiler can handle ARM mode as well as Thumb mode instructions. It just does not care about the instruction encoding because it is already handled by IDA.

Position independent code

In some case the disassembly listing can be misleading, especially with PIC (position independent code). While the address of a constant string is loaded into R12, the code does not care about it. It is just how variable addresses are calculated in PIC-code (it is .got-someoffset). Such calculations are very frequent in shared objects and unfortunately IDA cannot handle all of them. But the decompiler did a great job of tracing R12.

Comparisons of MIPS disassembly and decompilation

Here are some side-by-side comparisons of disassembly and decompiler for MIPS. Please maximize the window too see both columns simultaneously.

The following examples are displayed on this page:

Simple code
64-bit comparison

Simple code

This is a very simple code to decompile and the output is perfect. The only minor obstacle are references through the global offset table but both IDA and the Decompiler handle them well. Please note the difference in the number of lines to read on the left and on the right.

64-bit comparison

Sorry for another long assembler listing. It shows that for MIPS, as for other platforms, the decompiler can recognize 64-bit operations and collapse them into very readable constructs.

Magic divisions

We recognize magic divisions for MIPS the same way as for other processors. Note that this listing has a non-trivial delay slot.

Hard cases with delay slots

The previous example was a piece of cake. This one shows a tougher nut to crack: there is a jump to a delay slot. A decent decompiler must handle these cases too and produce a correct output without misleading the user. This is what we do. (We spent quite long time inventing and testing various scenarios with delay slots).

Little-endian MIPS

We support both big-endian and little-endian code. Usually they look the same but there may be subtle differences in the assembler. The decompiler keeps track of the bits involved and produces human-readable code.

MicroMIPS

MicroMIPS, as you have probably guessed, is supported too, with its special instructions and quirks.

Floating-point operations

The MIPS processor contains a number of complex floating point instructions, which perform several operations at once. It is not easy to decipher the meaning of the assembler code but the pseudocode is the simplest possible.

Compiler helpers

A compiler sometime uses helpers; our decompiler knows the meaning of the many helpers and uses it to simplify code.

Hex-Rays v7.4 vs. v7.3 Decompiler Comparison Page

Here are some side-by-side comparisons of decompilations for v7.3 and v7.4. Please maximize the window too see both columns simultaneously.

The following examples are displayed on this page:

Better array detection
Support for more floating-point helpers

Better array detection

The text produced by v7.3 is not quite correct because the array at [ebp-128] was not recognized. Overall determining the array is a tough task but we can handle simple cases automatically now.

Support for more floating-point helpers

On the left there is a mysterious call to _extendsfdf2. In fact this is a compiler helper function that just converts a single precision floating point value into a double precision value. However, we do not want to see this call as is. It is much better to translate it into the code that looks more like C. Besides, there is a special treatment for printf-like functions.

Automatic variable mapping

In some cases we can easily prove that one variable can be mapped into another. The new version automatically creates a variable mapping in such cases. This makes the output shorter and easier to read. Needless to say that the user can revert the mapping if necessary.

Automatic symbolic names

The new version automatically applies symbolic constants when necessary. Less manual work.

Simplified C++ names

This is not the longest C++ function name one may encounter but just compare the left and right sides. In fact the right side could even fit into one line easily, we just kept it multiline to be consistent. By the way, all names in IDA benefit from this simplification, not only the ones displayed by the decompiler. And it is configurable!

Improved handling of 64-bit arithmetics

The battle is long but we do not give up. More 64-bit patterns are recognized now.

Better detection of 64-bit decrements

Yet another example of 64-bit arithmetics. The code on the left is correct but not useful at all. It can and should be converted into the simple equivalent text on the right.

More meaningful variable names

Currently we support only GetProcAddress but we are sure that we will expand this feature in the future.\

Hex-Rays v7.3 vs. v7.2 Decompiler Comparison Page

Below you will find side-by-side comparisons of v7.2 and v7.3 decompilations. Please maximize the window too see both columns simultaneously.

The following examples are displayed on this page:

NOTE: these are just some selected examples that can be illustrated as side-by-side differences. There are many other improvements and new features that are not mentioned on this page. We just got tired selecting them. Some of the improvements that did not do to this page:

objc-related improvements
value range analysis can eliminate more useless code
better resolving of got-relative memory references

More hexadecimal numbers in the output

When a constant looks nicer as a hexadecimal number, we print it as a hexadecimal number by default. Naturally, beauty is in the eye of the beholder, but the new beahavior will produce more readable code, and less frequently you will fell compelled to change the number representation. By the way, this tiny change is just one of numerious improvements that we keep adding in each release. Most of them go literally unnoticed. It is just this time we decided to talk about them

Support for variable size structures

EfiBootRecord points to a structure that has RecordExtents[0] as the last member. Such structures are considered as variable size structures in C/C++. Now we handle them nicely.

UTF-32 strings are printed inline

We were printing UTF-8 and other string types, UTF-32 was not supported yet. Now we print it with the 'U' prefix.

Better argument detection for printf

The difference between these outputs is subtle but pleasant. The new version managed to determine the variable types based on the printf format string. While the old version ended up with int a2, int a3, the new version correctly determined them as one __int64 a2.

Better argument detection for scanf

A similar logic works for scanf-like functions. Please note that the old version was misdetecting the number of arguments. It was possible to correct the misdetected arguments using the Numpad-Minus hotkey but it is always better when there is less routine work on your shoulders, right?

Resolved TEB references

While seasoned reversers know what is located at fs:0, it is still better to have it spelled out. Besides, the type of v15 is automatically detected as struct _EXCEPTION_REGISTRATION_RECORD *.

Better automatic selection of union fields

Again, the user can specify the union field that should be used in the output (the hotkey is Alt-Y) but there are situations when it can be automatically determined based on the access type and size. The above example illustrates this point. JFYI, the type of entry is:

While we can not handle bitfields yet, their presence does not prevent using other, regular fields, of the structure.

Yet one more example of union fields

I could not resist the temptation to include one more example of automatic union selection. How beautiful the code on the right is!

Improved support for EABI helpers

No comments needed, we hope. The new decompiler managed to fold constant expressions after replacing EABI helpers with corresponding operators.

Improved local variable allocation

Now it works better especially in complex cases.

Better recognizition of string references

In this case too, the user could set the prototype of sub_1135FC as accepting a char * and this would be enough to reveal string references in the output, but the new decompiler can do it automatically.

Better handling of structures returned by value

The code on the left had a very awkward sequence to copy a structure. The code on the right eliminates it as unnecessary and useless.

More while loops

Do you care about this improvement? Probably you do not care because the difference is tiny. However, in additon to be simpler, the code on the right eliminated a temporary variable, v5. A tiny improvement, but an improvement it is.

Shorter code

Another tiny improvement made the output considerably shorter. We like it!

Improved recognition of magic divisions

This is a very special case: a division that uses the rcr instruction. Our microcode does not have the opcode for it but we implemented the logic to handle some special cases, just so you do not waste your time trying to decipher the meaning of convoluted code (yes, rcr means code that is difficult to understand).

Less gotos

Well, we can not say that we produce less gotos in all cases, but there is some improvement for sure. Second, note that the return type got improved too: now it is immediately visible that the function returns a boolean (0/1) value.

Division may generate an exception

What a surprise, the code on the right is longer and more complex! Indeed, it is so, and it is because now the decompiler is more careful with the division instructions. They potentially may generate the zero division exception and completely hiding them from the output may be misleading. If you prefer the old behaviour, turn off the division preserving in the configuration file.

Order of variadic arguments

Do you notice the difference? If not, here is a hint: the order of arguments of sub_88 is different. The code on the right is more correct because the the format specifiers match the variable types. For example, %f matches float a. At the first sight the code on the left looks completely wrong but (surprise!) it works correctly on x64 machines. It is so because floating point and integer arguments are passed at different locations, so the relative order of floating/integer arguments in the call does not matter much. Nevertheless, the code on the right causes less confusion.

Improved division recognition

This is a never ending battle, but we advance!

# void __fastcall free_argv(int argc, char **argv) .globl _Z9free_argviPPc # weak _Z9free_argviPPc: # CODE XREF: test_expand_argv(void)+264↑p # test_expand_argv(void)+51C↑p ... var_10 = -0x10 var_4 = -4 var_s0 = 0 var_s4 = 4 arg_0 = 8 arg_4 = 0xC # __unwind { addiu $sp, -0x28 sw $ra, 0x20+var_s4($sp) sw $fp, 0x20+var_s0($sp) move $fp, $sp la $gp, _GLOBAL_OFFSET_TABLE_+0x7FF0 sw $gp, 0x20+var_10($sp) sw $a0, 0x20+arg_0($fp) sw $a1, 0x20+arg_4($fp) lw $v0, 0x20+arg_4($fp) beqz $v0, loc_17778 nop sw $zero, 0x20+var_4($fp) loc_1770C: # CODE XREF: free_argv(int,char **)+80↓j lw $v1, 0x20+var_4($fp) lw $v0, 0x20+arg_0($fp) slt $v0, $v1, $v0 beqz $v0, loc_17760 nop lw $v0, 0x20+var_4($fp) sll $v0, 2 lw $v1, 0x20+arg_4($fp) addu $v0, $v1, $v0 lw $v0, 0($v0) move $a0, $v0 lw $v0, (qfree_ptr-0x7FF0 - _GLOBAL_OFFSET_TABLE_)($gp) move $t9, $v0 jalr $t9 ; qfree nop lw $gp, 0x20+var_10($fp) lw $v0, 0x20+var_4($fp) addiu $v0, 1 sw $v0, 0x20+var_4($fp) b loc_1770C nop # --------------------------------------------------------------------------- loc_17760: # CODE XREF: free_argv(int,char **)+40↑j lw $a0, 0x20+arg_4($fp) lw $v0, (qfree_ptr-0x7FF0 - _GLOBAL_OFFSET_TABLE_)($gp) move $t9, $v0 jalr $t9 ; qfree nop lw $gp, 0x20+var_10($fp) loc_17778: # CODE XREF: free_argv(int,char **)+28↑j nop move $sp, $fp lw $ra, 0x20+var_s4($sp) lw $fp, 0x20+var_s0($sp) addiu $sp, 0x28 jr $ra nop # } // starts at 176D8

Hex-Rays v7.3 vs. v7.2 Decompiler Comparison Page

Below you will find side-by-side comparisons of v7.2 and v7.3 decompilations. Please maximize the window too see both columns simultaneously.

The following examples are displayed on this page:

objc-related improvements
value range analysis can eliminate more useless code
better resolving of got-relative memory references

More hexadecimal numbers in the output

Support for variable size structures

EfiBootRecord points to a structure that has RecordExtents[0] as the last member. Such structures are considered as variable size structures in C/C++. Now we handle them nicely.

UTF-32 strings are printed inline

We were printing UTF-8 and other string types, UTF-32 was not supported yet. Now we print it with the 'U' prefix.

Better argument detection for printf

Better argument detection for scanf

Resolved TEB references

While seasoned reversers know what is located at fs:0, it is still better to have it spelled out. Besides, the type of v15 is automatically detected as struct _EXCEPTION_REGISTRATION_RECORD *.

Better automatic selection of union fields

While we can not handle bitfields yet, their presence does not prevent using other, regular fields, of the structure.

Yet one more example of union fields

I could not resist the temptation to include one more example of automatic union selection. How beautiful the code on the right is!

Improved support for EABI helpers

No comments needed, we hope. The new decompiler managed to fold constant expressions after replacing EABI helpers with corresponding operators.

Improved local variable allocation

Now it works better especially in complex cases.

Better recognizition of string references

Better handling of structures returned by value

The code on the left had a very awkward sequence to copy a structure. The code on the right eliminates it as unnecessary and useless.

More while loops

Shorter code

Another tiny improvement made the output considerably shorter. We like it!

Improved recognition of magic divisions

Less gotos

Division may generate an exception

Order of variadic arguments

Improved division recognition

This is a never ending battle, but we advance!

Comparisons of ARM disassembly and decompilation

Here are some side-by-side comparisons of disassembly and decompiler for ARM. Please maximize the window too see both columns simultaneously.

The following examples are displayed on this page:

Simple case
64-bit arithmetics

Simple case

The decompiler saves your time and allows you to concentrate on more exciting aspects of reverse engineering.

64-bit arithmetics

Sorry for a long code snippet, ARM code tends to be longer compared to x86 code. This makes our comparison even more impressive: look at how concise is the decompiler output!

Conditional instructions

The pseudocode shows it much better and does not require any explanations.

A quiz question: did you notice that MOVNE loads zero to R0? (because I didn't:)

Also note that in the disassembly listing we see var_8 but the location really used is var_A, which corresponds to v4.

Conditional instructions - 2

The decompiler represented it perfectly well. I renamed some variables and set their types, but this was an easy task.

Complex instructions

In short, the disassembly listing is like Chinese. The pseudocode is longer but requires much less time to understand.

Compiler helper functions

Sorry for another long code snippet. Just wanted to show you that the decompiler can handle compiler helper functions (like __divdi3) and handles 64-bit arithmetic quite well.

Immediate constants

Also a side: the decompiler can handle ARM mode as well as Thumb mode instructions. It just does not care about the instruction encoding because it is already handled by IDA.

Position independent code

; bool __cdecl uh_gt_uc() EXPORT _uh_gt_uc__YA_NXZ _uh_gt_uc__YA_NXZ ; DATA XREF: .pdata:$T7452o var_2C = -0x2C var_28 = -0x28 var_24 = -0x24 var_20 = -0x20 var_1C = -0x1C var_18 = -0x18 var_14 = -0x14 var_10 = -0x10 var_C = -0xC var_8 = -8 var_4 = -4 STR LR, [SP,#var_4]! ; $M7441 ; $LN8@uh_gt_uc SUB SP, SP, #0x28 $M7449 BL uh STR R1, [SP,#0x2C+var_24] STR R0, [SP,#0x2C+var_28] BL uc STRB R0, [SP,#0x2C+var_20] LDRB R3, [SP,#0x2C+var_20] STR R3, [SP,#0x2C+var_1C] LDR R1, [SP,#0x2C+var_1C] LDR R3, [SP,#0x2C+var_1C] MOV R2, R3,ASR#31 LDR R3, [SP,#0x2C+var_28] STR R3, [SP,#0x2C+var_18] LDR R3, [SP,#0x2C+var_24] STR R3, [SP,#0x2C+var_14] LDR R3, [SP,#0x2C+var_18] STR R3, [SP,#0x2C+var_10] STR R1, [SP,#0x2C+var_C] LDR R3, [SP,#0x2C+var_14] CMP R3, R2 BCC $LN3_8 loc_6AC BHI $LN5_0 loc_6B0 LDR R2, [SP,#0x2C+var_10] LDR R3, [SP,#0x2C+var_C] CMP R2, R3 BLS $LN3_8 $LN5_0 MOV R3, #1 STR R3, [SP,#0x2C+var_8] B $LN4_8 ; --------------------------------------------------------------------------- $LN3_8 ; uh_gt_uc(void)+68j MOV R3, #0 STR R3, [SP,#0x2C+var_8] $LN4_8 LDR R3, [SP,#0x2C+var_8] AND R3, R3, #0xFF STRB R3, [SP,#0x2C+var_2C] LDRB R0, [SP,#0x2C+var_2C] ADD SP, SP, #0x28 LDR PC, [SP+4+var_4],#4 ; End of function uh_gt_uc(void)

EXPORT op_two64 op_two64 ; CODE XREF: refer_all+31Cp ; main+78p anonymous_1 = -0x28 var_20 = -0x20 anonymous_0 = -0x18 var_10 = -0x10 arg_0 = 4 000 MOV R12, SP 000 STMFD SP!, {R4,R11,R12,LR,PC} 014 SUB R11, R12, #4 014 SUB SP, SP, #0x18 02C SUB R4, R11, #-var_10 02C STMDB R4, {R0,R1} 02C MOV R1, 0xFFFFFFF0 02C SUB R12, R11, #-var_10 02C ADD R1, R12, R1 02C STMIA R1, {R2,R3} 02C LDR R3, [R11,#arg_0] 02C CMP R3, #1 02C BNE loc_9C44 02C MOV R3, 0xFFFFFFF0 02C SUB R0, R11, #-var_10 02C ADD R3, R0, R3 02C SUB R4, R11, #-var_10 02C LDMDB R4, {R1,R2} 02C LDMIA R3, {R3,R4} 02C ADDS R3, R3, R1 02C ADC R4, R4, R2 02C SUB R12, R11, #-var_20 02C STMDB R12, {R3,R4} 02C B loc_9D04 ; --------------------------------------------------------------------------- loc_9C44 ; CODE XREF: op_two64+30j 02C LDR R3, [R11,#arg_0] 02C CMP R3, #2 02C BNE loc_9C7C 02C MOV R3, 0xFFFFFFF0 02C SUB R0, R11, #-var_10 02C ADD R3, R0, R3 02C SUB R4, R11, #-var_10 02C LDMDB R4, {R1,R2} 02C LDMIA R3, {R3,R4} 02C SUBS R3, R1, R3 02C SBC R4, R2, R4 02C SUB R12, R11, #-var_20 02C STMDB R12, {R3,R4} 02C B loc_9D04 ; --------------------------------------------------------------------------- loc_9C7C ; CODE XREF: op_two64+68j 02C LDR R3, [R11,#arg_0] 02C CMP R3, #3 02C BNE loc_9CB8 02C MOV R3, 0xFFFFFFF0 02C SUB R0, R11, #-var_10 02C ADD R3, R0, R3 02C SUB R2, R11, #-var_10 02C LDMDB R2, {R0,R1} 02C LDMIA R3, {R2,R3} 02C BL __muldi3 02C MOV R4, R1 02C MOV R3, R0 02C SUB R12, R11, #-var_20 02C STMDB R12, {R3,R4} 02C B loc_9D04 ; --------------------------------------------------------------------------- loc_9CB8 ; CODE XREF: op_two64+A0j 02C LDR R3, [R11,#arg_0] 02C CMP R3, #4 02C BNE loc_9CF4 02C MOV R3, 0xFFFFFFF0 02C SUB R0, R11, #-var_10 02C ADD R3, R0, R3 02C SUB R2, R11, #-var_10 02C LDMDB R2, {R0,R1} 02C LDMIA R3, {R2,R3} 02C BL __divdi3 02C MOV R4, R1 02C MOV R3, R0 02C SUB R12, R11, #-var_20 02C STMDB R12, {R3,R4} 02C B loc_9D04 ; --------------------------------------------------------------------------- loc_9CF4 ; CODE XREF: op_two64+DCj 02C MOV R3, 0xFFFFFFFF 02C MOV R2, 0xFFFFFFFF 02C SUB R4, R11, #-var_20 02C STMDB R4, {R2,R3} loc_9D04 ; CODE XREF: op_two64+5Cj ; op_two64+94j ... 02C SUB R12, R11, #-var_20 02C LDMDB R12, {R0,R1} 02C SUB SP, R11, #0x10 014 LDMFD SP, {R4,R11,SP,PC} ; End of function op_two64

loc_110D6 ; CODE XREF: sub_10E38+43Cj ; sub_10E38+442j ... LDR R1, =(tmin_ptr - 0x1CDB8) LDR R2, =(tmax_ptr - 0x1CDB8) LDR R0, =(aRttMinAvgMaxMd - 0x1CDB8) LDR R6, [R7,R1] LDR R5, [R7,R2] MOVS R3, #0xFA LDR R4, [R6] LSLS R1, R3, #2 LDR R6, [R5] ADDS R5, R7, R0 ; "rtt min/avg/max/mdev = %ld.%03ld/%lu.%0"... MOVS R0, R4 BLX __aeabi_idiv MOV R8, R0 MOVS R0, R4 MOVS R4, #0xFA LSLS R1, R4, #2 BLX __aeabi_idivmod LDR R3, =0 LDR R2, =0x3E8 MOVS R4, R1 LDR R0, [SP,#0x78+var_40] LDR R1, [SP,#0x78+var_40+4] BLX __aeabi_ldivmod LDR R3, =0 LDR R2, =0x3E8 STR R0, [SP,#0x78+var_50] STR R1, [SP,#0x78+var_4C] LDR R0, [SP,#0x78+var_40] LDR R1, [SP,#0x78+var_40+4] BLX __aeabi_ldivmod MOVS R1, #0xFA MOVS R0, R6 LSLS R1, R1, #2 STR R2, [SP,#0x78+var_78] BLX __aeabi_idiv STR R0, [SP,#0x78+var_74] MOVS R0, R6 MOVS R6, #0xFA LSLS R1, R6, #2 BLX __aeabi_idivmod MOVS R2, #0xFA STR R1, [SP,#0x78+var_70] LDR R0, [SP,#0x78+var_38] LSLS R1, R2, #2 BLX __aeabi_idiv MOVS R3, #0xFA STR R0, [SP,#0x78+var_6C] LSLS R1, R3, #2 LDR R0, [SP,#0x78+var_38] BLX __aeabi_idivmod MOVS R0, R5 ; format STR R1, [SP,#0x78+var_68] MOVS R2, R4 MOV R1, R8 LDR R3, [SP,#0x78+var_50] BLX printf

; =============== S U B R O U T I N E ======================================= ; int __cdecl myfunc(wchar_t *Str, int) myfunc proc near ; CODE XREF: sub_4060+76p ; .text:42E4p Str = dword ptr 4 arg_4 = dword ptr 8 mov eax, dword_1001F608 cmp eax, 0FFFFFFFFh jnz short loc_10003AB6 push offset aGetsystemwindo ; "GetSystemWindowsDirectoryW" push offset aKernel32_dll ; "KERNEL32.DLL" call ds:GetModuleHandleW push eax ; hModule call ds:GetProcAddress mov dword_1001F608, eax loc_10003AB6: ; CODE XREF: myfunc+8j test eax, eax push esi mov esi, [esp+4+arg_4] push edi mov edi, [esp+8+Str] push esi push edi jz short loc_10003ACA call eax ; dword_1001F608 jmp short loc_10003AD0 ; --------------------------------------------------------------------------- loc_10003ACA: ; CODE XREF: myfunc+34j call ds:GetWindowsDirectoryW loc_10003AD0: ; CODE XREF: myfunc+38j sub esi, eax cmp esi, 5 jnb short loc_10003ADD pop edi add eax, 5 pop esi retn ; --------------------------------------------------------------------------- loc_10003ADD: ; CODE XREF: myfunc+45j push offset aInf_0 ; "\\inf" push edi ; Dest call _wcscat push edi ; Str call _wcslen add esp, 0Ch pop edi pop esi retn myfunc endp

; =============== S U B R O U T I N E ======================================= wndproc proc near ; DATA XREF: sub_4010E0+21o Paint = tagPAINTSTRUCT ptr -0A4h Buffer = byte ptr -64h hWnd = dword ptr 4 Msg = dword ptr 8 wParam = dword ptr 0Ch lParam = dword ptr 10h mov ecx, hInstance sub esp, 0A4h lea eax, [esp+0A4h+Buffer] push 64h ; nBufferMax push eax ; lpBuffer push 6Ah ; uID push ecx ; hInstance call ds:LoadStringA mov ecx, [esp+0A4h+Msg] mov eax, ecx sub eax, 2 jz loc_4013E8 sub eax, 0Dh jz loc_4013B2 sub eax, 102h jz short loc_401336 mov edx, [esp+0A4h+lParam] mov eax, [esp+0A4h+wParam] push edx ; lParam push eax ; wParam push ecx ; Msg mov ecx, [esp+0B0h+hWnd] push ecx ; hWnd call ds:DefWindowProcA add esp, 0A4h retn 10h ; --------------------------------------------------------------------------- loc_401336: ; CODE XREF: wndproc+3Cj mov ecx, [esp+0A4h+wParam] mov eax, ecx and eax, 0FFFFh sub eax, 68h jz short loc_40138A dec eax jz short loc_401371 mov edx, [esp+0A4h+lParam] mov eax, [esp+0A4h+hWnd] push edx ; lParam push ecx ; wParam push 111h ; Msg push eax ; hWnd call ds:DefWindowProcA add esp, 0A4h retn 10h ; --------------------------------------------------------------------------- loc_401371: ; CODE XREF: wndproc+7Aj mov ecx, [esp+0A4h+hWnd] push ecx ; hWnd call ds:DestroyWindow xor eax, eax add esp, 0A4h retn 10h ; --------------------------------------------------------------------------- loc_40138A: ; CODE XREF: wndproc+77j mov edx, [esp+0A4h+hWnd] mov eax, hInstance push 0 ; dwInitParam push offset DialogFunc ; lpDialogFunc push edx ; hWndParent push 67h ; lpTemplateName push eax ; hInstance call ds:DialogBoxParamA xor eax, eax add esp, 0A4h retn 10h ; --------------------------------------------------------------------------- loc_4013B2: ; CODE XREF: wndproc+31j push esi mov esi, [esp+0A8h+hWnd] lea ecx, [esp+0A8h+Paint] push ecx ; lpPaint push esi ; hWnd call ds:BeginPaint push eax ; HDC push esi ; hWnd call my_paint add esp, 8 lea edx, [esp+0A8h+Paint] push edx ; lpPaint push esi ; hWnd call ds:EndPaint pop esi xor eax, eax add esp, 0A4h retn 10h ; --------------------------------------------------------------------------- loc_4013E8: ; CODE XREF: wndproc+28j push 0 ; nExitCode call ds:PostQuitMessage xor eax, eax add esp, 0A4h retn 10h wndproc endp

loc_804BCC7: ; CODE XREF: sub_804BB10+A42j mov [esp+28h+var_24], offset aUnzip ; "unzip" xor eax, eax test esi, esi setnz al mov edx, 1 mov ds:dword_804FBAC, edx lea eax, [eax+eax+1] mov ds:dword_804F780, eax mov eax, ds:dword_804FFD4 mov [esp+28h+var_28], eax call _strstr test eax, eax jz loc_804C4F1 loc_804BCFF: ; CODE XREF: sub_804BB10+9F8j mov eax, 2 mov ds:dword_804FBAC, eax loc_804BD09: ; CODE XREF: sub_804BB10+9FEj mov [esp+28h+var_24], offset aZ2cat ; "z2cat" mov eax, ds:dword_804FFD4 mov [esp+28h+var_28], eax call _strstr test eax, eax jz loc_804C495 loc_804BD26: ; CODE XREF: sub_804BB10+99Cj ; sub_804BB10+9B9j ... mov eax, 2 mov ds:dword_804FBAC, eax xor eax, eax test esi, esi setnz al inc eax mov ds:dword_804F780, eax .............................. SKIP ............................ loc_804C495: ; CODE XREF: sub_804BB10+210j mov [esp+28h+var_24], offset aZ2cat_0 ; "Z2CAT" mov eax, ds:dword_804FFD4 mov [esp+28h+var_28], eax call _strstr test eax, eax jnz loc_804BD26 mov [esp+28h+var_24], offset aZcat ; "zcat" mov eax, ds:dword_804FFD4 mov [esp+28h+var_28], eax call _strstr test eax, eax jnz loc_804BD26 mov [esp+28h+var_24], offset aZcat_0 ; "ZCAT" mov eax, ds:dword_804FFD4 mov [esp+28h+var_28], eax call _strstr test eax, eax jnz loc_804BD26 jmp loc_804BD3D ; --------------------------------------------------------------------------- loc_804C4F1: ; CODE XREF: sub_804BB10+1E9j mov [esp+28h+var_24], offset aUnzip_0 ; "UNZIP" mov eax, ds:dword_804FFD4 mov [esp+28h+var_28], eax call _strstr test eax, eax jnz loc_804BCFF jmp loc_804BD09

mov eax, [esp+argc] sub esp, 8 push ebx push ebp push esi lea ecx, ds:0Ch[eax*4] push edi push ecx ; unsigned int call ??2@YAPAXI@Z ; operator new(uint) mov edx, [esp+1Ch+argv] mov ebp, eax or ecx, 0FFFFFFFFh xor eax, eax mov esi, [edx] add esp, 4 mov edi, esi repne scasb not ecx dec ecx cmp ecx, 4 jl short loc_401064 cmp byte ptr [ecx+esi-4], '.' jnz short loc_401064 mov al, [ecx+esi-3] cmp al, 'e' jz short loc_401047 cmp al, 'E' jnz short loc_401064 loc_401047: ; CODE XREF: _main+41j mov al, [ecx+esi-2] cmp al, 'x' jz short loc_401053 cmp al, 'X' jnz short loc_401064 loc_401053: ; CODE XREF: _main+4Dj mov al, [ecx+esi-1] cmp al, 'e' jz short loc_40105F cmp al, 'E' jnz short loc_401064 loc_40105F: ; CODE XREF: _main+59j mov byte ptr [ecx+esi-4], 0 loc_401064: ; CODE XREF: _main+32j _main+39j ... mov edi, esi or ecx, 0FFFFFFFFh xor eax, eax repne scasb not ecx add ecx, 3 push ecx ; unsigned int call ??2@YAPAXI@Z ; operator new(uint) mov edx, eax

Hex-Rays v7.2 vs. v7.1 Decompiler Comparison Page

Below you will find side-by-side comparisons of v7.1 and v7.2 decompilations. Please maximize the window too see both columns simultaneously.

The following examples are displayed on this page:

NOTE: these are just some selected examples that can be illustrated as side-by-side differences. There are many other improvements and new features that are not mentioned on this page.

Magic divisions in 64-bit code

In the past the Decompiler was able to recognize magic divisions in 32-bit code. We now support magic divisions in 64-bit code too.

More aggressive 'if' to 'boolean' folding

More aggressive folding of if_one_else_zero constructs; the output is much shorter and easier to grasp.

Better type of 'this' argument

The decompiler tries to guess the type of the first argument of a constructor. This leads to improved listing.

Improved union field selection

The decompiler has a better algorithm to find the correct union field. This reduces the number of casts in the output.

Improved recognition of 'for' loops

We improved recognition of 'for' loops, they are shorter and much easier to understand.

Added support for shifted pointers

Please note that the code on the left is completely illegible; the assembler code is probably easier to work with in this case. However, the code on the right is very neat. JFYI, below is the class hierarchy for this example:

Also please note that the source code had

but at the assembler level we have

Visual Studio plays such tricks.

Better recognition of inlined standard functions

Yes, the code on the left and on the right do the same. We prefer the right side, very much.

Improved application of pre-increment and pre-decrement

Minor stuff, one would say, and we'd completely agree. However, these minor details make reading the output a pleasure.

Added support for RRX addressing mode in ARM

This is a rare addressing mode that is nevertheless used by compilers. Now we support it nicely.

Improved constant propagation in global memory

The new decompiler managed to disentangle the obfuscation code and convert it into a nice strcpy()

Added support for Objective C blocks

The new version knows about ObjC blocks and can represent them correctly in the output. See Edit, Other, Objective-C submenu in IDA, it contains the necessary actions to analyze the blocks.

Improved recognition of 64-bit comparisons

We continue to improve recognition of 64-bit arithmetics. While it is impossible to handle all cases, we do not give up.

Merged common code in 'if' branches

Yet another optimization rule that lifts common code from 'if' branches. We made it even more aggressive.

Added forced stack variables

Sometimes compilers reuse the same stack slot for different purposes. Many our users asked us to add a feature to handle this situation. The new decompiler addresses this issue by adding a command to at the specified point. Currently we support only aliasable stack variables because this is the most common case.

In the sample above the slot of the p_data_format variable is reused. Initially it holds a pointer to an integer (data_format) and then it holds a simple integer (errcode). Previous versions of the decompiler could not handle this situation nicely and the output would necessarily have casts and quite difficult to read. The two different uses of the slot would be represented just by one variable. You can see it in the left listing.

The new version produces clean code and displays two variables. Naturally it happens after applying the force new variable command.

Added support for virtual calls

Well, these listings require no comments, the new version apparently wins!

Comparisons of PowerPC disassembly and decompilation

Here are some side-by-side comparisons of disassembly and decompiler for PowerPC. Please maximize the window too see both columns simultaneously.

The following examples are displayed on this page:

Simple code
Linear execution

Simple code

This simple function calculates the sum of the squares of the first N natural numbers. While the function logic is obvious by just looking at the decompiler output, the assembly listing has too much noise and requires studying it. The decompiler saves your time and allows you to concentrate on more exciting aspects of reverse engineering.

Linear execution

The PowerPC processor has a number of instructions which can be used to avoid branches (for example cntlzw). The decompiler restores the conditional logic and makes code easier to understand.

64-bit comparison

64-bit comparison usually involves several compare and branch instructions which do not improve the code readability.

System calls

System call is always mysterious, but decompiler helps you with its name and arguments.

Compiler helpers

Compiler sometime uses helpers and decompiler knows the meaning of the many helpers and uses it to simplify code.

Floating point arithmetic

The PowerPC processor contains a number of complex floating point instructions which perform several operations at once. It is not easy to recover an expression from the assembler code but not for the decompiler.

Magic multiplication/division operations

Compilers can decompose a multiplication/division instruction into a sequence of cheaper instructions (additions, shifts, etc). This example demonstrates how the decompiler recognizes them and coagulates back to the original operation.

VLE code

This example demonstrates that the decompiler can handle VLE code without problems.

Interactive decompiler

The pseudocode is not something static because the decompiler is interactive the same way as IDA. You can change variable types and names, change function prototypes, add comments and more. The example above presents the result after these modifications.

Surely the result is not ideal, and there is a lot of room for improvement, but we hope that you got the idea.

And you can compare the result with the original:

# int __fastcall msdos_add_entry(struct inode *_dir, const unsigned __int8 *name, int is_dir, int is_hid, int cluster, struct timespec *_ts, struct fat_slot_info *_sinfo) msdos_add_entry: .set back_chain, -0x50 .set de, -0x48 .set date, -0x28 .set time, -0x26 .set var_14, -0x14 .set sender_lr, 4 mflr r0 stw r0, sender_lr(r1) bl _mcount stwu r1, back_chain(r1) mflr r0 stmw r27, 0x50+var_14(r1) stw r0, 0x50+sender_lr(r1) subfic r5, r5, 0 mr. r30, r6 lwz r0, 0(r4) subfe r10, r10, r10 mr r31, r3 lwz r11, 4(r4) lwz r3, 0x1C(r3) clrrwi r10, r10, 4 mr r29, r7 lhz r5, 8(r4) addi r10, r10, 0x20 mr r28, r8 lbz r6, 0xA(r4) mr r27, r9 lwz r3, 0x2B8(r3) stw r0, 0x50+de(r1) stw r11, 0x50+de.name+4(r1) sth r5, 0x50+de.name+8(r1) stb r6, 0x50+de.name+0xA(r1) stb r10, 0x50+de.attr(r1) beq loc_728 ori r10, r10, 2 li r9, 0 li r7, 0 addi r6, r1, 0x50+date stb r10, 0x50+de.attr(r1) addi r5, r1, 0x50+time mr r4, r8 stb r9, 0x50+de.lcase(r1) bl fat_time_unix2fat lhz r9, 0x50+time(r1) li r10, 0 sth r10, 0x50+de.adate(r1) sth r9, 0x50+de.time(r1) lhz r9, 0x50+date(r1) sth r10, 0x50+de.cdate(r1) sth r10, 0x50+de.ctime(r1) stb r10, 0x50+de.ctime_cs(r1) sth r9, 0x50+de.date(r1) loc_698: addi r10, r1, 0x50+de.start srawi r9, r29, 0x10 sthbrx r29, r0, r10 addi r10, r1, 0x50+de.starthi mr r6, r27 sthbrx r9, r0, r10 li r5, 1 li r9, 0 addi r4, r1, 0x50+de mr r3, r31 stw r9, 0x50+de.size(r1) bl fat_add_entries mr. r30, r3 bne loc_710 lwz r10, 0(r28) lwz r11, 4(r28) stw r10, 0x48(r31) stw r10, 0x50(r31) stw r11, 0x4C(r31) stw r11, 0x54(r31) lwz r9, 0x1C(r31) lwz r9, 0x34(r9) andi. r10, r9, 0x90 bne loc_704 lwz r9, 0xC(r31) andi. r10, r9, 0x41 beq loc_768 loc_704: mr r3, r31 # struct inode * li r30, 0 bl fat_sync_inode loc_710: mr r3, r30 lwz r0, 0x50+sender_lr(r1) lmw r27, 0x50+var_14(r1) addi r1, r1, 0x50 mtlr r0 blr # --------------------------------------------------------------------------- loc_728: li r7, 0 addi r6, r1, 0x50+date stb r30, 0x50+de.lcase(r1) addi r5, r1, 0x50+time mr r4, r8 bl fat_time_unix2fat li r9, 0 sth r30, 0x50+de.adate(r1) stb r9, 0x50+de.ctime_cs(r1) lhz r9, 0x50+time(r1) sth r30, 0x50+de.cdate(r1) sth r9, 0x50+de.time(r1) lhz r9, 0x50+date(r1) sth r30, 0x50+de.ctime(r1) sth r9, 0x50+de.date(r1) b loc_698 # --------------------------------------------------------------------------- loc_768: mr r3, r31 # struct inode * li r4, 7 bl __mark_inode_dirty mr r3, r3 lwz r0, 0x50+sender_lr(r1) lmw r27, 0x50+var_14(r1) addi r1, r1, 0x50 mtlr r0 blr # End of function msdos_add_entry

int __fastcall msdos_add_entry(struct inode *dir, const unsigned __int8 *name, int is_dir, int is_hid, int cluster, struct timespec *ts, struct fat_slot_info *sinfo) { __int16 zero; // r30@1 601 bool not_hidden; // cr34@1 601 TYPED int v10; // r11@1 611 signed int v11; // r10@1 619 TYPED __int16 v13; // r5@1 621 __u8 node_attrs; // r10@1 625 TYPED __u8 v16; // r6@1 62D TYPED struct msdos_sb_info *sbi; // r3@1 635 TYPED int err; // r30@3 6C9 TYPED __time_t sec; // r10@4 6D1 TYPED __syscall_slong_t nsec; // r11@4 6D5 TYPED struct msdos_dir_entry de; // [sp+8h] [-48h]@1 639 TYPED __le16 date; // [sp+28h] [-28h]@2 670 TYPED __le16 time; // [sp+2Ah] [-26h]@2 670 TYPED zero = is_hid; not_hidden = is_hid == 0; v10 = *((_DWORD *)name + 1); v11 = (unsigned int)is_dir <= 0 ? 0 : -16; v13 = *((_WORD *)name + 4); node_attrs = v11 + ATTR_ARCH; // ATTR_ARCH or ATTR_DIR v16 = name[10]; sbi = (struct msdos_sb_info *)dir->i_sb->s_fs_info; *(_DWORD *)&de.name[0] = *(_DWORD *)name; // memcpy(&de.name[0], name, 12); *(_DWORD *)&de.name[4] = v10; // ... *(_WORD *)&de.name[8] = v13; // ... de.name[10] = v16; de.attr = node_attrs; if ( not_hidden ) { de.lcase = zero; // = 0 fat_time_unix2fat(sbi, ts, &time, &date, 0); de.adate = zero; de.ctime_cs = 0; de.cdate = zero; de.time = time; de.ctime = zero; de.date = date; } else { de.attr = node_attrs | ATTR_HIDDEN; de.lcase = 0; fat_time_unix2fat(sbi, ts, &time, &date, 0); de.adate = 0; de.time = time; de.cdate = 0; de.ctime = 0; de.ctime_cs = 0; de.date = date; } de.start = _byteswap_ushort(cluster); de.starthi = _byteswap_ushort(HIWORD(cluster)); de.size = 0; err = fat_add_entries(dir, &de, 1, sinfo); if ( err ) return err; sec = ts->tv_sec; nsec = ts->tv_nsec; dir->i_mtime.tv_sec = ts->tv_sec; dir->i_ctime.tv_sec = sec; dir->i_mtime.tv_nsec = nsec; dir->i_ctime.tv_nsec = nsec; if ( dir->i_sb->s_flags & (MS_DIRSYNC|MS_SYNCHRONOUS) || dir->i_flags & (S_DIRSYNC|S_SYNC) ) { err = 0; fat_sync_inode(dir); return err; } _mark_inode_dirty(dir); return 0; }

Introduction to Decompilation vs. Disassembly

Comparisons of ARM disassembly and decompilation

hashtagSimple case

hashtag64-bit arithmetics

hashtagConditional instructions

hashtagConditional instructions - 2

hashtagComplex instructions

hashtagCompiler helper functions

hashtagImmediate constants

hashtagPosition independent code

Comparisons of MIPS disassembly and decompilation

hashtagSimple code

hashtag64-bit comparison

hashtagMagic divisions

hashtagHard cases with delay slots

hashtagLittle-endian MIPS

hashtagMicroMIPS

hashtagFloating-point operations

hashtagCompiler helpers

Hex-Rays v7.4 vs. v7.3 Decompiler Comparison Page

hashtagBetter array detection

hashtagSupport for more floating-point helpers

hashtagAutomatic variable mapping

hashtagAutomatic symbolic names

hashtagSimplified C++ names

hashtagImproved handling of 64-bit arithmetics

hashtagBetter detection of 64-bit decrements

hashtagMore meaningful variable names

Hex-Rays v7.3 vs. v7.2 Decompiler Comparison Page

hashtagMore hexadecimal numbers in the output

hashtagSupport for variable size structures

hashtagUTF-32 strings are printed inline

hashtagBetter argument detection for printf

hashtagBetter argument detection for scanf

hashtagResolved TEB references

hashtagBetter automatic selection of union fields

hashtagYet one more example of union fields

hashtagImproved support for EABI helpers

hashtagImproved local variable allocation

hashtagBetter recognizition of string references

hashtagBetter handling of structures returned by value

hashtagMore while loops

hashtagShorter code

hashtagImproved recognition of magic divisions

hashtagLess gotos

hashtagDivision may generate an exception

hashtagOrder of variadic arguments

hashtagImproved division recognition

Hex-Rays v7.4 vs. v7.3 Decompiler Comparison Page

hashtagBetter array detection

hashtagSupport for more floating-point helpers

hashtagAutomatic variable mapping

hashtagAutomatic symbolic names

hashtagSimplified C++ names

hashtagImproved handling of 64-bit arithmetics

hashtagBetter detection of 64-bit decrements

hashtagMore meaningful variable names

Comparisons of MIPS disassembly and decompilation

hashtagSimple code

hashtag64-bit comparison

hashtagMagic divisions

hashtagHard cases with delay slots

hashtagLittle-endian MIPS

hashtagMicroMIPS

hashtagFloating-point operations

hashtagCompiler helpers

Hex-Rays v7.3 vs. v7.2 Decompiler Comparison Page

hashtagMore hexadecimal numbers in the output

hashtagSupport for variable size structures

hashtagUTF-32 strings are printed inline

hashtagBetter argument detection for printf

hashtagBetter argument detection for scanf

hashtagResolved TEB references

hashtagBetter automatic selection of union fields

hashtagYet one more example of union fields

hashtagImproved support for EABI helpers

hashtagImproved local variable allocation

hashtagBetter recognizition of string references

hashtagBetter handling of structures returned by value

hashtagMore while loops

Simple case

64-bit arithmetics

Conditional instructions

Conditional instructions - 2

Complex instructions

Compiler helper functions

Immediate constants

Position independent code

Simple code

64-bit comparison

Magic divisions

Hard cases with delay slots

Little-endian MIPS

MicroMIPS

Floating-point operations

Compiler helpers

Better array detection

Support for more floating-point helpers

Automatic variable mapping

Automatic symbolic names

Simplified C++ names

Improved handling of 64-bit arithmetics

Better detection of 64-bit decrements

More meaningful variable names

More hexadecimal numbers in the output

Support for variable size structures

UTF-32 strings are printed inline

Better argument detection for printf

Better argument detection for scanf

Resolved TEB references

Better automatic selection of union fields

Yet one more example of union fields

Improved support for EABI helpers

Improved local variable allocation

Better recognizition of string references

Better handling of structures returned by value

More while loops

Shorter code

Improved recognition of magic divisions

Less gotos

Division may generate an exception

Order of variadic arguments

Improved division recognition

Better array detection

Support for more floating-point helpers

Automatic variable mapping

Automatic symbolic names

Simplified C++ names

Improved handling of 64-bit arithmetics

Better detection of 64-bit decrements

More meaningful variable names

Simple code

64-bit comparison

Magic divisions

Hard cases with delay slots

Little-endian MIPS

MicroMIPS

Floating-point operations

Compiler helpers

More hexadecimal numbers in the output

Support for variable size structures

UTF-32 strings are printed inline

Better argument detection for printf

Better argument detection for scanf

Resolved TEB references

Better automatic selection of union fields

Yet one more example of union fields

Improved support for EABI helpers

Improved local variable allocation

Better recognizition of string references

Better handling of structures returned by value

More while loops

Shorter code

Improved recognition of magic divisions

Less gotos

Division may generate an exception

Order of variadic arguments

Improved division recognition

Simple case

64-bit arithmetics