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. 

 

¿Cuáles aplicaciones fueron instaladas en un teléfono móvil con sistema operativo iOS y cuándo fueron instaladas?

¿Cuáles aplicaciones fueron instaladas en un terminal móvil con sistema operativo iOS y cuándo fueron instaladas?

Por Alex Brignoni

Traducción al español por Geraldine Blay

Fecha de actualización: 3 de abril, 2019 (1 versión anterior)

Enlace al articulo original: https://dfir.pubpub.org/pub/e5xlbw88

Sinopsis

Pregunta forense: ¿Cuáles aplicaciones fueron instaladas en un terminal móvil con sistema operativo iOS y cuándo fueron instaladas?

Versión del sistema operativo: iOS 11, iOS 12

Directorio: /private/var/installd/Library/Logs/MobileInstallation/*.log

Herramienta: Python

Introducción

En las últimas dos entradas de mi blog escribí acerca de cómo obtener un listado de las aplicaciones instaladas y sus respectivos directorios utilizando una imagen del sistema de archivos en iOS (full file system).

Mi método usual es hacer una consulta o “query” a la base de datos applicationState.db para encontrar su identificador (app bundle id) y el GUID del directorio correspondiente. El encontrar dicho directorio nos permite enfocarnos en las localidades de almacenamiento o “data stores”, para así analizar la data generada por el usuario cuando nuestras herramientas forenses no la pueden decodificar.

En mi segunda entrada del blog, recibí excelentes comentarios (feedback) de Sarah Edwards,  quien me mencionó del contenido de los registros de instalación móvil de iOS (mobile installation logs).

Cosas interesantes

Inmediatamente me pregunté si había un código o “script” de computadora que pudiese analizar dichos registros. Tras preguntarle a Sarah Edwards y realizar una búsqueda en el internet no encontré ninguno.

Yo lo hago

Metodología

El enlace siguiente es para un script de Python creado por mi para analizar las bitácoras o “logs” de instalación móvil. El mismo ha sido probado en iOS 11 y 12.

https://github.com/abrignoni/iOS-Mobile-Installation-Logs-Parser

·      iOS Mobile Installation Logs Parser (Analizador de Registros de Instalación Móvil de iOS)

Estos registros contienen mucha información. Actualmente este script solo extrae los siguientes eventos:

·      Instalación exitosa de una aplicación con fecha y hora.

·      Contenedor del app ha sido hecho activo o “made live” con fecha, hora, y localización de la carpeta.

·      Contenedor del app ha sido movido, con fecha, hora, y localización de la carpeta.

·      Contenedor del app ha sido destruido, con fecha, hora y localización de la carpeta.

La siguiente imagen es un ejemplo de como se ven los logs directamente al ser extraídos del dispositivo. Las letras de la imagen son muy pequeñas - para leerlas más fácilmente presione la imagen.

Mucha data

 El script es bien sencillo de utilizar.

1.             Instale Python 3.6.4 o alguna versión más reciente

2.             Extraiga los logs de la siguiente carpeta:  /private/var/installd/Library/Logs/MobileInstallation/

3.             Ponga el script en la misma carpeta que los logs que acaba de extraer.

4.             Ejecute el script utilizando CMD.

Al finalizar, la pantalla se verá de la siguiente manera:

El script ha terminado de ejecutarse. Algunas estadisticas

 El script producirá una base de dato en formato SQLite llamada mib.db, un directorio llamado Apps_State y un directorio llamado Apps_Historical.

Script y archivos generados por el mismo

La base de datos SQLite mantiene la información que se ha extraído del log. El script hace una búsqueda en la base de datos para producir el contenido de los dos directorios.

El directorio de Apps_State puede tener dos archivos adentro: InstalledApps.txt y UninstalledApps.txt. El contenido de estos archivos es consistente con el nombre de los mismos. He aquí un ejemplo del contenido de InstalledApps.txt:

Listado de aps instalados

El tener esta lista a la mano es muy útil,  ya que se puede utilizar para comparar las aplicaciones instaladas actualmente con las aplicaciones detectadas por nuestra herramienta forense preferida y determinar si alguna aplicación no ha sido detectada. 

Si desea un mejor contexto en cuanto a la fecha de instalación y la localización del directorio del app, el directorio Apps_Historical provee dicha información (listada por app). 

Un archivo txt por cada app

El siguiente es un ejemplo de información histórica acerca de un app que ha sido instalado.

Eventos historicos para com.blizzard.social

Note que el reporte tiene una estampa de tiempo para cada evento. El script coloca el evento mas reciente en la parte superior, por lo que el directorio actual para la aplicación está en la parte superior del archivo (o cerca de la parte superior).

El siguiente es un ejemplo de información histórica acerca de un app que ha sido desinstalado:

Eventos historicos para org.videolan.vlc.ios

Al igual que en el reporte anterior, hay una estampa de tiempo para cada evento y los eventos están ordenados, comenzando con el más reciente en la parte superior del archivo. Estos reportes son útiles si se desea determinar cuando un app fue desinstalado o si un app que está instalado actualmente fue desinstalado e instalado en múltiples ocasiones.

Eventos historicos

Note que las múltiples entradas que indican ‘Destroying’ (Destruyendo), ‘Made’ (Creado) e ‘Install Successful’ (Instalación Exitosa) . Nuevamente, las entradas más recientes se encuentran en la parte superior del archivo. El registro también muestra cuando un app ha sido actualizado, el número de la versión anterior del app y la versión más reciente después de la actualización.

Como se puede ver en el ejemplo, el resultado del script responde a la petición  inicial de obtener un listado de apps instalados con sus directorios correspondientes. De hecho, va ms allá, identificando aplicaciones desinstaladas, con sus respectivas estampas de tiempo y otros eventos históricos del app. Por último, el script produce un listado de los eventos de reinicio, así como las estampas de tiempo correspondientes.

Al mirar los registros, se pueden identificar algunas áreas en las que el script se pudiese mejorar. Este es mi listado de tareas por hacer:

·      Anadir un“updated bundle entries” para el contexto de los“container made live” en los reportes históricos .

·      Anadir un pedido de desinstalación (“uninstall requested”) y un identificador de desinstalación (“uninstalling identifier”) en los reportes históricos.

Enlaces a los artículos de blog originales:
https://abrignoni.blogspot.com/2019/01/ios-mobile-installation-logs-parser.html
https://abrignoni.blogspot.com/2018/12/update-on-identifying-installed-and.html

Reconocimientos

No puedo agradecer lo suficiente a mi colega @i_am_the_gia por probar el script en su conjunto de datos y a Sarah Edwards por informarme acerca de estos logs.

DFIR Review

Este trabajo detalla cómo extraer e interpretar los registros de instalación de los apps de un sistema operativo iOS para determinar que aplicaciones están instaladas actualmente y cuáles han sido borradas. Una lista exhaustiva de las actividades relacionadas con la instalación de un app (incluyendo estampas de tiempo), puede ser muy útil al investigar un dispositivo móvil.

Este trabajo provee un script de Python y un conjunto de datos para probar el script.
Utilizando el conjunto de datos provisto por el autor, no hubo ningún resultado para System_State en el mobile_installation.log.0. El log y la base de datos SQL creada fueron validados manualmente y este resultado es correcto. El archivo mobile_installation.log.0 de mi conjunto de datos personal tenía este tipo de entradas. Ambas pruebas analizaron de manera correcta el registro. Comparé de manera manual la data provista por mobile_installation.log.1 con los resultados en el Apps_Historical, Apps_State, System_State y mib.db, tanto para la data de prueba provista por el autor como para mi propia data de prueba. Ambos resultados fueron validados correctamente. El script funciona como es de esperarse en la data de prueba provista y en la data creada por mi.

Trabajo Futuro

Las instalaciones con errores no están desplegadas en la base de datos o en ninguno de los archivos de texto producidos por el script. Pudiera ser de valor el incluir estos eventos, así como su estampa de tiempo, en los archivos de textos correspondientes al bundleID (en el directorio Apps_Historical).

Revisor (Evaluador)

·       Addisu Afework Birhanu (Verificado utilizando un conjunto de datos provisto por el autor)

·       Ali Hadi (Revisión de la metodología)

·       Jessica Hyde (Verificado utilizando un conjunto de datos provisto por el autor y un conjunto de datos generado por el evaluador)

·       Anthony Knutson (Revisión de la metodología)

·       Sungmi Park (Revisión de la metodología)