Análisis Visual del Comportamiento de Aplicaciones para Android

RECSI 2014, Alicante, 2-5 septiembre 2014
Análisis Visual del Comportamiento de
Aplicaciones para Android
Oscar Somarriba, Ignacio Arenaza-Nuño, Roberto Uribeetxeberria, Urko Zurutuza
Dpto. de Electrónica e Informática
Mondragon Goi Eskola Politeknikoa
Mondragon Unibertsitatea
Emails: oscar.somarriba@alumni.mondragon.edu, {iarenaza,ruribeetxeberria,uzurutuza}@mondragon.edu
Resumen—Los dispositivos móviles inteligentes equipados con
funciones avanzadas de computación y comunicaciones han
crecido rápidamente. Sin embargo, a pesar de los mecanismos de
seguridad existentes, y dada la cantidad creciente de dispositivos
conectados a Internet, también han aumentado exponencialmente
la cantidad de aplicaciones maliciosas (malware) dirigidas a ellos.
En este trabajo mostramos cómo los componentes peligrosos
y maliciosos del malware móvil se pueden visualizar de una
manera intuitiva a fin de descubrir fácilmente qué funciones de
Android pueden desencadenar el fraude. Nuestro enfoque incluye
un método para interceptar llamadas a funciones (”hooking”) con
el fin de recoger trazas pertinentes de la aplicación durante de
tiempo de ejecución. Esto permite la monitorización de llamadas
a funciones de la API de Android relacionadas con los permisos
de instalación de la misma. Las trazas obtenidas se colectan en
un servidor web central donde tiene lugar la visualización del
comportamiento de las aplicaciones.
Palabras clave—seguridad en aplicaciones móviles (mobile
application security), software malicioso en aplicaciones móviles
(mobile malware), análisis Visual (visual analytics), análisis del
comportamiento de aplicaciones móviles (application behavior
analysis)
I.
I NTRODUCCI ÓN
La adopción masiva de las comunicaciones móviles en la
vida cotidiana ha traı́do una necesidad de establecer en la
sociedad una confianza en la infraestructura móvil, y esto
supone un gran reto en la actualidad. Esto es debido a que las
plataformas móviles, como teléfonos inteligentes y tabletas,
ası́ como las aplicaciones móviles están aumentando exponencialmente en popularidad. Actualmente existen alrededor
de 1 millión de aplicaciones para el Sistema Operativo móvil
Android en su sitio web de ventas en lı́nea Google Play, con un
estimado de 50 mil millones de descargas [1]. En contraste, el
software malicioso (malware) que ataca la plataforma Android
ha aumentado considerablemente en los últimos 24 meses en
un 100 %. Las nuevas familias de malware Android están
evolucionando rápidamente para evitar ser detectados por los
escáneres tradicionales basados en firmas. Hay una necesidad de mejorar las capacidades de detección para superar
los nuevos desafı́os de detección debido a la ofuscación, y
ası́ mitigar o remediar el impacto de la evolución de malware
para Android.
Dado que el sistema operativo móvil más popular es Android OS de la compañia Google (en la actualidad tiene el 70 %
del mercado), Android es el OS más atacado con un 99 % de
los ataques malware según lo publicado por Cisco y Kapersky
Labs durante el tercer trimestre Q3 del 2013, y resumido en
el reporte de SOPHOS [2]. Esta investigación se enfoca en el
seguimiento del comportamiento en tiempo de ejecución de las
applicaciones y la visualización de sus funciones maliciosas
para descubrir qué tipo de ataques o intenciones existen
detrás de estas. La plataforma propuesta de monitorización
está compuesta básicamente de cuatro elementos, a saber: (i)
una aplicación Android llamada (Sink) que guı́a al usuario en
la selección y parametrización de la aplicación a supervisar,
(ii) un cliente embebido que se inserta en cada aplicación a
ser supervisada, (iii) un servicio web encargado de recoger
la aplicación a monitorizar, enviar al dispositivo la aplicación
instrumentada, y recopilar las trazas que va generando, (iv) y
finalmente un componente de visualización que muestra grafos
relacionados con el comportamiento de las trazas o llamadas
a funciones, relativa a la aplicación monitorizada.
Se prevé que esta herramienta pueda ser utilizada por
analistas malware con el fin de realizar una inspección visual
de las aplicaciones en estudio. Por otra parte, la monitorización de una aplicación en el momento de su ejecución es
esencial para entender cómo esta interactúa con el dispositivo,
con componentes claves tales como las APIs (Application
Programming Interfaces) provistas por el sistema. Una API
especifica cómo algunos componentes de software (rutinas,
protocolos y herramientas) deben actuar cuando estén sujetos
a invocaciones de otros componentes. Al rastrear y analizar
estas interacciones, podemos ser capaces de dar seguimiento
a cómo se comportan las aplicaciones, a cómo manejan datos
sensibles e interactuar con el sistema operativo.
I-A.
Contribución y organización del artı́culo
A lo largo de este artı́culo se presenta un método para
la detección de malware, mediante el análisis visual de la
ejecución de las funciones a las que llaman. La subsiguientes
partes del trabajo están organizadas como a continuación se
detalla. La sección II le da al lector las nociones básicas detrás
de los componentes utilizados en las siguientes secciones y recopila el trabajo previo relacionado con la temática. La sección
III describe la arquitectura de monitorización y visualización
del sistema presentado. La sección IV muestra los resultados
ISBN: 978-84-9717-323-0
254
O. Somarriba, I. Arenaza, R. Uribeetxeberria, U. Zurutuza
obtenidos con la infraestructura implementada haciendo uso
de diferentes aplicaciones. Por último, las secciones V y VI
presentan las conclusiones e identifican unas posibles lı́neas
futuras de trabajo, respectivamente.
II.
A NTECEDENTES Y T RABAJOS RELACIONADOS
En los ambientes convencionales de Java, el código fuente
es compilado en un conjunto de instrucciones llamado bytecode, el cuál es almacenado en un formato de ficheros .class.
Estos ficheros son más tarde leı́dos por la Máquina Virtual de
Java (JVM) al momento de su ejecución. Por otra parte, en
Android, el código fuente de Java que ha sido compilado en
ficheros .class debe ser convertido en ficheros .dex, frecuentemente referidos como ficheros ejecutables del tipo Dalvik
(Dalvik Executable). Además, Android application package
file (apk), es el formato de fichero utilizado para distribuir
e instalar software de aplicaciones y middleware en el sistema
operativo Android. Las apps se presentan en un fichero con
el formato .apk, en un contenedor de la aplicación binaria
que consiste en ficheros .dex, AndroidManifest.xml, y los
ficheros de recursos de la aplicación. Asimismo, el archivo
.apk resultante se firma con una clave (keystore) para establecer
la identidad del autor de la app. Existen métodos para realizar
el proceso en el sentido inverso. Apktool es un conjunto
de herramientas para realizar ingenierı́a inversa en apps, lo
que simplifica el proceso de ensamble y desensamble de
ficheros binarios de Android (.apk) a ficheros Smali (.smali),
permitiendo la modificación del código fuente. Esto resulta
especialmente útil para el análisis de las aplicaciones.
El análisis y detección de malware para Android ha sido
un tema candente de la investigación en los últimos años. Un
ejemplo de los mecanismos de inspección para la identificación de aplicaciones con malware para Android se presenta en
[3], donde también se desarrolló un sistema de instrumentación
transparente para la automatización de las interacciones de los
usuarios.
Además, en [4] se utiliza un marco de seguridad llamado
XManDroid para extender el mecanismo de seguimiento de
Android, con el fin de detectar y prevenir ataques del tipo
escalada de privilegios a nivel de aplicación durante el tiempo
de ejecución sobre la base de una polı́tica determinada. Adicionalmente, los autores en [5] y [6] han propuesto diferentes
técnicas de seguridad con respecto a los permisos de las
apps. Por ejemplo, en este último, se propone una herramienta
para extraer la especificación de permisos del código fuente
de Android OS. Por otra parte, las técnicas de detección
de malware en dispositivos móviles usualmente se pueden
clasificar de acuerdo al modo en el que se realiza el análisis:
análisis estático y análisis dinámico. La primera se basa en
intentar identificar el código malicioso por descompilación de
la aplicación y la búsqueda de cadenas o bloques de códigos
sospechosos; en la segunda se analiza el comportamiento de
una determinada aplicación utilizando la información de su
estado de ejecución. Algunos tipos recientes de detección de
malware son: Dendroid [7] como un ejemplo de un análisis
estático para dispositivos con Android, y Crowdroid, sistema
que agrupa la frecuencia de llamadas al sistema de las aplicaciones para detectar malware [8]. En un reciente trabajo de
Jiang y Zhou [9] se han mapeado los tipos más comunes
de violaciones de permisos en un gran conjunto de datos de
malware. Por otro lado, en [10], [11] se pueden encontrar
estudios más amplios sobre el estado del arte de la seguridad
para los dispositivos móviles.
Entre los sistemas de monitorización de comportamiento
de aplicaciones se encuentra una propuestas que permite
visualizar mediante grafos las llamadas a funciones de una
aplicación determinada, pero los autores lo hacen mediante
técnicas de análisis estático [12]. El sistema hace un mapa de
todas las funciones disponibles, mientras que este trabajo solo
monitoriza y visualiza aquellas funciones que se suceden en
tiempo de ejecución, obteniendo además los parámetros que
se envı́an a la función. No se han encontrado propuestas de
detección de malware en base a análisis dinámico que opere
en el dispositivo del usuario de manera muy ligera y ”online”.
Esto es necesario debido a la apertura de la Plataforma
Android donde el malware puede también ser instalado a
través de apps de otras fuentes, tales como páginas web y
de memorias USB, lo que requiere mecanismos de detección
que operan en el propio dispositivo.
III.
D ESCRIPCI ÓN DEL SISTEMA
En esta sección se presenta una solución aplicable para la
detección de anomalı́as producto de la presencia de malware
en las aplicaciones, basada en un análisis dinámico combinado
con el soporte de un servidor web.
La Figura 1 muestra la estructura de la plataforma de monitorización propuesta. Las etapas para llevar a cabo la misma
consisten en los siguientes pasos lógicos: Etapa I: Envió de
la aplicación APP y de una lista de permisos que se desean
monitorizar al Servidor Web, Etapa II: Instrumentación de la
aplicación mediante un proceso de hooking generando APP’,
Etapa III: Instalación y activación de la APP’ reemplazando a
APP en el dispositivo, Etapa IV: Almacenamiento de las trazas
de APP’ en una base de datos, y la Etapa V: Visualización de
los grafos relacionados con APP’.
De nuevo, en la Figura 1 se muestra un diagrama de bloques
formado por cuatro componentes: la aplicación Sink, un cliente
embebido, un servidor web, y el componente de visualización.
III-1. La Aplicación Sink: es una aplicación Android con
dos funciones principales: una de gestión de la aplicación a
monitorizar, y otra para el manejo de las trazas. La parte del
tratamiento de la aplicación, a su vez, está compuesta de un
conjunto de actividades como se muestra en la Figura 2(d).
En la Figura 2(a) el usuario selecciona la aplicación que
desea monitorizar, entre aquellas que no vienen reinstaladas de
fábrica. En el siguiente paso se seleccionan los permisos que
el usuario estime convenientes a monitorizar, relacionados con
la aplicación y considerados como peligrosas según el mapa
de funciones API obtenido con PScout [6]. La interfaz guı́a
después al usuario a lo largo de varias actividades donde se
llevan a cabo la subida de la aplicación y lista de permisos a
monitorizar al Servidor, descarga de la aplicación modificada,
Análisis Visual del Comportamiento de Aplicaciones para Android
255
Hooking Process
Non
Monitored
Android
application N
Stage I
Function 2
APP
Function n
Application
to hook
Disassembled
files
Permissions
Monitored
Android
application 2
partial
trace
SINK
Embedded
client
Monitored
Android
application 1
Function 1
Stage III:
Running
APP’
APP’
Stage II
Hooked
application
partial
trace
List of
functions
to hook
Modified
files
DrawGraph
(Java Program)
Stage IV
Databases
Database
Traces
of APP’
Embedded
client
Stage V
Web Service
Smart Device
Server
Figura 1: Componentes del Sistema de Monitorización del comportamiento de la Aplicación.
e instalación de la misma. Finalmente, un botón permite iniciar
o detener la monitorización de la aplicación en el cualquier
instante.
Por otra parte, el Sink permite realizar la gestión de las
trazas, ejecutando servicios en segundo plano. Este gestor
es el encargado de colectar las trazas enviadas desde los
clientes embebidos individuales, ubicados en cada una de las
aplicaciones supervisadas, añadiéndoles una marca de tiempo
y el hash del ID del dispositivo, y su almacenamiento en una
memoria intermedia circular común. Por último, las trazas se
envı́an periódicamente al servicio web donde se almacenan en
una base de datos.
III-2. El Cliente Embebido: consiste en un módulo de
comunicación que utiliza el protocolo UDP para la transmisión
de las trazas de las funciones modificadas invocadas en APP’,
al Sink.
III-3. El Servicio Web: provee los siguientes servicios al
Sink: subir aplicaciones, descargar las aplicaciones modificadas y enviar las trazas. Ahora la pieza clave de todo el
sistema y donde reside la lógica del método presentado, es la
herramienta que instrumenta la aplicación, el proceso conocido
como ”hooking”. Este componente mapea los permisos de
la aplicación en llamadas a funciones que son marcadas, las
cuáles van ser monitorizadas. Por lo tanto, este proceso es una
acción automática realizada por el servidor Web cada vez que
una aplicación es enviada al mismo.
Las funciones modificadas registrarán el nombre de la
aplicación, el nombre de paquete de la aplicación, y el hash de
la aplicación y enviará esta información al cliente embebido
junto con el nombre de la función (e.g., sendTextMessage(),
getDeviceID(), execSQL(), SendBroadcast(), etc.). A continuación, todos los ficheros modificados junto con el resto de los
recursos desensamblados se reensamblan y se empaquetan en
un fichero binario Android .apk. Al terminar la Etapa II, la
APP’ es descargada al Sink.
III-4. Visualizaciones: Con el fin de realizar un análisis visual del comportamiento de las aplicaciones se utiliza una base
de datos NoSQL basada en grafos, Neo4j1 . Neo4j almacena los
datos en una estructura orientada a grafos, en lugar de utilizar
las tablas relacionales de las bases de datos convencionales.
En términos generales, un grafo es una representación de un
conjunto de nodos y las relaciones entre ellos unidos por medio
de enlaces, (vértices y aristas o arcos, respectivamente). Esto
se ilustra en la Etapa V de la Figura 1. De esta manera,
se puede plasmar cada uno de los comportamientos de la
aplicación analizada con una representación simple pero muy
ilustrativa. Los grafos se elaboran mediante relaciones de
tipo ”una Aplicación incluye varias Clases que a su vez
llaman a Funciones”. El primer nodo superior, ”Aplicación”,
contiene el nombre del paquete de la aplicación, que es única
para cada una de las aplicaciones existentes, mientras que el
segundo nodo, ”Clase”, representa el nombre del componente
de Android que ha llamado a la ”API call”, el nodo ”Función”.
Una vez se obtiene la información recogida por el servicio
Web en la base de datos, toda su estructura de llamadas a funciones puede ser filtrada y tratada. Inicialmente se genera un
grafo sin incluir colores empleando el lenguaje Cypher Query
1 Software
disponible en el sitio web http://www.neo4j.org
256
O. Somarriba, I. Arenaza, R. Uribeetxeberria, U. Zurutuza
(a)
(b)
(c)
(d)
Figura 2: Interfaz de Usuario del Sink. (a) Selección de la aplicación, (b) Pasos de la aplicación, (c) Selección de los permisos,
y (d) Proceso de monitorización.
Languaje, que permite operar y aplicar transformaciones en el
grafo.
Para ello, un experto debe completar y encadenar un
conjunto de reglas que ayudan a resaltar el comportamiento
malicioso conocido (por ejemplo, la llamada a la función
SendMessageText(). Para ello, se buscan los nodos en la parte
inferior del grafo relacionado con las llamadas a funciones
API consideradas maliciosas. Las reglas incluyen la búsqueda
y representación de funciones maliciosas (representadas en
rojo), sospechosas o maliciosas pero no crı́ticas (en naranja)
y benignas (en verde). Cuando se detecta un comportamiento
malicioso como el envı́o de mensajes SMS a un número de
pago premium sin el consentimiento del usuario, se procede a
representar el nodo bajo inspección en color rojo como señal
de alerta usando Cypher.
IV.
R ESULTADOS
En esta sección se muestran los resultados de utilizar la
plataforma de monitorización y visualización para algunos
ejemplos. En este artı́culo, exploramos 3 diferentes apps con
el fin de evaluar todo el marco de trabajo:
Skype-free IM & video calls
La aplicación popular Angry Birds
El malware Fake player
IV-A.
Las Trazas
Después de ejecutar las aplicaciones arriba mencionadas
durante 2-3 de minutos cubriendo todas las funcionalidad de
la aplicación, el servidor Web recolecta un gran volumen de
trazas de cada una de las mismas.
IV-B.
Análisis Visual de las Trazas
Como se ha dicho anteriormente, un conjunto de reglas
predefinidas por expertos nos permite identificar las funciones
API ”sospechosas”, y en función de sus parámetros, se asignan
colores a éstas. Al hacerlo, nos permite identificar rápidamente
las funciones y asociarla con elementos relacionados. Al
aplicar la clasificación de funciones en base a un color para
cada nodo del grafo, esto permite la construcción de un ”mapa
visual”que describe y ayuda al análisis de su funcionamiento.
Además, este grafo es adecuado para guiar el analista durante
el examen de clasificación de una muestra de malware peligrosa debido a que el sombreado rojo de los nodos indican
estructuras maliciosos identificados por la infraestructura de
monitorización. Esta revisión debe realizarse entre todos los
nodos de las funciones llamadas en el nivel más bajos de cada
rama del árbol del grafo. Sin embargo, con el fin de colorear
completamente el grafo de la aplicación hasta llegar al nodo
raı́z, hay que recurrir a realizar un análisis de abajo hacia
arriba (”bottom-top”) del vecindario de cada función invocada
y las asociadas. Por lo tanto, si una de las ramas del grafo es
coloreada en rojo, a continuación, la app se considera como
potencialmente maliciosa.
En particular, los grafos de las aplicaciones como Skype,
Angry Birds, y Fake Player se muestran en la Fig. 3 lo cual
proporciona al usuario una indicación del estado de seguridad
de éllos. Para ello, se han creado reglas Cypher para colorear
aquellos nodos que contienen una llamada a función de envı́o
de SMS en rojo, y llamadas a funciones para obtener y mostrar
publicidad (Adware) en naranja.
Como resultado, el grafo generado para la aplicación Skype
no muestra ninguna amenaza y sus nodos aparecen coloreados
en verde, tal y como se muestra en la Fig. 3(a).
Por otra parte, en la Fig. 3(b) existe una aplicación con
Adware, por lo que varios nodos de esta aplicación están
coloreados en naranja, mientras en contraste las funciones
maliciosas que identifican un malware se colorean en rojo,
Análisis Visual del Comportamiento de Aplicaciones para Android
como se muestra en la Figura 3(c) para la aplicación Fake
Player.
V.
C ONCLUSIONES
En este trabajo se propone una arquitectura de supervisión
con el objetivo de monitorizar aplicaciones Android a gran
escala, sin modificar el firmware del mismo, sin la necesidad
de obtener permisos de administrador del dispositivo, y que
resulta en un grafo de visualización donde se destacan las
llamadas a función correspondientes a los comportamientos de
malware predefinido. La plataforma está compuesta por cuatro
componentes: el cliente embebido, el Sink, el servicio web y
la visualización. Antes de que una aplicacón sea supervisada,
el Sink la transfiere al Servicio Web, que se encarga de la
inserción de los hooks añadiendo el cliente embebido en el
interior la aplicación. Finalmente el Sink descargará la aplicación recién instrumentada. Cuando una función modificada
es llamada, se construye una traza parcial que será pasada al
cliente embebido que a su vez la enviará al Sink. Este recoge
los trazas parciales de todas las aplicaciones supervisadas, las
completa, y las sube mediante el servicio Web. El Servidor
finalmente transforma las trazas y las almacena en una base
de datos de grafos.
Por último, se aplican un conjunto de reglas predefinidas
con el fin de obtener una visualización donde se pone de
relieve o resalta la conducta maliciosa de la aplicación supervisada. La infraestructura desarrollada es capaz de monitorizar
simultáneamente varias aplicaciones en distintos dispositivos
y la recopilación de todos las trazas se da en un mismo
lugar. Las pruebas realizadas en este trabajo muestran que
las aplicaciones pueden ser preparadas para ser supervisadas
en cuestión de minutos y las aplicaciones modificadas se
comportan como estaban originalmente diseñadas. Además, se
ha mostrado que la infraestructura se puede utilizar para detectar comportamientos maliciosos en aplicaciones, tales como
el monitorizado del malware Fake Player. Las evaluaciones
del Sink han revelado que nuestro sistema de supervisión es
reactivo, no pierde ninguna de las trazas parciales, y tiene un
impacto muy pequeño en el rendimiento de las aplicaciones
supervisadas.
VI.
T RABAJOS FUTUROS
Como trabajo futuro, la plataforma se puede ampliar para
ser capaz de supervisar las funciones Android conocidas como
Intents, enviadas por la aplicación que permitirı́an a una
aplicación llamar a funciones que no requieren ningún tipo
de permiso especı́fico (como por ejemplo que una función
llame a un navegador sin que la aplicación tenga permisos
de Internet). No ser capaz de monitorear Intents significa que
la infraestructura no es capaz de realizar un seguimiento, de
si la aplicación supervisada inicia otra aplicación durante un
corto perı́odo de tiempo para realizar una tarea determinada,
e.g., para abrir un navegador web para mostrar la EULA (enduser license agreement). Además, esto permitirı́a saber cómo
la aplicación bajo prueba se comunica con el resto de las
257
aplicaciones de terceras partes y las aplicaciones instaladas
en el dispositivo.
Asimismo se puede ampliar el modelo anti-malware descrito
en este trabajo, desarrollando una arquitectura que lo complemente mediante la detección automática de malware móvil
como por ejemplo con el uso de VirusTotal, realizando ası́ un
paso de filtrado previo. En definitiva, se podrı́a obtener un
sistema mas versátil disponiendo en el móvil de una aplicación
que reporte anomalı́as (i.e., desviación del patrón de tráfico de
las aplicaciones de red) a un servidor anti-malware en su red.
R EFERENCIAS
[1] Businessinsider, “businessinsider.” Available Online, 2014.
[2] Sophos, “Sophos mobilebile security threat report.” Available Online, 2014.
http://www.sophos.com/en-us/medialibrary/PDFs/other/
sophos-mobile-security-threat-report.ashx.
[3] M. Karami, M. Elsabagh, P. Najafiborazjani, and A. Stavrou, “Behavioral
analysis of android applications using automated instrumentation,” in
Software Security and Reliability-Companion (SERE-C), 2013 IEEE 7th
International Conference on, pp. 182–187, June 2013.
[4] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer, and A.-R. Sadeghi,
“Xmandroid: A new android evolution to mitigate privilege escalation
attacks,” Technical Report TR-2011-04, Technische Universität Darmstadt, Apr. 2011.
[5] J. Jeon, K. K. Micinski, J. A. Vaughan, A. Fogel, N. Reddy, J. S. Foster,
and T. Millstein, “Dr. android and mr. hide: Fine-grained permissions in
android applications,” in Proceedings of the Second ACM Workshop on
Security and Privacy in Smartphones and Mobile Devices, SPSM ’12,
(New York, NY, USA), pp. 3–14, ACM, 2012.
[6] K. W. Y. Au, Y. F. Zhou, Z. Huang, and D. Lie, “Pscout: Analyzing
the android permission specification,” in Proceedings of the 2012 ACM
Conference on Computer and Communications Security, CCS ’12, (New
York, NY, USA), pp. 217–228, ACM, 2012.
[7] G. Suarez-Tangil, J. E. Tapiador, P. Peris-Lopez, and J. Blasco, “Dendroid: A text mining approach to analyzing and classifying code structures in android malware families,” Expert Syst. Appl., vol. 41, pp. 1104–
1117, Mar. 2014.
[8] I. Burguera, U. Zurutuza, and S. Nadjm-Tehrani, “Crowdroid: Behaviorbased malware detection system for android,” in Proceedings of the 1st
ACM Workshop on Security and Privacy in Smartphones and Mobile
Devices, SPSM ’11, (New York, NY, USA), pp. 15–26, ACM, 2011.
[9] X. Jiang and Y. Zhou, Android Malware. Springer New York, 2013.
[10] M. La Polla, F. Martinelli, and D. Sgandurra, “A survey on security
for mobile devices,” Communications Surveys Tutorials, IEEE, vol. 15,
pp. 446–471, First 2013.
[11] G. Suarez-Tangil, J. Tapiador, P. Peris-Lopez, and A. Ribagorda, “Evolution, detection and analysis of malware for smart devices,” Communications Surveys Tutorials, IEEE, vol. PP, no. 99, pp. 1–27, 2013.
[12] H. Gascon, F. Yamaguchi, D. Arp, and K. Rieck, “Structural detection
of android malware using embedded call graphs,” in Proceedings of the
2013 ACM workshop on Artificial intelligence and security, pp. 45–54,
ACM, 2013.
258
O. Somarriba, I. Arenaza, R. Uribeetxeberria, U. Zurutuza
(a) Grafo de Skype.
(b) Grafo del juego Angry Birds.
(c) Grafo del malware Fake Player.
Figura 3: Grafos de las aplicaciones bajo prueba. (a) Diagrama Superior: Grafo de Skype, (b) Diagrama Intermedio: Grafo de
la aplicación Angry Birds, y (c) Diagrama Inferior: Grafo del malware Fake Player.