I am using Ghidra to analyze libpng-compat.1.5.10.so (downloaded from Fedora mirrors).

But it didn't load the expected disassembly. Then I used Objdump and IDA to check the code and they get the same results and process it correctly. Here are pictures of these three tools about the function png_write_rows:


enter image description here

we can see that from 0x6bf9, bad results are generated.

For comparison, Objdump:

enter image description here

and IDA:

enter image description here

I know IDA is the best SRE tool, and I always thought Ghidra and IDA are the top 2. Objdump is a basic, standard and old tool, but why is it that Ghidra can't even get the correct disassembly code while the other two tools do? I use auto-analyze and import the binary file for both IDA and Ghidra. How to correct these errors?

By adjusting analysis options,if Non-Returning Functions - Discovered is set as false, it will be correct.

  • (Replicated, using rpm.pbone.net/index.php3/stat/4/idpl/47213828/dir/fedora_17/com/…). Weird. That function entry gets marked noreturn, and it takes a "Clear flow and repair" command to get it to recognize it for what it is (a simple localized ebx loader). After that, "D" again on the original function appears to work -- but you have to do that on every function using entry. – Jongware Jun 25 '20 at 22:37
  • @usr2564301 "D" works for the extra code after "call entry", but the next lines following "call entry" get wrong disassembly. – xiaoyao Don Jul 3 '20 at 1:26
  • What does the align mean where an Intel mnemonic should be? I think I ran into this once before and never figured out what it was. – hippietrail Jul 4 '20 at 8:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.