Metodología para el análisis y la detección de aplicaciones maliciosas en el sistema operativo Android.

Grado en Ingeniería Informática
Informatikako Ingeniaritzako
gradua
Proyecto fin de grado
Gradu amaierako proiektua
Metodología para el análisis y la detección de
aplicaciones maliciosas en el sistema operativo
Android.
Jorge Lekuona Ocio
Director: Borja Sanz Urquijo
Bilbao, Junio de 2021
Resumen
A día de hoy el uso que se le da a los dispositivos móviles es una herramienta tanto de trabajo
como de ocio ampliamente utilizada, es un instrumento que llevamos a diario encima y es una
gran fuente de información, en dicho dispositivo guardamos desde mensajes privados hasta
imágenes de cualquier índole, además no solo contiene información vulnerable, sino que
realizamos tareas delicadas como consultar nuestra cuenta bancaria o realizar pagos con el
mismo. Todo lo anteriormente mencionado ha convertido a los teléfonos en un objetivo de alto
valor para los crackers o hackers malintencionados. Los usuarios tendemos a instalar
aplicaciones sin consultar su autenticidad sin comprobar que dicha aplicación pida permisos de
más o simplemente aunque los solicite sin necesitarlos, la instalamos igualmente, lo que hace a
nuestros dispositivos vulnerables.
El objetivo de este proyecto es el desarrollo de una metodología que permita avanzar en el
estudio sobre las diferentes técnicas para el análisis y detección de aplicaciones maliciosas en
el sistema operativo Android. De esta forma, se conseguirá aumentar la seguridad y
concienciar sobre los grandes riesgos que conlleva la instalación de apps maliciosas. Para ello,
descargaremos múltiples aplicaciones y observaremos cuáles son maliciosas y sus
características principales. Además estudiaremos las diferentes metodologías que hay que
llevar a cabo para la detección de dichas aplicaciones maliciosas y cómo aplicarlas.
Este proceso se realizará en seis pasos. El primero será la búsqueda tanto de aplicaciones
benignas como de malware. Posteriormente, en un segundo paso se investigarán las diferentes
características de cada aplicación. El tercero consistirá en la extracción de las características
encontradas en el anterior paso; el cuarto consistirá en el análisis de las características
extraídas. Este análisis se realizará mediante herramientas de aprendizaje automático, en el
quinto paso se evaluarán los resultados obtenidos del análisis y en el sexto paso se
combinarán las características con mejores resultados para su posterior análisis y evaluación.
Aplicando esta metodología, se ha descubierto que las características con mayor tasa de
aciertos a la hora de diferenciar el malware del software benigno son los Permisos y las
Acciones, aunque combinandolos el porcentaje de aciertos no se ve casi afectado, aunque con
la combinación de varias características, en este caso 17 sí que se observa una notoria mejora.
Descriptores
Ciberseguridad, Android, Malware, Python, Sklearn, IA
III
Índice general
1.
Introducción
1
2.
Objetivos y alcance
3
2.1.
Objetivos Generales…………………………………………………………….3
2.2.
Objetivos específicos…………………………………………………………... 3
2.3.
Alcance…………………………………………………………………………...4
2.4.
Herramientas utilizadas………………………………………………………... 4
2.4.1.
2.4.2.
2.4.3.
Herramientas de Android…………………………………………….. 5
2.4.1.1.
Android……………………………………………………….. 5
2.4.1.2.
Smali………………………………………………………….. 6
Herramientas genéricas……………………………………………… 8
2.4.2.1.
Python……………………………………………………...… 8
2.4.2.2.
Shell de Unix………………………………………………….8
2.4.2.3.
ApkTool………………………………………………………..9
2.4.2.4.
Numpy………………………………………………………... 9
2.4.2.5.
Pandas……………………………………………………….. 10
Bibliotecas de AI………………………………………………………. 10
2.4.3.1.
3.
Estado de la técnica
3.1.
3.2.
SKLearn……………………………………………………….10
11
Tipos de malware………………………………………………………………. 11
3.1.1.
Troyanos……………………………………………………………….. 13
3.1.2.
Keyloggers…………………………………………………………….. 15
3.1.3.
Ransomware…………………………………………………………...16
3.1.4.
Spyware y Stalkerware………………………………………………..17
3.1.5.
Adware…………………………………………………………………. 17
Tipos de análisis………………………………………………………………... 18
3.2.1.
Estático………………………………………………………………… 18
3.2.2.
Dinámico………………………………………………………………..18
3.2.3.
Híbrido…………………………………………………………………..19
V
3.3.
Explicacion de tecnicas IA…………………………………………………….. 19
3.3.1.
3.3.2.
Modelos Lineales……………………………………………………... 19
3.3.1.1.
Ridge Classifier……………………………………………… 19
3.3.1.2.
Logistic Regression…………………………………………. 20
3.3.1.3.
SGD Classifier……………………………………………..…21
Nearest Neighbors……………………………………………….…… 22
3.3.2.1.
3.3.3.
Naive Bayes……………………………………………………....……23
3.3.3.1.
3.3.4.
3.3.6.
3.3.5.1.
AdaBoost Classifier……………………………………….… 24
3.3.5.2.
Gradient Boosting Classifier……………………………..… 25
Multi-Layer Perceptron……………………………………………..… 25
MLP Classifier……………………………………………..… 25
Metodología Desarrollada
27
4.1.
CRISP-DM Based………………………………………………………….……27
4.2.
Conjunción de características…………………………………………….……28
4.3.
Características extraídas………………………………………………….……28
4.3.1.
VI
Decision Tree Classifier…………………………………..… 24
Ensemble Methods…………………………………………………….24
3.3.6.1.
4.
Gaussian Naive Bayes………………………………………23
Decision Trees…………………………………………………………23
3.3.4.1.
3.3.5.
KNeighors Classifier………………………………………… 22
AndroidManifest……………………………………………………..…30
4.3.1.1.
Paquete…………………………………………………….… 30
4.3.1.2.
Activity…………………………………………………...…… 30
4.3.1.3.
Service…………………………………………………...……31
4.3.1.4.
Content Providers…………………………………………… 32
4.3.1.5.
Broadcast Receivers…………………………………...…… 33
4.3.1.6.
Intent Actions e Intent Filter Categories……………...…… 34
4.3.1.7.
Permisos…………………………………………………...… 34
4.3.1.8.
Exports…………………………………………………..……35
4.3.1.9.
Backups…………………………………………………….…36
4.3.1.10.
Meta Data…………………………………………………..…36
4.3.1.11.
Uses Features…………………………………………..…… 36
4.3.2.
4.4.
5.
Datos de la aplicación……………………………………………...… 37
Caso de Uso…………………………………………...…………………..…… 37
4.4.1.
Decompilar…………………………………...…………………...……37
4.4.2.
Extraer Características……………………...………………..……… 38
4.4.3.
Generar listados……………………...……………………….…….…43
4.4.4.
Generar Dataset……………………...………………………….….…45
4.4.5.
Análisis………………………………………...………………….…… 47
Resultados
51
5.1.
5.2.
Métricas…………………………………………...………………………..…… 51
5.1.1.
Accuracy Score………………………...………………………………51
5.1.2.
Balanced Accuracy Score……………...……………………….…… 51
5.1.3.
Precision Score………………………...…………………………...… 52
5.1.4.
Average Precision Score……………...………………………………52
5.1.5.
Brier Score Loss………………………...…………………………..…53
5.1.6.
F1 Score………………………...………………………………...……53
5.1.7.
Recall Score……………………...……………………………….……54
5.1.8.
ROC AUC Score………………...……………………………….…… 54
Resultados obtenidos………………...…………………………………………54
5.2.1.
Permisos………………...……………………………………..……… 54
5.2.2.
Todos los permisos posibles………………………………….………56
5.2.3.
Acciones………………...………………………………………...……57
5.2.4.
Servicios………………...………………………………………...……58
5.2.5.
Categorías……………...………………………………………...…… 59
5.2.6.
Permisos y acciones…...……………………………………..……… 61
5.2.7.
Todos los valores………...…………………………………………… 62
VII
5.3.
6.
Comparativa con los diferentes Papers anteriores……………………….… 63
Planificación, presupuesto y estructura del proyecto
65
6.1.
Planificación……………………………………………………………..……… 65
6.2.
Presupuesto…………………………………………………………..………… 66
6.3.
Estructura del proyecto……………………………………………....…………67
7.
Trabajo futuro
69
8.
Conclusiones
71
8.1.
9.
VIII
Análisis de los aspectos éticos del proyecto……………………...………… 71
8.1.1.
Consecuencias…………………………………………...…………… 71
8.1.2.
Metodos de investigacion………………………………….………… 72
8.1.3.
Procedimientos de decisión………………………………..…………72
8.1.4.
Costes…………………………………………………………..……....72
Agradecimientos
73
Índice de figuras
Figura 1: Malware en Android a lo largo de los años (fuente AVTEST)
Figura 2: Nuevo malware en Android 2019-2021 (fuente AVTEST)
Figura 3: Capas dentro de un sistema Android
Figura 4: Método en Smali abstracto
Figura 5: Método en Smali
Figura 6: Llamada a un método en Smali abstracto
Figura 7: Opcodes en Smali
Figura 8: Ejecución de ApkTool
Figura 9: Cantidad de ataques a dispositivos móviles en 2019 y 2020
Figura 10: Cantidad de ataques a dispositivos móviles de 2017 a 2020
Figura 11: Cantidad de ataques a dispositivos móviles por tipo de malware
Figura 12: Cantidad de ataques de troyanos tipo ransom de 2018 a 2020
Figura 13: Cantidad de ataques de troyanos Banker de 2017 a 2020
Figura 14: Cantidad de ataques de Adware de 2018 a 2020
Figura 15: Fórmula modelos lineales
Figura 16: Función de costo 1
Figura 17: Problema de optimización
Figura 18: Función de costo 2
Figura 19: Fórmula Gaussian Naive Bayes
Figura 20: Diagrama CRISP-DM
Figura 21: Diagrama CRISP-DM Based
Figura 22: Formato paquete
Figura 23: Paquete en AndroidManifest
Figura 24: Activity en AndroidManifest
Figura 25: Formato service
Figura 26: Service en AndroidManifest
Figura 27: Formato Content Providers
IX
Figura 28: Content Providers en AndroidManifest
Figura 29: Broadcast Receiver en AndroidManifest
Figura 30: Intent filter en AndroidManifest
Figura 31: Categoría en AndroidManifest
Figura 32: Permisos en AndroidManifest
Figura 33: Exports en AndroidManifest
Figura 34: Backups en AndroidManifest
Figura 35: meta-data en AndroidManifest
Figura 36: uses-feature en AndroidManifest
Figura 37: Comando Decompilar
Figura 38: Script Decompilar
Figura 39: Ejecución del script para Decompilar
Figura 40: Ejecución del script para Extraer las características
Figura 41: Script para Extraer las características
Figura 42: Ejemplo de características a buscar en AndroidManifest
Figura 43: Ejemplo de características a buscar fuera de AndroidManifest
Figura 44: Resultado de carpeta de cada aplicación
Figura 45: Ejemplo de “.txt” generado
Figura 46: Comando ejecutar generador de listados
Figura 47: Ejemplo código generador de listados
Figura 48: Ejemplo ejecución generador de listado
Figura 49: Comando ejecutar generador de Datasets
Figura 50: Ejemplo código generador de Dataset
Figura 51: Ejemplo código generador de Datasets para datos no asignados en los listados
Figura 52: Ejemplo código de análisis
Figura 53: Función exactitud
Figura 54: Función Balanced Accuracy
Figura 55: Función Precision
Figura 56: Función Precision y Recuperación
X
Figura 57: Gráfica de Recuperación y precisión
Figura 58: Función F1
Figura 59: Función Recuperación
Figura 60: Tabla resultados Paper PERMISSION ANALYSIS FOR ANDROID MALWARE
DETECTION
Figura 61: Tabla resultados Paper Puma, Universidad de Deusto
XI
Índice de Tablas
Tabla 1: Ejemplo listados
Tabla 2: Resultado permisos
Tabla 3: Resultado todos los permisos posibles
Tabla 4: Resultado acciones
Tabla 5: Resultado servicios
Tabla 6: Resultado categorías
Tabla 7: Resultado permisos y acciones
Tabla 8: Resultado todos los valores
Tabla 9: Reparto de horas
Tabla 10: Datos del sistema usado
XIII
PROYECTO FIN DE GRADO
Capítulo 1
Introducción
Este proyecto de fin de grado nace debido al afán por la búsqueda de soluciones ante el
aumento constante de malware en dispositivos móviles, y más en concreto en el sistema
operativo Android.
Estos dispositivos son usados desde para el ocio, como ver videos o películas, hasta para el
trabajo diario como mirar el correo, leer documentos importantes, pasando por realizar tareas
que requieren privacidad y seguridad como ver los datos bancarios o realizar pagos. El
problema surge cuando, pensando que no hay malware alguno en dispositivos móviles, los
usuarios instalan aplicaciones de fuentes desconocidas sin prestar atención a los permisos que
estas piden y sin verificar sus fuentes, por otra parte, hay veces que estas aplicaciones se
encuentran disponibles en fuentes fiables como la “PlayStore” de Android o la “AppStore” de
iOS y los usuarios más cautos las descargan debido a la confianza que depositan en las
plataformas oficiales de los distintos sistemas.
Figura 1: Malware en Android a lo largo de los años [1].
1
1.INTRODUCCIÓN
Figura 2: Nuevo malware en Android 2019-2021 [1].
Estas aplicaciones maliciosas son capaces de robar información sensible, espiar la actividad
del dispositivo, tomar el control del mismo, eliminar archivos, bloquear la información y pedir
rescates, recoger datos como la ubicación del dispositivo, imagenes de las cámaras del mismo,
las conversaciones que se están manteniendo cerca del dispositivo, insertar anuncios en el
sistema, etc.
La falta de una concienciación sobre estos peligros ha ayudado a que los ataques hayan
aumentado drásticamente y se ha generado una industria a su alrededor, este malware cada
vez es más sofisticado y ágil, siendo de esta manera más efectivo y capaz de atacar a una gran
cantidad de usuarios en poco tiempo y sin ser descubiertos [2][3]. Esta evolución lleva a que los
antivirus cada vez tengan más problemas para detectar dicho software.
Para poder evitar estos ataques, es necesaria tanto la concienciación de los usuarios sobre los
peligros invisibles del uso indebido de la tecnología, como la creación de nuevos métodos y
software para la prevención y detección de dicho malware.
Como soporte a dicha detección, en este Proyecto de Fin de Grado se creará una metodología
para el análisis estático de las aplicaciones, así como una búsqueda de un grupo de
características distintivas para mejorar la detección de malware en Android. Además se
analizarán los diferentes algoritmos de aprendizaje automático en busca del óptimo para el
análisis de aplicaciones Android.
2
PROYECTO FIN DE GRADO
Capítulo 2
Objetivos y alcance
Este capítulo presenta el objetivo general de este Proyecto de Fin de Grado (PFG) así como los
objetivos específicos ligados al mismo. Además se expone el alcance del propio Proyecto y las
herramientas conceptuales y conocimientos necesarios para el desarrollo del mismo.
2.1 Objetivos Generales
El objetivo principal de este PFG es el análisis de las diferentes cualidades de las aplicaciones
Android, para ello se analizará principalmente los diferentes elementos del AndroidManifest,
archivo donde se declaran las diferentes funcionalidades de la aplicación, como ejemplos de
dichas características serían los permisos, los servicios, los proveedores de contenido o las
actividades. Además se compararán los diferentes algoritmos de clasificación y se buscará el
algoritmo o algoritmos que mejor evalúen las aplicaciones.
Con esta evaluación se busca una mejora a lo largo del proceso de análisis estático de
aplicaciones Android. No solo se busca el algoritmo de clasificación óptimo, sino que también
se busca un conjunto de características cuya combinación lleve a un análisis con una gran tasa
de aciertos.
Tras el análisis de las herramientas y las características se deberán comparar los resultados de
este proyecto con otros realizados con anterioridad en el ámbito del análisis de malware en
aplicaciones Android en busca de mejoras o de diferencias entre las características
encontradas y analizadas.
2.2 Objetivos específicos
En este apartado se procederá a dividir el proyecto en sus diferentes objetivos para poder
obtener el resultado deseado. A continuación de describe cada uno de los pasos a seguir para
la realización de los diferentes objetivos para conseguir el objetivo mencionado en el apartado
objetivos generales.
Primero se deberá investigar acerca de la estructura y funcionamiento de las aplicaciones
Android. Se analizará tanto la estructura de las carpetas, la forma en la que estas están
estructuradas y cómo están organizados los archivos, como, la estructura de los propios
archivos, pero más en profundidad el fichero “AndroidManifest.xml”.
Una vez se haya analizado la estructura tanto de las aplicaciones Android como sus
contenidos, se procederá a diseñar una metodología para la extracción, análisis y evaluación
de dichas características.
Cuando se haya analizado la estructura de las aplicaciones Android y se haya creado una
metodología, se extraerán tanto las características seleccionadas dentro del AndroidManifest y
como características fuera de este, es decir, se extraerán características no contenidas por
3
2. OBJETIVOS Y ALCANCE
dicho AndroidManifest como por ejemplo la cantidad de imágenes y videos. Generando de esta
manera un dataset con las características extraídas. Inicialmente se extraerán las
características por separado, generando de esta manera múltiples conjuntos de datos, una vez
se verifique la validez de las características se generará un conjunto de datos que contenga
múltiples características.
Con ese conjunto de datos se procederá a entrenar herramientas de aprendizaje automático
para la detección de las aplicaciones maliciosas, dichas herramientas serán comparadas y se
buscará la herramienta más adecuada para el análisis, es decir la herramienta con mayor tasa
de aciertos. Además se buscarán las características más distintivas y se realizarán
combinaciones para buscar una mejor tasa de aciertos.
Una vez se haya realizado el proceso se habrá desarrollado una metodología para el análisis
estático del malware en Android y se habrá obtenido un conjunto de características y un
algoritmo de aprendizaje automático óptimos. Con estos resultados se realizará una
comparación con Papers realizados anteriormente por otros individuos y otras instituciones
para verificar que se haya obtenido una mejora o que se haya descubierto algún dato
novedoso.
2.3 Alcance
El alcance de este proyecto es llegar a entrenar diferentes máquinas de aprendizaje automático
con las diferentes características estáticas de las aplicaciones contenidas en dicho dataset.
El alcance de este proyecto consta de dos objetivos principales, el primero es desarrollar una
metodología efectiva a la hora de realizar un análisis estático, el segundo es encontrar nuevas
características útiles en la detección de malware en Android.
El segundo objetivo se realizará a través de la metodología desarrollada y tratará de analizar
los diferentes algoritmos de aprendizaje automático y obtener el algoritmo o algoritmos óptimos
para la detección de malware en Android. Además se buscará un conjunto de características
con las que se pueda obtener una gran tasa de aciertos.
El proceso consta de tres pasos principales, el primero será extraer las diferentes
características por separado, el segundo consistirá en entrenar máquinas de aprendizaje
automático para la detección de las aplicaciones maliciosas, el tercer y último paso será el de
extraer las métricas de precisión de los clasificadores. Con los resultados obtenidos se
realizará el proceso otra vez para combinar las características con mayor precisión y
comprobar si la tasa de acierto aumenta.
Una vez obtenidos los resultados deseados se realizará una comparación de dichos resultados
con los resultados obtenidos en otros papers por otros investigadores. Se intentará obtener
mejores resultados y descubrir nuevas características representativas del malware.
2.4 Herramientas utilizadas
A continuación se procederá a detallar y a analizar cada una de las herramientas utilizadas
para la realización de este PFG. Dichas herramientas se dividirán en las herramientas propias
de android, las herramientas genéricas y las bibliotecas de AI
4
PROYECTO FIN DE GRADO
2.4.1 Herramientas de Android
2.4.1.1 Android
En este proyecto se procederá a realizar un análisis de aplicaciones maliciosas que afecten
este sistema operativo, es primordial conocerlo en profundidad. Por lo que en este apartado se
analizarán los diferentes componentes del mismo y su funcionamiento básico.
Android es un sistema operativo enfocado a dispositivos móviles basado en el núcleo del
sistema operativo Linux, además de otros sistemas de código abierto. Este SO fue diseñado
específicamente para dispositivos táctiles como tablets, smartphones, relojes inteligentes, o
vehículos que implementan Android Auto. Este sistema operativo fue originalmente
desarrollado por Android Inc. y adquirido por Google, el SO fue presentado por Google junto
con la fundación Open Handset Alliance para poder mantener un formato de código abierto. El
código fuente principal de Android es de código fuente abierto (open source) licenciado bajo la
Licencia Apache principalmente.
Contiene una arquitectura dividida en cinco apartados diferentes, el primero y más profundo
sería el núcleo Linux, este núcleo se encarga de la gestión de la memoria, de la gestión de
procesos, de la pila de red, del modelo de controladores y de la seguridad, además de los
servicios mencionados se encarga de hacer de capa de abstracción entre hardware y software.
El segundo componente es el Runtime de Android, el cual incluye un conjunto de bibliotecas
que proporcionan la mayoría de las funciones disponibles en las bibliotecas base del lenguaje
de programación Java, cada aplicación Android corre su propio proceso y su propia instancia
de la máquina virtual Dalvik, la cual es una herramienta que provee de múltiples máquinas
virtuales optimizadas para ejecutarse de una forma eficiente, esta máquina está basada en
registros y corre clases compiladas por el compilador de Java. El tercero son las bibliotecas, las
cuales son un conjunto de herramientas escritas en C y C++. Estas bibliotecas son usadas por
los diferentes componentes del sistema y son proporcionadas a los desarrolladores a través del
marco de trabajo de aplicaciones. Este marco de trabajo de aplicaciones es el cuarto elemento
de la arquitectura del sistema Android, es el elemento encargado de simplificar la reutilización
de componentes a través de la provisión de las bibliotecas a los desarrolladores además de
proveer las capacidades publicadas por una aplicación a las demás. La quinta y última capa es
la capa de aplicación, dependiendo la distribución algunas aplicaciones estarán previamente
instaladas, todas las aplicaciones están escritas en el lenguaje Java [4].
5
2. OBJETIVOS Y ALCANCE
Figura 3: Capas dentro de un sistema Android [5].
2.4.1.2 Smali
Es una herramienta que permite descompilar los ejecutables de Android y convertirlos a un
lenguaje intermedio que facilita su entendimiento. Con este lenguaje se puede descompilar,
modificar y volver a compilar una aplicación. El lenguaje es similar a código ensamblador. Las
aplicaciones Android son programadas en el lenguaje de programación java, cuando el código
java es compilado este se transforma en ficheros binarios cuya extensión es .class. A la hora
de crear una aplicación android no solo generamos los ficheros .class, sino que una vez
generados dichos archivos se volverán a compilar para generar un único archivo con extensión
.dex, dicho archivo contiene todas las clases existentes en la aplicación [6].
Estos ficheros .dex no se pueden volver a descompilar directamente a java debido a que los
archivos .dex son casi ilegibles. A pesar de esto existen herramientas para convertir dichos
archivos .dex a lenguaje java como dex2jar. Pero esto tiene varios problemas como que no
siempre es posible generar un fichero .jar o que aunque el código java nos permita comprender
la aplicación, no podremos volver a compilar la misma [7].
La sintaxis de smali es la siguiente:
●
6
Registros: Se guardan los datos de forma temporal. Todos los registros son de 32 bits,
aunque podremos almacenar datos de 64 bits utilizando dos registros con los tipos
primitivos Long o Double.
PROYECTO FIN DE GRADO
●
●
Tipos:
○ Primitivos: Los tipos primitivos son V (Void), Z (Boolean), B (Byte), S (Short),
C (Char), I (Integer), J (Long), F (Float) y D (Double). Estos valores primitivos
serán representados por una letra mayúscula anteriormente mencionada.
○
Objetos: Son declarados de la siguiente forma LPackage/Name/ObjectName;.
La primera L indica que es una variable de tipo objeto, Package/Name es la
ubicación del objeto, ObjectName es el nombre del mismo.
○
Vectores: Se representan mediante "[", por ejemplo [I siendo equivalente a
int[], o [[I siendo equivalente a [][]. La dimensión máxima de un vector es de
255.
Métodos: Los métodos son declarados de forma similar a java:
.method modificador nombre Método(ParámetrosEntrada)ParámetrosSalida
. Código
.end method
Figura 4: Método en Smali abstracto
Donde el modificador indica si el método es public, protected o private. Los parámetros de
entrada son escritos de forma contigua sin separadores. Los Parámetros de salida son el
resultado que devuelve el método.Como ejemplo de la clase main de una clase Java:
.method public static main([Ljava/lang/String;)V
. Código
.end method
Figura 5: Método en Smali
Los métodos se llaman de la siguiente forma:
LObjeto -> método(ParámetrosEntrada)V
Figura 6: Llamada a un método en Smali abstracto
Donde L indica que es una variable, Objeto es el nombre que asignaremos al Objeto que recoja
los datos del método, método es el nombre del mismo, los Parámetros de entrada son los que
el método recibe y V es la respuesta del mismo.
●
Opcodes: Los códigos operacionales son las operaciones que realiza Dalvik con los
registros y componen la lógica del programa. Son representados por dos dígitos
hexadecimales desde 00 hasta FF aunque algunos no son usados, por ejemplo los
representados desde E3 hasta ED o desde FC hasta FF. Como ejemplo está 00 que
significa nop (No operar), por lo que en un archivo smali se mostraría nop o en el caso
del 01 sería move vx, vy donde se mueve el contenido de vy a vx. Ejemplo en smali:
.class public LHelloWorld;
.super Ljava/lang/Object;
7
2. OBJETIVOS Y ALCANCE
.method public static main([Ljava/lang/String;)V
.registers 2
sget-object v0, Ljava/lang/System;->out:Ljava/io/PrintStream;
const-string v1, "Hello World!"
invoke-virtual {v0, v1},
Ljava/io/PrintStream;->println(Ljava/lang/String;)V
return-void
.end method
Figura 7: Opcodes en Smali [8].
2.4.2 Herramientas genéricas
2.4.2.1 Python
Es un lenguaje de programación interpretado, es decir, no es directamente ejecutado por el
hardware de la máquina, es ejecutado por una máquina virtual. El eje central sobre el que se
desarrolló este lenguaje es la legibilidad de su código y soporta tanto la programación orientada
a objetos como la programación imperativa y la programación funcional pero en menor medida.
Por lo que es un lenguaje muy extendido en el ámbito de la informática, en este caso se usará
tanto para generar los Datasets, como para aplicar aprendizaje automático sobre los conjuntos
de datos generados [9].
Entre sus elementos principales se encuentran:
●
Comentarios: Estos se muestran de dos formas, usando “# Comentario ” para los
comentarios de una línea y usando “ ‘‘’ comentario ‘’’ ” para los comentarios largos.
●
Variables: Se definen de forma dinámica, esto indica que no se tiene que especificar el
tipo en primera instancia, habilitando de esta manera la posibilidad de indicar distintos
valores posteriormente, además se puede asignar un tipo distinto al que contenía con
anterioridad. La asignación de una variable se realizaría de la siguiente manera “x = 1”
o “x = “python”. Tener en cuenta que también existen nombres reservados como and,
or, else, etc.
●
Tipos de datos: Los tipos de datos pueden ser de dos tipos, mutables, variables cuyo
valor puede cambiar en tiempo de ejecución, por ejemplo (list o set) e inmutables,
variables cuyo valor no puede cambiar en tiempo de ejecución, por ejemplo (str o
tuple). Los diferentes tipos son los siguientes: str, unicode, list, tuple, set, frozenset,
dict, int, long, float, complex, bool.
2.4.2.2 Shell de Unix
Es el intérprete de comandos usado en linux, se usa para, mediante instrucciones comunicarse
con el núcleo del sistema y ejecutar las diferentes órdenes del usuario. Más en concreto
usaremos zsh, el shell predeterminado de kali linux 2020.4 [10].
Entre sus principales características encontramos que es capaz de completar las líneas de
comandos y ayudar a los usuarios a escribir tanto los comandos como sus opciones, puede
8
PROYECTO FIN DE GRADO
compartir el historial entre todas las shells en ejecución, tiene distintos tipos de compatibilidad
pudiendo de esta forma fingir ser otras shells distintas, muestra los avisos en la ejecución, etc.
Sus principales comandos son ls, echo, touch, mkdir, grep, man, pwd, cd, mv, rmdir, locate,
less, compgen, cat, head, tail, chmod, exit.
2.4.2.3 ApkTool
ApkTool es una herramienta para realizar ingeniería inversa a aplicaciones Android. Es capaz
de descodificar un archivo .apk casi hasta su forma original. También es capaz de reconstruir
una aplicación decodificada después de realizar cambios. Cuando decodifica una aplicación
genera la siguiente estructura [11]:
●
Carpeta original: Contiene tanto el AndroidManifest.xml original y la carpeta
META-INF original.
●
assets: Contiene los recursos de la aplicación como videos, imágenes, audios y
ficheros HTML, XML etc.
●
res: Contiene los archivos adicionales de la aplicación y el contenido estático de la
aplicación.
●
Smali: Contiene el código de la aplicación. Dicho código está escrito en Smali.
●
lib: Contiene las librerías usadas por la aplicación, siempre y cuando no sean
descargadas en ejecución.
●
unknown: Contiene ficheros que no son de uso común en la mayoría de aplicaciones.
●
AndroidManifest.xml: El archivo AndroidManifest.xml ubicado en la raíz de la
aplicación es legible por el usuario y es el que contiene toda la información general de
la aplicación.
El comando usado para decodificar la aplicación es el siguiente:
$ apktool d NombreAplicación.apk
Figura 8: Ejecución de ApkTool
2.4.2.4 Numpy
Esta herramienta se ha usado porque es una biblioteca que permite crear vectores y matrices
multidimensionales de gran tamaño para Python. Se ha usado para la creación de vectores a
partir de los datos del Dataset para ser usados por los algoritmos de aprendizaje automático
[12].
9
2. OBJETIVOS Y ALCANCE
2.4.2.5 Pandas
Pandas es una biblioteca de software libre usada para la manipulación y análisis de datos en
Python, ofrece desde estructuras de datos hasta herramientas para manipular tablas
numéricas. Esta herramienta se usará para importar los conjuntos de datos junto con Numpy
[13].
2.4.3 Bibliotecas de AI
2.4.3.1 SKLearn
Scikit-learn es una biblioteca de aprendizaje automático, su objetivo es desarrollar técnicas que
aprendan, es una biblioteca de software libre y se aplica sobre el lenguaje Python. Entre sus
librerías están NumPy, Pandas, SciPy, Matplotlib, Ipython y SymPy. Gracias a esta librería
podremos usar los algoritmos y validaciones necesarios para analizar las aplicaciones [14].
10
PROYECTO FIN DE GRADO
Capítulo 3
Estado de la técnica
3.1 Tipos de malware
En este apartado del PFG analizaremos los principales tipos de malware existentes en Android,
el malware para esta plataforma comenzó a desarrollarse en el 2010, en sus inicios las
primeras aplicaciones maliciosas creadas fueron troyanos. Más adelante el malware fue
comercializado en la dark web y se crearon kits que permitían una fácil distribución y
generación del mismo, un ejemplo conocido es el MazelTov Toolkit, un kit creado en 2005 que
permite la generación y distribución de malware para dispositivos android [15].
En el año 2020 Kaspersky mobile ha detectado más de 5 millones y medio de paquetes de
instalación maliciosos, más de 156.000 troyanos bancarios y más de 20.000 troyanos de tipo
ransomware. En la mayoría de los casos de ciberataques los criminales usan técnicas de
ingeniería social, engañando al usuario para la instalación del malware. El año pasado los
ciberataques crecieron de forma exponencial debido al COVID-19 y al confinamiento de la
mayor parte de la población. Los cibercriminales han aprovechado para crear aplicaciones
maliciosas con el formato de aplicaciones que ayudan a la detección del coronavirus o que
informan sobre el estado del mismo en la zona del dispositivo [16].
Figura 9: Cantidad de ataques a dispositivos móviles en 2019 y 2020 [16].
Otro software, aunque no malicioso, si es similar al malware es el adware. Este software, no ha
crecido a lo largo de la pandemia, sino que su uso se ha mantenido estable, aunque sí se han
creado nuevas variantes que dificultan reconocer de qué aplicación provienen los anuncios que
el adware genera.
11
3. ESTADO DE LA TÉCNICA
Las zonas más afectadas por ataques maliciosos a dispositivos móviles son Irán, Algeria,
Bangladesh, India, Marruecos, Nigeria, Arabia Saudita, Malasia, Kenya, Indonesia, Brasil,
Argentina, Méjico, Chile y China (SecureList Kaspersky, 2020) [16].
En cuanto a los ataques provocados por malware a las distintas plataformas móviles podemos
observar que la cantidad de dispositivos Android atacados creció notablemente el año pasado.
Figura 10: Cantidad de ataques a dispositivos móviles Android de 2017 a 2020
Pasando al ataque producido por tipo de malware podemos observar que el malware más
común es el AdWare, seguido por las RiskTools y los troyanos con función Dropper.
Figura 11: Cantidad de ataques a dispositivos móviles por tipo de malware
Entre los permisos que estas aplicaciones maliciosas requieren, los más comunes son los
siguientes [17]:
●
12
AUTHENTICATE_ACCOUNTS: Es uno de los permisos más críticos, permite a la
aplicación autenticar información de alto valor como contraseñas, este permiso, pedido
por una aplicación desconocida muestra indicios de un gran riesgo [18].
PROYECTO FIN DE GRADO
●
READ_LOGS: Es un permiso muy solicitado por aplicaciones de terceros de
procedencia dudosa, este permiso permite a la aplicación acceder a los archivos de
log. En dicho log puede incluirse las pulsaciones de teclas, por lo que en el caso de
enviar dichos datos al creador de la aplicación, este podría obtener los usuarios y
contraseñas de la víctima.
●
READ_CONTACTS: Permite a la aplicación leer la información de los contactos del
dispositivo en el que esta se instala, una vez obtenidos estos contactos, puede usarlos
para enviar archivos maliciosos a dichos contactos a nombre de la víctima o
simplemente ir recopilando información de esta [18].
●
READ_CALENDAR/WRITE_CALENDAR: Estos dos permisos, dependiendo el caso
pueden ser insignificantes o de gran importancia ya que permiten a la aplicación leer
los datos y crear nuevos eventos en el calendario.
●
READ_HISTORY_BOOKMARKS/BOOKMARKS: Permite a la aplicación leer las
búsquedas producidas en el dispositivo, puede ser un permiso necesario para
aplicaciones que realicen copias de seguridad en el dispositivo pero hay que tener
cuidado ya que el historial de búsqueda se comparte entre todos los dispositivos que
compartan cuenta de google introducida en el navegador.
●
WRITE_SECURE_SETTINGS: Permite a la aplicación tanto leer como escribir los
ajustes del sistema, en el caso de sistemas rooteados hay que tener una precaución
extra porque tendrá más libertad para realizar ajustes sobre el sistema.
●
PROCESS_OUTGOING_CALLS/PHONE_CALLS: El primero permite a la aplicación
monitorear las llamadas salientes y el segundo permite tanto monitorizar cómo grabar y
procesar dichas llamadas. Estos permisos sólo deben administrarse en el caso de que
la aplicación instalada sea VoIP.
●
SEND_SMS: En los inicios de Android esta característica permitía a las aplicaciones
enviar mensajes SMS a números premium obligando a los usuarios realizar grandes
pagos, hoy en día aunque esa función está restringida, aunque hay que tener cuidado
porque hay ciertas compañías que siguen cobrando por la emisión y recibo de SMS.
●
READ_SOCIAL_STREAM: Permite a la aplicación leer la información obtenida de las
feeds de las redes sociales [19].
A continuación se describen los principales tipos de malware encontrados en Android:
3.1.1 Troyanos
Un caballo de troya o troyano es un tipo de software maligno camuflado como software benigno
o legítimo empleado para acceder a los sistemas de los usuarios. Este software es distribuido a
través de algún tipo de ingeniería social engañando a los usuarios para que instalen el mismo.
Una vez se instala y ejecuta es capaz de espiar, robar datos, instalar otro software malicioso,
tomar imágenes y videos de la cámara, bloquear los datos u obtener la ubicación del dispositivo
entre otros. Los diferentes tipos son los siguientes [20][21]:
13
3. ESTADO DE LA TÉCNICA
●
SMS: Es capaz de enviar mensajes desde el dispositivo móvil a teléfonos de pago,
generando de esta manera que el usuario tenga que realizar pagos a esos propietarios.
●
Spy: Son capaces de espiar el uso del dispositivo mediante capturas de pantalla,
obtener aplicaciones en ejecución, obtener pulsaciones en pantalla, obtener los datos
de la cámara u obtener la ubicación del mismo.
●
Mailfinder: Recopila las direcciones de correo electrónico del teléfono móvil.
●
Ransom: Bloquea el acceso al usuario a sus archivos y el acceso a ciertas partes del
sistema operativo, una vez bloqueados estos apartados, el acceso solo será
restablecido una vez sea pagado el rescate solicitado.
Figura 12: Cantidad de ataques de troyanos tipo ransom de 2018 a 2020 [16].
14
●
IM: Roba los datos de inicio de sesión y contraseñas del dispositivo.
●
FakeAV: Simula la actividad de los antivirus y es capaz de extorsionar al usuario
advirtiéndole sobre falsas amenazas y haciéndole pagar por su eliminación.
●
Dropper: Se usa como pasarela para la instalación de otro software malicioso evitando
la detección por el antivirus de dicho software malicioso.
●
Downloader: Descargan e instalan nuevas versiones del malware anteriormente
instalado en el dispositivo.
●
DDoS: Realiza ataques de denegación de servicio a una dirección, estos ataques usan
el dispositivo afectado como elemento de ataque hacia una dirección IP indicada.
●
Banker: Roba los datos bancarios de los distintos sistemas de banca online, de
tarjetas de credito y debito y los sistemas de pago electrónico al usuario que ha
instalado el troyano.
PROYECTO FIN DE GRADO
Figura 13: Cantidad de ataques de troyanos Banker de 2017 a 2020 [16].
●
Rootkit: Oculta objetos o actividades en el sistema y su principal objetivo es dificultar
la detección de programas maliciosos al sistema para ampliar el periodo en el que el
software malicioso pasa inadvertido.
●
Exploit: Hace de pasarela para la instalación de otro software malicioso aprovechando
una vulnerabilidad del sistema operativo o de alguna de las aplicaciones instaladas.
●
Backdoor: Proporciona el control del dispositivo al atacante. A través de este troyano
el atacante es capaz de ejecutar comandos, recibir, enviar y eliminar datos del sistema.
Son usados comúnmente para crear botnets con fines maliciosos.
3.1.2 Keyloggers
Es un software encargado de registrar las pulsaciones en pantalla del usuario y transmitirlas al
atacante. Suele ser un programa daemon, es decir, un software ejecutado en segundo plano e
invisible para el usuario. Su uso común es el de recoger usuarios y contraseñas de las
diferentes aplicaciones, datos bancarios u otro tipo de información bancaria y transmitirla al
atacante[22].
A lo largo de los últimos 10 años las compañías de ciberseguridad han detectado un
incremento de keyloggers, además el 80% de los keyloggers son indetectables para los
antivirus y firewalls [16]. Las aplicaciones keylogger más conocidas son [23]:
●
Hoverwatch: Es uno de los mejores, recoge las pulsaciones de mensajes de texto y
las pulsaciones en búsquedas online. Además es capaz de detectar cuando se cambia
la SIM del teléfono y rastrea las llamadas entrantes y salientes. Es invisible para el
usuario pero tiene que ser instalada accediendo físicamente al dispositivo.
●
FlexiSpy: Recoge información básica sobre el teléfono, rastrea llamadas, pulsaciones,
el atacante es capaz de leer emails, WhatsApp, SMS y obtener la ubicación del
dispositivo. Puede activar el micrófono y escuchar conversaciones, no es detectado por
el dispositivo.
●
mSpy: Lee mensajes, recoge el historial de búsqueda del navegador, obtiene la
ubicación GPS del dispositivo y monitoriza el uso tanto de los distintos navegadores
como de las aplicaciones como WhatsApp, Instagram, etc.
15
3. ESTADO DE LA TÉCNICA
●
HighsterMobile: Captura SMS enviados, monitorea llamadas, recoge las imagenes,
videos y audios de la galería, recoge la ubicación y recoge los mensajes de redes
sociales como WhatsApp o Snapchat.
●
iKeyMonitor: Disponible tanto para iOS como para Android, es capaz de monitorizar
llamadas, ubicaciones GPS, información del portapapeles, realizar capturas de pantalla
de las webs visitadas, recopilar información de SMS, mensajes de voz, imágenes,
videos y pulsaciones en los inicios de sesión.
3.1.3 Ransomware
Es un malware muy común en ordenadores aunque los sistemas operativos móviles no quedan
exentos de estos ataques, a través de estos ataques los ficheros del sistema quedan
encriptados y en ocasiones la pantalla se bloquea, para desbloquear el dispositivo el atacante
pide un rescate y en el caso de no pagarse el dispositivo quedará permanentemente bloqueado
o se borraran todos los archivos.
Aunque el ransomware es conocido desde hace bastante tiempo, como WannaCry, y ha
causado grandes pérdidas a diferentes organizaciones a lo largo del tiempo, en el caso de los
dispositivos móviles todavía es una tecnología bastante joven, el ransomware para dispositivos
móviles comenzó a producirse en el 2014 y es mucho más raro que se produzcan ataques a
estos dispositivos. Esto se puede deber a que el formateo del dispositivo es mucho más
sencillo y conlleva menos pérdidas de información [24].
A día de hoy el sector más afectado es el sector público, aunque tras la oleada de ataques
recibidos hace unos años muchas organizaciones han puesto en marcha medidas para impedir
dichos ataques. Además se han investigado técnicas para desencriptar los dispositivos por los
ransomware más comunes y sus distintas variantes.
En el año 2019 el ransomware GrandCrab, uno de los mayores Ransomware como servicio
(RaaS) anunció su final. El grupo creador de este RaaS obtuvo dos billones de dólares
vendiendo su software personalizado. En 2020 otra compañía de RaaS anunció su retirada tras
atacar a millones de organizaciones tanto públicas como privadas [24].
Un gran ejemplo de ransomware dedicado para Android es “Black Rose Lucy”, detectado por
primera vez en 2018, era un Malware como servicio, en ese momento era una botnet enfocada
a hacer de pasarela para la instalación de otro tipo de malware en los dispositivos Android. En
2020 reapareció con nuevas características aplicadas al ransomware habilitando la pérdida de
control sobre el dispositivo al usuario y permitiendo a los atacantes realizar cambios sobre el
sistema e instalar nuevo malware. Actualmente han sido encontradas más de 80 variantes
distribuidas a través de internet y la Deep Web [24].
Una vez descargado Lucy encripta todos los ficheros del dispositivo infectado y muestra un
mensaje haciéndose pasar por el FBI y acusa al usuario de tener contenido pornográfico en el
dispositivo. El mensaje también informa de que el dispositivo ha sido bloqueado y que los
detalles del usuario han sido subidos a la base de datos del FBI y pide que la víctima realice un
pago de 500 dólares para desbloquear el dispositivo [24].
Para poder realizar dichas acciones la víctima sólo debe dar permisos en la instalación a Lucy.
En la ventana donde se muestran los permisos que se van a dar a la aplicación el usuario dará,
16
PROYECTO FIN DE GRADO
en la mayoría de los casos sin darse cuenta, permiso para que dicha aplicación realice
acciones que realizaría el usuario sin consentimiento de éste, es decir realizará acciones
automáticamente. La aplicación mostrará un mensaje preguntando al usuario si quiere activar
la optimización de vídeo en streaming, una vez esté, pulse “OK”, el usuario habrá dado permiso
al malware para usar los servicios de accesibilidad y Lucy obtendrá privilegios administrativos.
3.1.4 Spyware y Stalkerware
El spyware es uno de los malware más comunes en dispositivos móviles. Permite a los
atacantes monitorizar y grabar información sobre la actividad del dispositivo móvil. Es capaz de
recopilar tanto información del dispositivo en sí como de las aplicaciones instaladas en el
mismo. La gran diferencia entre Stalkeware y Spyware es que el primero es más invasivo e
intrusivo que el segundo.
Dependiendo de si el dispositivo está rooteado el Spyware o el Stalkeware tendrá más
facilidades para activar el micrófono o la cámara de forma remota, realizar capturas de pantalla,
ver la actividad de aplicaciones de terceros como WhatsApp o Instagram, interceptar, redirigir y
grabar llamadas, etc. Aunque hay acciones que puede realizar sin que el dispositivo esté
rooteado, por ejemplo, ver la galería del dispositivo, las páginas web visitadas, los SMS
enviados y recibidos, la ubicación del dispositivo o el historial de llamadas [25].
Uno de los Spyware actuales más controvertidos y conocidos para Android es System
Update/Zimperium, el cual es uno de los malware actuales más sofisticados, una vez se instala
una aplicación infectada descargada desde una fuente externa a Google Play Store, la
aplicación lanza una notificación simulando ser una actualización del sistema operativo. Una
vez se pulsa este desplegable y confirma la actualización el malware obtendrá acceso total al
dispositivo. Este spyware tendrá acceso a los contactos, historial de llamadas, acceso a la
cámara, SMS, mensajes de WhatsApp, ver el historial de navegación, obtener la ubicación, etc
[26].
3.1.5 Adware
Aunque el uso de adware a lo largo de los años ha ido decayendo, el año 2020 esta decaida
sufrió un receso debido a la pandemia.
Figura 14: Cantidad de ataques de Adware de 2018 a 2020 [16]
17
3. ESTADO DE LA TÉCNICA
El funcionamiento del Adware es el siguiente, inicialmente la víctima instala una aplicación
maliciosa, una vez instalada, pueden ocurrir dos cosas, en el caso de que el usuario tenga
suerte, los anuncios se mostrarán bajo la tarea de la aplicación, es decir será fácil identificar
qué aplicación los genera, en el caso contrario, los anuncios se mostrarán a pantalla completa
aunque la aplicación permanezca cerrada en intervalos aleatorios [27].
3.2 Tipos de análisis
En este apartado analizaremos los distintos tipos de análisis tradicionales de aplicaciones
Android. Entre ellos se encuentran el análisis estático, el dinámico y el híbrido. Estos tres
análisis se diferencian en que el primero busca patrones dentro de las aplicaciones sin que
estas sean ejecutadas, es decir, decodifica la aplicación y buscan características distintivas
tanto dentro del código como en la estructura de los archivos. El segundo, el análisis dinámico,
ejecuta la aplicación y busca patrones de comportamiento dentro de la misma, ya sea
visualmente, por el tráfico de paquetes de red, por el consumo de recursos u otro tipo de
característica. Finalmente el análisis híbrido, realiza un equilibrio entre las dos, busca
características a través del análisis dinámico y genera un conjunto de datos con el que
posteriormente realiza un análisis mediante aprendizaje automático [28].
3.2.1 Estático
Esta técnica trata de analizar aplicaciones en busca de indicios de maliciosidad sin ejecutar la
aplicación en un dispositivo o emulador. Entre las ventajas de este método está que el costo
computacional es bajo, es decir consume pocos recursos, otra ventaja es que el tiempo
necesario para el análisis es menor que el necesario para el análisis dinámico. Como
inconveniente se encuentra la ofuscación del código, haciendo que la búsqueda de patrones
sea compleja. Dentro del análisis estático hay dos técnicas principales, la primera es la
detección del mal uso y la segunda es la detección de anomalías [29].
La primera técnica, la detección del mal uso, también conocida como detección basada en
firmas, trata de buscar coincidencias en la secuencia de instrucciones de la aplicación o en las
políticas de esta.
La segunda, la detección de anomalías se basa en el uso de algoritmos de aprendizaje
automático para detectar los comportamientos maliciosos de una aplicación. Las características
extraídas de la aplicación se utilizarán para entrenar un algoritmo de aprendizaje automático y
predecir nuevo malware o malware desconocido.
3.2.2 Dinámico
El análisis dinámico se basa en evaluar el malware mediante la ejecución de una aplicación en
tiempo real mediante una máquina virtual o un dispositivo físico. Sus principales ventajas son
que detecta la carga de código dinámico y puede registrar el comportamiento de la aplicación
en tiempo de ejecución. No determina la cantidad de código ejecutado a lo largo de la
ejecución, esto conlleva que existe la posibilidad de que el código malicioso no sea ejecutado
durante la ejecución. Existe malware que es capaz de detectar cuando la aplicación se está
ejecutando en una máquina virtual y reacciona ante ello no ejecutando código malicioso alguno.
Otro de sus grandes problemas es que es más difícil de implementar debido a la carga
computacional y que conlleva una mayor cantidad de tiempo a dedicar [29].
18
PROYECTO FIN DE GRADO
3.2.3 Híbrido
Es una combinación de análisis estático y dinámico. Integra los datos extraídos a lo largo del
análisis dinámico en tiempo de ejecución con los algoritmos de análisis estático para detectar el
comportamiento malicioso o la funcionalidad sospechosa.
Se usan las características obtenidas a lo largo del análisis dinámico, es decir, la información
recopilada a lo largo de la ejecución de la aplicación y se combina con las características
estáticas. Esta combinación puede conllevar beneficios en cuanto a la precisión del análisis
[29].
3.3 Explicación de técnicas IA
3.3.1 Modelos Lineales
Los siguientes son un conjunto de métodos destinados a la regresión en los que el valor
objetivo está previsto que sea una combinación lineal de funciones. En términos matemáticos,
si “y” es el valor predecido [30]:
Figura 15: Fórmula modelos lineales [30].
Para realizar la clasificación mediante modelos lineales generalizados, haremos uso de la
regresión logística.
3.3.1.1 Ridge Classifier
La regresión de Ridge tiene una variante de clasificación denominada Ridge Classifier o
Clasificador de Crestas. Este clasificador comienza convirtiendo objetivos binarios a {-1, 1} y a
continuación trata el problema como una tarea de regresión, optimizando el objetivo de la
misma forma que se ha mencionado anteriormente. La clase predicha corresponde al signo de
la predicción de la regresión. Para la clasificación de multiclase, el problema es tratado como
regresión de salida múltiple y la clase predicha corresponde a la salida con el valor más alto
[31].
Podría ser cuestionable la utilización de la pérdida de Least Squares (Mínimos Cuadrados)
penalizados para adaptarse a un modelo de clasificación en vez de a un modelo logístico más
tradicional o pérdidas de bisagra (hinge losses). De todas formas, en lo que se refiere a la
práctica, todos los modelos nombrados pueden conducir a similares puntuaciones de validación
cruzada en términos de precisión. Entre tanto, la pérdida de mínimos cuadrados penalizada
utilizada por el Ridge Classifier o Clasificador de Crestas, permite una elección muy diferente
de solucionadores numéricos con perfiles de rendimiento computacional distintos.
Puede ser significativamente más rápido que el Logistic Regression o Regresión Logística con
un alto número de clases, ya que es capaz de calcular la matriz de proyección sólo una vez.
19
3. ESTADO DE LA TÉCNICA
Los parámetros de regularización son los siguientes: RidgeCV implementa la regresión de
cresta con validación cruzada integrada del parámetro alfa. El objeto funciona de la misma
manera que GridSearchCV, excepto en que su valor predeterminado es Leave-One-Out
Cross-Validation.
Si se especifica el valor del atributo cv, se activará el uso de la validación cruzada con
GridSearchCV, por ejemplo cv=10 para la validación cruzada de 10 veces, en lugar de
Leave-One-Out Cross-Validation [32].
3.3.1.2 Logistic Regression
La regresión logística, a pesar de su nombre, en un modelo lineal para la clasificación en lugar
de la regresión. La regresión logística también se conoce como, clasificación de máxima
entropía (MaxEnt) o clasificador logarítmico-lineal. En este modelo, las probabilidades que
describen los posibles resultados de un solo ensayo se modelan mediante una función
logística.
Hay que tener en cuenta que la regularización se aplica de forma predeterminada, lo que es
común en el aprendizaje automático, pero no en las estadísticas. Otra ventaja de la
regularización es que mejora la estabilidad numérica. Ninguna regularización equivale a
establecer C en un valor muy alto [33].
En el caso multiclase, el algoritmo de entrenamiento utiliza el esquema de one-vs-rest (OvR) o
“uno contra otro” si la opción “multi_class” se establece en “ovr”, y utiliza la pérdida de entropía
cruzada si la opción de “multi_class” se establece como “multinominal”. Actualmente la opción
“multinominal” es solo compatible con los solucionadores “lbfgs”, “sag”, “saga” y “newton-cg”.
Este tipo de clase implementa la regresión logística regularizada utilizando la biblioteca
“liblinear” y los solucionadores “lbfgs”, “sag”, “saga” y “newton-cg”.
Los solucionadores “newton-cg”, “sag” y “lbfgs” solo admiten la regularización ℓ2 con formación
primaria, o ninguna regularización. El solucionador “liblinear” soporta tanto la regularización ℓ1
como la ℓ2, con una formulación dual solo para la penalización ℓ2. La regularización de
Elastic-Net solo es compatible con el solucionador de “saga” [34].
Como problema de optimización, la regresión logística penalizada de clase binaria ℓ2 minimiza
la siguiente función de costo:
Figura 16: Función de costo 1 [34].
Similarmente, ℓ1 la regresión logística regularizada resuelve el siguiente problema de
optimización:
Figura 17: Problema de optimización [34].
20
PROYECTO FIN DE GRADO
La regularización Elastic-Net es una combinación de ℓ1 y ℓ2 y minimiza la siguiente función de
costo:
Figura 18: Función de costo 2 [34].
Donde ρ controla la fuerza de regularización ℓ1 contra la regularización ℓ2 (corresponde al
parámetro l1_ratio).
En lo que se refiere a los solucionadores, el solucionador “sag” utiliza el descenso de gradiente
medio estocástico (Stochastic Average Gradient). Es más rápido que otros solucionadores para
conjuntos de datos grandes, cuando tanto el número de muestras, como el número de
entidades son grandes.
Por otro lado, el solucionador “saga” es una variante del “sag” que también admite la
non-smooth (no suave) penalización=”l1”. Por lo tanto, este es el solucionador de elección para
la regresión logística multinomial dispersa. También es el único solucionador que admite la
penalización = "Elastic-Net".
Por último, el "lbfgs" es un algoritmo de optimización que se aproxima al algoritmo de
Broyden-Fletcher-Goldfarb-Shanno, que pertenece a los métodos cuasi-Newton. El
solucionador "lbfgs" se recomienda para el uso de conjuntos de datos pequeños, pero para
conjuntos de datos más grandes su rendimiento se ve afectado [34].
3.3.1.3 SGD Classifier
La clase SGD Classifier implementa una rutina de aprendizaje de descenso de gradiente
estocástico simple que admite diferentes funciones de pérdida y penalizaciones para la
clasificación. El gradiente de la pérdida se estima cada muestra a la vez y el modelo se
actualiza a lo largo del camino con un programa de disminución de la fuerza (también conocido
como tasa de aprendizaje). SGD permite el aprendizaje de minibatch (en línea / fuera del
núcleo) a través del método de partial_fit. Para obtener los mejores resultados utilizando el
programa de tasa de aprendizaje predeterminado, los datos deben tener una media cero y una
varianza unitaria [35].
Esta implementación funciona con datos representados como matrices densas o dispersas de
valores de punto flotante para las entidades. El modelo que se ajusta se puede controlar con el
parámetro de pérdida; de forma predeterminada, se ajusta a una máquina de vectores de
soporte lineal (SVM).
El regularizador es una penalización añadida a la función de pérdida que reduce los parámetros
del modelo hacia el vector cero utilizando la norma euclidiana al cuadrado ℓ2 o la norma
absoluta ℓ1 o una combinación de ambos (Elastic-Net). Si la actualización del parámetro cruza
21
3. ESTADO DE LA TÉCNICA
el valor 0.0 debido al regularizador, la actualización se trunca a 0.0 para permitir el aprendizaje
de modelos dispersos y lograr la selección de características en línea.
El SGD Classifier o Clasificador SGD admite la clasificación multiclase mediante la
combinación de varios clasificadores binarios en un esquema “one vs all” (OVA) o “uno contra
todos”. Para cada una de las K clases, entrene un clasificador binario que discrimina entre eso
y todas las demás K−1 clases [36].
3.3.2 Nearest Neighbors
Los vecinos más cercanos no supervisados son la base de muchos otros métodos de
aprendizaje, en particular el aprendizaje múltiple y el clustering espectral. El aprendizaje
supervisado basado en vecinos viene en dos grupos: clasificación para datos con etiquetas
discretas y regresión para datos con etiquetas continuas [37].
El principio detrás de los métodos de Nearest Neighbors o vecino más cercano es encontrar un
número predefinido de muestras de entrenamiento más cercanas en distancia al nuevo punto y
predecir la etiqueta a partir de estos.
El número de muestras puede ser una constante definida por el usuario, o variar en función de
la densidad local de puntos (aprendizaje de vecino basado en radio). La distancia puede, en
general, ser cualquier medida métrica (la distancia euclidiana estándar es la opción más
común). Los métodos basados en vecinos se conocen como métodos de aprendizaje
automático no generalizados, ya que simplemente "recuerdan" todos sus datos de
entrenamiento [37].
A pesar de su simplicidad, Nearest Neighbors o vecinos más cercanos ha sido exitoso en un
gran número de problemas de regresión y clasificación, incluyendo los dígitos escritos a mano y
las imágenes de satélite. Siendo un método no-paramétrico a menudo tiene éxito en
situaciones de clasificación donde el límite de decisión es muy irregular.
En la clasificación de Nearest Neighbors o vecinos más cercanos, se pueden diferenciar dos
técnicas:
Por un lado, el Radius Neighbors Classifier que implementa el aprendizaje basado en el
número de vecinos dentro de un radio “r” fijo de cada punto de entrenamiento, donde “r” es un
valor de punto flotante especificado por el usuario. En los casos en los que los datos no se
muestran uniformemente, la clasificación de vecinos basada en radios en Radius Neighbors
Classifier puede ser la mejor opción.
Por otro lado nos encontramos con KNeighbors Classifier, esta es la técnica más utilizada y
está pensada para datos uniformes. Esta técnica será analizada en el apartado contiguo.
3.3.2.1 KNeighbors Classifier
KNeighbors Classifier es la técnica más común e implementa el aprendizaje basado en los
vecinos más cercanos de cada punto de consulta, donde “k” es un valor entero especificado por
el usuario. La elección óptima del valor “k” es altamente dependiente de los datos: en general,
un mayor “k” suprime los efectos del ruido, pero hace que los límites de clasificación sean más
regulares [38].
22
PROYECTO FIN DE GRADO
La clasificación básica de vecinos más cercanos utiliza ponderaciones uniformes: es decir, el
valor asignado a un punto de consulta se calcula a partir de un voto por mayoría simple de los
vecinos más cercanos. En algunas circunstancias, es mejor ponderar a los vecinos de tal
manera que los vecinos más cercanos contribuyan más al ajuste. Esto se puede lograr a través
de la palabra clave weights. El valor predeterminado, weights = “uniform”, asigna pesos
uniformes a cada vecino. Weights = “distance” asigna pesos proporcionales a la inversa de la
distancia desde el punto de consulta. Alternativamente, se puede proporcionar una función
definida por el usuario de la distancia para calcular los pesos.
3.3.3 Naive Bayes
Los métodos Naive Bayes son un conjunto de algoritmos revisados de aprendizaje basados en
aplicar el teorema de Bayes con la suposición ingenua de la independencia condicional entre
cada par de entidades dado el valor de la variable de clase. El teorema de Bayes establece una
relación, dada la variable de clase y el vector de entidad dependiente a través de diversas
fórmulas.
A pesar de sus suposiciones aparentemente demasiado simplificadas, los clasificadores Bayes
ingenuos han funcionado bastante bien en muchas situaciones del mundo real, famosamente la
clasificación de documentos y el filtrado de spam. Requieren una pequeña cantidad de datos
de entrenamiento para estimar los parámetros necesarios.
Los algoritmos de aprendizaje y clasificadores Naive Bayes pueden ser extremadamente
rápidos en comparación con métodos más sofisticados [39].
3.3.3.1 Gaussian Naive Bayes
El GaussianNB implementa el algoritmo Bayes ingenuo Gaussiano para la clasificación. Se
supone que la probabilidad de las entidades es Gaussiana:
Figura 19: Fórmula Gaussian Naive Bayes [39].
Los parámetros σy y μy se estiman utilizando la máxima verosimilitud.
3.3.4 Decision Trees
Los árboles de decisión o Decision Trees (DTs) son un método de aprendizaje supervisado no
paramétrico utilizado para la clasificación y la regresión. El objetivo es crear un modelo que
prediga el valor de una variable de destino mediante el aprendizaje de reglas de decisión
simples inferidas de las características de datos. Un árbol se puede ver como una aproximación
constante por partes.
Son simples para entender e interpretar, ya que se pueden visualizar, además, requieren una
pequeña base de datos y tienen la capacidad de manejar problemas de salida múltiple.
23
3. ESTADO DE LA TÉCNICA
Por el contrario, los árboles de decisión pueden ser inestables porque pequeñas variaciones en
los datos pueden dar lugar a la generación de un árbol completamente diferente y los
algoritmos de aprendizaje de árboles de decisión crean árboles sesgados si algunas clases
dominan. Por lo tanto, se recomienda equilibrar el conjunto de datos antes de ajustarlo al árbol
de decisión [40].
3.3.4.1 Decision Tree Classifier
Decision Tree Classifier es una clase capaz de realizar la clasificación multiclase en un
conjunto de datos.
Al igual que con otros clasificadores, Decision Tree Classifier toma como entrada dos matrices:
una matriz X, dispersa o densa, de forma (n_samples, n_features) que contiene las muestras
de entrenamiento, y una matriz Y de valores enteros, de forma (n_samples,), que contiene las
etiquetas de clase para las muestras de entrenamiento. Después de ser ajustado, el modelo se
puede utilizar para predecir la clase de muestras.
En caso de que haya varias clases con la misma y más alta probabilidad, el clasificador
predecirá la clase con el índice más bajo entre esas clases. Como alternativa a la salida de una
clase específica, se puede predecir la probabilidad de cada clase, que es la fracción de
muestras de entrenamiento de la clase en una hoja.
Para terminar, Decision Tree Classifier es capaz de clasificación binaria (donde las etiquetas
son [-1, 1]) y multiclase (donde las etiquetas son [0, ..., K-1]) [41].
3.3.5 Ensemble Methods
El objetivo de los conjuntos de métodos es combinar las predicciones de varios estimadores
base construidos con un algoritmo de aprendizaje dado con el fin de mejorar la generalización
sobre un solo estimador. Se suelen distinguir dos tipos de conjuntos de métodos:
Por una parte, los métodos de promediación (averaging methods) que tienen como objetivo
construir varios estimadores de forma independiente para luego promediar sus predicciones.
En promedio, el estimador combinado suele ser mejor que cualquiera de los estimadores de
base única porque su varianza se reduce.
Por el contrario, en los métodos de impulso (boosting methods), los estimadores de base se
construyen secuencialmente y se intenta reducir el sesgo del estimador combinado. La
motivación es combinar varios modelos débiles para producir un conjunto poderoso [42].
3.3.5.1 AdaBoost Classifier
Un clasificador AdaBoost es un meta-clasificador que comienza ajustando un clasificador en el
conjunto de datos original y, a continuación, ajusta copias adicionales del clasificador en el
mismo conjunto de datos, pero donde los pesos de las instancias clasificadas incorrectamente
se ajustan de modo que los clasificadores posteriores se centran más en casos difíciles [43].
24
PROYECTO FIN DE GRADO
3.3.5.2 Gradient Boosting Classifier
El Clasificador del Árbol de Gradiente admite la clasificación binaria y multiclase.
Construye un modelo aditivo de una manera avanzada en cuanto a la etapa; permite la
optimización de funciones de pérdida diferenciables arbitrarias. En cada etapa n_classes, los
árboles de regresión se ajustan al gradiente negativo de la función de pérdida de desviación
binomial o multinomial. La clasificación binaria es un caso especial en el que solo se induce un
único árbol de regresión.
3.3.6 Multi-Layer Perceptron
Multi-layer Perceptron (MLP) es un algoritmo de aprendizaje supervisado que aprende de una
función f(⋅):Rm→Ro mediante el entrenamiento en un conjunto de datos, donde m es el
número de dimensiones para la entrada y o es el número de dimensiones para la salida. Dado
un conjunto de características X=x1,x2,...,xm y un objetivo Y, puede aprender un aproximador
de función no lineal para clasificación o regresión. Es diferente de la regresión logística, en que
entre la capa de entrada y la de salida, puede haber una o más capas no lineales, llamadas
capas ocultas [44].
3.3.6.1 MLP Classifier
La clase MLP Classifier implementa un algoritmo Perceptron de varias capas (MLP) que
entrena mediante Backpropagation [44].
MLP entrena en dos matrices: matriz X de tamaño (n_samples, n_features), que contiene las
muestras de entrenamiento representadas como vectores de entidad de punto flotante, y la
matriz y de tamaño (n_samples,), que contiene los valores de destino (etiquetas de clase) para
las muestras de entrenamiento.
Después del entrenamiento, el modelo puede predecir etiquetas para nuevas muestras. MLP
puede ajustar un modelo no lineal a los datos de entrenamiento. clf.coefs contiene las matrices
de peso que constituyen los parámetros del modelo.
Actualmente, MLP Classifier sólo admite la función de pérdida de entropía cruzada, que permite
las estimaciones de probabilidad mediante la ejecución del método de predict_proba. Más
precisamente, MLP Classifier entrena usando alguna forma de descenso de gradiente y los
gradientes se calculan usando Backpropagation. Para la clasificación, minimiza la función de
pérdida de entropía cruzada, dando un vector de estimaciones de probabilidad P(y/x) por
muestra x.
MLP Classifier admite la clasificación multiclase aplicando Softmax como la función de salida.
Además, el modelo admite la clasificación de varias etiquetas en la que una muestra puede
pertenecer a más de una clase. Para cada clase, la salida sin procesar pasa a través de la
función logística. Los valores mayores o iguales a 0,5 se redondean a 1, de lo contrario a 0.
Para una salida predicha de una muestra, los índices donde el valor es 1 representan las
clases asignadas de esa muestra [44].
25
3. ESTADO DE LA TÉCNICA
26
PROYECTO FIN DE GRADO
Capítulo 4
Metodología Desarrollada
4.1 CRISP-DM Based
Para este Proyecto Fin de Grado se propone un esquema basado en CRISP-DM (Cross
Industry Standard Process for Data Mining), este modelo es un modelo de estándar abierto
usado para describir los enfoques comunes usados en minería de datos. CRISP-DM está
dividido en seis fases principales, dichas fases se pueden permutar [45].
Figura 20: Diagrama CRISP-DM [46]
Este PFG, utiliza como base dicho esquema CRISP-DM, pero con los pasos propios del
análisis de una aplicación Android, es decir, en vez de entender los datos se entienden las
características, en vez de modelar, se buscan nuevas características, se analizan y evalúan los
datos extraídos y se vuelve a comenzar.
Los pasos seguidos a lo largo de esta metodología son los siguientes:
Figura 21: Diagrama CRISP-DM Based
27
4. METODOLOGÍA DESARROLLADA
●
Búsqueda de nuevas muestras: Se buscan aplicaciones Android, tanto software
benigno, como malware. Este software será el software a analizar para verificar la
efectividad de las características extraídas.
●
Búsqueda de nuevas características: Se analizan las distintas muestras en busca de
características identificativas para su posterior análisis y evaluación.
●
Extracción: Cuando se haya encontrado una nueva característica o se haya realizado
una combinación de distintas características, dichas características serán extraídas a
un Dataset con formato “.csv”
●
Análisis: El Dataset extraído será aplicado a diferentes algoritmos de clasificación y
posteriormente se analizará la efectividad de dichos clasificadores con las
características extraídas.
●
Evaluación de resultados: Los resultados obtenidos a partir del análisis serán
evaluados y se verificará si son válidos para combinarlos con las características
escogidas en sucesiones de fases anteriores.
●
Combinación de características: En el caso de que los resultados sean válidos se
combinarán con otros resultados positivos para obtener una cantidad de variables lo
más completa posible, creando así un análisis estático efectivo.
4.2 Conjunción de características
Una de las principales innovaciones de este PFG ante papers anteriores es la búsqueda de
nuevas características interesantes a analizar para una búsqueda más efectiva de malware en
software Android. Para ello, como se ha mencionado anteriormente se propone un análisis
basado en CRISP-DM. Lo que se hace a través de esta metodología es la repetición del mismo
proceso en busca de las mejores características a analizar en una aplicación Android.
Una vez se realice el análisis de las diferentes características de forma individual, se realizará
un análisis de la combinación de las diferentes características. Una vez se hayan combinado
dichas características se realizará otro análisis para verificar que la combinación de dichas
características aporta mejoría.
Cuando se han encontrado combinaciones de características se volverán a buscar nuevas
características a analizar y si son validas serán añadidas al conjunto y así sucesivamente.
4.3 Características extraídas
En este apartado se analizarán las características extraídas de la aplicación, para ello primero
se realizará un análisis de los contenidos de las aplicaciones Android y seguidamente se
analizarán las diferentes características, tanto del AndroidManifest.xml, como de la aplicación
en sí por separado.
Para empezar es necesario saber que es un fichero “.apk”, un fichero “.apk” (Android
Application Package) es un paquete usado en el sistema operativo Android. Es una variante del
formato “.jar” de Java [47], es usado para empaquetar y distribuir software en Android. El uso
28
PROYECTO FIN DE GRADO
es similar a otros paquetes como “.appx” en Windows o .deb en sistemas basados en Debian.
Para crear una aplicación Android se deberá compilar un programa en un archivo “.apk” [48], el
cual contendrá:
●
●
Directorio META-INF: Es el contenedor de los archivos reconocidos, es interpretado
por Java para configurar la aplicación, sus extensiones, clases y servicios [49][50]:
○
MANIFEST.MF: Archivo manifest, contiene los metadatos de la aplicación. Es
decir describe el nombre, número de versión, licencia y los archivos que
forman parte de la aplicación [51].
○
CERT.RSA: Certificado de la aplicación con el que se firma la aplicación.
Contiene el nombre de la organización o desarrollador que generó el APK y la
clave pública utilizada para firmar los contenidos.
○
CERT.SF: Contiene un listado de todos los archivos junto con el resumen
SHA-1 de los mismos.
Directorio lib: Contiene el código compilado específico de la capa de software de un
procesador:
○
armeabi: Código compilado para los procesadores basados en ARM.
○
armeabi-v7a: Código compilado para los procesadores ARMv7 y posteriores.
○
arm64-v8a: Código compilado para los procesadores ARMv8, arm64 y
posteriores.
○
x86: Código compilado para procesadores x86.
○
x86_64: Código compilado para procesadores x86_64.
○
Mips: Código compilado para procesadores MIPS.
●
Directorio res: Contiene los recursos no compilados en resources.arsc, es decir los
archivos adicionales y el contenido estático usado por el código como bitmaps,
definición de estructuras, ajustes de la UI, instrucciones de animación etc [52].
●
Directorio assets: Contiene los recursos de la aplicación. Es decir contiene ficheros
como archivos de texto, XML, HTML, fuentes, audios, imágenes, videos o audios
usados por la aplicación [53].
●
AndroidManifest.xml: Archivo de manifiesto adicional de Android.
●
classes.dex: Clases compiladas en el formato .dex es legible tanto por una máquina
virtual Dalvik como por Android Runtime [54][55].
●
resources.arsc: Contiene los recursos precompilados [56].
29
4. METODOLOGÍA DESARROLLADA
Un fichero “.apk” es un archivo “.zip” que contiene código java ensamblado. Si dicho archivo se
extrae usando una herramienta que descomprima “.zip” se generará una carpeta con los assets
de la aplicación, una carpeta con los metadatos de la misma, otra llamada res con los
elementos de diseño de la misma, unos archivos .dex y .arsc y un archivo AndroidManifest.xml.
Hay que tener en cuenta que los archivos contenidos, en el caso de ser extraídos por una
herramienta no específica para aplicaciones Android “.apk”, serán difícilmente legibles o en
ciertos casos completamente ilegibles, por esa razón se usan herramientas como ApkTool.
4.3.1 AndroidManifest
4.3.1.1 Paquete
El paquete se usa como id para las diferentes llamadas a la aplicación, por ejemplo cuando se
compila la aplicación las herramientas de compilación Android usan el paquete como espacio
de nombres para la clase R.java [57]. Por ejemplo:
com.aplicacion.R
Figura 22: Formato paquete [51].
También es usado para resolver los nombres de clase declarados en el AndroidManifest.xml. El
nombre del package debe coincidir con el nombre del paquete básico del proyecto, para que a
la hora de importar los subpaquetes de la misma se le añada el sufijo al nombre del paquete.
Una vez se compila y se genera el fichero .apk, el nombre del paquete será el ID de la
aplicación, por lo que el valor del atributo Package debe ser único para garantizar que la
aplicación pueda ser identificada por el dispositivo Android y por Google Play. Ejemplo del
campo paquete en AndroidManifest.xml:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.aplicacion"
android:versionCode="1"
android:versionName="1.0" >
...
</manifest>
Figura 23: Paquete en AndroidManifest [51].
4.3.1.2 Activity
Una Activity es la representación de la realización de una acción por el usuario, casi todas las
actividades interaccionan con los usuarios. Aunque dichas actividades normalmente son
usadas como ventanas de pantalla completa, también pueden ser usadas para otros propósitos
como ventanas flotantes, por ejemplo para el uso en multiventana de Android. El campo Activity
dentro del AndroidManifest declara una actividad la cual implementa una parte de la UI de la
aplicación, toda actividad debe estar representada por el identificador en el manifiesto. Las
actividades que no estén nombradas en dicho manifiesto no serán visibles para el sistema por
lo que nunca serán ejecutadas [58].
30
PROYECTO FIN DE GRADO
Este campo puede tener diferentes atributos como "android:banner", que proporciona un
banner extendido para el componente asociado o "android:configChanges" que muestra una
lista de todos los cambios que realizará dicha actividad a lo largo de la ejecución. Estas
variables pueden contener a su vez diferentes parámetros, los cuales pueden ser tanto las
definiciones mostradas como ="string" o ="integer" o bien pueden ser los parámetros de las
diferentes variables como =["true" | "false"], =[ "hdr" | "wideColorGamut"], etc.
<activity android:allowEmbedded=["true" | "false"]
android:allowTaskReparenting=["true" | "false"]
android:alwaysRetainTaskState=["true" | "false"]
android:autoRemoveFromRecents=["true" | "false"]
android:banner="drawable resource"
android:clearTaskOnLaunch=["true" | "false"]
android:colorMode=[ "hdr" | "wideColorGamut"]
android:configChanges=["mcc", "mnc", "locale",
"touchscreen", "keyboard", "keyboardHidden",
"navigation", "screenLayout", "fontScale",
"uiMode", "orientation", "density",
"screenSize", "smallestScreenSize"]>
. . .
</activity>
Figura 24: Activity en AndroidManifest [59].
4.3.1.3 Service
Un servicio es un componente que pretende mantener una operación de ejecución larga sin
interactuar con el usuario, uno de sus posibles usos es para aportar funcionalidad a otras
aplicaciones. Cada servicio debe tener un correspondiente en el AndroidManifest.xml para que
pueda ser usado por el sistema, en caso contrario y al igual que las actividades, los servicios
que no se muestren en el AndroidManifest.xml nunca serán ejecutados ni detectados por el
sistema.
Los servicios, al igual que otros objetos de aplicación, son ejecutados en el hilo principal del
proceso host, lo que conlleva que si el servicio va a realizar operaciones de alta carga debe
usar un hilo propio en el cual realice dicha operación. A diferencia de las actividades los
servicios no requieren interfaz de usuario [60].
En el archivo AndroidManifest.xml los services deben ser declarados en el AndroidManifest de
la siguiente manera:
<service android:atributo="tipo"
android:atributo=["opción" | "opción" | . . .]
. . . >
. . .
</service>
Figura 25: Formato service [61].
31
4. METODOLOGÍA DESARROLLADA
Ejemplo de código en AndroidManifest.xml:
<service android:description="string resource"
android:directBootAware=["true" | "false"]
android:enabled=["true" | "false"]
android:exported=["true" | "false"]
android:foregroundServiceType=["camera" | "connectedDevice" |
"dataSync" | "location" |
"mediaPlayback" |
"mediaProjection" | "microphone" |
"phoneCall"]
android:icon="drawable resource"
android:isolatedProcess=["true" | "false"]>
. . .
</service>
Figura 26: Service en AndroidManifest [61].
4.3.1.4 Content providers
Los "Content providers" son una de las principales estructuras usadas en las aplicaciones
Android. Estos bloques encapsulan la información y la proveen a las diferentes aplicaciones a
través del ContentResolver. El content provider solo es necesario si tienes que compartir
información entre múltiples aplicaciones. Un ejemplo serían los contactos, la información de la
aplicación Contactos es compartida en múltiples aplicaciones como WhatsApp o Telegram.
Cuando una petición se realiza mediante el ContentResolver el sistema inspeccionará el
privilegio de la URI proporcionada y transmitirá la petición al "Content provider" con los
privilegios mencionados. El content provider es capáz de interpretar el resto de la URI a su
elección.
En el AndroidManifest.xml se declarará con la etiqueta “Provider” y al igual que con los
Services y las Activities todo ContentProvider debe manifestarse en el AndroidManifest.xml. En
el AndroidManifest de una aplicación sólo deben mostrarse los content providers propios de la
aplicación, los que se usen en la aplicación pero sean de otra aplicación no deberán
mencionarse [62][63].
El Sistema guardará las referencias de los "Content providers" de acuerdo con el string de
privilegios, siendo este parte de la URI del proveedor. Por ejemplo si deseamos acceder a un
proveedor de contenido que almacena información de contactos, llamaremos a el metodo
ContentResolver.query(), este método recogerá una URI que identifica al proveedor como por
ejemplo:
content://com.proyecto.contactos/rn
Figura 27: Formato Content Providers [62]
El content es un esquema que identifica la URI como una URI de contenido que llama al
proveedor de contenido. La autoridad "com.proyecto.contactos" identifica al propio proveedor.
El sistema Android buscará a la autoridad en su propia lista de autoridades y el substring
32
PROYECTO FIN DE GRADO
contactos/rn indica la ruta que usará el "Content provider" para recoger la información. En el
elemento sólo debe mostrarse la autoridad, no los paths.
Los content providers seguirán el mismo formato que los anteriores métodos.
<provider android:authorities="list"
android:directBootAware=["true" | "false"]
android:enabled=["true" | "false"]
android:exported=["true" | "false"]
android:grantUriPermissions=["true" | "false"]
android:icon="drawable resource"
android:initOrder="integer"
android:label="string resource"
android:multiprocess=["true" | "false"]
android:name="string"
android:permission="string"
android:process="string"
android:readPermission="string"
android:syncable=["true" | "false"]
android:writePermission="string" >
. . .
</provider>
Figura 28: Content Providers en AndroidManifest
4.3.1.5 Broadcast receivers
Las aplicaciones pueden enviar o recibir mensajes de difusión tanto del propio sistema Android
como de otras aplicaciones Android, estos mensajes se enviarán cuando suceda un evento de
interés. Por ejemplo cuando el dispositivo se apaga o reinicia, cuando se pone en modo avión,
cuando comienza a cargarse, etc. También estos mensajes de difusión pueden ser transmitidos
por las diferentes aplicaciones para notificar sucesos de interés a otras aplicaciones. Una vez
suceda algún evento de interés el sistema enviará un mensaje de difusión a todas las
aplicaciones que estén registradas para recibir dicho tipo de mensaje [64][65].
El uso incorrecto de este módulo puede llegar a acarrear la ralentización del sistema o el uso
inadecuado de la información del mismo.
Estos mensajes de difusión pueden ser recibidos de dos formas, la primera es a través de
receptores declarados en el archivo AndroidManifest.xml, la segunda es a través de los
receptores con contexto registrado. En nuestro caso solamente analizaremos los que son
registrados a través del AndroidManifest.
Cuando un mensaje de difusión que es declarado en el AndroidManifest hace que una vez
suceda un evento de interés se pueda ejecutar la aplicación a no ser que esta ya esté en
ejecución.
33
4. METODOLOGÍA DESARROLLADA
Los Broadcast Receiver son declarados en el manifest de la siguiente manera:
<receiver android:name=".MyBroadcastReceiver" android:exported="true">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED"/>
<action android:name="android.intent.action.INPUT_METHOD_CHANGED"
/>
</intent-filter>
</receiver>
Figura 29: Broadcast Receiver en AndroidManifest [66]
4.3.1.6 Intent Filter Actions e Intent Filter Categories
En este apartado comenzaremos definiendo los Intent Filters, seguidamente pasaremos a los
Intent Filter Actions y finalizaremos con los Intent Filter Categories.
Un Intent Filter especifica los tipos de intenciones a los que una actividad, servicio o broadcast
puede responder, es decir, a qué broadcast puede responder y qué actividades y servicios
puede realizar la aplicación [67].
Su formato es el siguiente:
<intent-filter android:icon="drawable resource"
android:label="string resource"
android:priority="integer" >
. . .
</intent-filter>
Figura 30: Intent filter en AndroidManifest [67]
El elemento “<action />” añade una acción al "Intent filter", este puede contener una o más
acciones, en el caso de que un <intent-filter> esté vacío, no aceptará ningún "Intent". La acción
dentro del intent filter indica la acción que realizará el Intent, el valor contenido debe ser el del
string de la acción, no el de la clase [68][69].
El atributo “<category />” indica la categoría a la que pertenece el elemento al que se le asigna
el Intent.
Este elemento solo tiene un atributo, el nombre. Este atributo se llama de la siguiente forma:
<category android:name="android.intent.category.DEFAULT"/>
Figura 31: Categoría en AndroidManifest [67]
4.3.1.7 Permisos
Los permisos protegen a los usuarios restringiendo el acceso a las aplicaciones tanto sobre la
información como sobre las acciones. Los tipos de permisos están divididos en cinco
categorías [70]:
34
PROYECTO FIN DE GRADO
●
Permisos de tiempo de instalación: Permiten a la aplicación un acceso limitado a la
información restringida, además de ciertas acciones que afecten mínimamente al
sistema y sus diferentes aplicaciones. Los permisos declarados como permisos de
tiempo de instalación son automáticamente entregados a la aplicación. Dentro de estos
permisos hay diferentes categorías, pero las principales son los permisos normales y
los permisos de firmado.
●
Permisos normales: Estos permisos posibilitan el acceso a las acciones e información
que se encuentran fuera de la propia aplicación. Estos permisos representan un riesgo
muy bajo para la privacidad de los usuarios.
●
Permisos de firmado: Si una aplicación declara unos permisos de firmado que otra
aplicación ha definido previamente y ambas están firmadas bajo el mismo certificado el
sistema entrega estos permisos a la aplicación en tiempo de instalación.
●
Permisos de ejecución: Estos permisos son llamados también permisos peligrosos y
dan un acceso adicional a la información restringida y habilitan la posibilidad de que la
aplicación realice acciones que afecten al sistema y otras aplicaciones. Para que la
aplicación pueda hacer uso de estos permisos aparecerá un mensaje en pantalla
solicitando los mismos. La mayoría de estos permisos dan acceso a información
privada del usuario a la aplicación.
●
Permisos especiales: Estos permisos corresponden a operaciones de la aplicación en
particular. Solo pueden definirse por el fabricante de la plataforma o del dispositivo y
son permisos que protegen el acceso a acciones muy avanzadas.
Los permisos se solicitan en el AndroidManifest de la siguiente manera:
<manifest ... >
<uses-permission android:name="android.permission.SEND_SMS"/>
...
</manifest>
Figura 32: Permisos en AndroidManifest [71]
4.3.1.8 Exports
Este atributo representa la posibilidad de otra aplicación para lanzar tanto un servicio como una
actividad dentro de la aplicación. En el caso de que este valor no esté definido el sistema
devolverá la excepción “ActivityNotFoundException”.
En el caso de que el valor exported sea “true” cualquier aplicación que conozca el nombre de
dicho atributo podrá acceder al elemento en cuestión. En caso contrario, siendo “false” limitará
la exposición de dicho elemento ante otras aplicaciones.
android:exported=["true" | "false"]
Figura 33: Exports en AndroidManifest
35
4. METODOLOGÍA DESARROLLADA
4.3.1.9 Backups
Este atributo permite que a la hora de realizar copias de seguridad se guarden los datos de la
aplicación en dicha copia. Su valor de fábrica es “true”, en caso que no se quiera realizar esta
acción debe especificarse asignando el valor en “false” [71].
android:allowBackup=["true" | "false"]
Figura 34: Backups en AndroidManifest [71]
4.3.1.10 Meta Data
Representa la opción adicional para almacenar información a la que se puede acceder desde
todo el proyecto, es decir, se puede entregar un dato a otro apartado del proyecto habiéndose
solicitado previamente [72]. Un ejemplo del código:
<meta-data android:name="string"
android:resource="resource specification"
android:value="string" />
Figura 35: meta-data en AndroidManifest [73]
4.3.1.11 Uses Features
Declara un componente hardware o software usado por la aplicación, el propósito de este
elemento es el de informar a las entidades externas del conjunto de hardware y software de los
que depende la aplicación. Por cada elemento usado debe añadirse un nuevo uses-feature
[74].
Contiene también un elemento required para especificar si la aplicación puede funcionar sin
ese elemento o no.
<uses-feature
android:name="string"
android:required=["true" | "false"]
android:glEsVersion="integer" />
Figura 36: uses-feature en AndroidManifest [74]
Los elementos del uses-feature son únicamente informativos, es decir el sistema Android no
verifica que los uses-features coincidan con el software o hardware disponible en el dispositivo.
Esta característica solamente sirve para que servicios como Google Play adviertan sobre los
posibles errores que se pueden producir en la ejecución de la aplicación.
36
PROYECTO FIN DE GRADO
4.3.2 Datos de la aplicación
En este apartado se comentarán las características extraídas ajenas al AndroidManifest.xml.
Entre las características extraídas se encuentran los iconos, imágenes, audios, videos y el
tamaño de la aplicación.
Primeramente se intentará encontrar una correlación entre las diferentes características, es
decir comprobaremos si existe una cantidad distinta de imágenes, audios y videos entre las
aplicaciones malware y las aplicaciones benignas.
Por otra parte también se verificará que ambos tipo de aplicaciones tengan un tamaño similar, y
en caso contrario se intentará detectar si existe algún tipo de similitud entre las aplicaciones
malware entre sí y si existe algún tipo de diferencia entre el malware y el software benigno.
4.4 Caso de uso
En este apartado se procederá a explicar el proceso seguido para poder analizar las diferentes
aplicaciones. Para ello se usará tanto la shell de linux, para extraer las características a un
“.txt”, como python, para generar un conjunto de datos y para realizar el análisis de las
aplicaciones.
La realización de este proyecto, en cuanto a código refiere, está basado en el proyecto
“AndroidAppLyzer” de Arash Habibi Lashkari [98] aunque se ha modificado para extraer las
características deseadas y dividir la totalidad de los datos de las aplicaciones en malware y
software benigno.
Además se ha usado el dataset de la universidad de New Brunswick [94][95] para obtener las
aplicaciones, en este se encuentran muestras tanto de malware como de software benigno.
4.4.1 Decompilar
Una vez tenemos el software dividido en dos ficheros, uno para el software benigno y otro para
el malware, procederemos a descompilar las aplicaciones en dos carpetas, para ello usaremos
un script escrito para bash y la herramienta ApkTool, descrita anteriormente.
./decompilar.sh
Figura 37: Comando Decompilar
#!/bin/bash
IFS='/'
echo -e " Decompilando malware ... "
for DIRECTORIO in ../../0_Datos/apks/malware/*; do
read -a strarr <<< "$DIRECTORIO"
mkdir ../../0_Datos/analized/malware/${strarr[2]}"_Analizada"/
echo -e
37
4. METODOLOGÍA DESARROLLADA
"-----------------------------------------------------------------"
echo -e "APK: "${strarr[2]}
echo -e " Usando apktool..."
echo ../../0_Datos/apks/malware/${strarr[2]}
apktool d ../../0_Datos/apks/malware/${strarr[2]} -o
../../0_Datos/analized/malware/${strarr[2]}"_Analizada"/ -f
done
echo -e " Decompilando aplicaciones benignas ... "
for DIRECTORIO in ../../0_Datos/apks/benign/*; do
read -a strarr <<< "$DIRECTORIO"
mkdir ../../0_Datos/analized/benign/${strarr[2]}"_Analizada"/
echo -e
"-----------------------------------------------------------------"
echo -e "APK: "${strarr[2]}
echo -e " Usando apktool..."
echo apks/benign/${strarr[2]}
apktool d ../../0_Datos/apks/benign/${strarr[2]} -o
../../0_Datos/analized/benign/${strarr[2]}"_Analizada"/ -f
done
Figura 38: Script Decompilar
Figura 39: Ejecución del script para Decompilar
4.4.2 Extraer Características
Una vez descompiladas todas las aplicaciones, procederemos a extraer las diferentes
características a un .txt con un script de Linux para bash.
./0_Extraer_Caracteristicas.sh
Figura 40: Ejecución del script para Extraer las características
38
PROYECTO FIN DE GRADO
Para realizar este PFG se han extraído múltiples características, pero en el ejemplo inferior se
muestra como se extraerán las acciones existentes en cada aplicación. La extracción se
realizará en dos bucles, el primero para el malware y el segundo para el software benigno.
#!/bin/bash
IFS='/'
for DIRECTORIO in ../../../0_Datos/analized/malware/*; do
read -a strarr <<< "$DIRECTORIO"
echo -e " Extrayendo acciones del AndroiManifest"
echo -e "DIRECTORIO" $DIRECTORIO
echo -e "strarr" ${strarr[6]}
echo -e " Acciones: " >>
../../../0_Datos/analized/malware/${strarr[6]}/Acciones.txt
grep -oP 'action.*".*"'
../../../0_Datos/analized/malware/${strarr[6]}/AndroidManifest.xml
-u >> ../../../0_Datos/analized/malware/${strarr[6]}/Acciones.txt
echo -e " " >>
../../../0_Datos/analized/malware/${strarr[6]}/Acciones.txt
done
for DIRECTORIO in ../../../0_Datos/analized/benign/*; do
read -a strarr <<< "$DIRECTORIO"
echo -e "DIRECTORIO" $DIRECTORIO
echo -e " Extrayendo acciones del AndroiManifest"
echo -e "strarr" ${strarr[6]}
echo -e " Acciones: " >>
../../../0_Datos/analized/benign/${strarr[6]}/Acciones.txt
grep -oP 'action.*".*"'
../../../0_Datos/analized/benign/${strarr[6]}/AndroidManifest.xml
-u >> ../../../0_Datos/analized/benign/${strarr[6]}/Acciones.txt
echo -e " " >>
../../../0_Datos/analized/benign/${strarr[6]}/Acciones.txt
done
| sort
| sort
Figura 41: Script para Extraer las características
En la figura inferior se muestra el código para extraer las diferentes características. Las que
están relacionadas con el AndroidManifest se buscarán de forma similar, simplemente se
intentará encontrar una coincidencia dentro del código del AndroidManifest.
grep -oP 'package=.*" '
../../0_Datos/analized/malware/${strarr[5]}/AndroidManifest.xml | sort -u
>> ../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
grep -oP 'activity.*" '
../../0_Datos/analized/malware/${strarr[5]}/AndroidManifest.xml | sort -u
>> ../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
grep -oP 'service .*"'
../../0_Datos/analized/malware/${strarr[5]}/AndroidManifest.xml | sort -u
39
4. METODOLOGÍA DESARROLLADA
>> ../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
grep -oP 'provider .*"'
../../0_Datos/analized/malware/${strarr[5]}/AndroidManifest.xml | sort -u
>> ../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
grep -oP 'receiver .*"'
../../0_Datos/analized/malware/${strarr[5]}/AndroidManifest.xml | sort -u
>> ../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
grep -oP 'action.*".*"'
../../0_Datos/analized/malware/${strarr[5]}/AndroidManifest.xml | sort -u
>> ../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
grep -oP 'category.*"'
../../0_Datos/analized/malware/${strarr[5]}/AndroidManifest.xml | sort -u
>> ../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
grep -oP 'permission.*"'
../../0_Datos/analized/malware/${strarr[5]}/AndroidManifest.xml | sort -u
>> ../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
grep -oP 'exported="true".*"'
../../0_Datos/analized/malware/${strarr[5]}/AndroidManifest.xml | sort -u
>> ../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
grep -oP 'allowBackup.*" ' ../../0_Datos/analized/malware/${strarr[5]}/And
roidManifest.xml | sort -u >>
../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
grep -oP 'meta-data.*"'
../../0_Datos/analized/malware/${strarr[5]}/AndroidManifest.xml | sort -u
>> ../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
grep -oP 'uses-features.*"'
../../0_Datos/analized/malware/${strarr[5]}/AndroidManifest.xml | sort -u
>> ../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
Figura 42: Ejemplo de características a buscar en AndroidManifest
En cambio para extraer la cantidad de imágenes, iconos, videos, audios y el tamaño se
realizará de forma diferente, en el caso del tamaño de la aplicación se realizará con el
comando “cut”, se ha optado por este comando debido a que en el caso de que este código sea
usado en otro sistema Unix sea posible su ejecución, comandos como “stat” son específicos de
GNU/Linux, lo que imposibilita su uso es otros sistemas Unix.
Para extraer la cantidad de imágenes, audios, iconos y videos se realizará una búsqueda
dentro de cada aplicación de archivos con la extensión correspondiente a cada uno.
find ../../0_Datos/analized/malware/${strarr[5]}/ -iname "*.png" -type f
-printf '.' | wc -c >>
../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
find ../../0_Datos/analized/malware/${strarr[5]}/* -iname "*.jpg" -type f
-printf '.' | wc -c
>>
../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
find ../../0_Datos/analized/malware/${strarr[5]}/* -iname "*.mp3" -type f
-printf '.' | wc -c
>>
../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
40
PROYECTO FIN DE GRADO
find ../../0_Datos/analized/malware/${strarr[5]}/* -iname "*.mp4" -type f
-printf '.' | wc -c
>>
../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
du -sh ../../0_Datos/analized/malware/${strarr[5]}/ | cut -f -1 >>
../../0_Datos/analized/malware/${strarr[5]}/caracteristicas1.txt
Figura 43: Ejemplo de características a buscar fuera de AndroidManifest
Una vez se hayan extraído las características, cada carpeta de aplicación tendrá el siguiente
formato, los archivos con extensión “.txt” corresponderá a los diferentes análisis, es decir, el
fichero “Acciones.txt” corresponderá a los datos extraídos específicos de las acciones de la
aplicación, pero el fichero “permisosAcciones.txt” contendrá tanto los datos extraídos de las
acciones como los de los permisos. El resto de carpetas y ficheros serán los extraídos al
decompilar la aplicación por ApkTool.
Figura 44: Resultado de carpeta de cada aplicación
Las diferentes características se guardarán de la siguiente forma:
Package :
package="com.hudway.online" platformBuildVersionCode="23"
Activities :
activity android:configChanges="keyboardHidden|orientation|screenSize"
android:excludeFromRecents="true"
android:name="com.startapp.android.publish.FullScreenActivity"
android:taskAffinity=""
activity android:configChanges="keyboardHidden|orientation|screenSize"
android:excludeFromRecents="true"
Services :
service android:enabled="true" android:exported="false"
android:name="com.google.android.gms.measurement.AppMeasurementService"
service android:enabled="true" android:exported="false"
android:name="com.google.android.gms.tagmanager.TagManagerService"
Providers :
provider android:authorities="com.hudway.online.firebaseinitprovider"
android:exported="false" android:initOrder="100"
android:name="com.google.firebase.provider.FirebaseInitProvider"
Receivers :
receiver android:enabled="true" android:exported="false"
android:name="com.google.android.gms.measurement.AppMeasurementReceiver"
receiver android:enabled="true"
41
4. METODOLOGÍA DESARROLLADA
android:name="com.google.android.gms.measurement.AppMeasurementInstallRefer
rerReceiver"
Intents Action :
action android:name="android.app.action.DEVICE_ADMIN_ENABLED"
action android:name="android.intent.action.MAIN"
Intents Category :
category android:name="android.intent.category.BROWSABLE"
category android:name="android.intent.category.DEFAULT"
Permissions :
permission android:name="android.permission.ACCESS_COARSE_LOCATION"
permission android:name="android.permission.ACCESS_FINE_LOCATION"
Exported :
exported="true"
android:name="com.batsman.revoices.HaimsuckenCheapishlyService"
exported="true" android:name="com.facebook.CustomTabActivity"
Backup :
allowBackup="true" android:icon="@mipmap/hudway_icon"
android:label="@string/app_name"
android:name="com.hudway.online.controllers.App.App"
android:supportsRtl="true"
Meta-Data :
meta-data android:name="android.app.device_admin"
android:resource="@xml/device_admin"
meta-data android:name="com.facebook.sdk.ApplicationId"
android:value="@string/fb_login_protocol_scheme"
Number of Icons :
1413
Number of Pictures :
2
Number of Audio :
3
Number of Videos :
0
Size of the App :
159M
Figura 45: Ejemplo de “.txt” generado
42
PROYECTO FIN DE GRADO
4.4.3 Generar listados
A la hora de extraer los permisos, las acciones, los servicios y las categorías existen dos
posibilidades, la primera, buscar unos en concreto, es decir, se tratará de encontrar solamente
los valores más peligrosos, la segunda es crear una lista que contenga todos los valores
contenidos en el dataset entero, posteriormente, en vez de realizar una búsqueda de ciertos
valores únicamente, se buscarán todos los valores posibles.
En el caso de que se quiera realizar la segunda opción, se usará el siguiente código escrito en
python, al igual que en el anterior apartado, este es un ejemplo de cómo se extraerán las
acciones:
for i in
/mnt/discoDuro/clasesFinales/extraccion/0_Datos/analized/*/*/Acciones.txt;
do python 1_CrearLista.py $i; done
Figura 46: Comando ejecutar generador de listados
import re
import csv
import sys
Feature = []
name = ""
with open (sys.argv[1], 'rt') as myfile:
for myline in myfile:
Feature.append(myline.rstrip('\n').rstrip(' '))
print(Feature)
for index, line in enumerate(Feature):
if " Acciones:" in str(line):
for a in range(index+1, index + 100):
if len(Feature[a]) == 0:
break
else:
name = re.search(r'"([^"]*)"', Feature[a]).group(1)
if name != None:
print(name)
else:
print(" None !!!! ")
print("###################################################################"
)
print("Analysing App : "+name)
print("\n")
Actions = []
for index, line in enumerate(Feature):
if " Acciones:" in str(line):
for a in range(index+1, index + 100):
if len(Feature[a]) == 0:
43
4. METODOLOGÍA DESARROLLADA
break
else:
try:
actio = re.search(r'".*.action.([^"]*)"',
Feature[a]).group(1)
Actions.append("action."+actio)
except:
print("None !!!!")
print("*************************************************************")
Act = []
for i in Actions:
Act.append(i)
print("List of actions for this app :")
for i in Act:
print(i)
print("*************************************************************")
for i in Act:
print(i)
if i in
open('/mnt/discoDuro/clasesFinales/extraccion/0_Datos/Unique_Lists/3_List_A
ctions.csv').read():
print("0")
else:
print("1")
with
open('/mnt/discoDuro/clasesFinales/extraccion/0_Datos/Unique_Lists/3_List_A
ctions.csv', 'a+') as csvfile:
csvfile.write(i.encode())
csvfile.write('\n'.encode())
csvfile.close()
print("Added ... ")
Figura 47: Ejemplo código generador de listados
El resultado, será un archivo de extensión “.csv” con todas las acciones, permisos, servicios o
categorías existentes en el dataset, tener en cuenta que cada una de las características estará
contenida en un listado diferente, es decir los permisos tendrán un conjunto de datos, las
acciones otro y así sucesivamente:
category.BROWSABLE
category.DEFAULT
category.LAUNCHER
category.HOME
category.CARDBOARD
Tabla 1: Ejemplo listados
44
PROYECTO FIN DE GRADO
Figura 48: Ejemplo ejecución generador de listados
4.4.4 Generar Dataset
Una vez extraídas las características y generados los listados, se procederá a generar un
dataset con la información de las aplicaciones para su posterior análisis:
for i in
/mnt/discoDuro/clasesFinales/extraccion/0_Datos/analized/*/*/Acciones.txt;
do python 2_CrearCSV.py $i .; done
Figura 49: Comando ejecutar generador de Datasets
Para la generación de dicho dataset, se usará Python y las herramientas csv, sys y re. Lo que
realiza el código inferior es, inicialmente abrir el archivo de la característica o características a
extraer, es decir, el que se ha generado en el paso dos, y se guardarán en una variable.
Seguidamente se procederá a comprobar si existe coincidencia en el listado generado en el
anterior paso, en caso de que si exista, se añadirá un 1 al dataset, en el caso contrario un 0.
Finalmente se comprobará si se está analizando dentro de la carpeta de malware o software
benigno y dependiendo de cual sea se añadirá un 0, correspondiente al software benigno, o un
1, correspondiente al malware.
En este ejemplo solamente se analizarán las acciones, en el caso de que se deseen analizar
más variables, se deberá introducir el código correspondiente antes del último paso.
45
4. METODOLOGÍA DESARROLLADA
import csv
import sys
import re
Feature = []
name = ""
Values =[]
with open (sys.argv[1], 'rt') as myfile:
for myline in myfile:
Feature.append(myline.rstrip('\n').rstrip(' '))
end = sys.argv[2]
sp1=sys.argv[1].split(end)
sp2=sp1[0].split('.')
Values.append(sp2[0])
Actions = []
print(Feature)
for index, line in enumerate(Feature):
if " Acciones:" in str(line):
for a in range(index+1, index + 100):
if len(Feature[a]) == 0:
break
else:
try:
actio = re.search(r'".*.action.([^"]*)"',
Feature[a]).group(1)
Actions.append("action."+actio)
except:
print("None !!!!")
with
open('/mnt/discoDuro/clasesFinales/extraccion/0_Datos/Unique_Lists/3_List_A
ctions.csv') as csvFile:
dataAct = csvFile.readlines()
csvFile.close()
for i in dataAct:
if i.strip() in Actions:
Values.append(1)
else:
Values.append(0)
tipo = sp1[0].split("/")
tipoFn = tipo[-2]
if tipoFn == 'malware':
Values.append(1)
else:
Values.append(0)
with
open('/mnt/discoDuro/clasesFinales/extraccion/0_Datos/Output_CSV_Files/Acci
ones.csv', 'a+') as csvFile:
46
PROYECTO FIN DE GRADO
writer = csv.writer(csvFile)
writer.writerow(Values)
csvFile.close()
Figura 50: Ejemplo código generador de Datasets
Para analizar las características que no contengan un listado, como el tamaño de la aplicación
o la cantidad de imágenes, iconos, audios o videos, se realizará a través del siguiente código:
print(" Number of Videos ***************************")
for index, line in enumerate(Feature):
if " Number of Videos :" in str(line):
for a in range(index+1, index + 100):
if len(Feature[a]) == 0:
break
else:
Hardware.append(Feature[a])
print(" Size of the App ***************************")
for index, line in enumerate(Feature):
if " Size of the App :" in str(line):
for a in range(index+1, index + 100):
if len(Feature[a]) == 0:
break
else:
print(Feature[a][:-1])
Hardware.append(int(float(Feature[a][:-1])))
Figura 51: Ejemplo código generador de Datasets para datos no asignados en los listados
4.4.5 Análisis
Una vez se haya obtenido el dataset se procederá a analizarlo y a verificar la efectividad de los
algoritmos de aprendizaje automático. Para ello se usará Sklearn, una conocida librería de
aprendizaje automático implementada en Python.
Primero se leerá el dataset y se guardarán sus valores en una lista, posteriormente se
procederá a dividir los datos para entrenar a los diferentes modelos, finalmente se
implementarán algoritmos de verificación para comprobar la efectividad de dichos algoritmos
con los datos utilizados.
train_x = [[]]
train_y = [[]]
Values = []
nombre = ""
def carga():
global train_x
global train_y
global test_x
47
4. METODOLOGÍA DESARROLLADA
global test_y
file = pd.read_csv("Output_CSV_Files/Acciones.csv")
coulmnNames = file.iloc[1:1, 1:].columns
FeatureNames = list(coulmnNames[1:-1])
LabelName = coulmnNames[-1]
X = file[FeatureNames]
X = np.asarray(X)
Y = file[LabelName]
Y = np.asarray(Y)
feature_vectors = X
labels = Y
train_x, test_x, train_y, test_y =
train_test_split(feature_vectors,labels,test_size=0.2)
def ridge():
global train_x
global train_y
global test_x
global pred_x
global nombre
nombre = "Bayesian Ridge"
carga()
br = RidgeClassifier()
br.fit(train_x, train_y)
pred_x = br.predict(test_x)
print("This is a Linear Model")
print("Bayesian Ridge")
resultado()
def mlp():
global train_x
global train_y
global test_x
global pred_x
global nombre
nombre = "Multi-layer Perceptron"
carga()
mlp = MLPClassifier()
mlp.fit(train_x, train_y)
pred_x = mlp.predict(test_x)
print("This is a Neural Network")
print("Multi-layer Perceptron")
resultado()
def resultado():
Values =[]
global test_y
global pred_x
48
PROYECTO FIN DE GRADO
print("Accuracy:", accuracy_score(test_y, pred_x)) # accuracy
print("Balanced Accuracy:", balanced_accuracy_score(test_y, pred_x,
sample_weight=None, adjusted=False)) # balanced_accuracy
print("Precision score:", precision_score(test_y, pred_x,
average=None)) # precision
print("Average Precision score:", average_precision_score(test_y,
pred_x)) # average_precision
print("Neg Brier Score:", brier_score_loss(test_y, pred_x)) #
neg_brier_score
print("F1 Score:", f1_score(test_y, pred_x)) # f1
print("Recall Score:", recall_score(test_y, pred_x))# recall
print("AUC:", roc_auc_score(test_y, pred_x)) # roc_auc
Values.append(nombre)
Values.append(accuracy_score(test_y, pred_x))
Values.append(balanced_accuracy_score(test_y, pred_x,
sample_weight=None, adjusted=False))
Values.append(precision_score(test_y, pred_x, average=None))
Values.append(average_precision_score(test_y, pred_x))
Values.append(brier_score_loss(test_y, pred_x))
Values.append(f1_score(test_y, pred_x))
Values.append(recall_score(test_y, pred_x))
Values.append(roc_auc_score(test_y, pred_x))
with open('resultadoAnalisis/resultadoAcciones.csv', 'a+') as
csvFile:
writer = csv.writer(csvFile)
writer.writerow(Values)
csvFile.close()
def nombres():
global Values
Values.append("Clasificador")
Values.append("accuracy_score")
Values.append("balanced_accuracy_score")
Values.append("precision_score")
Values.append("average_precision_score")
Values.append("brier_score_loss")
Values.append("f1_score")
Values.append("recall_score")
Values.append("roc_auc_score")
with open('resultadoAnalisis/resultadoAcciones.csv', 'a+') as
csvFile:
writer = csv.writer(csvFile)
writer.writerow(Values)
csvFile.close()
def main():
global train_x
49
4. METODOLOGÍA DESARROLLADA
global train_y
global test_x
global pred_x
train_x = [[]]
train_y = [[]]
Values = []
train_y = []
train_x = []
nombres()
ridge()
logisticRegression()
SGD()
KNN()
gaussian()
decisionTree()
adaBoost()
gradientBoosting()
mlp()
main()
Figura 52: Ejemplo código de análisis
50
PROYECTO FIN DE GRADO
Capítulo 5
Resultados
5.1 Métricas
5.1.1 Accuracy Score
A través de la función accuracy_score calcularemos la precisión o exactitud de los diferentes
tipos de clasificadores. Para calcular la exactitud compararemos las predicciones correctas con
las predicciones totales, por ejemplo siendo el resultado de la fórmula accuracy_score 0.87, de
cada 100 predicciones 87 serán correctas [77][78]. Dicha exactitud se calculará con la siguiente
fórmula:
Figura 53: Función exactitud [75]
En esta fórmula VP serán los verdaderos positivos, VN verdaderos negativos, FP falsos
positivos y FN falsos negativos.
Los valores representarán las siguientes muestras [76]:
●
Verdaderos positivos: En nuestro caso representaría las aplicaciones maliciosas
detectadas como malignas por el clasificador.
●
Verdaderos negativos: Representará las aplicaciones benignas predichas como
benignas.
●
Falsos positivos: Representará las aplicaciones benignas predichas como malignas.
●
Falsos negativos: Representará las aplicaciones malignas predichas como benignas.
Los problemas que puede contener esta función es que aunque la precisión sea de un 87%
puede que de ese porcentaje la gran mayoría sean verdaderos negativos y el modelo no
detecte de la forma más correcta las aplicaciones malignas.
5.1.2 Balanced Accuracy Score
Esta función calcula la la precisión equilibrada, es útil en clases muy desequilibradas, es decir
cuando uno de los dos tipos de elementos a comparar es más frecuente [80][81]. Al igual que la
"accuracy_score", contiene los valores VP (Verdaderos Positivos), VN (Verdaderos Negativos),
FP (Falsos Positivos) y FN (Falsos Negativos). Para hacer el cálculo se hará la división de la
suma de la sensibilidad y la especificidad dividido entre 2, donde la sensibilidad es la división
51
5. Resultados
entre los VP y la suma de los VP y FN y la especificidad es la división entre los VN y la suma
de los FP y VN, es decir la fórmula sería la siguiente:
Figura 54: Función Balanced Accuracy [79]
Lo que se consigue a través de esta verificación es intentar seleccionar los aspectos negativos
de la métrica y evitar seleccionar los positivos, así evitará las estimaciones de rendimiento
infladas, por lo que si el resultado de esta función varía mucho del resultado de
"accuracy_score" se puede decir que el conjunto de datos será bastante desequilibrado [79].
5.1.3 Precision Score
La precisión es el número de resultados positivos dividido entre la cantidad de resultados
totales, es decir mide la capacidad de no marcar de forma positiva una muestra negativa. La
fórmula a la que llama "precision_score" es el calculo de el total de VP (Verdaderos Positivos)
dividido entre los VP (Verdaderos Positivos) sumados a los FP (Falsos Positivos), es decir
cumpliría la siguiente fórmula [82]:
Figura 55: Función Precision [83]
Cuyo resultado será mejor si es más próximo a 1 y peor si es más próximo a 0. La gran
diferencia entre la función "precision_score" y "accuracy_score" es que el segundo sólo es una
buena medida cuando la cantidad de muestras benignas y malignas son del mismo tamaño.
5.1.4 Average Precision Score
La precisión promedio o average precision es una métrica que calcula el valor de la precisión
promedio para el valor de recuperación entre 0 y 1. Para ello hay que tener en cuenta la
precisión y la recuperación. La precisión por una parte, como su nombre indica, medirá la
exactitud de las predicciones, es decir la cantidad de predicciones correctas. En cambio la
recuperación medirá con qué precisión encontrará los positivos [84]. Es decir seguirán las
siguientes fórmulas:
Figura 56: Función Precision y Recuperación [85].
52
PROYECTO FIN DE GRADO
Esto nos generará, llevando la precisión y la recuperación a una gráfica, un resultado con la
siguiente forma.
Figura 57: Gráfica de Recuperación y precisión [85].
De la cual esta fórmula calcula la curva de recuperación de la precisión como media ponderada
de las precisiones logradas en cada umbral, para realizar dicha ponderación se usa el umbral
anterior como ponderación.
5.1.5 Brier Score Loss
Esta función mide la diferencia cuadrática entre la probabilidad predicha y el resultado real. El
valor estará recogido entre 0 y 1, cuanto más bajo sea el valor la predicción será más precisa.
Este método es apropiado para medir valores binarios, es decir o existe o no existe, en cambio
si los valores pueden ser de tres o más tipos diferentes no es válido, esto se debe a que esta
función da por hecho que la distancia entre las variables es igual entre ellas. En definitiva con
esta métrica sabremos si el clasificador está calibrado [86].
También hay que tener en cuenta que aunque el valor sea muy bajo, no significa que el
clasificador esté mejor calibrado, es decir esta función se puede dividir en la suma de la pérdida
de calibración y la pérdida de refinamiento. La pérdida de refinamiento es independiente a la
pérdida de calibración, por lo que no significa que esté mejor calibrado, sino que solamente
cuando la pérdida de refinamiento sea invariable y la pérdida de puntaje Brier sea baja significa
que el clasificador esté mejor calibrado [87].
5.1.6 F1 Score
Este valor se puede interpretar como el promedio ponderado de la precisión y la recuperación,
su puntuación estará entre 0 y 1 donde 1 será la mejor y 0 la peor. La importancia de la
precisión y la recuperación es equivalente, por lo que es una media armónica de ambas. Su
fórmula es la siguiente:
Figura 58: Función F1 [88]
53
5. Resultados
5.1.7 Recall Score
Esta función muestra la habilidad de detectar todas las muestras positivas por el clasificador.
Se calcula con VP / (VP + FN) donde TP es la cantidad de verdaderos positivos y FN la
cantidad de falsos negativos, el valor oscila entre 0 y 1 siendo el mejor valor 1 y el peor 0 [90].
Su fórmula es la siguiente:
Figura 59: Función Recuperación [89]
5.1.8 ROC AUC Score
Calcula el área bajo la curva de características operativas del receptor a partir de las
puntuaciones de la predicción. Analiza el rendimiento de un clasificador binario gracias a la
variación de su umbral de discriminacion [91].
5.2 Resultados obtenidos
En este apartado se analizarán los diferentes clasificadores con las distintas características
extraídas a través de las métricas seleccionadas en el apartado anterior.
5.2.1 Permisos
Clasificador
accur
acy_s
core
balan
ced_a
ccura
cy_sc
ore
precisi
on_sc
ore
average_pre
cision_score
brier_s
core_lo
ss
f1_sc
ore
recall
_scor
e
roc_a
uc_sc
ore
Bayesian
Ridge
0.912
0.914
43643
85
[0.873
01587
0.951
6129 ]
0.901987481
9
0.088
0.914
72868
22
0.880
59701
49
0.914
43643
85
Logistic
Regression
0.856
0.856
24679
98
[0.881
35593
0.833
33333
]
0.795247311
8
0.144
0.859
375
0.887
09677
42
0.856
24679
98
Stochastic
Gradient
Descent SGD
0.76
0.765
78674
95
[0.830
50847
0.696
9697 ]
0.652510822
5
0.24
0.754
09836
07
0.821
42857
14
0.765
78674
95
Neighbors
Classifier
0.808
0.804
21842
65
[0.796
2963
0.816
90141
]
0.774670749
1
0.192
0.828
57142
86
0.840
57971
01
0.804
21842
65
54
PROYECTO FIN DE GRADO
GaussianNB
0.656
0.662
14139
34
[0.595
74468
0.838
70968
]
0.644725806
5
0.344
0.547
36842
11
0.406
25
0.662
14139
34
Decision Tree
Clasifier
0.872
0.870
60041
41
[0.884
05797
0.857
14286
]
0.798693877
6
0.128
0.857
14285
71
0.857
14285
71
0.870
60041
41
Ada Boost
Classifier
0.816
0.816
77817
81
[0.786
88525
0.843
75 ]
0.784037313
4
0.184
0.824
42748
09
0.805
97014
93
0.816
77817
81
Gradient Tree
Boosting
Classifier
0.872
0.867
37089
2
[0.865
38462
0.876
71233
]
0.846275902
0.128
0.888
88888
89
0.901
40845
07
0.867
37089
2
Multi-layer
Perceptron
0.888
0.886
74884
44
[0.894
73684
0.882
35294
]
0.850139037
4
0.112
0.895
52238
81
0.909
09090
91
0.886
74884
44
Tabla 2: Resultado permisos
Primero se analizarán los resultados extraídos con únicamente los permisos que Android
Developers, la plataforma de desarrolladores de Android, considera de riesgo. Con estos
permisos se puede observar que se obtienen unos resultados bastante buenos con la mayoría
de clasificadores. Además se puede observar que la balanced_accuracy_score es similar a la
accuracy, por lo que se puede determinar que el modelo detecta correctamente el malware.
Por otro lado, el campo brier_score_loss, en la mayoría de los casos, devuelve unos valores
bastante bajos, aunque en el caso del clasificador GaussianNB obtiene unos valores
demasiado altos, lo que indica que el clasificador no está muy bien calibrado. El clasificador
que mejores resultados obtiene es Bayesian Ridge con un 0.912 en la accuracy_score, como
se puede observar en el resto de tablas, este valor solo es superado por el cálculo con todas
las variables posibles, por lo que se podría decir que este método es el mejor en el caso de que
la cantidad de muestras sea muy grande y el tiempo disponible para la clasificación sea bajo.
55
5. Resultados
5.2.2 Todos los permisos posibles
Clasificador
accur
acy_s
core
balance
d_accu
racy_sc
ore
precisi
on_sco
re
average_pre
cision_score
brier_s
core_lo
ss
f1_sc
ore
recall
_scor
e
roc_a
uc_s
core
Bayesian
Ridge
0.808
0.8093
154915
[0.8412
6984
0.7741
9355]
0.720711902
1
0.192
0.8
0.827
5862
069
0.809
3154
915
Logistic
Regression
0.88
0.8764
766307
[0.8493
1507
0.9230
7692]
0.838977835
7
0.12
0.864
8648
649
0.813
5593
22
0.876
4766
307
Stochastic
Gradient
Descent SGD
0.712
0.6954
451879
[0.6666
6667
0.8437
5 ]
0.640780172
4
0.288
0.6
0.465
5172
414
0.695
4451
879
Neighbors
Classifier
0.84
0.8397
33743
[0.8620
6897
0.8208
9552]
0.780654821
1
0.16
0.846
1538
462
0.873
0158
73
0.839
7337
43
GaussianNB
0.672
0.6773
821721
[0.6111
1111
0.8285
7143]
0.655446428
6
0.328
0.585
8585
859
0.453
125
0.677
3821
721
Decision Tree
Clasifier
0.88
0.8807
692308
[0.8571
4286
0.9032
2581]
0.850163771
7
0.12
0.881
8897
638
0.861
5384
615
0.880
7692
308
Ada Boost
Classifier
0.808
0.8116
314977
[0.8644
0678
0.7575
7576]
0.717082549
6
0.192
0.806
4516
129
0.862
0689
655
0.811
6314
977
Gradient Tree
Boosting
Classifier
0.864
0.8628
205128
[0.8771
9298
0.8529
4118]
0.817085972
9
0.136
0.872
1804
511
0.892
3076
923
0.862
8205
128
Multi-layer
Perceptron
0.912
0.9121
794872
[0.9218
75
0.9016
3934]
0.866502732
2
0.088
0.909
0909
091
0.916
6666
667
0.912
1794
872
Tabla 3: Resultado todos los permisos posibles
Una vez realizado el primer análisis se consideró realizar un segundo pero esta vez analizando
todos los permisos contenidos por las aplicaciones del Dataset. Como se puede observar en la
tabla, en la combinación de todos los permisos, los valores obtenidos son similares, aunque
56
PROYECTO FIN DE GRADO
esta vez el clasificador Bayesian ridge obtiene peores resultados pero el Multi Layer Perceptron
obtiene unos valores mejoresa. El clasificador GaussianNB sigue siendo el clasificador con
peores resultados, aunque mejoran algo respecto al anterior análisis.
En conclusión, es mejor buscar los permisos de alto riesgo únicamente, ya que los resultados
obtenidos son similares y el tiempo de ejecución es menor en el caso de la extracción de los
permisos de riesgo.
5.2.3 Acciones
Clasificador
accur
acy_s
core
balan
ced_a
ccura
cy_sc
ore
precisi
on_sc
ore
average_pre
cision_score
brier_s
core_lo
ss
f1_sc
ore
recall
_scor
e
roc_a
uc_sc
ore
Bayesian
Ridge
0.88
0.879
41628
26
[0.833
33333
0.943
39623
]
0.856803408
4
0.12
0.869
56521
74
0.806
45161
29
0.879
41628
26
Logistic
Regression
0.816
0.816
76938
88
[0.790
32258
0.841
26984
]
0.779565175
6
0.184
0.821
70542
64
0.803
03030
3
0.816
76938
88
Stochastic
Gradient
Descent SGD
0.76
0.762
55122
95
[0.706
66667
0.84
]
0.72725
0.24
0.736
84210
53
0.656
25
0.762
55122
95
Neighbors
Classifier
0.72
0.719
87179
49
[0.734
375
0.704
91803
]
0.641191256
8
0.28
0.710
74380
17
0.716
66666
67
0.719
87179
49
GaussianNB
0.608
0.605
22273
43
[0.842
10526
0.566
03774
]
0.563083558
0.392
0.710
05917
16
0.952
38095
24
0.605
22273
43
Decision Tree
Clasifier
0.824
0.829
73805
86
[0.753
42466
0.923
07692
]
0.815328671
3
0.176
0.813
55932
2
0.727
27272
73
0.829
73805
86
Ada Boost
Classifier
0.856
0.857
56562
02
[0.822
58065
0.888
8889]
0.830951907
1
0.144
0.861
53846
15
0.835
82089
55
0.857
56562
02
57
5. Resultados
Gradient Tree
Boosting
Classifier
0.824
0.823
86072
71
[0.815
38462
0.833
33333
]
0.768043010
8
0.176
0.819
67213
11
0.806
45161
29
0.823
86072
71
Multi-layer
Perceptron
0.8
0.800
43522
79
[0.768
11594
0.839
28571
]
0.754133786
8
0.2
0.789
91596
64
0.746
03174
6
0.800
43522
79
Tabla 4: Resultado acciones
Una vez analizados los permisos, se procederá a analizar los resultados obtenidos de las
acciones, en este caso podemos observar que aunque los valores no son malos, no son tan
buenos como los de los permisos. Otra vez el clasificador con mejores resultados es el
Bayesian Ridge, y el peor es GaussianNB y los resultados de esta característica oscila entre
0.608 y 0.88, por lo que se puede decir que es una característica aceptable siempre y cuando
se elija el clasificador correcto, es decir, si se usa Bayesian Ridge se obtendrán unos buenos
resultados y la calibración del clasificador será precisa.
5.2.4 Servicios
Clasificador
accur
acy_s
core
balan
ced_a
ccura
cy_sc
ore
precisi
on_sc
ore
average_pre
cision_score
brier_s
core_lo
ss
f1_sc
ore
recall
_scor
e
roc_a
uc_sc
ore
Bayesian
Ridge
0.44
0.507
04225
35
[1.
0.435
48387
]
0.435483871
0.56
0.606
74157
3
1
0.433
21243
23
Logistic
Regression
0.52
0.530
86577
87
[0.504
20168
0.833
33333
]
0.537104166
7
0.48
0.142
85714
29
0.078
125
0.530
86577
87
Stochastic
Gradient
Descent SGD
0.544
0.540
32258
06
[0.525
1. ]
0.536645161
3
0.456
0.149
25373
13
0.080
64516
129
0.546
49077
87
Neighbors
Classifier
0.584
0.520
73552
43
[0.578
5124
0.75
]
0.449666666
7
0.416
0.103
44827
59
0.055
55555
556
0.575
24613
GaussianNB
0.512
0.537
87878
79
[0.491
66667
1.
]
0.563757575
8
0.488
0.140
84507
04
0.075
75757
576
0.506
75675
68
58
PROYECTO FIN DE GRADO
Decision Tree
Clasifier
0.56
0.549
18032
79
[0.537
81513
1.
]
0.538360655
7
0.44
0.179
10447
76
0.098
36065
574
0.563
23604
71
Ada Boost
Classifier
0.528
0.524
32155
66
[0.516
66667
0.8
]
0.515612903
2
0.472
0.119
40298
51
0.064
51612
903
0.5
Gradient Tree
Boosting
Classifier
0.472
0.511
86790
51
[0.462
18487
0.666
66667
]
0.551215686
3
0.528
0.108
10810
81
0.058
82352
941
0.522
05882
35
Multi-layer
Perceptron
0.536
0.510
27221
37
[0.533
33333
0.6]
0.478508474
6
0.464
0.093
75
0.050
84745
763
0.530
86577
87
Tabla 5: Resultado servicios
Continuando con las características, procederemos a analizar los servicios, como se puede
observar es la característica con peores resultados de todas las analizadas, es decir los valores
de la accuracy y la balanced accuracy son muy bajos, además se puede decir que todos los
clasificadores no se calibran correctamente, ya que obtienen unos valores muy altos. En el
caso del Stochastic Gradient Descent - SGD el valor del f1_score es notablemente bajo, lo que
indica que el algoritmo no mantiene concordancia entre la precisión y la recuperación, además
el valor de recall_score, es también muy bajo, lo que indica que no es nada útil para detectar
muestras positivas.
5.2.5 Categorías
Clasificador
accur
acy_s
core
balan
ced_a
ccura
cy_sc
ore
precisi
on_sc
ore
average_pre
cision_score
brier_s
core_lo
ss
f1_sc
ore
recall
_scor
e
roc_a
uc_sc
ore
Bayesian
Ridge
0.632
0.634
71435
92
[0.677
9661
0.590
90909
]
0.549335423
2
0.368
0.629
03225
81
0.672
41379
31
0.634
71435
92
Logistic
Regression
0.584
0.582
05128
21
[0.571
42857
0.594
2029 ]
0.566804905
2
0.416
0.611
94029
85
0.630
76923
08
0.582
05128
21
Stochastic
Gradient
Descent SGD
0.488
0.521
23005
66
[0.475
0.8 ]
0.551761194
0.512
0.1111
11111
1
0.059
70149
254
0.521
23005
66
59
5. Resultados
Neighbors
Classifier
0.592
0.589
26741
8
[0.604
16667
0.584
41558
]
0.562917207
8
0.408
0.638
29787
23
0.703
125
0.589
26741
8
GaussianNB
0.528
0.538
29405
74
[0.777
77778
0.508
62069
]
0.507944601
5
0.472
0.666
66666
67
0.967
21311
48
0.538
29405
74
Decision Tree
Clasifier
0.592
0.584
66289
24
[0.571
42857
0.605
26316
]
0.583553809
9
0.408
0.643
35664
34
0.686
56716
42
0.584
66289
24
Ada Boost
Classifier
0.656
0.661
22233
93
[0.741
93548
0.571
42857
]
0.523604395
6
0.344
0.626
08695
65
0.692
30769
23
0.661
22233
93
Gradient Tree
Boosting
Classifier
0.616
0.616
99948
8
[0.659
57447
0.589
74359
]
0.565551695
6
0.384
0.657
14285
71
0.741
93548
39
0.616
99948
8
Multi-layer
Perceptron
0.632
0.632
61648
75
[0.660
37736
0.6111
1111]
0.577691756
3
0.368
0.656
71641
79
0.709
67741
94
0.632
61648
75
Tabla 6: Resultado categorías
Continuando con la siguiente característica, se puede observar que aunque se obtienen
mejores resultados que con los servicios, estos resultados son muy bajos también. En el caso
del Stochastic Gradient Descent - SGD el valor del f1_score es notablemente bajo, lo que
indica que el algoritmo no mantiene concordancia entre la precisión y la recuperación, además
el valor de recall_score, es también muy bajo, lo que indica que no es nada útil para detectar
muestras positivas.
60
PROYECTO FIN DE GRADO
5.2.6 Permisos y acciones
Clasificador
accur
acy_s
core
balance
d_accu
racy_sc
ore
precisi
on_sco
re
average_pre
cision_score
brier_s
core_lo
ss
f1_sc
ore
recall
_scor
e
roc_a
uc_s
core
Bayesian
Ridge
0.88
0.8796
72299
[0.8529
4118
0.9122
807 ]
0.845138653
1
0.12
0.873
9495
798
0.838
7096
774
0.879
6722
99
Logistic
Regression
0.896
0.8957
479508
[0.9
0.8923
0769]
0.856653846
2
0.104
0.899
2248
062
0.906
25
0.895
7479
508
Stochastic
Gradient
Descent SGD
0.912
0.9051
724138
[0.8589
7436 1.
]
0.898344827
6
0.088
0.895
2380
952
0.810
3448
276
0.905
1724
138
Neighbors
Classifier
0.864
0.8691
966615
[0.8032
7869
0.9218
75 ]
0.862065140
8
0.136
0.874
0740
741
0.830
9859
155
0.869
1966
615
GaussianNB
0.72
0.7306
999485
[0.6455
6962
0.8478
2609]
0.717510707
3
0.28
0.690
2654
867
0.582
0895
522
0.730
6999
485
Decision Tree
Clasifier
0.912
0.9121
794872
[0.9218
75
0.9016
3934]
0.866502732
2
0.088
0.909
0909
091
0.916
6666
667
0.912
1794
872
Ada Boost
Classifier
0.88
0.8772
727273
[0.8873
2394
0.8703
7037]
0.807771043
8
0.12
0.862
3853
211
0.854
5454
545
0.877
2727
273
Gradient Tree
Boosting
Classifier
0.88
0.8733
766234
[0.9
0.8666
6667]
0.844761904
8
0.12
0.896
5517
241
0.928
5714
286
0.873
3766
234
Multi-layer
Perceptron
0.856
0.8561
187916
[0.8688
5246
0.8437
5 ]
0.798879032
3
0.144
0.857
1428
571
0.870
9677
419
0.856
1187
916
Tabla 7: Resultado permisos y acciones
Una vez analizadas todas las características principales, se ha procedido a analizar la
combinación de las dos con mejores resultados, en este caso los permisos y las acciones.
Como se puede observar, los resultados obtenidos son bastante similares a los obtenidos en
61
5. Resultados
los análisis de ambas características por separado, lo que indica que la combinación de ambas
no aporta una mejora.
Aunque se haya obtenido una tasa de aciertos mínima, siendo esta 0.72 obtenida por
GaussianNB, la mejor tasa de aciertos es 0.912, siendo igual que en los permisos y en las
acciones, lo único que varía es el clasificador que obtiene una mejor precisión, siendo el
Decision Tree Classifier en vez de el Multi-layer Perceptron o el Bayesian Ridge.
5.2.7 Todos los valores
Clasificador
accur
acy_s
core
balance
d_accu
racy_sc
ore
precisi
on_sco
re
average_pre
cision_score
brier_s
core_lo
ss
f1_score
recall_sc
ore
Bayesian
Ridge
0.92
0.9193
75645
[0.9264
7059
0.9122
807 ]
0.872256078
8
0.08
0.912280
7018
0.912280
7018
Logistic
Regression
0.84
0.8391
393443
[0.8235
2941
0.8596
4912]
0.78653782
0.16
0.830508
4746
0.803278
6885
Stochastic
Gradient
Descent SGD
0.672
0.7102
987421
[0.5666
6667
0.9428
5714]
0.744142857
1
0.328
0.616822
4299
0.458333
3333
Neighbors
Classifier
0.888
0.8867
827869
[0.9272
7273
0.8571
4286]
0.835571428
6
0.112
0.895522
3881
0.9375
GaussianNB
0.776
0.7698
717949
[0.7228
9157
0.8809
5238]
0.727253968
3
0.224
0.725490
1961
0.616666
6667
Decision Tree
Clasifier
0.824
0.8243
589744
[0.8064
5161
0.8412
6984]
0.781958486
0.176
0.828125
0.815384
6154
Ada Boost
Classifier
0.88
0.8776
376737
[0.8909
0909
0.8714
2857]
0.841390191
9
0.12
0.890510
9489
0.910447
7612
Gradient Tree
Boosting
Classifier
0.952
0.9519
230769
[0.95
0.9538
4615]
0.933822485
2
0.048
0.953846
1538
0.953846
1538
Multi-layer
0.888
0.8913
[0.9354
0.814233361
0.112
0.883333
0.929824
62
PROYECTO FIN DE GRADO
Perceptron
828689
8387
0.8412
6984]
2
3333
5614
Tabla 8: Resultado todos los valores
Finalmente es analizarán todas las características posibles, es decir, los permisos, el nombre
de paquete, las actividades, los proveedores, los servicios, los receivers, las Intents Action, las
Intent Category, las funcionalidades exportadas, la posibilidad de realizar copia de seguridad de
la aplicación, la Meta-Data, las declaraciones del uso de hardware y software del dispositivo, la
cantidad de imágenes, iconos y videos y el tamaño de la aplicación.
Los resultados de este análisis son mejores que todos los obtenidos anteriormente, el
clasificador que mejores resultados obtiene es el Gradient Tree Boosting con una tasa de 0.952
en accuracy_score y un 0.048 en brier_score_loss, lo que indica que es muy preciso y que está
muy bien calibrado. También se puede observar que el Stochastic Gradient Descent - SGD es
el clasificador con peores resultados.
Con estos datos podemos concluir que aunque no todas las características obtengan buenos
resultados, la unión de ellas conlleva unos mejores resultados, superando a los conjuntos de
características de menor tamaño y a las características analizadas por separado.
5.3 Comparativa con los diferentes Papers anteriores
En este apartado se comparan los resultados obtenidos en este proyecto fin de grado con los
resultados de papers anteriores. Para dichos resultados compararemos los datos obtenidos
recogiendo todas las características.
Primero se comparan los resultados obtenidos en el trabajo PERMISSION ANALYSIS FOR
ANDROID MALWARE DETECTION realizado por Nguyen Viet Duc, Pham Thanh Giang y
Pham Minh Vi [92].
Figura 60: Tabla resultados Paper PERMISSION ANALYSIS FOR ANDROID MALWARE
DETECTION [92]
En este proyecto se realiza un análisis estático de permisos. Como podemos observar, en este
experimento se obtienen unos resultados inferiores a los obtenidos por los clasificadores de
este PFG. No solo se obtienen peores resultados comparándolos con el conjunto de datos final
obtenido en este PFG, sino que también se obtienen peores resultados que los obtenidos
solamente con los permisos o las acciones.
63
5. Resultados
Se puede concluir que la gran diferencia en este caso no está en las características extraídas,
sino que reside en el algoritmo de análisis.
El siguiente experimento con el que se compararán los resultados de este PFG, es un análisis
realizado por seis investigadores de Deusto Borja Sanz, Igor Santos, Carlos Laorden, Xabier
Ugarte-Pedrero, Pablo Garcia Bringas y Gonzalo Álvarez en el paper PUMA: Permission Usage
to detect Malware in Android [93].
Figura 61: Tabla resultados Paper Puma, Universidad de Deusto [93]
El formato del paper es similar al formato de este PFG, es decir, se analizarán los permisos y
los clasificadores utilizados son similares a los utilizados en este PFG. Como se puede
observar, cuando de permisos solamente se trata, los resultados son similares, pero cuando se
compara el paper con los resultados obtenidos del conjunto que engloba las características
extraídas, se puede observar cierta mejora. Se puede concluir que con un mayor conjunto de
datos se obtienen mejores resultados.
Lo que se puede concluir con la comparación entre los resultados obtenidos en este PFG y los
resultados obtenidos en otros Papers es que tanto los algoritmos de análisis, como el conjunto
de datos es importante, y para obtener este conjunto de datos la metodología usada funciona.
64
PROYECTO FIN DE GRADO
Capítulo 6
Planificación, presupuesto y estructura del proyecto
6.1 Planificación
El reparto de tareas a lo largo del proyecto es la siguiente:
MAR
Actividades
10
ABR
JU
N
MAY
11 12 13 14 15 16 17
18
19 20 21
22 23
0. Gestión y
coordinación del
proyecto
Total
Experto
10
0
5
0 10
0
5
0
10
30 20 20 20 15 15 15 15
10
0
5
0
10 25
10 10
0
0
0
80
1. Desarrollo del
proyecto
2. Documentación y
memoria
2.1 Introducción,
antecedentes y
justificación
5
5
0
0
0
0
0
0
0
0
0
0
0
5
2.2 Objetivos y alcance
0
0
5
5
0
0
0
0
0
0
0
0
0
5
2.3 Metodología
0
0
0
0 10 10
5
0
0
0
0
0
0
5
2.4 Desarrollo
0
0
0
0
0
0 10 10
5
5
0
0
0
5
2.5 Planificación
5 10
5
0
0
0
0
0
0
0
0
0
0
5
2.6 Presupuesto
7 10
0
0
0
0
0
0
0
0
0
2
0
3
2.7 Conclusiones
0
0
0
0
0
0
0
0
0
0
0
2.8 Bibliografía
Total Proyecto y
Memoria
1
0
0
0
0
1
0
0
0
0
48 45 30 25 26 25 30 25
15
1
0
0
16 10
2
10 10
1
Total
Program
1 ador
11 39
347
Total
Equipo
427
Tabla 9: Reparto de horas
65
6. Planificación, presupuesto y estructura del proyecto
A continuación se describen las tareas mencionadas en el diagrama:
● Gestión y coordinación del proyecto: Tarea realizada por el coordinador del
proyecto, entre sus diferentes labores entran, el soporte al programador, la revisión de
los procesos seguidos, la verificación de los resultados y la gestión del trabajo.
●
Desarrollo del proyecto: Es el desarrollo del proyecto, enfocado en el diseño del
código y la realización de la parte práctica. Consta de la búsqueda de un dataset de
aplicaciones apropiado, la extracción de características y análisis de las mismas.
●
Documentación y memoria:
○
Introducción, antecedentes y justificación: Poner contexto al proyecto.
○
Objetivos y alcance: Establecer los límites y tareas a realizar dentro del
proyecto.
○
Metodología: Desarrollar el orden que seguirá el desarrollo.
○
Desarrollo: Explicación detallada del proceso seguido para la creación del
PFG y sus contenidos.
○
Planificación: Enfocar los pasos a seguir para una correcta ejecución del
análisis.
○
Presupuesto: Cálculo de los costes económicos.
○
Conclusiones: Analizar los resultados obtenidos.
○
Bibliografía
6.2 Presupuesto
Para la realización de este proyecto se requerirá un Jefe de Proyecto con una dedicación de 80
horas y un sueldo de 35 euros/hora y un programador junior con una dedicación de 347 horas y
un sueldo de 18 euros/hora.
Por otra parte se usará software libre, cuyo coste es gratuito, en cuanto al hardware, se calcula
que su coste será de 1000€.
El coste total del proyecto es de 10.046€ aproximadamente.
66
PROYECTO FIN DE GRADO
6.3 Estructura del proyecto
Este proyecto será realizado por un programador junior y un Jefe de Proyecto. La labor del
programador consistirá en las siguientes tareas:
●
●
●
●
●
●
Búsqueda de nuevas características distintivas de las aplicaciones Android.
Evaluación de las nuevas características.
Creación de Datasets para el análisis de las aplicaciones.
Entrenamiento y análisis de algoritmos de aprendizaje automático.
Evaluación de los resultados obtenidos de los algoritmos.
Creación de una metodología para el análisis y detección de malware en Android.
El Jefe de Proyecto guiará al programador junior a lo largo del proceso enfocando la dirección
que el proyecto seguirá y ayudando en los diferentes problemas con los que el programador
pueda encontrarse.
Para realizar dicho proceso se usará el siguiente sistema:
Procesador
AMD Ryzen 7 3800X
Memoria Ram
32GB / 30 Útiles
Disco Duro
Samsung SSD 970 EVO Plus
Tarjeta Gráfica
Nvidia GeForce RTX 2070 Super
Sistema Operativo
Kali linux 2021.2
Lenguaje de Programación
Python 3.9.5
Librería Aprendizaje Automático
Scikit-learn 0.24.2
Decompilador
ApkTool 2.5.0
Tabla 10: Datos del sistema usado
67
68
PROYECTO FIN DE GRADO
Capítulo 7
Trabajo futuro
Con este PFG se ha realizado no solo un análisis estático a través de los permisos de las
aplicaciones Android. Además se ha analizado la posibilidad de una mejora introduciendo
nuevas variables para la detección de malware. Este enfoque se ha realizado con las
aplicaciones obtenidas a través de un repositorio de código abierto con 300 aplicaciones
maliciosas y 300 benignas. El trabajo futuro incluye la introducción de otros tipos de análisis
como el análisis híbrido, otro de los posibles trabajos futuros es el análisis a través de nuevas
características como el análisis por códigos operacionales para la búsqueda de otras
vulnerabilidades de seguridad.
Otro elemento a tener en cuenta para el trabajo futuro es el análisis de más aplicaciones para
poder obtener mejores resultados y unas mejores tasas de acierto. Además de tratar de
identificar las acciones, servicios y categorías que pertenecen al malware para así reducir el
tiempo de ejecución del proceso.
69
70
PROYECTO FIN DE GRADO
Capítulo 8
Conclusiones
A través de este Proyecto de Fin de Grado se ha conseguido un nuevo enfoque al
conocimiento del análisis estático de las aplicaciones Android. Por otra parte puede servir como
soporte y guía para aquellas personas que comienzan a adentrarse en el mundo del malware
en el sistema operativo Android.
En cuanto al resultado final se puede decir que se han cumplido los objetivos propuestos al
inicio del proyecto, es decir, se han estudiado las diferentes técnicas para el análisis malware
en android, el análisis estático, dinámico e híbrido, se han buscado las características
distintivas del malware en android y se ha creado una metodología para la detección de dichas
aplicaciones.
Se ha propuesto una metodología diferente a las tradicionales, modificando CRISP-DM para
una aplicación específica para el análisis malware. Además se han analizado nuevas
características y algoritmos de aprendizaje automático, verificando su utilidad o inutilidad para
detectar malware.
Además este proyecto no solamente es un proyecto teórico sobre las diferentes características
y sus funcionalidades o los algoritmos y su funcionamiento, además se realiza un análisis
práctico de todas las características analizadas y de los diferentes algoritmos de aprendizaje
automático.
La idea principal es que sirva como base para proyectos más grandes, siendo usado como
parte de un análisis más extenso de aplicaciones Android.
8.1 Análisis de los aspectos éticos del proyecto
En este apartado se realizará un análisis de los aspectos éticos de este PFG. Se analizarán las
consecuencias, los métodos de investigación, los procedimientos de decisión y ejecución y sus
costos.
8.1.1 Consecuencias
Los resultados de este proyecto permitirán un nuevo enfoque ante el análisis malware en
Android, además ayudará a facilitar la introducción al mundo del análisis de malware en
android. Por otra parte, ayudará a facilitar la realización de nuevas investigaciones en el ámbito
android ya que con los resultados obtenidos se pueden descartar características a analizar en
futuros proyectos.
En cambio también puede tener consecuencias negativas como posibles fallas que lleven a
equivocaciones en el análisis de las características de las aplicaciones. Además informa sobre
las características más importantes en las aplicaciones Android, por lo que permiten a los
fabricantes de malware evitar que su software malicioso sea detectado.
71
8.Conclusiones
8.1.2 Métodos de investigación
La parte principal de este proyecto es la investigación, esto es el análisis de la tecnología a
investigar y las herramientas necesarias para realizar el proyecto. La fuente única ha sido
internet y en su mayoría dos sitios web, Android Developers y scikit-learn, aunque además se
han analizado papers existentes, documentos o libros publicados en formato pdf entre otros.
Esto presenta ciertas desventajas, la mayor es la dificultad para comprobar la veracidad de la
información extraída de los diferentes sitios web, aunque debido a que la mayor parte de la
información está extraída de sitios web fiables, se puede decir que la información es integra.
Dicha falta de veracidad de la información puede provocar consecuencias negativas como la
exclusión de ideas que pueden ser válidas.
En cuanto a ventajas existen la diversidad de información y la facilidad de acceso a esta, se
puede acceder rápidamente a dicha información rápidamente y está disponible en diversos
idiomas.
8.1.3 Procedimientos de decisión
Los procedimientos de decisión de este proyecto se han llevado a cabo en base al método de
prueba y error, ya que es un proyecto realizado a nivel personal y trata de encontrar nuevas
variables y nuevas metodologías de análisis de aplicaciones Android. Finalmente una vez se ha
encontrado una metodología válida, se han buscado características en base a los datos de
internet, pero sobre todo esta búsqueda se ha basado en la intuición del programador. Se
puede decir que aunque se haya realizado un proyecto en pequeña escala se han conseguido
resultados positivos aunque para verificar dichos resultados habría que aplicar la metodología y
los datos extraídos a un entorno real con software novedoso.
8.1.4 Costes
En cuanto a coste económico, debido a que es un proyecto realizado por un individuo a nivel
personal, se puede decir que su coste económico en el aspecto humano es nulo, por otra parte
todo el software usado es software libre, por lo que su coste es también nulo, finalmente, los
únicos costes económicos serían, el hardware necesario para la realización del proyecto y los
costes de electricidad e internet.
Pasando al coste temporal, se dividirá en dos apartados, el primero, el tiempo invertido por el
programador, el cual habrá realizado unas 350 horas de trabajo, por otro lado el coste del
director del proyecto será de 80 horas. Lo que en total suman unas 430 horas de trabajo, esto
lleva a pensar, en si a lo largo de esas 430 horas se podrían haber investigado otros aspectos
del sistema android para mejorar la detección de malware en android o de podrían haber
investigado otros tipos de análisis más novedosos para poder encontrar unas mejores
soluciones ante el malware.
Finalmente, se pasará a analizar el coste medioambiental de este proyecto, debido a que es un
proyecto realizado a pequeña escala, su coste no es excesivamente elevado, aunque dicho
coste se puede reducir con el uso de un sistema adaptado al proyecto, es decir, el sistema
usado es un sistema con unas características excesivas para la tarea a realizar, lo que conlleva
también un consumo eléctrico elevado.
72
PROYECTO FIN DE GRADO
Capítulo 9
Agradecimientos
Quiero agradecer a todas aquellas personas que me han apoyado a lo largo de la creación de
este PFG.
En primer lugar a mi tutor Borja Sanz Urquijo , por todo el apoyo y atención recibido a lo largo
de este Proyecto Fin de Grado, por las horas de reuniones y tutorías y a la aportación de ideas
y herramientas.
En segundo lugar, a mi familia por apoyarme a lo largo de los años de estudio y en especial
estos últimos meses.
En tercer lugar, a mis amigos por las horas de compañía a lo largo de todo el PFG, haciendo
más amena la investigación y redacción del mismo.
73
74
PROYECTO FIN DE GRADO
Bibliografía:
[1] “AV-Test”. https://www.av-test.org/en/statistics/malware/ (consultado el 16/05/2021)
[2] “statista”. https://www.statista.com/statistics/680705/global-android-malware-volume/
(consultado el 16/05/2021)
[3] “verizon”.
https://www.verizon.com/business/resources/reports/mobile-security-index/2021/cheat-sheet/
(consultado el 16/05/2021)
[4] “Android Developers”. https://developer.android.com/jetpack/guide?authuser=1 (consultado
el 16/05/2021)
[5] “Android Developers”. https://developer.android.com/guide/platform (consultado el
16/05/2021)
[6] Iordic “GitHub”.
https://iordic.github.io/android/smali/reversing/apk/coding/2018/10/08/introduccion-a-smali.html
(consultado el 21/05/2021)
[7] Jesus Freke “GitHub”. https://github.com/JesusFreke/smali/wiki (consultado el 21/05/2021)
[8] Jesus Freke “GitHub”.
https://github.com/JesusFreke/smali/blob/master/examples/HelloWorld/HelloWorld.smali
(consultado el 21/05/2021)
[9] “Python.org” https://www.python.org/ (consultado el 21/05/2021)
[10] “EthicalHacking Consultores”.
https://blog.ehcgroup.io/2020/08/20/16/25/30/9481/kali-linux-2020-3-estrena-nuevo-shell-y-nuev
a-interfaz-para-windows/kali-linux/ehacking/ (consultado el 20/05/2021)
[11] “ApkTool”. https://ibotpeaches.github.io/Apktool/ (consultado el 25/05/2021)
[12] “NumPy” https://numpy.org/ (consultado el 21/05/2021)
[13] “Pandas”. https://pandas.pydata.org/ (consultado el 25/05/2021)
[14] “SKLearn”. https://scikit-learn.org/stable/ (consultado el 25/05/2021)
[15] “Heimdal Security”. https://heimdalsecurity.com/blog/android-malware/
21/05/2021)
(consultado el
[16] “SecureList by Kaspersky”. https://securelist.com/mobile-malware-evolution-2020/101029/
(consultado el 21/05/2021)
[17] “MalwareFox”. https://www.malwarefox.com/android-app-permissions/ (consultado el
21/05/2021)
75
[18] “Tap Reason”. https://blog.tapreason.com/android-permissions-explained-e540ef90574d
(consultado el 21/05/2021)
[19] “Android Permissions”.
http://androidpermissions.com/permission/android.permission.READ_SOCIAL_STREAM
(consultado el 21/05/2021)
[20] “El Español”.
https://www.elespanol.com/elandroidelibre/noticias-y-novedades/20130607/sofisticado-androidanalizado-milimetro-caracteristicas-funcionamiento-descubierto/1000157_0.html (consultado el
21/05/2021)
[21] “Kaspersky”. https://www.kaspersky.es/resource-center/threats/trojans (consultado el
21/05/2021)
[22] “techJury”. https://techjury.net/blog/what-is-a-keylogger/ (consultado el 21/05/2021)
[23] “iavcei”. https://www.iavcei.org/12-best-android-keylogger-apps-in-2019-no-root-hidden/
(consultado el 21/05/2021)
[24] “SecureList by Kaspersky”. https://securelist.lat/ransomware-world-in-2021/93642/
(consultado el 21/05/2021)
[25] “Technology Safety”.
https://www.techsafety.org/spyware-and-stalkerware-phone-surveillance (consultado el
21/05/2021)
[26] “XatakaAndroid”.
https://www.xatakandroid.com/seguridad/nuevo-malware-android-se-hace-pasar-actualizacion-s
istema (consultado el 21/05/2021)
[27] “MalwareBytes” https://es.malwarebytes.com/adware/ (consultado el 21/05/2021)
[28] Christian Camilo Urcuqui López, Andres Navarro, “Machine learning classifiers for android
malware analysis”, 10-16, 2016
https://www.researchgate.net/publication/305649819_Machine_learning_classifiers_for_android
_malware_analysis
[29] Modupe Odusami, Olusola Oluwakemi Abayomi-Alli, Sanjay Misra, Olamilekan Shobayo,
Robertas Damasevicius, Rytis Maskeliunas, “Android Malware Detection: A Survey”, 2018
https://www.researchgate.net/publication/328495819_Android_Malware_Detection_A_Survey
[30] “Scikit Learn”. https://scikit-learn.org/stable/modules/linear_model.html (consultado el
23/05/2021)
[31] “Scikit Learn”.
https://scikit-learn.org/stable/modules/generated/sklearn.linear_model.RidgeClassifier.html
(consultado el 23/05/2021)
76
PROYECTO FIN DE GRADO
[32] “Scikit Learn”.
https://scikit-learn.org/stable/modules/generated/sklearn.linear_model.Ridge.html (consultado
el 23/05/2021)
[33] “Scikit Learn”. https://scikit-learn.org/stable/modules/linear_model.html#logistic-regression
(consultado el 23/05/2021)
[34] “Scikit Learn”. https://scikit-learn.org/stable/modules/linear_model.html#logistic-regression
(consultado el 23/05/2021)
[35] “Scikit Learn”.
https://scikit-learn.org/stable/modules/generated/sklearn.linear_model.SGDClassifier.html
(consultado el 23/05/2021)
[36] “Scikit Learn”. https://scikit-learn.org/stable/modules/sgd.html#sgd (consultado el
23/05/2021)
[37] “Scikit Learn”. https://scikit-learn.org/stable/modules/neighbors.html (consultado el
23/05/2021)
[38] “Scikit Learn”. https://scikit-learn.org/stable/modules/neighbors.html#classification
(consultado el 23/05/2021)
[39] “Scikit Learn”.
https://scikit-learn.org/stable/modules/naive_bayes.html#gaussian-naive-bayes (consultado el
23/05/2021)
[40] “Scikit Learn”. https://scikit-learn.org/stable/modules/tree.html#tree (consultado el
23/05/2021)
[41] “Datacamp”.
https://www.datacamp.com/community/tutorials/decision-tree-classification-python (consultado
el 23/05/2021)
[42] “Scikit Learn”. https://scikit-learn.org/stable/modules/ensemble.html (consultado el
25/05/2021)
[43] “Scikit Learn”.
https://scikit-learn.org/stable/modules/generated/sklearn.ensemble.AdaBoostClassifier.html
(consultado el 25/05/2021)
[44] “Scikit Learn”. https://scikit-learn.org/stable/modules/neural_networks_supervised.html
(consultado el 25/05/2021)
[45] “SNGULAR”. https://www.sngular.com/es/data-science-crisp-dm-metodologia/ (consultado
el 25/05/2021)
[46] “Wikipedia Images”.
https://es.wikipedia.org/wiki/Cross_Industry_Standard_Process_for_Data_Mining#/media/Archiv
o:CRISP-DM_Process_Diagram.png (consultado el 25/05/2021)
77
[47] “Oracle”. https://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html (consultado el
25/05/2021)
[48] “Android Developers”.
https://developer.android.com/google/play/expansion-files?authuser=1 (consultado el
25/05/2021)
[49] “We Live Security”.
https://www.welivesecurity.com/la-es/2017/01/19/metadatos-en-archivos-apk/ (consultado el
25/05/2021)
[50] “Stack Overflow”.
https://stackoverflow.com/questions/39305775/what-are-the-purposes-of-files-in-meta-inf-folderof-an-apk-file/39305776 (consultado el 25/05/2021)
[51] “Android Developers”.
https://developer.android.com/guide/topics/manifest/manifest-intro?hl=es-419 (consultado el
25/05/2021)
[52] “Android Developers”.
https://developer.android.com/guide/topics/resources/providing-resources (consultado el
25/05/2021)
[53] “Geeks for Geeks”. https://www.geeksforgeeks.org/assets-folder-in-android/ (consultado el
25/05/2021)
[54] “C# Corner”. https://www.c-sharpcorner.com/blogs/apk-and-dex-extension-in-android1
[55] “ReviverSoft”. https://www.reviversoft.com/es/file-extensions/dex (consultado el 25/05/2021)
[56] “File Extension”. https://www.file-extension.info/es/format/arsc (consultado el 25/05/2021)
[57] “Android Developers”.
https://developer.android.com/reference/android/content/pm/PackageItemInfo?hl=es-419#meta
Data (consultado el 15/06/2021)
[58] “Android Developers”. https://developer.android.com/reference/android/app/Activity
(consultado el 01/06/2021)
[59] “Android Developers”. https://developer.android.com/guide/topics/manifest/activity-element
(consultado el 01/06/2021)
[60] “Android Developers”. https://developer.android.com/reference/android/app/Service
(consultado el 01/06/2021)
[61] “Android Developers”. https://developer.android.com/guide/topics/manifest/service-element
(consultado el 01/06/2021)
78
PROYECTO FIN DE GRADO
[62] “Android Developers”.
https://developer.android.com/guide/topics/manifest/provider-element (consultado el
01/06/2021)
[63] “Android Developers”.
https://developer.android.com/reference/android/content/ContentProvider (consultado el
01/06/2021)
[64] “Android Developers”.
https://developer.android.com/reference/android/content/BroadcastReceiver (consultado el
02/06/2021)
[65] “Android Developers”.
https://developer.android.com/guide/components/broadcasts#system-broadcasts (consultado el
02/06/2021)
[66] “Android Developers”. https://developer.android.com/guide/topics/manifest/receiver-element
(consultado el 02/06/2021)
[67] “Android Developers”.
https://developer.android.com/guide/components/fundamentals#Components (consultado el
02/06/2021)
[68] “Android Developers”.
https://developer.android.com/guide/components/intents-filters?authuser=1 (consultado el
02/06/2021)
[69] “Android Developers”.
https://developer.android.com/guide/topics/manifest/intent-filter-element?authuser=1
(consultado el 15/06/2021)
[70] “Android Developers”.
https://developer.android.com/guide/topics/permissions/overview?authuser=1 (consultado el
15/06/2021)
[71] “Android Developers”.
https://developer.android.com/guide/topics/manifest/application-element?authuser=1
(consultado el 15/06/2021)
[72] “StackOverflow”.
https://stackoverflow.com/questions/38687159/what-is-metadata-and-what-is-the-use-of-it-in-an
droid#:~:text=In%20Android%2C%20you%20can%20define,and%20inside%20tag (consultado
el 15/06/2021)
[73] “Android Developers”.
https://developer.android.com/guide/topics/manifest/meta-data-element?hl=es-419 (consultado
el 15/06/2021)
79
[74] “Android Developers”.
https://developer.android.com/guide/topics/manifest/uses-feature-element (consultado el
15/06/2021)
[75] “Google Developers”.
https://developers.google.com/machine-learning/crash-course/classification/accuracy
(consultado el 09/06/2021)
[76] “Google Developers”.
https://developers.google.com/machine-learning/crash-course/glossary#accuracy (consultado el
09/06/2021)
[77] “Scikit Learn”. https://scikit-learn.org/stable/modules/model_evaluation.html#accuracy-score
(consultado el 09/06/2021)
[78] “Scikit Learn”.
https://scikit-learn.org/stable/modules/generated/sklearn.metrics.accuracy_score.html
(consultado el 10/06/2021)
[79] “Statistical Odds & Ends”.
https://statisticaloddsandends.wordpress.com/2020/01/23/what-is-balanced-accuracy/#:~:text=B
alanced%20accuracy%20is%20a%20metric,the%20presence%20of%20a%20disease.
(consultado el 10/06/2021)
[80] “Scikit Learn”.
https://scikit-learn.org/stable/modules/generated/sklearn.metrics.balanced_accuracy_score.html
(consultado el 10/06/2021)
[81] “Scikit Learn”.
https://scikit-learn.org/stable/modules/model_evaluation.html#balanced-accuracy-score
(consultado el 10/06/2021)
[82] “Scikit Learn”.
https://scikit-learn.org/stable/modules/model_evaluation.html#precision-recall-f-measure-metrics
(consultado el 11/06/2021)
[83] “Scikit Learn”.
https://scikit-learn.org/stable/modules/generated/sklearn.metrics.precision_score.html
(consultado el 11/06/2021)
[84] “Runebook”.
https://runebook.dev/es/docs/scikit_learn/modules/generated/sklearn.metrics.average_precision
_score (consultado el 11/06/2021)
[85] “Jonathan Hui”.
https://jonathan-hui.medium.com/map-mean-average-precision-for-object-detection-45c121a311
73 (consultado el 11/06/2021)
80
PROYECTO FIN DE GRADO
[86] “Scikit Learn”.
https://scikit-learn.org/stable/modules/generated/sklearn.metrics.brier_score_loss.html
(consultado el 13/06/2021)
[87] “Scikit Learn”.
https://scikit-learn.org/stable/modules/model_evaluation.html#brier-score-loss (consultado el
13/06/2021)
[88] “Scikit Learn”.
https://scikit-learn.org/stable/modules/generated/sklearn.metrics.f1_score.html (consultado el
13/06/2021)
[89] “Scikit Learn”.
https://scikit-learn.org/stable/modules/model_evaluation.html#precision-recall-f-measure-metrics
(consultado el 13/06/2021)
[90] “Scikit Learn”.
https://scikit-learn.org/stable/modules/generated/sklearn.metrics.recall_score.html (consultado
el 13/06/2021)
[91] “Scikit Learn”. https://scikit-learn.org/stable/modules/model_evaluation.html#roc-metrics
(consultado el 13/06/2021)
[92] Pham Thanh Giang, “THE PROCEEDINGS OF THE 7th VAST - AIST WORKSHOP
“RESEARCH COLLABORATION: REVIEW AND PERSPECTIVE”, 207-216, 2015
https://www.researchgate.net/publication/296704790_Permission_Analysis_for_Android_Malwar
e_Detection
[93] Borja Sanz, Igor Santos, Carlos Laorden, Xabier Ugarte-Pedrero, Pablo García Bringas,
Gonzalo Alvarez, “PUMA: Permission Usage to Detect Malware in Android”, 2013
https://www.researchgate.net/publication/256194732_PUMA_Permission_Usage_to_Detect_Ma
lware_in_Android
[94] “University of New Brunswick”.
http://205.174.165.80/CICDataset/CICAndAdGMal2017/Dataset/
[95] “University of New Brunswick”. https://www.unb.ca/cic/datasets/android-adware.html
[96] “GitHub”.
https://github.com/Saket-Upadhyay/Android-Permission-Extraction-and-Dataset-Creation-with-P
ython (consultado el 13/04/2021)
[97] “GitHub”. https://github.com/terry2012/android-a2p (consultado el 20/04/2021)
[98] “GitHub”. https://github.com/ahlashkari/AndroidAppLyzer (consultado el 15/04/2021)
81