0

The decompilation and auto-analysis of this binary is grossly inaccurate. I am providing the binary as well as the IDB. IDA v6.95, 32 bit was used for the analysis. Can anyone take a look and suggest how I can improve the accuracy of IDA's analysis in this case?

Improve this question

1 Answer 1

Reset to default
1

Would you mind ellaborating which functions you are refering to? The ones I see (IDA 6.95, 32bit, linux) seem pretty normal to me. Here is the list:

function list

Generally, IDA adds functions as soon as it finds any referal of control flow, so broken functions are often generated by opaque predicates and falsely parsed jump tables.

edit: The functions you are referring to (sub_6C8, sub_6D0, sub_6D8) are functions related to the global offset table (see segment name). These are basically trampoline functions redirecting the control flow.

(PLT stands for procedure linkage table)

I'm not completely certain why IDA treats them as functions, but the functionality is no mistery.

You may try commands like:

readelf --relocs bug_manage_system

or

objdump -T bug_manage_system

Also, it may help to have a look at raw disassembler output of .plt.got using objdump or any other tool.

Reading an article about the linking procedure of elf files may certainly help: PLT and GOT - the key to code sharing and dynamic libraries GOT and PLT for pwning. What is PLT/GOT?

Improve this answer
3
  • There are many e.g. sub_6C8, sub_6D0, sub_6D8 etc. Also, I seem to be not able to find any cross reference to malloc
    – sherlock
    Jul 25, 2017 at 14:09
  • Look at the decompiler's output of the functions above.
    – sherlock
    Jul 25, 2017 at 15:29
  • @Holmes.Sherlock any other functions? See my updated answer
    – Nordwald
    Jul 27, 2017 at 5:38

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.