Analisis Forense Android Whastapp

8/19/2019 Analisis Forense Android Whastapp

1/53

Grao en Enxeñaría Informática

Seguridad en Sistemas Informáticos

Curso 2013-2014

Análisis forense en dispositivosmóviles Android

Conceptos básicos

Profesor:José Manuel Vázquez Naya

Autores:

Iván Sixto López Xacobe Macía da Silva


2/53

“Es imposible que un criminal actúe,

especialmente en la tensión de la acción criminal,sin dejar rastro alguno de su presencia.”

Edmon Locard.


3/53

Índice general

1. El análisis forense digital 1

1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3. Contexto e incidentes más comunes . . . . . . . . . . . . . . . 2

1.4. Conceptos básicos . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.1. Principio de Locard . . . . . . . . . . . . . . . . . . . . 3

1.4.2. Delito informático . . . . . . . . . . . . . . . . . . . . . 4

1.4.3. Evidencia digital . . . . . . . . . . . . . . . . . . . . . 4

1.4.4. Línea de tiempo . . . . . . . . . . . . . . . . . . . . . . 4

1.4.5. Perito informático . . . . . . . . . . . . . . . . . . . . . 4

1.4.6. Metadatos . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5. Fases de un análisis forense . . . . . . . . . . . . . . . . . . . . 5

1.6. Buenas prácticas para la recogida y el análisis de datos . . . . 7

1.6.1. Estudio preliminar . . . . . . . . . . . . . . . . . . . . 8

1.6.2. Equipos afectados . . . . . . . . . . . . . . . . . . . . . 9

1.6.3. Utilización de herramientas . . . . . . . . . . . . . . . 9

1.6.4. Copia del sistema . . . . . . . . . . . . . . . . . . . . . 9

1.6.5. Otras recomendaciones . . . . . . . . . . . . . . . . . . 10

1.6.6. Guías de buenas prácticas . . . . . . . . . . . . . . . . 10

1.7. Herramientas relevantes . . . . . . . . . . . . . . . . . . . . . 11

2


4/53

Índice general 3

1.7.1. Herramientas Software . . . . . . . . . . . . . . . . . . 11

1.7.2. Herramientas Hardware . . . . . . . . . . . . . . . . . 12

2. Análisis forense en dispositivos móviles 13

2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1. Diferencias: Forense tradicional-Forense de móviles . . 14

2.2.2. Tipos de memoria en dispositivos móviles . . . . . . . . 15

2.3. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1. Herramientas Software . . . . . . . . . . . . . . . . . . 15

2.3.2. Herramientas Hardware . . . . . . . . . . . . . . . . . 18

2.4. Sistema operativo Android . . . . . . . . . . . . . . . . . . . . 19

2.4.1. Estructura del sistema operativo Android . . . . . . . . 20

2.4.2. Modos del sistema operativo Android . . . . . . . . . . 20

2.4.3. Proceso de rooteo . . . . . . . . . . . . . . . . . . . . . 24

2.4.4. Primeros pasos . . . . . . . . . . . . . . . . . . . . . . 25

2.4.5. Análisis de la memoria interna: logs e información deldispositivo . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.4.6. Análisis de la memoria interna: Shared Preferences . . 32

2.4.7. Análisis de la memoria interna: Databases . . . . . . . 34

2.4.8. Extracción de datos con AF Logical . . . . . . . . . . . 40

2.4.9. Análisis de la memoria externa . . . . . . . . . . . . . 42

3. Conclusión 43


5/53

Índice de figuras

1.1. Esquema de las fases de un análisis . . . . . . . . . . . . . . . 81.2. Guías de buenas prácticas . . . . . . . . . . . . . . . . . . . . 11

1.3. Guías de buenas prácticas ISFS . . . . . . . . . . . . . . . . . 11

2.1. Componentes dispositivo móvil . . . . . . . . . . . . . . . . . 16

2.2. Dispositivo Cellebrite . . . . . . . . . . . . . . . . . . . . . . . 19

2.3. Estructura S.O. Android por capas . . . . . . . . . . . . . . . 21

2.4. Captura estructura directorios Android . . . . . . . . . . . . . 22

2.5. Ejemplo visual modo Fastboot . . . . . . . . . . . . . . . . . . 23

2.6. Ejemplo visual modo Recovery . . . . . . . . . . . . . . . . . . 24

2.7. Comprobación de acceso root al terminal . . . . . . . . . . . . 26

2.8. Esquema patrón de desbloqueo Android . . . . . . . . . . . . 26

2.9. Proceso de lectura de gesture.key . . . . . . . . . . . . . . . . 27

2.10. Proceso de borrado de gesture.key . . . . . . . . . . . . . . . . 28

2.11. Backup completo memoria interna y externa . . . . . . . . . . 29

2.12. Cambio de formato backup a tar . . . . . . . . . . . . . . . . 30

2.13. Copia de la SD haciendo uso del comando dd . . . . . . . . . 30

2.14. Detección cambio de estado en Wifi con logcat . . . . . . . . . 31

2.15. Detección cuentas de usuario con dumpsys . . . . . . . . . . . 31

2.16. Últimas geolocalizaciones conocidas con bugreport . . . . . . . 32

4


6/53

Índice de figuras 5

2.17. Ejemplo: Localización de la última fotografía tomada . . . . . 33

2.18. Ejemplo: Obtención de números del propietario de Whatsapp . 34

2.19. Directorio data/data . . . . . . . . . . . . . . . . . . . . . . . 35

2.20. Bases de datos de Facebook . . . . . . . . . . . . . . . . . . . 36

2.21. Tablas de la BD contacts_db2.db . . . . . . . . . . . . . . . . 37

2.22. Columnas de la tabla contacts de la BD contacts_db2.db . . . 37

2.23. Bases de Datos del navegador . . . . . . . . . . . . . . . . . . 38

2.24. Tablas de la BD webviewCookiesChromium . . . . . . . . . . . 39

2.25. Columnas de la tabla cookies de la BD webviewCookiesChro-mium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.26. Nautilus AF Logical . . . . . . . . . . . . . . . . . . . . . . . 40

2.27. Exportar datos con AF Logical . . . . . . . . . . . . . . . . . 41

2.28. Pull de datos a equipo externo . . . . . . . . . . . . . . . . . . 41

2.29. Comprobación de datos exportados con AFLogical . . . . . . . 42


7/53

Resumen

En este trabajo se abordarán aspectos generales del análisis forense, para conmayor detalle, proceder a la aplicación de dichos conceptos al mundo de losdispositivos móviles o smartphones.

Actualmente, en el mercado predominan dos Sistemas Operativos en pla-taformas móviles: Android e iOS. Por este motivo la división fundamental deltrabajo estará condicionada a este planteamiento, profundizando principal-mente en aquellos apartados relacionados con el Sistema Operativo Android,debido a la limitación de material disponible para la realización del trabajo.

Finalmente, se presentarán ejemplos prácticos basados en situaciones realesdentro del Análisis Forense en dispositivos móviles para ayudar al lector acomprender todos los aspectos teóricos expuestos a lo largo de este trabajo.


8/53

Capítulo 1

El análisis forense digital

1.1. Introducción

En la actualidad, nadie duda de que gran parte de nuestra actividad diariadescansa en la utilización de una gran cantidad de dispositivos informáticosy electrónicos. En la vida cotidiana utilizamos habitualmente ordenadorespersonales, móviles, tablets, gps o cámaras digitales, por poner ejemplos.

Todos estos dispositivos, como es lógico, registran cantidades ingentes deinformación; no sólo la que gestionamos personalmente, si no también muchaotra de la que no somos conscientes y que tiene que ver con su funcionamientointerno. Toda esa información es susceptible de ser analizada por terceros,para la reconstrucción y prueba de ciertos hechos bajo los cuales habría sidogenerada.

Por todo esto, se da la necesidad de disponer de una serie de protocolos omecanismos que permitan la recogida y análisis de los datos para un posterioranálisis y justificación de las acciones realizadas. Estas serán las bases bajo lasque se moverá en Análisis Forense. A continuación se abordarán los conceptos

básicos y necesarios para comprensión y desarrollo del trabajo.La organización de un equipo de respuesta a incidentes requiere esta-

blecer, entre otras muchas cosas, una serie de procedimientos y métodos deanálisis que nos permita identificar, recuperar, reconstruir y analizar todasy cada una de las evidencias de lo ocurrido. La ciencia encargada de cubrirestas necesidades es la Ciencia Forense o el Análisis Forense, encargado deaportar las técnicas, conocimientos y principios necesarios para realizar unainvestigación, criminal o no.

1


9/53

1.2. Definición 2

1.2. Definición

