2

I know that there is a similar question but the answers didn't provide any fix for that problem.

I am decompiling a .dll file, and I have found out the subroutine that I needed, but it's throwing a "call analysis failed" at line call eax.

My question is: Can I properly decompile the subroutine with this call eax line, or can I change it to something else, or simply ignore it? Working in ASM is really tough because I need to take out the code itself, not patch, and manually converting assembly code into pseudocode will be really hard to do.

2 Answers 2

2

You can take one of the following approaches:

  1. call eax usually means there is an indirect call. try to find what and where eax is defined. Maybe only by looking at it, you will found the problem. If you find the origin but not understand the problem, you can try to patch it, to something like: mov eax, <known_function_address>

  2. Maybe you can change a function signature to overcome the issue like it described here.

  3. You can try to use a different decompiler, when the most notable one is Ghidra.

1
  • Thanks, I'll try to use Ghidra. EDIT: Yes, it worked!
    – xxd
    May 5, 2020 at 12:34
1

This problem is not unique to call eax but potentially any indirect call or a call to a function with wrong type information. The possible causes and solutions are described in the Hex-Rays Decompiler manual.

One common cause is the stack adjustment of the call not being correctly detected by IDA (e.g. the called function is stdcall with arguments but IDA detected that stack change is 0). This can be fixed by specifying the correct stack change value via the Alt+K shortcut (4 for each push is a good rule of thumb).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.