iOS – Rastreando los Bundle IDs de Contenedores, Contenedores Compartidos, y Funcionalidades Añadidas (“Plugins”)

Artículo original escrito por Christopher Vance (@cScottVance). Traducción al español por Geraldine Blay (@i_am_the_gia).

En el sistema operativo iOS, una de las cosas más irritantes que he encontrado cuando trabajo con data o cuando ayudo a un estudiante es el intentar rastrear que aplicación es responsable de colocar data en cierto lugar en específico. Gracias al gran trabajo realizado por otros, incluyendo Alexis Brignoni (enlace aquí),ApplicationState.db (como parte del directorio de FrontBoard) siempre ha sido uno de los primeros lugares que frecuento cuando construyo un “mapa del tesoro” de las aplicaciones. Esta base de datos nos ayuda a poder lidiar con los AppGUIDs fastidiosos que Apple le asigna a cada app.  

Estos AppGUIDs molestosos de los que estoy hablando se pueden encontrar en: 

/private/var/mobile/Containers/Data/Application

Afortunadamente, la mayoría de las herramientas procesan ApplicationState.db y relacionan cada uno de los identificadores únicos (AppGUIDs) con sus respectivas aplicaciones. 

¡Grandioso! Esta es una manera mucho más sencilla de identificar donde “viven” cada una de esas aplicaciones. Sin embargo, a veces encuentras un archivo de interés dentro de un directorio y necesitas hallar una correspondencia entre el directorio y esta base de datos. Quizás te encuentras en una situación en la que solo tienes la imagen y acceso muy limitado a herramientas. ¿Cómo podemos encontrar el bundleID de la aplicación dentro del directorio?

Dentro del directorio de la aplicación debe de haber un archivo llamado ".com.apple.mobile_container_manager.metadata.plist" (este nombre parece ser el mismo dentro del directorio de cada aplicación). Este archivo de tipo plist contiene claves con el bundleID de la aplicación, lo que es fenomenal si te encuentras en apuro y no quieres saltar de una localización a otra. 

Lo más interesante es lo que ocurre cuando realizas una búsqueda con el nombre de este archivo a lo largo de la imagen del dispositivo iOS. Si haces esto, notarás que hay archivos nombrados .com.apple.mobile_container_manager.metadata.plist en muchos lugares, incluyendo: 

·                /private/var/containers/Bundle/Application/APPGUID/

·                /private/var/containers/Shared/SystemGroup/APPGUID/

·                /private/var/containers/Data/System/APPGUID/

·                /private/var/mobile/Containers/Shared/AppGroup/APPGUID/

·                /private/var/mobile/Containers/Data/Application/APPGUID [¡obviamente!]

·                /private/var/mobile/Containers/Data/InternalDaemon/APPGUID/

·                /private/var/mobile/Containers/Data/PluginKitPlugin/APPGUID/

¡Caramba! Esos son muchos lugares que tenemos que explorar para poder realizar nuestro mapa del tesoro. A fin de cuentas, ¿qué es este archivo? Primero, vamos a hablar de “sandboxing” (o aislamiento de procesos y aplicaciones). Apple utiliza “sandboxing” mucho en el sistema operativo iOS. Esto es para prevenir que las aplicaciones tengan acceso a data que no se supone que accedan por motivos de seguridad. Se le otorga a cada aplicación un “sandbox” y solo pueden jugar en ella. .com.apple.mobile_container_manager.metadata.plist nos permite ver que en que “sandbox” nos encontramos y a qué aplicación le pertenece ese “sandbox”. Utilizando esta información, podemos desglosar un poco más la localización del directorio que habíamos identificado para poder entender por qué ciertas aplicaciones guardan la data en ciertos lugares. 

/private/var/containers/Bundle/Application/

Este es el directorio que contiene el .app, así como información adicional sobre la aplicación, y quién la descargó. Además del .app, el directorio contiene dos plists (iTunesMetadata y BundleMetadata) que guardan información que pudiera ser útil, como cuándo se descargó la aplicación, qué versión de la aplicación se descargó, y cuál AppleID se utilizó para descargarla. 

 

 

/private/var/containers/Shared/SystemGroup/

 

Este directorio es similar al que listamos arriba, pero aplica a las aplicaciones principales del dispositivo iOS. Este directorio contiene menos información, pero también contiene un archivo .plist que muestra qué aplicación del sistema corresponde a este contenedor.  

 

/private/var/containers/Data/System/

 

