CRIMINALISTIQUE MOBILE

Faire analyser les métadonnées numériques par des professionnels

QUESTIONS FRÉQUEMMENT POSÉES

Dans quels cas cette analyse est-elle nécessaire ?

• ✔D'un point de vue technique, ce message fait-il partie de la conversation affichée ?

• ✔Un fichier multimédia est-il associé à un enregistrement d'actualité spécifique ?

• ✔Quelles dates et heures ont été enregistrées pour la création, l'envoi, la réception ou la modification du statut ?

• ✔Existe-t-il des relations entre bases de données qui confirment ou nuancent cette capture d'écran ?

• ✔Ces lacunes s'expliquent-elles par une suppression, une synchronisation, une migration de données ou le comportement d'une application ?

• ✔Est-il possible de comparer les identifiants de messages ou les références de fils de discussion avec d'autres appareils ou sauvegardes ?

La génération automatique d'outils ne doit pas être assimilée à une évaluation finale. Les schémas de base de données et la signification des champs peuvent varier d'une version de l'application à l'autre. C'est pourquoi une vérification manuelle, une validation et une interprétation documentée sont indispensables.

Le système de fichiers gère non seulement le contenu d'un fichier, mais aussi ses caractéristiques techniques telles que son nom, son chemin d'accès, sa taille, ses attributs et diverses informations temporelles. Selon le système d'exploitation et le système de fichiers, d'autres informations peuvent être disponibles. Ces données permettent d'analyser l'emplacement d'un fichier, les éventuels processus de copie et son lien avec une application.

Les horodatages du système de fichiers ne doivent toutefois pas être assimilés à la date de création du contenu. Lorsqu'une photo est exportée depuis une application de messagerie, le nouveau fichier peut se voir attribuer une date de création postérieure, même si l'image elle-même est plus ancienne. À l'inverse, lors d'une restauration à partir d'une sauvegarde, les horodatages d'origine peuvent parfois être conservés. L'interprétation correcte dépend donc du mode de stockage et de transfert concret.

Les informations de localisation peuvent apparaître directement dans des médias, dans des bases de données d'applications, dans des données cartographiques ou de navigation, dans des références WLAN ou dans d'autres éléments du système. Les coordonnées GPS contenues dans une image ne constituent qu'une source parmi d'autres. D'autres éléments peuvent refléter des lieux, des déplacements, des recherches d'itinéraires, des positions enregistrées ou des références réseau.

Les données de localisation doivent être traitées avec une prudence particulière. Un lieu enregistré peut désigner la localisation de l’appareil, la destination d’une recherche, le lieu où un fichier a été enregistré ou simplement une position déduite d’autres données. Il convient également de vérifier la précision, la méthode de mesure et la référence temporelle. Une donnée de localisation isolée ne doit donc jamais être présentée comme une preuve de présence sans être replacée dans son contexte.

D'autres traces connexes pertinentes concernent l'appareil et les applications installées. Il peut s'agir notamment d'informations sur le modèle et le système, d'identifiants de paquets d'applications, de références d'installation ou Update, d'autorisations, d'identifiants de compte, d'état de synchronisation et d'informations de sauvegarde. Ces données permettent, par exemple, de vérifier si une application donnée était présente au cours de la période concernée ou si des données ont pu être synchronisées entre plusieurs appareils et services cloud.

Ces informations doivent elles aussi être replacées dans leur contexte temporel. Le statut d'installation actuel ne prouve pas nécessairement qu'une application ait été activement utilisée à un moment antérieur. À l'inverse, des traces d'une application installée précédemment peuvent subsister, même si celle-ci a été supprimée par la suite.

De nombreuses applications mobiles stockent des données dans des bases de données SQLite. Outre les données utiles visibles, ces bases de données contiennent souvent des champs techniques, des identifiants, des valeurs d'état et des relations entre les tables. En mode WAL, des pages supplémentaires ou qui n'ont pas encore été transférées dans la base de données principale peuvent être présentes dans un fichier WAL associé. Le fichier SHM prend en charge la gestion du fonctionnement du WAL.

Pour une analyse dans les règles de l'art, la base de données principale, le fichier WAL et le fichier SHM doivent être sauvegardés et documentés conjointement, dans la mesure où ils sont disponibles. Il convient toutefois de noter que tous les enregistrements trouvés dans un fichier WAL ne sont pas automatiquement supprimés, obsolètes ou pertinents à des fins de preuve. Leur emplacement, leur transaction, leur attribution de page et l'état de la base de données doivent faire l'objet d'une évaluation technique.

