State-of-the-art binary code analysis tools
In one of the past tips we mentioned the __unused attribute which can be applied to function arguments. When can it be useful? Let’s consider this code from Apple’s dyld: v19 is passed as fist argument to dyld4::ProcessConfig::PathOverrides::setString(). Since its name looks like a class method, the decompiler assigned the class type to the first argument […]
Previously, we discussed a situation where the decompiler wrongly used a combined stack slot for two separate variables. We could solve it because each variable had a distinct stack location, so editing the stack frame to split them worked. However, modern optimizing compilers can actually reuse the same stack location for different variables active at […]
Previously we’ve seen how to do small edits to types directly from the pseudocode view. While this is enough for minor edits, sometimes you still need to use the full editor. Of course, it is always possible to open Structures, Enums, or Local Types and look for your type there, but what if you have […]
We already know that user-defined types such as structures and enums can be created and edited through the corresponding views, or the Local Types list. However, some small edits can be performed directly in the pseudocode view: structure fields can be renamed using the “Rename” action (shortcut N): you can also quickly retype them using […]
Occasionally you may run into the following error message: To ensure that the decompilation speed remains acceptable and does not block IDA, especially when using batch decompilation, by default the decompiler refuses to decompile the functions over 64 kilobytes (0x10000 bytes). But here we have function which is 3x as large: In such case you can manually […]
Let’s consider this snippet from decompilation of an x86 Windows binary: The same function is called twice with the same argument and the last one doesn’t seem to use the result of the GetComputerNameExW call. By switching to disassembly, we can see that eax is initialized before each call with a string address: However the decompiler does not […]
Let’s say you found a promising-looking string in the binary, followed the cross reference to the function using it, then decompiled it to see how the string is used, only to see no signs of it in the pseudocode. What’s happening? In such situation it often helps to set up two synchronized disassembly<->pseudocode views and […]
In order to faithfully represent the behavior of the code and to conform to the rules of the C language, the decompiler may need to add casts in the pseudocode. A few examples: a variable has been detected to be unsigned but participates in a signed comparison: An argument being passed to a function does not match […]
In order to show the user only the most relevant code and hide the unnecessary clutter, the decompiler performs various optimizations before displaying the pseudocode. Some of these optimizations rely on various assumptions which are usually correct in well-behaved programs. However, in some situations they may be incorrect which may lead to wrong output, so […]
When working with the decompiler, you probably spend most of the time in the pseudocode view, since most interactive operations (e.g. renaming, retyping and commenting) can be done right there. IDA is usually smart enough to detect important changes during such actions and update the pseudocode as necessary. However, occasionally you may perform actions […]