Este directorio también es similar al directorio discutido arriba, pero parece contener aplicaciones del sistema que no quieren compartir información con otras aplicaciones principales. No contiene información de mucha relevancia, con excepción del bundleID que indica qué aplicación es dueña del contenedor. 

 

/private/var/mobile/Containers/Shared/AppGroup/

 

Aquí es donde en realidad comienza la diversión. Anteriormente mencioné el “sandboxing”. Apple indica que a las aplicaciones no se les permite compartir información sin pedirla a través de canales oficiales. Para poder compartir información, los desarrolladores de las aplicaciones asignan un “grupo” a su aplicación. De acuerdo con la documentación para desarrolladores publicada por Apple, estos grupos pueden compartir data entre ellos. Puede ser que hayas visto algo similar listado como “AppDomainGroup-group.bundleID” en vez de “AppDomain-com.bundle.ID” al analizar una imagen estilo “backup”. Con frecuencia he utilizado este directorio cuando no puedo encontrar la data que estoy buscando en el directorio principal de Application Data.  

 

Ahora hablemos de la desventaja… El ApplicationState.db no contiene información sobre la localización de este directorio. ¿La ventaja? El directorio “Shared/AppGroup” de cada aplicación va a contener uno de nuestros archivos .com.apple.mobile_container_manager.metadata.plist. ¡Woohoo! 

 

Mejor aún, Alexis Brignoni ha añadido soporte en iLEAPP para crear una lista de todos los archivos de este directorio. Esto nos permite establecer una relación entre el contenido del archivo y la localización del directorio correspondiente. [Descarga iLEAPP aquí]

 

Una aplicación también puede tener más de un directorio en esta localización. Por ejemplo, la aplicación de Dropbox tiene más de 4 contenedores distintos aquí, y la aplicación de correo electrónico de Spark tiene 2. Más importante aún, algunas aplicaciones pueden almacenar toda su data relevante aquí en vez de en /private/var/mobile/Containers/Application/Data/. Un ejemplo de esto es la aplicación de Spark (enlace de iTunes en la red), la cual almacena todas sus bases de datos relevantes en /private/var/mobile/Containers/Shared/AppGroup/en vez de en /private/var/mobile/Containers/Application/Data/, que por lo general es una estructura de directorio mas común. [Otros ejemplos notables de esto incluyen WhatsApp y Signal]

 

 

/private/var/mobile/Containers/Application/Data

 

Este es el lugar donde “se supone” que miremos para encontrar data de las aplicaciones. Este directorio esta bien documentado y estudiado dentro del campo de la informática forense. Sin embargo, puede ser que no sea aquí donde encontremos lo que necesitamos, a fin de cuentas. 

 

/private/var/mobile/Containers/Application/InternalDaemon

 

En mis dispositivos de prueba, este directorio parece contener servicios de Apple (o internal “daemons”, obviamente, como indica el nombre) que pueden ser rastreados utilizando los archivos .com.apple.mobile_container_manager_metadata.plist. 

 

/private/var/mobile/Containers/Application/PluginKitPlugin/

 

Recientemente me he topado con dos situaciones en las que he estado asistiendo a estudiantes y hemos acabado encontrando data crucial dentro de este directorio. Establecer una relación entre la data que se encuentra aquí puede ser difícil, pero ha rendido fruto en varias situaciones.  

 

Como Apple permite a las aplicaciones utilizar funcionalidades añadidas o “plugins” (por ejemplo, el teclado de Giphy, que es mi favorito), estos “plugins” pueden almacenar data dentro de este directorio. En un caso de prueba, se intentó identificar por qué muchos videos ilegales aparecían dentro de un directorio en especifico. Utilizando el archivo .com.apple.mobile_container_manager.metadata.plist, el analista pudo identificar qué “plugin” estaba colocando la data en este directorio, y cual era el bundleID correspondiente. En este caso se encontró que estaba relacionado al PhotoMessagesApp de com.apple.mobileslideshow.

 

 

Nota: com.apple.mobileslideshow es la aplicación de Fotos en iOS. 

 

Ahora que sabemos a qué “plugin” y aplicación pertenece el directorio, podemos tratar de generar data de prueba para verificar cómo esta información llegó ahí. En mi ejemplo, utilicé el “plugin” de “photo picker” dentro de iMessage y modifiqué el video desde dicho “plugin” sin lanzar la aplicación original de com.apple.mobileslideshow. Utilizando KnowledgeC, podemos ver en las siguientes capturas de pantallas que el momento en que estos archivos fueron creados dentro del directorio de PluginKitPlugin/APPGUID/ coincide con la aplicación de MobileSMS. 

 

