Autor
Formatos de archivo .DEX y .JAR
Como sabemos la mayoría de aplicaciones para Android están programadas en Java, los ejecutables de este sistema operativo tienen una extensión de tipo .APK, hasta aquí todo bien, pero debemos saber que esta extensión no es más que una variación de la extensión .JAR, por lo que si alguna vez hemos programado en Java sabemos que los .JAR funcionan como una especie de contenedor con varios archivos adentro, por lo que con cualquier compresor podemos extraer su contenido y ver una serie de archivos que son los que componen la aplicación.
Por lo tanto, si a una aplicación Android (.APK) le extraemos los ficheros con un compresor cualquiera podremos ver todos los ficheros que componen la aplicación:
Uno de estos archivos es classes.dex que será uno de los más importantes pues este es el que contiene las clases y todo el código en general de la aplicación.
Herramientas necesarias
Como mencionábamos más arriba, en Windows para poder ver el código en ensamblador de un archivo con extensión .exe usábamos el OllyDB, en esta ocasión haremos uso de una serie de herramientas que harán lo mismo y con esto podremos ver el código Java.
El proceso será sencillo, pasaremos el archivo .dex a .jar y luego descompilaremos este último. Para esto necesitaremos:
JD-GUI: Es una aplicación con interfaz gráfica muy intuitiva con la que podremos ver el código fuente de los archivos .class (básicamente .jar de Java). Con esta herramienta podremos ver clases, métodos y otros componentes del programa. Web oficial: http://java.decompiler.free.fr/?q=jdgui
Dex2Jar: Como su nombre nos lo dice, permite pasar de .dex a .jar, podemos usarlo individualmente o en conjunto con las herramientas que nombraremos aquí. Web oficial: http://code.google.com/p/dex2jar/
Eclipse: Es un IDE de desarrollo para varias plataformas y que funciona con java. Web oficial: http://www.eclipse.org/downloads/
Configurar .Dex2Jar en Eclipse
Lo primero será configurar un nuevo proyecto, por lo que vamos a File > New > Java Proyect, le ponemos un nombre al proyecto y damos a finalizar.
Seleccionamos nuestro proyecto en explorador de paquetes, luego estando seleccionado vamos al menú Project > Properties > Java Build Path. Allí en la pestaña “Libraries” damos click en “Add external Jars”, allí en la ventana que sale ubicamos la carpeta de Dex2Jar y añadimos todos los .Jar de la carpeta a nuestro proyecto y seleccionamos Ok.
Ahora añadimos nuestro fichero .APK al proyecto, es decir, lo arrastramos hasta el explorador de paquetes.
Ahora hacemos click derecho en la carpeta de nuestro proyecto, seleccionamos Run As > Run Configurations y hacemos doble click en “Java application”, por lo que se añadirá una especie de página en la cual podemos pasar argumentos.
Aquí en la pestaña “Main“añadimos el nombre de la clase Main de Dex2Jar, la cual es posible encontrarla haciendo click en el botón “search” de la misma pestaña, en mi caso tiene una estructura así: com.googlecode.dex2jar.v3.Main
Luego vamos a la pestaña arguments y en la primera caja de texto colocamos el nombre de nuestro fichero APK con la extensión:
Damos click en Aplicar (Apply) y luego en “Run”, para ver un resultado de este tipo:
Ahora actualizamos nuestro explorador de proyectos (Click derecho y luego le damos “Refresh”) y veremos un nuevo fichero con extensión .Jar, es el que necesitábamos.
Descompilar archivos .JAR
Con el proceso anterior obtuvimos un .JAR limpio, ahora debemos “decompilarlo” para así poder ver su código fuente, por lo que abrimos el JD-GUI y allí abrimos nuestro .JAR generado, lo primero que observo son los métodos y en especial uno que dice button1_click(), ya que de seguro allí habrá algo.
Pero bueno, ya a partir de aquí podemos seguir e investigar todo el código, obviamente los conocimientos de programación nunca están demás para entender los algoritmos implicados en la aplicación.
Crackme
http://www.mediafire.com/download/tbdy9228c2reclg/crackmetest.apk
Fuente
Ingeniería inversa en aplicaciones de Android II
se puede definir que el código generado para las aplicaciones Android no es exactamente “Java Bytecode”, por eso los ejecutables para Android no contienen ficheros .class si no .dex que significa Dalvik Executable. De igual forma estos ficheros .dex se pueden “decompilar” y lo que veremos posteriormente será un lenguaje de bajo nivel (Dalvik Bytecode).
Aunque como tal con algunas aplicaciones específicas podemos ver en un lenguaje de alto nivel estos códigos (aplicaciones como Dex2Jar posteriormente decompilando con JD-GUI). Algunos enlaces interesantes sobre Dalvik y los OPCodes:
http://www.dalvikvm.com/
http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html
http://developer.android.com/reference/dalvik/bytecode/Opcodes.html
Herramientas a utilizar y preparación del entorno
Para la preparación del entorno tendremos en cuenta todo lo necesario para empezar casi “desde cero”, los requisitos como siempre son saber la lógica de un lenguaje de programación (mejor si es Java) y bueno, lo demás se explicará poco a poco.
Como trabajaremos con Android necesitaremos usar la plataforma Java, ojo, no basta con el entorno de ejecución (JRE) necesitaremos todas las herramientas para desarrolladores (JDK – Java Development Kit) y un IDE cualquiera, puede ser Eclipse. http://www.oracle.com/technetwork/java/javase/downloads/index.html
También necesitaremos las herramientas de desarrollo de Android o SDK, en el portal oficial hay una guía de instalación http://developer.android.com/sdk/installing.html también debemos configurar un emulador o el AVD, que nos permitirá ejecutar una “máquina virtual” de Android en nuestros ordenadores (ver aquí http://developer.android.com/sdk/adding-components.html).
Smali/Baksmali: se trata de un ensamblador/desemsamblador de ficheros apk que nos servirá para generar los fuentes en lenguaje de bajo nivel (aunque como tal no lo usaremos en esta guía). Se puede descargar de aquí: http://code.google.com/p/smali/
APKTool: Esta herramienta sustituirá el Smali/Baksmali ya que los integra dentro de su paquete. Como su nombre lo indica es un kit de herramientas para trabajar con ficheros APK. http://code.google.com/p/android-apktool/ con el generaremos el código de bajo nivel y luego recompilaremos.
Testsign.jar: Es una herramienta de terceros desarrollada para “firmar” o generar certificados aleatorios para indicarle al sistema que el fichero que hemos modificado se trata de una aplicación Android. Se descarga de aquí http://code.google.com/p/zen-droid/downloads/list (buscar el fichero testsign.jar).
zipalign: se trata de una herramienta que viene incluida en el SDK (PATH\android-sdk-windows\tools\zipalign.exe), que está hecha para preparar nuestro apk para el sistema Android, es decir, para que su rendimiento sea tal cual para dicho sistema ya que si no está “comprimida” con esta herramienta podría afectar el rendimiento de la misma en el dispositivo.
Instalar aplicaciones APK en el emulador de Android
El AVD Manager Tool es la herramienta que nos permite gestionar distintas “máquinas virtuales” de un sistema Android configuradas para un api específica (es decir, para distintas versiones del sistema operativo Android). Supondré que ya tienen instalado el Android SDK que viene con el SDK Manager pero aún falta configurar dicho “emulador” o máquina virtual. Por lo que aquí explicaré como crear una. Lo que necesitaremos es ir al directorio en donde hemos instalado el Android SDK, allí veremos el ícono del logo o mascota de Android llamado SDK Manager, desde allí podremos instalar diversas apis y claro, configurar nuestra nueva máquina virtual.
Allí hacemos clic en la opción “Virtual Devices” y si es la primera vez que lo usamos de seguro no habrá ninguna máquina virtual configurada, por lo que hacemos clic en el botón de la derecha que dice “New…”.
Luego tendremos que configurarla. Los parámetros son:
Name: El nombre de la máquina virtual. Esta no puede contener espacios.
Target: Es el api que utilizaremos para ejecutar la máquina virtual es decir, como si fuera la versión de Android. Recomiendo de momento la “API Level 8″ o Android 2.2 que es lo mismo
Lo demás ya se configura una vez hemos seleccionado el api, pero si queremos parámetros adicionales podemos explorar la herramienta. Por último le damos a Create AVD.
Listo ahora la seccionamos en el listado y en la parte derecha le damos “Start” y “Launch”. Se empezará a cargar la nueva unidad virtual lo que puede tardar varios minutos así que debemos ser pacientes en este paso. Cuando arranque veremos una pantalla como si fuese un móvil Android, con el sistema operativo completamente funcional. Pero como lo que vamos a hacer es un proceso de ingeniería inversa necesitaremos probar la aplicación, por lo que surge la necesidad de instalar aplicaciones APK en esta nueva unidad virtual.
Lo base para esto será saber que las aplicaciones Android se deben copiar a la carpeta “platform-tools” por ejemplo, la mía está en C:\Android SDK\android-sdk-windows\platform-tools, esto porque allí hay una herramienta llamada ADB (Android Debug Bridge) la cual es una herramienta que funciona por línea de comandos y que también sirve de conexión de nuestro móvil al ordenador y realizar tareas desde allí
En esta ocasión la utilizaremos para instalar APKs, por lo que una vez copiado el APK al directorio “Platform-tools” debemos ejecutar (con el emulador abierto):
adb install fichero.apk o para desinstalar adb uninstall fichero
Ahora si todo ha salido bien veremos la aplicación instalada en el emulador. Por cierto, algo importante a tener en cuenta es que el emulador o unidad virtual debe estar ejecutándose al momento de realizar este proceso de instalación del APK.
Instalar y usar ApkTool
Con el proceso anterior aprendimos a probar los APK. Bien, olvidemos por un rato eso y ahora iniciemos con el proceso de “ingeniería inversa” como tal. En esta ocasión usaremos APKTool, que básicamente sirve para cambiar algunas cosas de las aplicaciones Android pero además de ensamblar y desensamblarlas, que es nuestro uso principal en esta ocasión.
Para instalar APKTool deberemos bajar tanto el fichero apktool.jar (el principal) y si estamos en Windows debemos bajar las dependencias, veamos el proceso paso a paso mejor:
Descargar APKTool y dependencias (apktool1.4.1.tar.bz2 y apktool-install-windows-r04-brut1.tar.bz2).
Descomprimir todo en una sola carpeta.
Copiar estos ficheros al directorio principal de Windows, es decir, C:\Windows.
Listo ahora podemos ejecutar desde la consola de Windows el APKTool (Tecla Windows + R > cmd > Tecleamos apktool para ver todos sus parámetros). Para continuar con dicho proceso deberemos generar nuestro bytecode o fuentes en código de bajo nivel. Para “decompilar” nos ubicamos en la carpeta del APK y tecleamos en la consola:
apktool d fichero.apk nombre_nuevo_sin_extension
En la consola sería algo como esto:
Ya “desensamblamos” todo por lo que si revisamos la carpeta de nuestro APK hay un nuevo directorio el cual tiene el mismo nombre que le especificamos en la línea de comandos hace un momento. Lo que contiene son los ficheros fuente, el AndroidManifest.xml, entre otros recursos Lo que nos interesa es la carpeta smali, donde están los fuentes.
Si revisamos dicha carpeta y los ficheros generados, veremos unos archivos con extensión .smali, y lo primero que noto es un archivo llamado “main.smali“, pues sí, el código en lenguaje de bajo nivel.
En el tomo nº 1 de esta guía básica compartí un “crackme” o una aplicación Android que pedia un usuario y contraseña, no era más que una comparación de strings. Supongamos ahora que estamos revisando dicha aplicación y nos ponemos a buscar el mensaje de error que muestra cuando el usuario y contraseña son incorrectos.
Usaré ahora un editor de textos, de forma intuitiva uso el buscador para encontrar este mensaje y revisando un poco el código encuentro una comparación de strings, que no representan más que dicha comparación de usuario y contraseña. Pero estos string están declarados en un OPCode llamado const-string, por lo que ya sabemos la importancia de reconocerlos y que para buscar cadenas está el OPCode const-string.
Ahora, esto quiere decir que si cambio el const-string y la cadena encontrada en la comparación podré modificar los datos de acceso a la aplicación, si pongo por ejemplo “123” como contraseña podremos ver que pasa (sabiendo que la contraseña actual es “2014″ y el nombre de usuario como se puede ver es “ricadmin”):
Una vez modificado el siguiente paso será empaquetar nuevamente nuestro fichero APK, por lo que abrimos una consola de comandos, nos ubicamos en la carpeta donde estábamos trabajando y tecleamos:
apktool b carpeta_de_trabajo ficherocompilado.apk
Nótese que anteriormente yo había “desensamblado” y le llamé a mi carpeta “debug-crackmetest”. Tengan muy en cuenta los espacios que hay entre colocar el nombre de la carpeta y el del nuevo fichero compilado.
Y listo, con eso habremos generado un nuevo fichero APK con el nombre que le hemos acabado de poner (aparece en la misma carpeta de trabajo).
Firmando la aplicación o “generando certificados”
Es importante decirle a Android que nuestro APK en realidad si se trata de una aplicación para Android, pues estos tienen ciertas características que el sistema lee antes de su ejecución como tal.
Para esta tarea usaremos el “testsign.jar” una utilidad escrita para dicha finalidad y que podemos bajar en para empezar a usarla debemos colocarla en la misma carpeta de nuestro APK recién compilado y en la consola escribimos:
java -classpath testsign.jar testsign compilado-firmado.apk
Tener en cuenta que esto se le aplica a nuestro APK recién compilado. Si todo sale bien no saldrá nada por pantalla:
Generar un APK apto para Android
Listo, con el paso anterior “firmamos” la aplicación, ahora debemos optimizar el nuevo APK con una herramienta llamada “zipalign” que se encuentra en la carpeta “tools” de donde tenemos instalado el Android SDK.
El siguiente paso será copiar nuestro APK recién firmado a la carpeta “tools” que es donde se encuentra la aplicación “zipalign”, abrimos una consola, nos ubicamos en el directorio donde está la aplicación y nuestro fichero recién copiado y tecleamos:
zipalign -f 4 fichero-compilado.apk fichero-final.pak
Si todo sale bien tampoco saldrá nada. Ahora solo nos queda probar la aplicación y que los cambios se hayan realizado funcionen. Por lo que nuestro “fichero-final.apk” lo copiamos a “platform-tools” para instalarlo en nuestra unidad virtual que debe estar ejecutándose (por lo que en la consola escribimos “adb install fichero-final.apk”). Y el resultado es:
Fuente
En línea
