Android Apk decompilación parece fácil

Estaba jugando. He descargado el http://code.google.com/p/dex2jar/ dex2jar y el Java Decompiler JD-GUI http://java.decompiler.free.fr/?q=jdgui

Tengo mi propio archivo apk (firmado, sellado y en Google Play), utilizamos dex2jar para convertirlo en un repositorio de jar.

Línea de comandos (los usuarios de Windows utilizan .bat, todos los demás .sh):

d2j-dex2jar.bat -f MyAwesomeApp.apk

Arrastré y solté la salida en una JD-GUI, y todos los archivos de clase, el código original reapareció. Me sorprendió un poco. ¿Está expuesto mi código java / Android? ¿Cómo protege ProGuard mi APK si se puede descompilar y regenerar tan fácilmente? No parece ofuscado en absoluto …

Gracias por adelantado.

Obfuscators usualmente simplemente cambian clases, métodos y nombres de campos a nombres que no tienen significado. Por lo tanto, si tiene "ScoreCalculator.computeScore (Player p, Match m)" terminará con "A.zk (F f, R r)". Esto es similar a lo que Uglify o Cierre de compilador hacer para javascript, excepto que en javascript es reducir la longitud de la fuente.

Es posible entender lo que el método hace de todos modos, es sólo más difícil.

Además, Java utiliza enlace tardío (como archivos DLL o SO). Por lo tanto, las llamadas que van fuera de su código (como a java.util, java.lang etc .. paquetes) no puede ser ofuscada. Además, si su código necesita recibir llamadas desde fuera (un ejemplo típico, registre un oyente en un botón), ese código no puede ser ofuscado. Lo mismo ocurre con un DLL, donde se puede ver claramente el nombre del método que se debe llamar forma fuera de la DLL y las llamadas a otros DLL.

Sin embargo, la correlación entre un código fuente determinado y el código compilado no es necesariamente uno a uno. Los compiladores C más antiguos utilizados para producir el mismo código op para una directiva de origen dada, por lo que los descompiladores eran muy eficaces. Entonces los compiladores de C agregaron muchas optimizaciones al código op resultante, y estas optimizaciones hicieron el descompilador casi ineficaz [1]

Java nunca implementó (una gran cantidad) de optimizaciones en tiempo de compilación, porque para ejecutar en diferentes plataformas (incluyendo dispositivos android diferentes), Java decidió aplicar serias optimizaciones más tarde, en tiempo de ejecución, basándose en las propiedades de arquitectura y hardware del dispositivo en ejecución (Esto es lo que "HotSpot" es sobre todo [2] ).

Los obfuscadores buenos también suelen reordenar las instrucciones del bytecode, o insertar algunas inútiles, o aplicar algunas optimizaciones por adelantado para hacer que los descompiladores no puedan (o menos) derivar el código fuente tan fácilmente.

Esta técnica es inútil cuando se trata de personas que pueden leer bytecode, como cualquier ofuscación C posible es inútil si una persona puede leer el código de ensamblador.

Como muchos programas de craqueo demuestran, la ingeniería inversa siempre es posible, incluso con C u otros lenguajes, incluso en el firmware (piense en los firmwares del iPhone), porque el cliente en el que se ejecuta el código siempre no es de confianza y siempre se puede manipular.

Si tienes código de misión crítica, algo que vale mucho dinero que alguien puede robar, te sugiero que lo ejecutes en el lado del servidor, o validarlo de alguna manera.

También podría añadir, que hay alternativa moderna a esta ruta APKTool-> dex2jar-> JD-GUI!

Simplemente intente abrir el APK de código abierto y DEX decompiler llamado Jadx: https://sourceforge.net/projects/jadx/files/ También tiene versión en línea aquí: http://www.javadecompilers.com/apk