iOS – Suivi des ID de lot pour les conteneurs, les conteneurs partagés et les plug-ins
Dans iOS, l’une des choses les plus frustrantes que j’ai pu rencontrer en travaillant sur des données ou en répondant aux questions d’un étudiant consiste à déterminer quelle application a mis des données dans un emplacement spécifique. Grâce au fabuleux travail accompli par certaines personnes telles qu’Alexis Brignoni sur ApplicationState.db dans le cadre du répertoire FrontBoard, cela a toujours été l’un de mes endroits préférés pour me constituer une « carte au trésor » d’applications permettant de gérer ces AppGUID pénibles qu’Apple attribue à chaque application sur un appareil. Ces choses pénibles dont je parle peuvent être trouvées à l’emplacement suivant lorsque vous cherchez des données :
/private/var/mobile/Containers/Data/Application
Heureusement, la plupart des outils analyseront le ApplicationState.db et mapperont chacun de ces identifiants uniques à l’application qui est stockée à l’intérieur.
Super ! Ainsi, il est tellement plus facile de déterminer quelles applications sont installées et où elles se trouvent. Cependant, il peut arriver que vous tombiez sur un fichier intéressant au sein d’un dossier et que vous deviez alors établir une correspondance entre le chemin de répertoire et cette base de données. Vous vous trouvez peut-être dans une situation où vous travaillez uniquement avec l’image brute et un accès limité aux outils. Comment peut-on trouver le bundleID de l’application à partir d’un répertoire ?
Dans le chemin d’accès des données de l’application, vous devriez trouver à la racine un fichier « .com.apple.mobile_container_manager.metadata.plist » qui semble avoir le même nom dans chaque répertoire d’application. Cette information contiendra des clés ayant le bundleID de l’application, ce qui est parfait si vous êtes en retard et que vous souhaitez éviter les allers-retours.
Le plus intéressant dans tout cela, c’est ce qui se passe lorsque vous faites une recherche de ce fichier dans votre appareil iOS. Vous verrez ainsi que le fichier .com.apple.mobile_container_manager.metadata.plist apparaît dans beaucoup d’emplacements, y compris :
- /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 [duh]
- /private/var/mobile/Containers/Data/InternalDaemon/APPGUID/
- /private/var/mobile/Containers/Data/PluginKitPlugin/APPGUID/
Wow. Cela nous offre beaucoup plus d’endroits à explorer pour créer notre carte au trésor. Mais quel est ce fichier au juste ? Parlons tout d’abord de bac à sable. Apple utilise énormément le bac à sable dans iOS. Cela permet d’éviter que les applications aient accès à des données auxquelles elles ne sont pas censées avoir accès. Chaque application reçoit son propre bac à sable pour jouer, et uniquement cette zone. Ce fichier plist nous permet de voir dans quel bac à sable nous nous trouvons et qui possède ce bac à sable du point de vue de l’application. À l’aide de ces informations, nous pouvons décomposer un peu plus ces informations de chemin d’accès afin de déterminer pourquoi certaines applications conservent des données dans un emplacement.
/private/var/containers/Bundle/Application/
Ce répertoire est l’endroit où vit le fichier .app sur l’appareil. Il existe ici quelques données supplémentaires que nous pouvons suivre au sujet de l’application elle-même et de la personne qui l’a téléchargée sur l’appareil. En plus du fichier .app, il y a un fichier plist iTunesMetadata et BundleMetadata pouvant fournir des renseignements comme le moment où l’application a été téléchargée, quelle version de l’application a été téléchargée et quel AppleID l’a téléchargée.
/private/var/containers/Shared/SystemGroup/
Ce répertoire ressemble à celui mentionné précédemment, mais fait référence aux applications principales de l’appareil iOS. Il contient moins d’informations, mais possède tout de même un fichier .plist qui peut dévoiler quelle application système est responsable du conteneur. /
private/var/containers/Data/System/
À nouveau, similaire au répertoire précédent, mais cela ressemble à des applications systèmes qui ne souhaitaient pas partager d’informations entre les applications principales. À nouveau, il s’agit d’informations moins pertinentes, sauf pour le bundleID qui possède le conteneur.
/private/var/mobile/Containers/Shared/AppGroup/
C’est ici que les choses deviennent VRAIMENT amusantes ! J’ai évoqué plus tôt le bac à sable. Apple affirme que les applications ne sont pas autorisées à partager des informations sans en avoir fait la demande au préalable par le biais de canaux officiels. Pour partager des informations, les développeurs d’applications peuvent affecter un « groupe » à leur application. Selon les informations de développement d’Apple, ces groupes peuvent ensuite partager des données les uns avec les autres. Vous les avez aussi peut-être vus dans des images de style sauvegarde qui sont répertoriées comme « AppDomainGroup-group.bundleID » au lieu de la structure « AppDomain-com.bundle.ID ». J’ai souvent utilisé ce chemin lorsque je ne parvenais pas à trouver les données que je cherchais dans le principal chemin d’accès des données de l’application.
Parlons maintenant du côté négatif. Le fichier ApplicationState.db ne contient aucune information sur ce chemin. Le côté positif ? Le répertoire « Shared/AppGroup » de chaque application contiendra l’un de nos fichiers .com.apple.mobile_container_manager.metadata.plist ! Super ! Pour améliorer les choses, Alexis Brignoni a intégré la prise en charge dans iLeapp afin de répertorier tous ces fichiers depuis ce répertoire, nous permettant d’établir une correspondance entre les contenus du fichier et le chemin d’accès où il se trouve. [Obtenez iLeapp ici]
Une application peut également contenir plus d’un dossier dans ce chemin. Deux exemples illustrant ce principe seraient l’application Dropbox ayant plus de 4 conteneurs différents ici et l’application d’e-mail Spark qui en avait deux. Plus important encore, il est possible que certaines applications conservent toutes leurs données pertinentes ici plutôt que dans le répertoire /private/var/mobile/Containers/Application/Data/. Prenons le cas, par exemple, de l’application d’e-mail Spark (lien Web iTunes) qui choisit de stocker toutes ses bases de données pertinentes au sein de la structure de répertoire /private/var/mobile/Containers/Shared/AppGroup/ au lieu de la structure de répertoire plus courante /private/var/mobile/Containers/Application/Data/. [D’autres exemples notables sont WhatsApp et Signal] [Other notable examples of this include WhatsApp and Signal]
/private/var/mobile/Containers/Application/Data
L’endroit où nous sommes censés chercher des données d’application. Bien compris et documenté. Mais ce n’est pas toujours l’endroit où nous avons envie de chercher.
/private/var/mobile/Containers/Application/InternalDaemon
Dans mes appareils tests, il s’agissait apparemment de services Apple (ou de démons internes, visiblement) qui pouvaient être suivis à l’aide des mêmes fichiers .com.apple.mobile_container_manager_metadata.plist.
/private/var/mobile/Containers/Application/PluginKitPlugin/
Récemment, j’ai été amené à deux reprises à aider des étudiants à comprendre où des données cruciales pour leurs dossiers étaient arrivées dans cette zone. Dans ce cas, il est difficile de fournir des données exactement identiques, mais il est parfois arrivé dans certaines situations que je sois capable de suivre une quantité intéressante d’informations. Étant donné qu’Apple autorise les applications à utiliser des plug-ins à associer (pensez au clavier Giphy, celui que je préfère), ces plug-ins peuvent conserver des données au sein de cette structure de répertoire. Un dossier test consistait à déterminer pourquoi plusieurs vidéos illicites apparaissaient au sein d’un répertoire spécifique. En utilisant le fichier .com.apple.mobile_container_manager.metadata.plist, l’analyste a pu déterminer quel plug-in contribuait à placer des données dans ce répertoire et à quel bundleID le plug-in appartenait. Dans le cas présent, il était lié à PhotoMessagesApp de com.apple.mobileslideshow.
Remarque : com.apple.mobileslideshow est l’application Photos sur iOS.
Maintenant que nous savons à quel plug-in et à quelle application le répertoire appartient, nous pouvons ensuite essayer de générer des données pour prouver comment ces informations sont arrivées ici. Dans mon exemple, j’ai utilisé le plug-in sélecteur de photo au sein de iMessage, puis j’ai modifié la vidéo directement dans ce plug-in sans lancer l’application com.apple.mobileslideshow d’origine. En utilisant KnowledgeC, vous pouvez voir dans les captures d’écran suivantes que, lorsque ces fichiers ont été créés dans la structure de répertoire PluginKitPlugin/APPGUID/, l’application MobileSMS et d’autres plug-ins se chevauchent.
D’autres plug-ins comme « com.apple.mobileslideshow.photo-picker » sont apparus dans d’autres enquêtes, mais il est parfois difficile de renseigner ces répertoires sans KnowledgeC ou PowerLog pour continuer. En ayant au moins une compréhension du BundleID propriétaire, nous pouvons commencer à comprendre les possibilités quant à la façon dont les données sont arrivées où elles sont.
Nous disposons maintenant d’une meilleure façon de créer nos propres cartes au trésor et nous savons que les fichiers .com.apple.mobile_container_manager.metadata.plist vont généralement fournir le « X » qui marque l’emplacement.
Cet article a été rédigé par Christopher Vance, gestionnaire de l’élaboration des programmes chez Magnet Forensics. Il apparait également dans son blog D20 Forensics.