He visto otros “plugins” como com.apple.mobileslideshow.photo-picker en algunas investigaciones pero a veces es difícil entender cómo se han poblado estos directorios sin tener acceso a KnowledgeC o PowerLog para ver la perspectiva completa. Pudiendo descifrar qué BundleID corresponde a cada directorio, tenemos al menos un punto de partida para poder entender cómo la data llegó al lugar donde está. 

 

Ahora tenemos una mejor manera de poder construir nuestros “mapas del tesoro” y sabemos que los archivos .com.apple.mobile_container_manager.metadata.plist por lo general van a contener nuestro punto clave para encontrar el mismo. 

 

Una Mirada Rápida (“QuickLook”) de los Snapshots de iOS

Translation by Geraldine Blay

No puedo creer que finalmente estoy publicando un artículo en el blog. He comenzado a escribir acerca de 5 o 6 temas distintos, pero con frecuencia me distraigo y comienzo a investigar otro tema y me olvido de terminar lo que había comenzado. 

 

En los dispositivos móviles que utilizan iOS, el usuario puede deslizar el dedo desde la parte inferior del iPhone o iPad hacia la mitad de la pantalla para acceder el selector de apps. (En los dispositivos móviles que aún tienen el botón de inicio (“home”), se puede acceder esta función  haciendo doble clic a dicho botón). El selector de apps le permite al usuario navegar entre las aplicaciones que ha utilizado recientemente. Por ejemplo, si un usuario recibe una llamada mientras esta utilizando un app, la aplicación activa pasa al estado de suspensión. El usuario puede utilizar el selector de apps para volver rápidamente a la aplicación inicial.

Una imagen instantánea de la pantalla (“snapshot”) es generada para crear una transición visual mas fluida para el usuario.  Durante el resto de este artículo, utilizaré la palabra inglesa (“snapshot”) por función de brevedad. Los desarrolladores de apps pueden optar por desactivar la opción de crear un “snapshot” o pueden utilizar una imagen alterna por seguridad. 

A partir de iOS 10, estos “snapshots” han sido creados en formato KTX. KTX es un formato de compresión creado por el grupo Khronos, el cual provee un contenedor para múltiples texturas o imágenes.  Este formato por lo general ocupa menos memoria y es mas rápido y eficiente que otros formatos, lo cual es beneficial en los dispositivos móviles. Una discusión mas detallada sobre el formato KTX esta fuera del alcance de este artículo, pero las especificaciones de este formato pueden ser encontradas en la página del Grupo Khronos. 

En iOS, estos “snapshots” pueden ser encontrados en 

/private/var/mobile/Library/Caches/Snapshots/<bundleID>/<bundleID>/

/private/var/mobile/Containers/Data/Application/<ApplicationUUID>/Library/Caches/Snapshots/<bundleID>

Nota: El bundle ID, también conocido como identificador de paquete, es el nombre interno del app. Para efectos de este artículo vamos a utilizar el nombre en inglés.

Mediante investigación encontré que la información pertinente a estos “snapshots” esta almacenada en la base de datos applicationState.db, localizada en /private/var/mobile/Library/FrontBoard… pero claro está, no está almacenada de manera simple de interpretar. Está almacenada en un blob dentro de esta base de datos – en un plist binario dentro de otro plist binario. 

 

Al darme cuenta de esto, contacté a mi buen amigo y mentor Alexis Brignoni (@AlexisBrignoni), ya que está familiarizado con los bplists anidados, Python, y dispositivos móviles en general.

Actualmente, algunos de los programas forenses analizan los “snapshots”, pero este no era el caso en el momento en que escribí el artículo original en inglés. NO obstante, la solución presentada en este artículo aún es útil, ya que siempre es buena practica validar los resultados que nos dan las herramientas. 

Metodología


Yo siempre he pensado que la mejor manera de examinar una Mac de manera forense es utilizando una Mac. En mi opinión, esto también aplica a iOS. Hay varias herramientas que realizan un trabajo excelente procesando imágenes de iOS, pero ¿qué hacemos cuando no tenemos acceso a estas herramientas?  Aún cuando tenemos acceso a las herramientas, es nuestro deber entender de donde provienen los resultados obtenidos, y verificar que los mismos sean correctos, especialmente si la libertad de alguien depende de ellos. 

Hasta el momento**, mi manera favorita de mirar archivos KTX ha sido utilizando la opción de vista rápida (“Quick Look”) en Finder (claro está, siempre me aseguro que estén protegidos contra la escritura para no alterar la evidencia).

 