Se puede definir formalmente el Análisis Forense Digital como el procesode estudio exhaustivo de un sistema del que se desea conocer su historia. Secompone de un conjunto de principios y técnicas que comprende el procesode adquisición, conservación, documentación, análisis y presentación de evi-dencias digitales. Por lo general, esto se aplica sobre sistemas de los que setiene sospecha o certeza de que ha sido víctima de intrusión, ataque u origende acción maliciosa.

1.3. Contexto e incidentes más comunes

Aunque el ámbito de desarrollo del análisis forense es sumamente amplio,existen ciertos casos que en los que la aplicación de sus técnicas resulta in-dispensable. Se incluyen aquí referencias al código penal aplicable sobre cadauna de ellas por si se desea profundizar en su conocimiento.

Ataques contra el derecho a la intimidad: Delito de descubri-miento y revelación de secretos mediante el apoderamiento y difusión

de datos reservados registrados en ficheros o soportes informáticos queafecten a la vida privada. (Artículos del 197 al 201 del Código Penal).

Infracciones a la propiedad intelectual: Delito de descubrimientoy revelación de secretos mediante el apoderamiento y difusión de datosreservados registrados en ficheros o soportes informáticos afecten a lapropiedad. (Artículos del 197 al 201 del Código Penal).

Accesos no autorizados: Se produce cuando un usuario no permi-tido consigue autenticarse o introducirse en un sistema al que no tieneacceso. Se incluyen aquí todas las incidencias relacionadas con el robo

de cuentas, secuestro de sesiones o elevación de privilegios (Artículo197.3 del Código Penal).

Código malicioso: Dentro de este grupo se encuentran los ataquesrealizados mediante virus, troyanos, gusanos, rootkits u otro tipo demalware (Artículo 267.2 del Código Penal).

Interrupción del servicio: Abarca todos aquellos incidentes rela-cionados con la interrupción o saturacción de un servicio determinado.


10/53

1.4. Conceptos básicos 3

Claros ejemplos dentro de este grupo son los ataques DoS o DDoS

(Artículo 264.2 del Código Penal).

Falsificaciones: Extensión de la falsificación de moneda a las tarjetasde débito y crédito. Fabricación o tenencia de programas de ordenadorpara la comisión de delitos de falsedad. (Artículos 386 y ss. del CódigoPenal).

Pornografía infantil: Probablemente uno de los campos en los que laaplicación del análisis forense está más arraigada actualmente. Induc-ción, promoción, posesión, producción, venta o distribución de materialpornográfico (Artículo 189 del Código Penal).

1.4. Conceptos básicos

Es importante, antes de abordar el núcleo del trabajo, tener claros ciertosconceptos del ámbito de la seguridad informática y el análisis forense parapartir de una base que ayude a comprender la temática de este trabajo.

1.4.1. Principio de Locard

Se le atribuye a Edmon Locard, criminalista francés pionero en su campoen torno a finales del siglo XIX y principios del XX la autoría de una serie demetodologías que, aplicadas a una serie de pruebas permitían la consideraciónde las mismas como evidencias irrefutables ante un juez.

Es conocido por sus famosas frases, destacando entre ellas el conocidocomo “principio de Locard”:

“Siempre que dos objetos entran en contacto transfieren parte del material que incorporan al otro objeto” .

Este principio puede extrapolarse al ámbito del análisis forense digital yaque, aunque no se produce un intercambio físico entre dispositivos electróni-cos, si se transfieren rastros lógicos entre los mismos (entradas de registro,formato de ficheros característicos de otro sistema, metadatos, etc).


11/53

1.4. Conceptos básicos 4

1.4.2. Delito informático

Partiendo siempre desde el punto de vista de la legislación española, sedefine como delito informático a aquel hecho tipificado como delictivo en elcódigo penal, siempre y cuando se hayan empleado técnicas o mecanismos detipo informático para su cometido.

1.4.3. Evidencia digital

Se entiende como evidencia cualquier información contrastable encontra-

da en un sistema. En cuanto a evidencia digital sería considerada cualquierinformación electrónica que pueda aportar algún dato de interés en un aná-lisis forense posterior.

1.4.4. Línea de tiempo

Se trata de un concepto que ayuda al investigador y juez al entendimiendosobre la evolución de los hechos mediante la exclusión de ambigüedades en lasdistintas afirmaciones realizadas por el propio perito informático. Constade una sucesión de momentos indicados por algún tipo de indicio (comopueden ser entradas en archivos de registro) a partir de ficheros logs y fechashalladas en metadatos de archivos.

Se trata de un proceso meramente manual, aunque existen ciertas herra-mientas que facilitan la extracción de dichos datos.

1.4.5. Perito informático

Es un perito informático aquel perito judicial que en su carácter de au-

xiliar de la justicia, tiene como tarea el asesoramiento a un juez contemas relacionados con la informática. El perito debe estar familiarizadocon técnicas de análisis y recuperación de datos. Además, es vital que cuentecon amplios conocimientos legales que le permitan gestionar evidencias sindescalificación de las mismas por mala manipulación.


12/53

1.5. Fases de un análisis forense 5

1.4.6. Metadatos

Comunmente definidos como datos sobre los datos. De forma másdetallada se podrían entender como información no relevante para el usuariofinal, pero sí de suma importancia para el sistema que maneja los datos. Losmetadatos permanecen actualizados para facilitar su localización.

1.5. Fases de un análisis forense

Las fases de un análisis forense, se pueden dividir en dos grandes grupos,las relativas a la escena y las que se llevan a cabo en el laboratorio forense.

Escena

1. Asegurar la escena: Consiste en proteger la escena para evitarla modificación o destrucción de las evidencias digitales.

2. Identificar evidencias: Consiste en identificar todos los siste-mas de información y seleccionar aquellos que puedan contener

información relevante. Es muy importante tener en cuenta que nose trabaja con el soporte original de la información, si no siemprecon una copia para no alterar lo mas mínimo cualquier tipo deevidencia. Es indispensable también, asegurarse de que ningunode los soportes fue o será modificado, mendiante el uso de funcio-nes hash1.

3. Recogida de evidencias: Es una de las etapas más importantesy será la que permita determinar el método de entrada al sistema,la actividad de los intrusos, su identidad o origen, etc, y todo ello

teniendo una precaución extrema para evitar alterar las evidenciasdurante el proceso de recolección.

Dentro de esta etapa, se debe decidir si el comienzo de la reco-lección se realizará con el sistema encendido o apagado, siempre

1Se llaman funciones hash criptográficas a aquellas funciones hash que se utilizan en elárea de la criptografía. Este tipo de funciones se caracterizan por cumplir propiedades quelas hacen idóneas para su uso en sistemas que confían en la criptografía para dotarse deseguridad. Estas propiedades las hacen resistentes frente ataques maliciosos que intentanromper esa seguridad.


13/53

1.5. Fases de un análisis forense 6

teniendo en cuenta los diferentes niveles de volatilidad de la

información que existe en el sistema (Memoria RAM, caché, cone-xiones activas, usuarios, procesos actuales, sistemas de archivos,etc). Mucha de esta información será muy complicada de conseguiruna vez apagado el equipo.

En lo comentado anteriormente, se pueden presentar dos tipos desituaciones: aquellas en la que es posible mantener el equipo/sencendido y aquellas en las que el equipo tiene que ser apagadopara evitar graves consecuencias en caso de un posible ataque (conla perdida de información volátil que el apagado conlleva).

Como es habitual en el análisis forense, dentro de la recolección

de evidencias digitales, existen una serie de pasos a seguir para lacorrecta obtención de las mismas, cuyo orden viene definido porla volatilidad de los datos. De forma genérica y resumida los pasosson:

• Registros y contenidos de la caché .

• Contenidos de la memoria .

• Estado de las conexiones de red, tablas de rutas .

• Estado de los procesos en ejecución .

• Contenido del sistema de archivos de los discos duros .

• Contenido de otros dispositivos de almacenamiento.

Otros datos útiles dentro de la recoleción de evidencias puedenser la fecha y la hora del sistema, los procesos activos, los puertosTCP/UDP abiertos con sus respectivas aplicaciones a la escuchaasí como también los usuarios conectados local y remotamente.

Durante este proceso, es indispensable tener precaución y contarcon un buen entrenamiento, para así, ser capaz de recopilar todala información empleando el menor número de comandos posible,para hacer que la labor del perito informático[1.4.5] pase desaper-cibida.

Laboratorio Forense

1. Preservar evidencias: Consiste en aplicar el tratamiento ade-cuado que permita garantizar la cadena de custodia2. Para ello,

2En la cadena de custodia se establecen las responsabilidades y controles de cada unade las personas que manejan la evidencia.


14/53

1.6. Buenas prácticas para la recogida y el análisis de datos 7

es imprescindible definir métodos adecuados para el almacena-

