Si generamos un resumen con MD5 a los paquetes de spy2mobile y light veremos que se tratan del mismo fichero:
Y como vimos en las trazas de las comunicaciones del artículo anterior podemos deducir el proceso que ha seguido el troyano: a través de la aplicación com.supportcaptcha se realizó la descarga en la SD del paquete light.apk, que posteriormente se instaló bajo el nombre com.spy2mobile.light y el cual se inicia con el arranque del dispositivo.
Pero continuemos obteniendo información con otras herramientas.
apktoolkit
Nos sirve para extraer los recursos de la aplicación. Para usarla es necesario copiar el APK que queremos analizar en el directorio /usr/share/apktoolkit/ , en nuestro caso vamos a centrarnos en el troyano que se descargó vía Internet una vez instalada la aplicación:
El resultado de esta aplicación nos permitirá inspeccionar el código
smali (código ensamblador para el formato dex) sobre el que podremos localizar comportamientos anómalos a través de comandos en el sistema:
Además utilizando el explorador del sistema de ficheros podremos revisar los recursos recuperados del APK donde encontraremos las imágenes, definición de pantallas, textos, ficheros incluidos en la aplicación (tenéis más información acerca de las estructuras de directorios utilizadas por Android
aquí)...
Dentro de los recursos que encontraremos cabe destacar el fichero AndroidManifest.xml. donde se definen versiones, permisos, servicios, actividades... información esencial para que Android tenga conocimiento de cuándo y cómo ejecutar los componentes de la aplicación.
En el caso de la aplicación que estamos analizando podemos ver como nos hacen un all-in de permisos:
En ese mismo fichero también se reflejarán los
broadcast receivers:
Como podemos ver la aplicación se declara a la escucha de llamadas salientes y del arranque del dispositivo. Cualquiera de estas dos acciones desencadenará que la clase com.source.MainReceiver gestione el evento, dato que en términos del arranque ya habíamos identificar al listar los procesos al inicio del sistema.
Herramientas d2j
Esta herramienta se utiliza de forma habitual para convertir un fichero en formato
dex (los APK) en un fichero en formato
jar:
Una vez realizado el paso anterior es posible decompilar el contenido del jar con las herramientas
jd-gui o
jad.
Es interesante comentar también que este conjunto de herramientas dispone de otras utilidades que nos permitirán:
-
Modificar el contenido de un APK a través de código
Jasmin.
No profundizo en esta opción ya que se escapa del objetivo del artículo, aunque podéis imaginar el uso de esta herramienta para modificar aplicaciones y publicarlas en mercados alternativos.
-
Des-ofuscar código bajo un criterio establecido de forma manual.
Vamos a ver esta opción más en detalle. Primero abrimos el fichero jar generado con jd-gui:
Si exploramos las clases encontraremos que el código que nos interesa se encuentra ofuscado:
El siguiente paso será extraer los nombres de paquetes, clases, métodos y atributos para editarlos:
Modificamos su contenido para hacerlo más legible (aunque con sólo extraerlos se generarán nombres aleatorios que serán algo más sencillos de identificar que los ofuscados):
A continuación insertaremos estos nombres dentro del fichero
jar y volveremos a abrirlo desde
jd-gui:
El resultado que veremos será el siguiente:
sqlitebrowser
Con esta herramienta podremos ver de forma gráfica las bases de datos de tipo SQLite, de modo que lo primero que haremos será instalar el paquete en la máquina de análisis con:
apt-get install sqlitebrowser
Una vez instalada la herramienta la encontraremos en Applications > Programming > SQLite Database Browser.
El siguiente paso es disponer de la base de datos que queremos analizar, de modo que continuando con el ejemplo que teníamos entre manos vamos a intentar localizar su base de datos.
En Android lo habitual es que para gestionar las bases de datos se cree una clase que herede de la clase
SQLiteOpenHelper, de modo que vamos a intentar localizar esta cadena en el código:
Tenemos una clase ganadora:
com.source.b.f . Esta misma búsqueda la podemos realizar desde jd-gui para ver el código de forma más clara:
Si curioseamos esa clase nos encontraremos el siguiente método:
De modo que todo apunta a que tendremos una base de datos con nombre
system.bd, la descargamos desde su directorio por defecto (
/data/data/com.spy2mobile.light/databases/) y la abrimos con
sqlitebrowser:
Y aunque ya sabíamos desde el principio que estábamos analizando una aplicación para espiar el uso del dispositivo, confirmamos a través de la base de datos las múltiples tablas preparadas para capturar la información del usuario.
Conclusiones
Como veis tenemos a nuestro alcance múltiples herramientas que nos permitirán transformar la aplicación para que la podamos analizar desde distintas perspectivas, haciendo que los resultados del proceso de análisis se reduzcan a una cuestión de habilidad, experiencia y el tiempo que le queramos/podamos dedicar.
Finalmente os dejo una captura de la pinta que tiene el panel de administración Web del software espía que al final he podido configurar desde un dispositivo físico:
Artículo cortesía de Miguel Ángel García