Primeramente, utilizamos el script de Python “SnapshotImageFinder.py escrito por Alexis Brignoni para extraer todos los KTX “snapshots” de una extracción de iOS. Luego, utilizamos una Acción Rápida (“Quick Action”) de Automator que convierte todos los archivos KTX a PNG para poder trabajar mas fácilmente con ellos. Finalmente, utilizamos SnapshotTriage.py (tambien creado por Brigs) para identificar y extraer los bplists anidados dentro de ApplicationState.db. Este script también crea un reporte en formato HTML para cada aplicación que contenga “snapshots” en nuestra imagen de iOS. Esto es solo un resumen de la metodología utilizada por nosotros. Para una explicación más detallada, pueden leer este artículo. 

 

Por cierto, los “snapshots” en iOS me recuerdan a las Tareas Recientes (“Recent Tasks”) en Android. Si no sabes a lo que me refiero, puedes estar perdiendo mucha evidencia importante en tus casos - este enlace contiene un tremendo articulo escrito por Brigs al respecto. 

 

**Nota: En el momento en que escribí el artículo era mi manera favorita, hoy día me gusta utilizar iLEAPP (https://github.com/abrignoni/iLEAPP ) ya que permite analizar archivos KTX y otros artefactos de manera rápida y sencilla. 

Implicaciones Forenses / Estudio de Caso 

Nuestro escenario: El sospechoso (John Doe) ha utilizado la aplicación nativa de iOS “Cámara” para grabar un video mientras está cometiendo el crimen. Mientras John graba el video, decide suspender la aplicación (quizás recibió una llamada telefónica o a lo mejor se volvió un poco paranoide y decidió deshacerse de la evidencia). Claro esta, él es muy competente utilizando tecnología y ha borrado todas sus fotos y videos del folder de “Fotos borradas” en la aplicación nativa de fotos de iOS. Como ya sabemos, a veces no es posible recuperar información que ha sido borrada en dispositivos móviles. 

 
Al examinar la extracción de la imagen del sistema de archivos “full file system” del teléfono de Mr. Doe, recobramos varios KTX “snapshots” provenientes de distintas aplicaciones. Estos “snapshots”, junto con otros archivos como KnowledgeC, plists, etc. pueden ayudarnos a pintar un mejor paisaje de lo que estaba ocurriendo en el teléfono durante el tiempo en que se cometido el crimen. 

En particular, recobramos el siguiente “snapshot” en /private/var/mobile/Library/Caches/Snapshots/com.apple.camera/com.apple.camera

 

A pesar de que este video ya no lo encontramos en el sistema de archivos “file system” de iOS, puede ser que el “snapshot” correspondiente nos ayude en nuestra investigación. Por ejemplo, la estampa de tiempo asociada con dicho “snapshot” nos puede dar mas perspectiva de lo que estaba ocurriendo en ese instante. Quizás Mr. Doe compartió el video con alguien, o lo subió a las redes sociales o transfirió a un app secreto. A lo mejor podemos obtener proceso legal para copias de seguridad de iCloud. Tal vez tengamos mucha suerte y encontramos un video de aproximadamente 21 segundos de duración, grabado alrededor del tiempo indicado en la estampa de tiempo. 

“Todo contacto deja un rastro.”- Profesor Edmond Locard 


A pesar de que el Principio de Intercambio de Locard se aplica con frecuenta a la evidencia tangible, como DNA o análisis de huellas dactilares, también aplica a la evidencia digital. 

Es extremadamente importante que entrenemos a nuestros examinadores forenses y a nuestro personal de emergencia a limitar su interacción con la evidencia digital al mínimo necesario para preservarla. A fin de cuentas, no queremos tener que explicarle al Jurado por que estos “snapshots” tienen estampas de tiempo con fechas que ocurrieron luego de que la policía llegara a la escena del crimen, o peor aun (en mi opinión), que un asesino sea absuelto porque destruimos un pedazo clave de evidencia por no ser diligentes.

Nota: Nuestra investigación se ha enfocado de manera primaria en iOS 11 y 12, pero planificamos expandirlo para incluir otras versiones. Actualmente estamos haciendo investigaciones adicionales en las estampas de tiempo localizadas dentro de los bplists. Como siempre, ¡es imprescindible validar! Si tienes alguna contribución adicional respecto a este tema, por favor contáctanos, ya que es así como crecemos como comunidad forense.