Geek Answers Handbook

Decompiling (binary, NDK) C applications against Java applications (Dalvik bytecode)

Well,

since I'm interested in reengineering. I have spent a lot of time reengineering Android so far.

Nevertheless, I got to the point that I had a problem with compiled binary C code (NDK), and I found out that it is very difficult to decompile it back to C / C ++ than to decompile a DEX file back more or less well sources Java

What is the reason for this? I mean, bytecode is executed by Dalvik VM, and in the case of a regular binary file, it is executed instead of the real processor. Both are pretty similar, with the exception of some additional emulation levels, aren't they? At the moment, I do not see any big differences or causes for this problem.

Do you have any information for me, why is it more difficult to decompile a regular binary file (e.g. ELF or MS EXE) back to source C?

Thanks.

+4
source share
2 answers

The short answer is that C / C ++ code does not contain any reflective information, and C / C ++ has built-in functions, macros, and expanded loops that the Java compiler simply does not (as much as C / C + + compilers). It is also possible to optimize C / C ++ so that all you can do is decompile the assembly because there are no references to the application’s own functions. (Links to system functions will be found, though.)

+4
source

BTW, Hex-Rays ARM Decompiler makes reverse engineering a lot easier, check this out: http://www.hex-rays.com/hexarm_compare0.shtml

Another question is that it costs a lot ...

+2
source

More articles: