Decompilación de aplicaciones (binarias, NDK) C en comparación con aplicaciones Java (bytecode Dalvik)

Bien,

Ya que estoy interesado en la reingeniería que pasar mucho tiempo en Android reengineering hasta ahora.

Sin embargo, llegué a un punto, donde tuve el problema de C-Code binario compilado (NDK) y llegué a saber que es muy difícil decompilar de nuevo a C / C ++ que descompilar un archivo DEX de nuevo a más o menos Así fuentes Java.

¿Cuál es la razón de esto? Quiero decir que el bytecode es ejecutado por la VM de Dalvik y en caso de un archivo binario habitual, es ejecutado directamente por el procesador real. Ambos son bastante similares a excepción de algunas capas de emulación adicionales, ¿no? No veo muchas diferencias en este momento o la razón de este problema.

¿Tiene alguna información para mí por qué es más difícil decompilar un archivo binario habitual (por ejemplo, ELF o MS EXE) de nuevo a la fuente C?

Gracias.

La respuesta corta es que el código C / C ++ no contiene ninguna información reflexiva y C / C ++ tiene funciones en línea, macros y bucles desenrollados que el compilador Java no hace (tanto como los compiladores C / C ++) . También es posible optimizar C / C ++ de forma tan extensa que todo lo que puede hacer es descompilar el ensamblaje porque no hay referencias a las funciones propias de las aplicaciones. (Sin embargo, se encontrarán referencias a las funciones del sistema.)

BTW, Hex-Rays ARM Decompiler hace trabajo de ingeniería inversa mucho más fácil, echa un vistazo a esto: http://www.hex-rays.com/hexarm_compare0.shtml

La otra pregunta es que cuesta mucho …

FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.