miento y etiquetado de las evidencias.Será necesaria la realización de dos copias de seguridad, rea-lizando posteriormente una suma de comprobación de integridadmediante MD5 o, preferiblemente SHA-1. El motivo de estas co-pias no es otro que el de trabajar sobre una de ellas, sin riesgode corrupción de la evidencia original. En caso de corrupción deuna, se seguirá disponiendo de otra copia para realizar un nuevoduplicado con su correspondiente prueba de integridad.

2. Analizar evidencias: El análisis de evidencias es la tarea máslaboriosa. Con dichos datos, se construirá en esta etapa la línea detiempo (o timeline [1.4.4]) de los hechos siguiendo una metodolo-gía forense especializada y empleando las herramientas necesariaspara cada caso.De forma posterior al timeline, se debe proceder a la búsqueda deinformación mediante palabras clave.Finalmente, es necesario crear perfiles sobre los usuarios delequipo, así como de los distintos contactos con la finalidad de es-tablecer relaciones dentro los distintos perfiles.

3. Presentar resultados: Esta etapa incluye la elaboración de do-cumentación mediante informes que ilustren los hechos de formaclara y concisa, siendo presentados respetando los formatos ade-cuados al tipo de informe requerido en cada caso. Cabe destacarque esta fase requiere de una documentación exhaustiva y paralelaal resto de pasos anteriores.

1.6. Buenas prácticas para la recogida y el aná-lisis de datos

Se resumirán aquí una serie de principios, consideraciones y recomenda-ciones que todo analista forense debe conocer y tener en consideración paraejercer correctamente su actividad.

Toda investigación debe ser rigurosa, y más en esta disciplina, en la cualel trabajo riguroso es indispensable desde el principio. La primera de las


15/53


Figura 1.1: Esquema de las fases de un análisis

bases del análisis forense es como no, conocer la arquitectura sobre la cual seva trabajar. Sin el conocimiento pleno del sistema a analizar, la recogida deevidencias se convertirá en un arduo y complicado trabajo.

La necesidad de contar con evidencias válidas se convierte en una de lasprincipales preocupaciones. Surge por tanto, la necesidad de definir cuáles se

considerarían válidas: Todas aquellas correctamente recogidas.La elección de una u otra herramienta será transcendental dentro de la

investigación, e incluso en el caso de que no exista la apropiada, será necesariocrearla, lo que hace vital, una vez más, el conocimiento de la arquitecturasobre la que se trabaja.

1.6.1. Estudio preliminar

El primero de los pasos en un análisis forense, es la explicación, de la

forma más exacta posible, de qué ha ocurrido para el análisis forense hayasido lanzado, cuál fue la acción que lo desencadenó, cómo se detectó, cuándoocurrió y todos aquellos detalles que se puedan conseguir.

Es indispensable contar también con información de la organización, en-tidad, equipo o persona afectada que va ser objeto de análisis, para así poderrealizar una explicación más detallada de las evidencias encontradas.

La topología de la red, la gente relacionada directa e indirectamente, eltipo de escenario, el sistema o sistemas afectados también serán de vital


16/53


importancia dentro de la primera recolección de información.

1.6.2. Equipos afectados

Como ya se comentó en el apartado de Recolección de Información [3],resulta determinante la decisión de apagar o no el sistema a analizar.

En el caso de optar por no apagar el sistema, una recomendación funda-mental es mitigar el riesgo de seguridad, para evitar que el sistema sea o sigasiendo un objetivo de ataque, o bien, aislar completamente el equipo de lared (esto no es posible en determinados escenarios).

1.6.3. Utilización de herramientas

Aunque se comentó brevemente en apartados anteriores, otra de las con-sideraciones en un escenario de análisis es no alterar lo más mínimo la infor-mación, algo prácticamente imposible, ya que el uso de cualquier herramientaalterará la memoria del sistema.

Por todo esto, las herramientas usadas deberán ser mínimamente intru-sivas. Por norma general, se deberá tratar en lo posible, de no abusar deherramientas con interfaz gráfica (emplean más memoria) y de emplear he-rramientas que no requieran instalación (escriben información en el registrodel sistema).

Como norma habitual se suelen emplear aplicaciones externas almace-nadas en algún soporte externo y nunca se deberán utilizar herramientaspropias del sistema analizado, pues no se conoce de antemano si existe unaposible manipulación.

1.6.4. Copia del sistema

Se deberá realizar siempre más de una copia de seguridad del sistema, ya ser posible, dichas copias deberán ser firmadas digitalmente para verificarsu integridad.

Una recomendación fundamental es que las copias de seguridad realizadasqueden bajo custodia de algún responsable de la compañía o equipo afectadopara que el cliente pueda pedir una segunda opinión, y una de ellas deberáser guardada herméticamente para aislarla del exterior.


17/53


Deberá existir también una tercera copia, para que los responsables del

análisis forense puedan trabajar sobre ella.

Como es lógico, todas las copias deberán ser lo mas exactas posibles yfieles al sistema que se está copiando.

1.6.5. Otras recomendaciones

Es fundamental que en los primeros trabajos forenses que se realicen, queel analista lleve una lista de comprobaciones, escrita con estricta rigurosidad,para que el proceso vaya pasando por todas las etapas y procesos descritos

en este trabajo.

Aunque es muy importante realizar un análisis forense como un procesoguíado, siempre cabe la posibilidad de que haya errores, si bien, pese a te-ner claros los conocimientos teóricos, se trata de una disciplina marcadaindiscutiblemente por la experiencia.

1.6.6. Guías de buenas prácticas

Como es lógico, todo lo comentado en este apartado son unos brevesconsejos para llevar a cabo un análisis forense, y evidentemente, existen unaserie de guías estandarizadas que recogen las prácticas y buenas pautas aseguir en un análisis.

A continuación se citan brevemente algunas de ellas con propósito mera-mente informativo:

RFC 3227: Los artículos RFC o “Request for Comments” son docu-mentos públicos sometidos al debate de la comunidad, para estandarizarprocesos. El correspondiente al análisis forense es el RFC 3227, que tra-

ta aspectos como: Principios para la recolección de evidencias, orden devolatilidad, acciones que deben ser evitadas, consideraciones relativasa la privacidad de los datos, consideraciones legales, procedimientos derecolección, técnicas y herramientas transparentes, recoleción en fun-ción de la volatilidad, etc.

Guía de la IOCE: “Guidelines for the Best Practices in the ForensicsExamination of Digital Technology”. (Web: http://www.enfsi.eu/uploads/files/ENFSI_Forensic_IT_Best_Practice_GUIDE_5%5B1%5D.

0.pdf).

http://www.enfsi.eu/uploads/files/ENFSI_Forensic_IT_Best_Practice_GUIDE_5%5B1%5D.0.pdfhttp://www.enfsi.eu/uploads/files/ENFSI_Forensic_IT_Best_Practice_GUIDE_5%5B1%5D.0.pdfhttp://www.enfsi.eu/uploads/files/ENFSI_Forensic_IT_Best_Practice_GUIDE_5%5B1%5D.0.pdfhttp://www.enfsi.eu/uploads/files/ENFSI_Forensic_IT_Best_Practice_GUIDE_5%5B1%5D.0.pdfhttp://www.enfsi.eu/uploads/files/ENFSI_Forensic_IT_Best_Practice_GUIDE_5%5B1%5D.0.pdfhttp://www.enfsi.eu/uploads/files/ENFSI_Forensic_IT_Best_Practice_GUIDE_5%5B1%5D.0.pdf


18/53

1.7. Herramientas relevantes 11

Figura 1.2: Guías de buenas prácticas

