Análisis de una aplicación Android (Parte I) - Análisis estático

Esta semana voy a hablar sobre el análisis de una aplicación Android, para que la gente que nunca lo haya hecho tenga un primer contacto. Se dividirá en 2 post, el de hoy sobre análisis estático (parte I) y el de análisis dinámico (parte II).

Para ello vamos a utilizar una vulnerable, creada para practicar, se llama Diva, puedes descargarla desde aquí, o visitar el repositorio en GitHub.

Además, se va a hacer uso de un emulador, puede ser el que trae Android Studio, pero también valen otros, como Genymotion.

Análisis estático de App Android

Vamos a analizar el código, lo primero que haremos es obtener el archivo Androidmanifest.xml, que nos dará una idea de la estructura del proyecto y otra información importante, para ello usaremos Apktool. El código a ejecutar será el siguiente (teniendo en cuenta rutas):

apktool.jar d Apps\diva-beta.apk -o diva-app

Indicamos que decompile (d) la aplicación en la carpeta (-o) diva-app. Allí tendremos el código smali, código ensamblador de la app, el archivo Androidmanifest.xml, etc. Los archivos que conseguimos se ven a continuación:

Podemos usar otras aplicaciones para obtener el código de las clases Java, son dex2jar y jd-gui. Primero usamos dex2jar para obtener un archivo .jar:

Y luego lo abrimos con la herramienta jd-gui y vemos el código de las clases, que suele venir bastante bien.

Por ejemplo, si miramos la clase SqlInjectionActivity veremos un código un código que nos deja claro que es vulnerable (quitando el nombre de la clase, que lo dejaba obvio).

Cursor localCursor = this.mDB.rawQuery("SELECT * FROM sqliuser WHERE user = '" + paramView.getText().toString() + "'", null);

Concatena el texto que escribe el usuario directamente a la consulta, sin ninguna validación. Si comprobamos la clase HarcodeActvity veremos que la clave que tiene que meter el usuario se puede obtener directamente del código:

if (((EditText)findViewById(2131492987)).getText().toString().equals("vendorsecretkey"))

Solo revisando el código obtendríamos un acceso que no tendríamos que tener, por eso al desarrollar código hay que revisar bien estas cosas.

La parte de análisis estático llega a su fin, con esta información ya se puede seguir trabajando y revisando el código de las aplicaciones. Nos vemos en la parte II, con el análisis dinámico.

Ir al análisis dinámico