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:
- Magic divisions in 64-bit code
- More aggressive 'if' to 'boolean' folding
- Better type of 'this' argument
- Improved union field selection
- Improved recognition of 'for' loops
- Added support for shifted pointers
- Better recognition of inlined standard functions
- Improved application of pre-increment and pre-decrement
- Added support for RRX addressing mode in ARM
- Improved constant propagation in global memory
- Added support for Objective C blocks
- Improved recognition of 64-bit comparisons
- Merged common code in 'if' branches
- Added forced stack variables
- Added support for virtual calls
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:
struct __cppobj B1 { B1_vtbl *__vftable /*VFT*/; char d1[4]; }; struct __cppobj B2 { B2_vtbl *__vftable /*VFT*/; char d2[4]; }; struct __cppobj A : B1, B2 { char d3[4]; };
Also please note that the source code had
A::a2(A *this)but at the assembler level we have
A::a2(B2 *this)
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 force creation of a new variable 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!