Guía DoJ1: “Electronic Crime Scene Investigation: A Guide for FirstResponders” (Web: http://nij.gov/nij/pubs-sum/219941.htm).

Guía DoJ2: “Forensic Examination of Digital Evidence: A Guide forLaw Enforcement” (Web: https://www.ncjrs.gov/pdffiles1/nij/199408.pdf).

Guía de la ISFS (Honk-Kong): “Computer Forensics – Part2: BestPractices” (Web: http://www.isfs.org.hk/publications/ISFS_ComputerForensics_part2_20090806.pdf).

Figura 1.3: Guía ISFS de Honk-Kong

1.7. Herramientas relevantes

A continuación se presentará una serie de herramientas destinadas a fa-cilitar la extracción de datos, así como el análisis de documentos y el estudiode sus metadatos. Se citarán algunas de las más relevantes.

1.7.1. Herramientas Software

1. Forensic FOCA: Se trata de una herramienta española desarrolladapor la empresa Informática 64 enfocada en la utilización de los metada-tos, la cual permite ser empleada en análisis forenses. Trata ficheros con

http://nij.gov/nij/pubs-sum/219941.htmhttps://www.ncjrs.gov/pdffiles1/nij/199408.pdfhttps://www.ncjrs.gov/pdffiles1/nij/199408.pdfhttp://www.isfs.org.hk/publications/ISFS_ComputerForensics_part2_20090806.pdfhttp://www.isfs.org.hk/publications/ISFS_ComputerForensics_part2_20090806.pdfhttp://www.isfs.org.hk/publications/ISFS_ComputerForensics_part2_20090806.pdfhttp://www.isfs.org.hk/publications/ISFS_ComputerForensics_part2_20090806.pdfhttps://www.ncjrs.gov/pdffiles1/nij/199408.pdfhttps://www.ncjrs.gov/pdffiles1/nij/199408.pdfhttp://nij.gov/nij/pubs-sum/219941.htm


19/53

1.7. Herramientas relevantes 12

los formatos más conocidos (pdf, docx, JPG, etc). Posee dos funcionali-

dades principales: visualización de documentos y visualización median-te timeline [1.4.4]. Permite, además, la exportación de los resultados aformatos XML. (Más información: http://www.informatica64.com/forensicfoca/).

2. Digital Forensics Framework: Se trata de una herramienta de aná-lisis forense de sistema de archivos, de arquitectura modular. Al estardividida en módulos esta herramienta permite realizar varias tareas ala vez y así agilizar el análisis forense. Permite la recuperación de ar-

chivos borrados, análisis del sistema de archivos de teléfonos móviles,descifra contenido y metadatos de SMS y posee una serie de editoresque facilitan las tareas al perito informático[1.4.5]. (Más información:http://www.digital-forensic.org/).

1.7.2. Herramientas Hardware

1. Jaula de Faraday: Caja metálica que aisla al dispositivo situado enel interior del campo electromagnético existente en el exterior. Es decir,aisla al dispositivo de posibles comunicaciones que alterasen sus datos.

Se basa en las propiedades de un conductor en equilibrio electroestático.

2. Laboratorio forense portable: Se trata de una serie de dispositivoscontenidos en maletín que incluyen herramientas para el duplicado dediscos, cámara e incluso impresora.

http://www.informatica64.com/forensicfoca/http://www.informatica64.com/forensicfoca/http://www.digital-forensic.org/http://www.digital-forensic.org/http://www.informatica64.com/forensicfoca/http://www.informatica64.com/forensicfoca/


20/53

Capítulo 2

Análisis forense en dispositivos

móviles

2.1. Introducción

Resulta interesante comprobar cómo a lo largo de los últimos años, losdispositivos móviles han experimentado una evolución que los acerca al pc

convencional. Este hecho fue provocado en gran parte al progresivo abarata-miento de los mismos, provocando así que en la actualidad, cualquier personapueda disponer de un dispositivo móvil.

En la actualidad, los dispositivos móviles predominantes por excelenciason los conocidos smartphones y tablet digitales, que suelen contar con panta-llas de gran tamaño, cámara de fotos y vídeo, GPS y posibilidad de conexióna todos los tipos de redes (GSM, WCDMA, WiFi, Bluetooth, etc). Además,por todos es sabido que la mayoría de los dispositivos permiten a los usua-rios la instalación de ciertas aplicaciones, así como el almacenamiento deinformación personal, y lo que es más importante, información confidencial.

Del mismo modo que los ordenadores convencionales fueron avanzandohasta una “estadarización” en tres sistemas operativos (Unix, Windows yMAC), en estos momentos, la electrónica móvil parece estar entrando en uncontexto similar encabezado por las dos plataformas más evolucionadas en elmarco de la telefonía móvil: Android e iOS. Ambas funcionan con hardwarediferente, aunque las funcionalidades son comunes en su mayoría.

13


21/53

2.2. Contexto 14

2.2. Contexto

Un Iphone o un terminal Android, en lo referente a un análisis forense, noson como los antiguos teléfonos móviles en los cuales el investigador forensepodía rescatar únicamente los datos de la SIM, las últimas llamadas, loscontactos, algunos SMS y poco más. El ir ampliando paulatinamente lasposibles tareas a realizar en un dispositivo móvil provocó que el arte dedesmenuzar su contenido forense, se conviertiese poco a poco en un árduotrabajo.

Debido a la ya comentada facilidad de adquirir un dispositivo móvil, ya

extorsión telefónica se ha incrementado. Cada vez que una persona mal in-tencionada tenga acceso a un dispositivo que no le pertenezca, puede utilizaresta información con fines poco éticos. Como es lógico, cada vez son máscomunes las labores de análisis forense de estos dispositivos. Por ejemplo,prácticamente en cualquier operación policial con incautación de los teléfo-nos móviles de los sospechosos, se realiza un análisis de los mismos, aunquedependiendo de la necesidad, se hará en mayor o menor profundidad.

2.2.1. Diferencias: Forense tradicional-Forense de móvi-

les

Es vital tener claras algunas de las diferencias que separan en análisisforense en dispositivos móviles y en ordenadores tradicionales con el obje-to de saber dónde se puede tocar y dónde no. A continuación se citan lasprincipales:

Arquitectura diferente[2.2.2]

Diversidad en los modelos y tecnologías de los dispositivos.

Diseño de aplicaciones específicas para tecnología e inclusodeterminados tipos de terminales.

Software de análisis forense y hardware específico para dispo-sitivos móviles.

La mayoría de software forense es de pago.


22/53

2.3. Herramientas 15

2.2.2. Tipos de memoria en dispositivos móviles

A pesar de la amplia variedad de modelos existentes en el mercado, todosellos emplean una serie de memorias para el almacenamiento de datos quesiguen la siguiente estructura[2.1]:

1. Memoria RAM o principal: Volátil, sirve de apoyo a procesos paraalmacenamiento temporal de datos.

2. MTP o NAND: Se trata de la memoria ROM o interna no volátil delpropio dispositivo.

3. Almacenamiento externo: Se trata de almacenamiento no volátilextraíble. Normalmente se guardan datos de usuario.

2.3. Herramientas

En esta sección se comentarán brevemente las herramientas más conocidasdentro del mundo del análisis forense de dispositivos móviles, centrando la

atención fundamentalmente en herramientas dedicadas a Android OS, porser el núcleo de este trabajo.

2.3.1. Herramientas Software

ADB

Android Debug Bridge es una herramienta de línea de comandos que per-mite la comunicación con un emulador o un dispositivo Android conectado.Normalmente incluído en el SDK de Android (orientado al desarrollo de apli-caciones para este sistema), se trata de un programa cliente-servidor con lossiguientes componentes:

1. Cliente: Que se ejecuta en la máquina de desarrollo o, en su defecto,el computador empleado por el perito informático.

2. Servidor: Se trata de un proceso en segundo plano que se ejecuta endicha computadora. Se encarga de gestionar la comunicación entre elcliente y el demonio adb.


23/53


Figura 2.1: Componentes dispositivo móvil


24/53


3. Demonio: Se ejecuta en segundo plano en cada uno de los dispositivos

conectados (o emuladores).

Fastboot

Herramienta con los protocolos necesarios para hacer uso del modo Fast-boot (se explicará más adelante con detalle).

ClockWorkmod Recovery

Uno de los Recovery [2.4.2] modificados más destacados de la comunidad.Compatible con la mayor parte de dispositivos del mercado (aunque requierela descarga en particular del .img específico para cada modelo).

Santoku

Santoku es una distribución Linux basada en OWASP’s MobiSec 1 espe-cializada en pruebas de seguridad, análisis de malware y análisis forenses parateléfonos móviles, válida para dispositivos con Android, BlackBerry, iOS y

Windows Phone.La versión Santoku Community Edition es un proyecto colaborativo para

proveer un entorno Linux preconfigurado con utilidades, drivers y guías paraeste campo. (Más información: https://santoku-linux.com/).

AFLogical

Se trata de un programa gratuíto para el análisis forense de dispositivosAndroid y desarrollado por viaForensics . Este programa se encarga de realizar

una extracción lógica de datos comunes como SMS y contactos, ofreciendouna exportación en formatos csv legibles para el perito informático. (Másinformación en: https://viaforensics.com).

1Se trata de un proyecto centralizado que tiene como objetivo principal el dar a losdesarrolladores y equipos especializados en seguridad una fuente de trabajo común paraayudar a construir y mantener aplicaciones móviles seguras.

https://santoku-linux.com/https://viaforensics.com/https://viaforensics.com/https://santoku-linux.com/


25/53


XRY Logical

Se trata de un software comercial y de pago para arquitecturas Windows.Se trata de uno de los programas más empleados por las grandes compañiaspara el análisis forense de dispositivos móviles, ya que presenta una interfazintuitiva y amigable al mismo tiempo por ser compatible con la mayoría deteléfonos del mercado. Cuenta con un amplio soporte y se complementa conuna serie de herramientas hardware distribuidas por la misma compañia, lascuales se comentarán brevemente en la siguiente sección. (Más informaciónen: http://www.msab.com/).

Oxygen Forensics

Al igual que el anterior, se trata también de un software comercial depago con una interfaz de usuario para hacer el análisis forense más sencillo.Permite también complementar el software con un equipo hardware. (Másinformación en: http://www.oxygen-forensic.com/).

2.3.2. Herramientas Hardware

Dentro de esta sección se describirán brevemente los complementos hard-ware que incluyen algunas de las suits software descritas en la sección ante-rior, por ser estas las más conocidas.

XRY Physical and Complete

Se compone del paquete software XRY Logical y una serie de herramientashardware. Presenta como ventaja que las herramientas hardware permitenproteger más la información del análisis y permiten recuperar información

de dispositivos bloqueados. Incluye un maletín con herramientas y un kitde cables, así como lectores de tarjetas SIM y SD. En función del paqueteseleccionado (XRY Physical o XRY Complete ) se incluyen unas herramientasu otras. (Más información en: http://www.msab.com/).

Oxygen Forensics Kit

Una vez más, al igual que su análogo, incluye el software Oxygen Forensics y herramientas hardware, con posibilidad de configurar el kit. (Más informa-

http://www.msab.com/http://www.oxygen-forensic.com/http://www.msab.com/http://www.msab.com/http://www.oxygen-forensic.com/http://www.msab.com/


26/53

2.4. Sistema operativo Android 19

ción: http://www.oxygen-forensic.com/en/order/oxygen-forensic-kit).

Cellebrite

Se trata de una empresa que destaca por la fabricación de equipos hard-ware para el análisis forense de dispositivos móviles (también dispone deherramientas software). Dispone desde lectores hasta clonadores de memoriainterna y externa. El inconveniente fundamental reside en el elevado pre-cio de sus dispositivos, partiendo de unos 20.000 euros en sus modelos másbásicos. Actualmente en España sólo exite un dispositivo de este tipo, que

pertenece al ejército. (Más información en: http://www.cellebrite.com/es/mobile-forensics).

Figura 2.2: Dispositivo Cellebrite

2.4. Sistema operativo Android

El conocimiento del sistema operativo a estudiar por parte del peritoinformático es vital, ya que será necesario saber qué buscar y dónde. Pararesponder a estas preguntas son necesarias unas nociones básicas sobre laestructuración del sistema Android, recordando al lector que no es el fococentral del trabajo y por ello se explicarán brevemente.

http://www.oxygen-forensic.com/en/order/oxygen-forensic-kithttp://www.cellebrite.com/es/mobile-forensicshttp://www.cellebrite.com/es/mobile-forensicshttp://www.cellebrite.com/es/mobile-forensicshttp://www.cellebrite.com/es/mobile-forensicshttp://www.oxygen-forensic.com/en/order/oxygen-forensic-kit


27/53


A pesar de tratarse de un sistema operativo joven, actualmente se encuen-

tra ampliamente extendido en el mercado de los smartphones y tablets. Laempresa que comenzó su desarrollo fué adquirida por Google en el año 2005y desde su presentación oficial en el año 2008 se han publicado numerosasversiones, siendo hasta la fecha la versión KitKat (4.4) la más reciente.

Parte del éxito de este sistema desde el punto de vista de los desarrolla-dores se debe al soporte de tecnologías extendidas como pueden ser XML yJava, así como la abstracción del hardware gracias a la estructura en capasobservable en la Figura 2.3, quedando a decisión del lector la indagación decada una de ellas.

2.4.1. Estructura del sistema operativo Android

En cuanto a la estructuración de directorios empleados por el sistema sedestacan los siguientes:

1. Carpeta data: Alberga información y datos sobre las aplicaciones desistema (data ) y usuario (data/data ).

2. Carpeta storage: En esta carpeta encontramos referencias a losdistintos tipos de almacenamiento que tenemos en nuestro dispositivo.Por ejemplo, en dispositivos sin opción de memoria externa (tarjetaminisd) la memoria interna es accesible mediante storage/sdcard0 .

3. Carpeta mnt: Puntos de montaje sobre el almacenamiento, destacan-do sdcard referenciado por storage/sdcard0 .

4. Carpeta etc: En su interior se encuentran ficheros de configuraciónde servicios y aplicaciones del sistema.

2.4.2. Modos del sistema operativo Android

En Android destacan, principalmente, los siguientes modos de funciona-miento:

Modo Fastboot

Se trata de un protocolo utilizado en los terminales Android para ope-raciones básicas relacionadas con la instalación de ROM, kernels, recoveries,


28/53


Figura 2.3: Estructura Android por capas

etc... La forma de acceso en cada terminal es única, normalmente consis-tiendo en la pulsación de una secuencia determinada de teclas o medianteADB.

Se carga antes de la ejecución del sistema operativo y, además

de las herramientas de gestión, casi siempre aporta datos interesantes decara al perito informático: nombre del producto, versión hardware, númerode serie, versión de banda base y de fastboot (también llamado bootloader).

Modo Recovery

Se trata de otro modo de ejecución especial que proporciona herramientaspara el mantenimiento del sistema. Puede entenderse como un “modo seguro”que no permite la ejecución de procesos de usuario pero sí carga ciertos tiposde drivers o controladores. Cabe destacar que de forma nativa el recovery

apenas sirve para instalar actualizaciones firmadas y originales. Para aprove-char todo su potencial es recomendable instalar o hacer uso de un recoverymodificado. Entre las características completas que suele aportar un recoverymodificado se encuentran:

1. Backup o respaldo de información.

2. Restore o restauración de dicha información.


29/53


Figura 2.4: Captura estructura directorios Android

3. Wipe o limpieza de particiones de memorias (Dalvik, system, data,cache... )


30/53


Figura 2.5: Ejemplo visual modo Fastboot

4. Montaje de particiones.

5. Instalación o actualización del sistema o algún componente del mis-mo) mediante ficheros .zip.

6. Formateo de la memoria.

Modo Depuración y Root

La ejecución del sistema con opción de depuración permite la comunica-ción con adb y la de root con privilegios de superusuario. Para su activaciónbasta iniciar un modo recovery o bien acceder en Android a opciones dedesarrollo y activar las opciones oportunas.


31/53


Figura 2.6: Ejemplo visual modo Recovery

2.4.3. Proceso de rooteo

Para usuarios habituales de UNIX, la idea les resultará sencilla. No cabeolvidar que la base de Android es Linux, por lo que los conocimientos básicosde dicho sistema son aplicables al sistema de Google. ¿En qué consiste pues?En obtener acceso de superadministrador o root , pudiendo así modificar fi-cheros del sistema.

El proceso de rooteo varía dependiendo del dispositivo y, puesto que noes objeto central de estudio, no se indagará en la técnica y sólo se dará unesquema de lo que podría hacer el perito informático siempre bajo la premisade evitar modificar los datos de usuario y los de sistema lo menos posible.Así pues, se puede proceder de forma aproximada a:

1. Acceder a modo Fastboot[2.3.1].

2. Cargar un recovery en memoria, evitando así escribir en la par-tición del sistema. Con esto tendremos el modo depuración necesario


32/53


para gestionar vía ADB[2.3.1]

3. Carga de script que se encargue de obtener acceso root.

2.4.4. Primeros pasos

Al igual que un análisis forense convencional, en el análisis forense deun dispositivo Android, se deben seguir unos pasos para que la extracciónde datos sea satisfactoria. En los puntos sucesivos se describen brevementealguna de estas fases:

Aislado

Es el primero y uno de los pasos más importantes en el caso de encontrarseante un caso judicial (p.ej. una incautación). Consiste en aislar el terminal to-talmente de la red, es decir cortar la comunicación del terminal con cualquiertipo de red.

Lo ideal para estos casos es una Jaula de Faraday, es decir un habitáculoespecial que aisla el terminal de cualquier campo electromagnético. Esto serealiza para preservar el terminal en el mismo estado en el cual se entrega.

Como es lógico, lo ideal sería poner el terminal en modo avión, pero esto,en algunos casos es imposible en el momento de la entrega, por tener patrón ocódigo de desbloqueo (En posteriores apartados de este trabajo se verá comopoder acceder a terminales con esta restricción, pero ya en el laboratorioforense).

En caso de no disponer de una Jaula de Faraday o no poder poner elmodo avión, un método alternativo podría ser aislar el terminal con papel dealuminio o equivalente.

Saltar el patrón o código de bloqueo

Comunmente los dispositivos cuentan con algún tipo de bloqueo que pro-tege el acceso instantaneo al dispositivo, para poder proteger de forma sencillalos datos. Aunque estos bloqueos pueden suponer una pequeña barrera en elanálisis forense, se pueden conseguir de forma sencilla para un profesionaldel sector.


33/53


Esta técnica de salto del patrón de desbloqueo, requiere de acceso root

al terminal, por lo que en caso de ser necesario, el perito informático o lapersona a cargo del análisis, debe realizar los pasos necesarios para obtenerdicho acceso [2.4.3] (Este proceso será omitido en este trabajo por no formarparte explícita del análisis). En la Figura 2.7 se muestra cómo comprobar siel dispositivo permite el acceso privilegiado, haciendo uso de la herramientaadb[2.3.1] incluída en el SDK de Android.

Figura 2.7: Comprobación de acceso root al terminalUna vez conseguida la escalada de privilegios en el terminal, se puede

proceder al proceso de eliminación del patrón de desbloqueo.

Para comenzar, es importante conocer el modo en el que Android alma-cena los datos relativos al patrón. Básicamente, el patrón es una secuenciade números obtenida a partir del esquema que se puede ver en la Figura 2.8

Figura 2.8: Esquema patrón de desbloqueo Android

Basándose en el esquema de la Figura 2.8 anterior es fácil deducir la formaen la que se calcula el patrón. En este caso se obtiene la secuencia 1-2-5-8-7-4.Esta secuencia se almacena en un fichero llamado gesture.key , que Androidalmacena bajo el directorio /data/system/gesture.key . Este fichero contiene


34/53


la secuencia anteriormente generada en formato codificado hexadecimal, es

decir, un hash o resumen de la secuencia calculado mediante el algoritmoSHA-1 2.

Se puede visualizar el contenido del fichero gesture.key ayudándose de laherramienta adb[2.3.1] de Android y de un editor hexadecimal, como puedeser hexdump. Este proceso se ejemplifica en la Figura 2.9.

Figura 2.9: Proceso de lectura de gesture.key

La secuencia obtenida en la Figura 2.9 es el resumen SHA-1 generadoa partir del patrón de desbloqueo, lo que significa que será necesaria suextracción para obtener la secuencia del patrón en texto plano.

Una vez obtenida esa secuencia, se debe intentar buscar un texto (se-cuencia de puntos en este caso) tal que fh(x)=hash, siendo este hash el valorextraído del fichero gesture.key . Obtener todas las posibles secuencias y suhash sería muy costoso en tiempo (ya que se necesita generar todas las com-binaciones posibles de x y aplicarles fh(x). Por tanto, se puede pre-calcular

fh(x) para una función dada (en este caso SHA-1) y almacenar el resultadoen tablas de consulta denominadas Raindow Tables3, ofreciendo un com-promiso entre tiempo y espacio. Dicho esto, la labor de obtener el patrón seconvierte únicamente en conseguir una base de datos con Rainbow table delos posibles hashes (existen muchas en la red) y realizar una consulta SQL

2Es una funcion hash criptográfica relacionada de la Agencia de Seguridad Nacionalde los Estados Unidos y publicada por el National Institute of Standards and Technology(NIST).

3Se trata de una explicación muy sencilla y aproximada de la rainbow table.


35/53


por el valor del hash obtenido del fichero gesture.key .

Para el ejemplo realizado en este trabajo se usó sqlite como gestor debases de datos y se realizó la siguiente consulta:

SELECT * FROM RainbowTable WHERE hash = “6698337718b194a6d1e7812ece0007d051ad5c5f”;(Siendo RainbowTable la tabla que contiene los hashes).

Obteniendo como resultado:

6698337718b194a6d1e7812ece0007d051ad5c5f = [1-2-5-8-7-4]

Otro método más sencillo y que permite ahorrar los pasos anteriores seríaborrar directamente el fichero gesture.key , aunque en el caso de que el análisisforense forme parte de un proceso judicial, no sería una opción a tener encuenta, pues el proceso de borrado altera el sistema de ficheros y por tanto,invalidaría totalmente el análisis como pruebas. Además, el conocer el patrón(o pin) puede aportar información adicional ya que el usuario puede haberloutilizado en más dispositivos.

Se presenta este método en la Figura 2.10 a modo de ejemplo.

Figura 2.10: Proceso de borrado de gesture.key

Si el dispositivo presenta código o pin de bloqueo en lugar de patrón,ambos procesos son completamente análogos, a excepción del fichero, queserá password.key , en lugar de gesture.key .


36/53


Copia de la memoria interna

La copia de la memoria interna debe contemplar un respaldo o backupde las aplicaciones, datos de aplicaciones, preferencias compartidas y apli-caciones del propio sistema. Para hacerlo, lo ideal sería realizar una copiabit a bit de dicha memoria con cualquier dispositivo hardware compatibleexistente en el mercado[2.3.2] y de forma separada a la memoria externa.Debido a la carencia de medios a la hora de realizar el trabajo, se ha optadopor una alternativa que busca evitar en la medida de lo posible la alteraciónde los datos haciendo uso de ADB [2.3.1].

Como se indica en la figura 2.11 se han indicado las opciones necesariaspara la copia de lo citado anteriormente. Cabe destacar, además, que se herealizado un backup tanto de la memoria interna como de la SD, aunque sele recuerda al lector que lo recomendable es hacerlo de forma separada (taly como se explica en el siguiente punto).

Esta opción solamente será válida para dispositivos Android 4.X o su-periores. En el caso de disponer de versión anterior, será necesario realizarel backup dentro del propio dispositivo haciendo uso de la herramienta pro-porcionada por el Recovery [2.4.2]. Posteriormente volcar el fichero al equipoinformático empleado por el perito. Este respaldo de datos será más completo

incluso que el anterior, pero con el defecto de estar escribiendo en el propiodispositivo, alterando ya la evidencia.

Figura 2.11: Backup completo memoria interna y externa

Una vez se dispone del fichero de backup en una carpeta especificadapor el perito forense, para poder examinar sus datos se debe convertir dicho

fichero a formato tar como se indica en la figura [2.12] y descomprimirloposteriormente.

Quedarán dos carpetas: apps (con las aplicaciones y sus datos) y share(con los datos públicos de la memoria o sdcard).


37/53


Figura 2.12: Cambio de formato backup a tar

Copia de la memoria externa

Si se ha realizado el paso anterior ya se incluye copia de los datos de lamemoria externa. No obstante, si se desea realizar una nueva copia de formaseparada puede ser de interés para el lector aplicar el comando de Unix dd

para realizar el clonado bit a bit tal como se muestra en la imagen [ 2.13]

Figura 2.13: Copia de la SD haciendo uso del comando dd

2.4.5. Análisis de la memoria interna: logs e información

del dispositivo

Es vital considerar que los distintos datos obtenidos en este punto nopueden ser tomados como completamente fiables, ya que el dispositivo puedeencontrarse deliberadamente comprometido, generando falsos datos. El maluso de algunos de los comandos propios del sistema podría romper la cadenade custodia. Así pues, deberá caer en valoración del perito si le merece lapena ejecutar ciertas utilidades en función del tipo de información (técnicasde chip-off para extracción de memorias, volcados de memoria RAM, etc... )

En este punto, se tratará la obtención con el sistema en “vivo” de datos

que pueden resultar de importancia clara para el analista forense.

Logcat

Se trata de una utilidad contenida en el propio ADB [2.3.1], que permite elvolcado de eventos generados por el sistema. Android dispone de cuatro buf-fers para la recogida de dichos eventos: main, system, events y radio situadosen /dev/log.


38/53


39/53


información con las herramientas comentadas en los puntos anteriores, se

interpreta en la Figura 2.16 como obtener las últimas posiciones conocidaspor los distintos elementos de localización (gps o red móvil) así como lasaplicaciones que solicitaron el acceso.

Figura 2.16: Últimas geolocalizaciones conocidas con bugreport

2.4.6. Análisis de la memoria interna: Shared Preferen-

ces

Se entiende por shared preferences aquellos archivos que albergan en for-mato primitivo (XML4) datos relacionados con la configuración de las

aplicaciones instaladas en el dispositivo. Su localización habitual es bajo eldirectorio data/data/paquetedeaplicacion/shared_prefs.

Estos archivos, contienen pequeñas cantidades de información, pero quepueden llegar a ser representativas en un análisis forense. Un claro ejemplo

4XML, siglas en inglés de eXtensible Markup Language (“lenguaje de marcas extensi-ble”), es un lenguaje de marcas desarrollado por el World Wide Web Consortium (W3C)utilizado para almacenar datos en forma legible para un ser humano, y fácilmente proce-sable por un ordenador.

http://localhost/var/www/apps/conversion/tmp/scratch_7/data/data/paquetedeaplicacion/shared_prefshttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/data/paquetedeaplicacion/shared_prefs


40/53


de esto, es la posibilidad de obtener las coordenadas geográficas del lugar en

el fue tomada la última fotografía tomada por el dispositivo.

Ejemplo: Camera Shared Preferences

En la Figura 2.17, se ejemplifica la obtención de dichas coordenadas. Paraello simplemente es necesario acceder al directorio data/data/com.google.android.apps.maps/shared_prefs, abrir el fichero camera.xml y buscar lostags lat y lng que se corresponden con latitud y longitud, respectivamente(Todo ello ayudándose del comando grep5 para facilitar las búsquedas).

Figura 2.17: Ejemplo: Localización de la última fotografía tomada

5Grep es un comando Unix que permite el filtrado de texto por contenido.

http://localhost/var/www/apps/conversion/tmp/scratch_7/data/data/com.google.android.apps.maps%20/shared_prefshttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/data/com.google.android.apps.maps%20/shared_prefshttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/data/com.google.android.apps.maps%20/shared_prefshttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/data/com.google.android.apps.maps%20/shared_prefs


41/53


Ejemplo: WhatsApp Shared Preferences

En el siguiente ejemplo, reflejado en la Figura 2.18, se muestra comoobtener la lista de números que han instalado Whatsapp en el dispositivo, asícomo el número actual. Para ello, simplemente es necesario repetir el procesoanterior, pero en este caso, los datos se alojarán en el fichero data/data/com.whatsapp/shared_prefs/RegisterPhone.xml

Figura 2.18: Ejemplo: Obtención de números del propietario/s que han re-gistrado Whatsapp en el dispositivo

Además de los ejemplos comentados en esta sección, bajo el directoriodata/data, se encontrará una carpeta por cada aplicación instalada en eldispositivo, tal y como se ejemplifica en la Figura 2.19. Es posible obtener,por ejemplo, los contactos o la cuenta de usuario de Facebook, Twitter oInstagram del usuario poseedor del dispositivo.

2.4.7. Análisis de la memoria interna: Databases

Dentro de la memoria interna de estos dispositivos, se ecuentra una delas mayores fuentes de información, las bases de datos del dispositivo y delas aplicaciones. Como bien es sabido, las Bases de Datos o Databases sonun conjunto de datos pertenecientes a un mismo contexto y almacenadossistemáticamente para su posterior uso, en las cuales se aloja informaciónde todo tipo, desde configuraciones hasta contactos, o incluso informaciónsensible.

El análisis de las Bases de Datos puede llegar a ser una de las tareasmás arduas y complicadas dentro de la etapa de análisis. Es muy importante

http://localhost/var/www/apps/conversion/tmp/scratch_7/data/data/com.whatsapp/shared_prefs/RegisterPhone.xmlhttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/data/com.whatsapp/shared_prefs/RegisterPhone.xmlhttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/datahttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/datahttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/datahttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/data/com.whatsapp/shared_prefs/RegisterPhone.xmlhttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/data/com.whatsapp/shared_prefs/RegisterPhone.xml


42/53


Figura 2.19: Directorio data/data

realizar una búsqueda por objetivos, es decir, se debe centrar la atención

exclusivamente en aquellas que se consideren relevantes en función del casoforense. Es muy importante realizar preclasificación o prefiltrado antes de suposterior análisis, ya que una exploración de todas y cada una de ellas seríaprácticamente inviable en la práctica.

A modo de ejemplificar la exploración de estas fuentes de información, sellevarán a cabo un par de ejemplos básicos de algunas de las bases de datosde las aplicaciones más comunes hoy en día.

Como es lógico, la extracción de datos de las Databases se realizaráen el backup del dispositivo previamente realizado y nunca conectado por

ADB [2.3.1], ya que cualquier error en la ejecución de algún comando o o enla forma de obtener la información podría alterar el dispositivo e invalidar,el análisis forense.

Las herramientas necesarias serán el propio backup y como no, un sistemade gestión de bases de datos relacional. Para no entrar en grandes compli-caciones, el gestor empleado para los ejemplos es un SQLite por linea decomandos (Puede resultar más cómodo en algunos casos, la instalación de unvisor gráfico).


43/53


Ejemplo: Facebook Databases

En el primero de los ejemplos que se mostrarán a continuación, se proce-derá a analizar alguna de las Bases de Datos de la conocida aplicación de Fa-cebook y que un alto porcentaje de usuarios tienen instalada en sus dispositi-vos. Accediendo al directorio data/data/com.facebook.katana/databasesse pueden ver aquellas BD de las que Facebook hace uso (Ver Figura 2.20).Se analizará por ejemplo, la contacts_db2.db.

Figura 2.20: Bases de datos de Facebook

El primero de los pasos, es cargar la base de datos en el gestor de SQLite ,para ello es necesario situarse en el directorio en el que se encuentra la basede datos y ejecutar:

sqlite contacts_db2.db

Una vez cargada la base de datos, se puede ver las tablas disponibles con

el siguiente comando SQLite :

.tables (Ver Figura 2.21)

Dentro de la lista de tablas de la Figura 2.21, se puede observar comopor su nombre, es fácilmente deducible su contenido. Continuando con elejemplo, se mostrará la información de la tabla contacts (Ver Figura 2.22),la cual contiene el ID de usuario de Facebook dentro de la aplicación (Co-lumna internal_id ), y el ID externo real de Facebook (Columna contact_id )

http://localhost/var/www/apps/conversion/tmp/scratch_7/data/data/com.facebook.katana/databaseshttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/data/com.facebook.katana/databases


44/53


Figura 2.21: Tablas de la BD contacts_db2.db

además de una serie de datos (Columna data ) como puede ser, la URL ala imagen de perfil de cada uno de los contactos del usuario (Las columnasque contiene una tabla se pueden obtener a través del comando PRAGMAtable_info(nombredelatabla ).

Se puede ver la información de la tabla con una sencilla sentencia SQL(En este trabajo no se mostrará la información de esta tabla por contenerinformación sensible del propietario del dispositivo):

SELECT * FROM contacts;

Figura 2.22: Columnas de la tabla contacts de la BD contacts_db2.db

Ejemplo: Browser Databases

En el segundo de los ejemplos, se analizarán las bases de datos del navega-dor por defecto de Android. Una vez más, se encuentran en el directorio data/data, concretamente en data/data/com.android.browser/databases, y cons-ta de las BD que se pueden ver en la Figura 2.23.

http://localhost/var/www/apps/conversion/tmp/scratch_7/data/datahttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/datahttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/data/com.android.browser/databaseshttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/data/com.android.browser/databaseshttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/datahttp://localhost/var/www/apps/conversion/tmp/scratch_7/data/data


45/53


Figura 2.23: Bases de Datos del navegador

Observando detenidamente sus nombres, se deduce, por ejemplo que den-tro de la BD webviewCookiesChromium.db se podrán encontrar las cookiesde navegación, en webviewCookiesChromiumPrivate.db6 las cookies pertene-cientes a el uso del navegador en modo incógnito (navegación privada) o bienel historial de páginas web visitadas en browser2.db.

Para este ejemplo práctico, se empleará la base de datos webviewCookies-Chromium.db, que se cargará haciendo uso una vez más del gestor SQLite :

sqlite webviewCookiesChromium.db

Cargada la base de datos, se comprobará qué tablas contiene:

.tables

Mostrando como resultado dos tablas: cookies y meta (Ver Figura 2.24).

Para ver las columnas que almacena la tabla cookies :

PRAGMA table_info(cookies) (Ver Figura 2.25).

Aplicando otra vez un razonamiento deductivo sobre las columnas:

host_key : Almacenará la clave que identifica el host al cual pertenecela cookie.

6Esta base de datos se borra en el momento que el usuario cierra el navegador, peroen un caso forense, puede ser de utilidad si el usuario tenía el navegador abierto en elmomento de la incautación.


46/53


Figura 2.24: Tablas de la BD webviewCookiesChromium

Figura 2.25: Columnas de la tabla cookies de la BD webviewCookiesChro-

mium

name: Nombre del host al que pertenece la cookie.

value: Valor de la cookie.

path : Directorio dentro del host.

expire_utc : Fecha y hora de expiración de la cookie.

secure: Es un campo que indicará si soporta el protocolo HTTPS.

httponly : Indica si el host sólo soporta HTTP.

last_acces_utc: Fecha y hora del último acceso empleando dichacookie.

Una consulta intesante en esta tabla podría ser por ejemplo:

SELECT name, value, expire_utc FROM cookies;


47/53


Obteniendo de esta forma las cookies, el nombre del host al que pertenecen

y la fecha de caducidad de la misma.

Esto posibilita por ejemplo, haciendo uso de alguna herramienta, iniciarsesión en muchos de los servicios de internet del usuario del dispositivo móvil.

Lógicamente los ejemplos mostrados en este apartado son puramente di-dácticos y tienen como único objetivo mostrar al lector un ejemplo prácticode cómo y qué tipo de información se podría obtener dentro del soporte dealmacenamiento del dispositivo móvil.

2.4.8. Extracción de datos con AF Logical

AFLogical [2.3.1] ofrece una alternativa más sencilla y visual al análisisde ciertas bases de datos de aplicaciones. Permite una extracción sin teneracceso de superadministrador a SMS, contactos, MMS, registros de llamadase información sobre aplicaciones instaladas.

Se trata de una aplicación intrusiva, ya que requiere la instalación de unaaplicación en el dispositivo Android. Ésta creará unos ficheros en formatoCSV y XML legibles para el analista forense. Además, está incluído un toolkiten la distribución Santoku que facilita la tarea [2.3.1].

El primer paso es conectar el dispositivo en cuestión en modo depura-ción[2.4.2]. Posteriormente dirigirse al menú del sistema y abrir el ejecutabletal como se indica en la Figura 2.26. Teclear como indica aflogical-ose parainstalar la aplicación en el dispositivo y comenzar el proceso.

Figura 2.26: Nautilus AF Logical

El siguiente paso (Figura 2.27) será atender al dispositivo, marcar losdatos que se desea exportar y esperar a que acabe. Una vez finalizado pulsar


48/53


ENTER como se indica en la Figura 2.28 para volcar dichos datos al equipo

del perito.

Figura 2.27: Exportar datos con AF Logical

Tras esto, comprobar en la carpeta de destino (cd $HOME/aflogical-data/) que se encuentra el backup de datos. La persona encargada ya puedeproceder a su análisis.

2.4.9. Análisis de la memoria externa

La memoria externa junto con la memoria interna, conforma el subsistema

de memoria de un terminal móvil, es decir, es otro de los soportes físicosde memoria no volátil. A grosso modo, se puede decir que se almacenanaquí todos los archivos multimedia (fotos, videos, música, etc) y copias deseguridad de las aplicaciones.

Por norma general, las copias de seguridad que las aplicaciones realizan yalmacenan en memoria externa, suelen estar cifradas. Caso por ejemplo, delas bases de datos de Whatsapp, que son prácticamente idénticas a las que sepueden encontrar en la memoria interna, pero aquí se encontrarán cifradas


49/53


Figura 2.28: Pull de datos a equipo externo

Figura 2.29: Comprobación de datos exportados con AFLogical

(actualmente no es un impedimento extraer igualmente su contenido, perono es objeto de este trabajo).

Es por todo esto que el estudio y análisis de la memoria externa se puedellevar a cabo con las herramientas forenses de metadatos habituales, en buscade documentos, imágenes, videos o cualquier otro contenido similar paraanalizar todos y cada uno de los archivos encontrados.


50/53

Capítulo 3

Conclusión

Aunque en la gran mayoría de este trabajo se ha dado prioridad al sistemaoperativo Android, por ser uno de los dos sistemas que con el tiempo hanterminado por imponerse, no está solo. Habría sido muy interesante tambiéntratar la investigación forense de dispositivos basados en iOS, Blackberry,Windows Mobile o Windows Phone (Sistemas que, según los expertos, ofrecencaracterísticas de seguridad empresarial mucho más sólidas que Android oiOS, aunque no hayan tenido éxito a la hora de seducir al consumidor). Este

trabajo, por desgracia no puede extenderse a tanto ya que todo ello constituyemateria de libros especializados (Se mencionan algunos en la biografía parael que tenga interés en ampliar la materia) y sería inabordable.

Por otra parte, tras la realización de este documento, se pueden sacarciertas conclusiones en lo referente a las diferencias con un análisis forenseconvencional que hacen incluso que se puedan considerar dos disciplinas muydistintas.

Mientras que en la adquisición y el análisis de ordenadores o soportes dedatos (Memorias USB, CD’s, DVD’s) se ajusta a procedimientos estándar

reconocidos por la comunidad de investigadores y la Administración de Jus-ticia, con los dispositivos móviles no ocurre lo mismo. Es decir, y a modo deejemplo, el comando dd para la copia de un disco duro ofrece plenas garan-tías de que la prueba no ha sido alterada (de cara a la justicia) y que cumplecon todos los requerimientos de integridad y mantenimiento de la cadena decustodia, por lo que en un jucio la parte contraria tendrá poco que decir.

No ocurre lo mismo en el caso de que la prueba principal consista enun dispositivo móvil, ya que no existen esos estándares y procedimientos,además de que muchas de las prácticas de análisis forense de este campo

43


51/53

44

son claramente intrusivas. Defender esto delante de un tribunal y frente a

un abogado con experiencia en tecnologías puede llegar a ser complicado.Es más, en muchas ocasiones, el mero hecho de tocar el dispositivo mientrasestá funcionando (en el momento de la recogida de evidencias), activar mo-do avión, eliminar el patrón de desbloqueo, ya implica modificaciones en elaparato. Es por tanto, muy complicado interactuar con un dispositivo móvilsin verse obligado en cada momento a tomar decisiones que pueden terminarafectando a la cadena de custodia. En otras palabras, resulta prácticamenteimposible, examinar un terminal móvil sin que este acuse el impacto de lapropia actividad del análisis forense.

La informática forense desde hace más de doce años que funciona bajo procedimientos establecidos, validados y reconocidos por las autoridades judiciales de todos los paises, es por ello por lo que ya no es lo que era ni vol-verá a serlo. La tecnología móvil, el cloud o la nube pueden hacer que todo loaprendido hasta la fecha quede obsoleto en unos pocos años, o incluso meses.Por lo tanto, está claro que no sólo serán necesarios unos cuantos conoci-mientos sobre los sistemas de archivos o sobre un software de recuperación.No es tan sencillo. La Informática Forense del futuró necesitará gente conperspicacia y con sentido común, entusiasta de lo que hace, bien entrenaday sobre todo alguien con talento para encontrar una aguja en un pajar, unverdadero investigador. Si ya lo dijo Claude Shannon hace más de 50 años,

“la mayor parte de la energía no se emplea en escribir los datos, si no para borrarlos” .


52/53

Bibliografía

[1] Garrido Caballero, Juan. Análisis Forense Digital en Entornos Win-

dows . Alonso, Chema (col.), G.Rambla, Juan Luis (col). 3a Edición. Ma-drid: Informática 64, 2012. 238p. ISBN:978-84-616-0392-3. Web:.

[2] Lázaro Domínguez, Francisco. Introducción a la Informática Forense . 1aEdición. Madrid. RA-MA Editorial 2013. 337p. ISBN:978-84-9964-209-3.Web:.

[3] Montero Miguel, Roberto. Desarrollo de aplicaciones para Android . 1aEdición. Madrid. RA-MA Editorial 2012. 343p. ISBN:978-84-9964-201-7.Web:.

[4] García Rambla, Juan Luis. Un forense llevado a jucio. Flu-ProyectWeb:.

[5] Becerril Sierra, Israel. El análisis forense en dispositivos móviles y su futuro riesgo. Revista Digital Universitaria. Volumen 9, Número4, Abril 2008. ISSN:1067-6079. Web:.

[6] García Pol, David. Análisis forense y prueba de concepto de dispositivos móviles con sistema operativo iOS . Proyecto final de carrera. A Coruña,

2012. 73p.

[7] Hoog, Andrew Android Forensics . 1a Edición. Syngress Editorial 2011.432p. ISBN:978-1597496513.

[8] Hoog, Andrew. Strzempka, K. Iphone and iOS Forensics. Investigation,Analysis and Mobile Security for Apple iPhone, iPad and iOS Devices .1a Edición. Syngress Editorial 2011. 336p. ISBN: 978-1597496599.

45

http://www.informatica64.com/http://www.informatica64.com/http://www.ra-ma.com/http://www.ra-ma.com/http://www.flu-project.com/http://www.revista.unam.mx/vol.9/num4/art26/art26.pdfhttp://www.revista.unam.mx/vol.9/num4/art26/art26.pdfhttp://www.revista.unam.mx/vol.9/num4/art26/art26.pdfhttp://www.revista.unam.mx/vol.9/num4/art26/art26.pdfhttp://www.flu-project.com/http://www.ra-ma.com/http://www.ra-ma.com/http://www.informatica64.com/http://www.informatica64.com/


53/53

Bibliografía 46

[9] Lessard, Jeff. C.Kessler, Gary. Android Forensics: Simplifying Cell Pho-

ne Examinations . Small scale digital device forensics journal. Vol 4. Nú-mero 1. Septiembre 2010. ISSN: 1941-6164. Web: http://www.ssddfj.org/papers/SSDDFJ_V4_1_Lessard_Kessler.pdf
http://www.ssddfj.org/papers/SSDDFJ_V4_1_Lessard_Kessler.pdfhttp://www.ssddfj.org/papers/SSDDFJ_V4_1_Lessard_Kessler.pdfhttp://www.ssddfj.org/papers/SSDDFJ_V4_1_Lessard_Kessler.pdfhttp://www.ssddfj.org/papers/SSDDFJ_V4_1_Lessard_Kessler.pdf

Analisis Forense Android Whastapp

Documents

Transcript of Analisis Forense Android Whastapp