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 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 […]
When you need to change the prototype of a function in the decompiler, the standard way is to use the “Set item type…” action (shortcut Y).
One case where you may need to do it is to add or remove arguments. Especially in embedded code or when decompiling variadic functions, the decompiler may deduce the argument […]