Les métadonnées peuvent mettre en évidence des contradictions. Une photo prétendument prise directement avec un smartphone peut, par exemple, contenir des informations logicielles indiquant un traitement ultérieur. Une capture d'écran d'une conversation peut ne pas correspondre, sur le plan temporel ou structurel, aux entrées existantes dans la base de données. Un fichier peut avoir été créé dans le système de fichiers à un moment différent de celui de la prise de vue qui y est enregistrée.

Ces écarts ne constituent toutefois, dans un premier temps, que des indices à examiner. Ils peuvent également résulter d'opérations légitimes telles que l'exportation, la synchronisation dans le cloud, le transfert, la modification, le changement de fuseau horaire ou la restauration à partir d'une sauvegarde. Une analyse rigoureuse établit donc une distinction entre :

• ✔un écart constaté sur le plan technique,

• ✔une explication technique plausible,

• ✔un indice solide laissant supposer une modification ultérieure et

• ✔un acte de manipulation effectivement vérifiable.

Neutralité judiciaire : la mission d'enquête ne doit pas avoir pour objectif de confirmer une affirmation souhaitée. Seules comptent les traces objectivement présentes et les conclusions raisonnables qui peuvent en être tirées.

Préciser la problématique : quelle affirmation doit faire l'objet d'une vérification technique ?

Consigner les éléments de preuve : l'appareil, son état, ses caractéristiques d'identification et la remise sont consignés.

Sauvegarde des données à des fins d'expertise judiciaire : la méthode de sauvegarde appropriée est choisie en fonction de l'appareil et de la mission.

Documenter l'intégrité : les fichiers et les exportations sont sécurisés, lorsque cela s'avère pertinent, à l'aide de valeurs de hachage et de copies de travail traçables.

Identifier les sources pertinentes : les médias, les bases de données, le système de fichiers, les journaux, ainsi que les artefacts du cloud et des applications sont ciblés.

Vérification des formats et des significations : le format de l'heure, le fuseau horaire, le champ de la base de données et la sémantique technique sont validés.

Corrélation des métadonnées : les pistes individuelles sont recoupées avec des sources indépendantes.

Vérifier les autres explications possibles : la synchronisation, l'exportation, la migration, la sauvegarde et le comportement du logiciel sont pris en compte.

Documenter les résultats de manière reproductible : les étapes de travail, les outils, les versions, les requêtes et les limites sont consignés.

Distinguer le constat de l'évaluation : une distinction claire est établie entre le constat technique et la conclusion de l'expert.

• ✔Un horodatage isolé est désigné, sans vérification, comme „ date de création “.

• ✔On confond souvent l'UTC, l'heure locale et l'heure d'été.

• ✔L'heure du système de fichiers et l'heure d'enregistrement du contenu sont considérées comme identiques.

• ✔L'absence de données EXIF est automatiquement considérée comme un indice de manipulation.

• ✔Les données GPS sont présentées comme une preuve de présence sans que leur pertinence soit vérifiée.

• ✔Les résultats des outils analysés automatiquement sont pris en compte sans validation manuelle.

• ✔Les versions des applications et les différents schémas de base de données ne sont pas pris en compte.

• ✔Une copie ou un fichier exporté est traité comme le fichier d'origine.

• ✔Les conflits ne sont pas pris en compte lors d'éventuelles opérations de synchronisation ou de sauvegarde.

• ✔L'absence de toute trace est interprétée comme la preuve qu'un événement n'a pas eu lieu.

Les métadonnées peuvent être supprimées, modifiées, écrasées ou recréées par des opérations système normales. Certaines applications n'enregistrent que peu d'informations ; d'autres utilisent des structures de données cryptées ou propriétaires. Les systèmes d'exploitation modernes restreignent l'accès à certaines zones. De plus, des manipulations sophistiquées ou des bogues logiciels inconnus peuvent compliquer l'analyse.

Une analyse rigoureuse ne prétend donc pas pouvoir reconstituer chaque événement sans aucune ambiguïté. Elle décrit plutôt quelles sources de données étaient disponibles, quelles méthodes ont été utilisées, quels résultats sont reproductibles et où subsistent des incertitudes techniques.

• ✔Vérification de l'authenticité ou de la chronologie des photos et des vidéos,

• ✔Enquête sur des allégations de manipulation de discussions en ligne,

• ✔Reconstitution des enchaînements de communication et des événements,

• ✔Vérification de l'origine des fichiers, de leur exportation ou de leur traitement,

• ✔Analyse des données relatives à la localisation et aux déplacements,

• ✔enquêtes internes et gestion des incidents,

• ✔Préparation d'une expertise privée ou judiciaire,

• ✔Contrôle de plausibilité des éléments de preuve numériques.