State-of-the-art binary code analysis tools
When decompiling code without high-level metadata (especially firmware), you may observe strange-looking address expressions which do not seem to make sense. What are these and how to fix/improve the pseudocode? Because on the CPU level there is no difference between an address and a simple number, distinguishing addresses and plain numbers is a difficult task which […]
When working on a binary, you often recover types used in it from many sources: creating structures manually, from data, or using decompiler; parsing header files; importing them from type libraries or debug information; However, it may happen that eventually you discover duplicates. For example, you find out that the “custom” structure you’ve been […]
While working with decompiled code and retyping variables (or sometimes when they get typed by the decompiler automatically), you might be puzzled by the discrepancies between pseudocode and disassembly. Consider the following example: We see that X22 is accessed with offset 0x10 (16) in the disassembly but 2 in the pseudocode. Is there a bug in the […]
Previously we’ve described how to use available type info to make decompilation of calls more precise when you have type information, but there may be situations where you don’t have it or the existing type info does not quite match the actual call arguments, and you still want to adjust the decompiler’s guess. One common […]
When dealing with compile binary code, the decompiler lacks information present in the source code, such as function prototypes and so must guess it or rely on the information provided by the user (where its interactive features come handy). One especially tricky situation is indirect calls: without exact information about the destination of the call, the […]
We’ve covered structure creation using disassembly or Local Types, but there is also a way of doing it from the decompiler, especially when dealing with unknown, custom types used by the program. Whenever you see code dereferencing a variable with different offsets, it is likely a structure pointer and the function is accessing different fields […]
While currently (as of version 8.1) the Hex-Rays decompiler does not try to perform full type recovery, it does try to deduce some types based on operations done on the variables, or using the type information for the API calls from type libraries. One simple type deduction performed by the decompiler is creation of typed […]
Sometimes in pseudocode you may encounter strange-looking code: The code seems to dereference an array calledMEMORY and is highlighted in red. However, this variable is not defined anywhere. What is it? Such notation is used by the decompiler when the code accesses memory addresses not present in the database. In most cases it indicates an error in […]
The Hex-Rays decompiler was initially created to decompile C code, so its pseudocode output uses (mostly) C syntax. However, the input binaries may be compiled using other languages: C++, Pascal, Basic, ADA, and many others. While the code of most of them can be represented in C without real issues, some have peculiarities which require […]
The release notes for IDA 8.0 mention outlined functions. What are those and how to deal with them in IDA? Function outlining is an optimization that saves code size by identifying recurring sequences of machine code and replacing each instance of the sequence with a call to a new function that contains the identified sequence […]