Applications, artefacts et rapports

Dans la plupart des cas, les applications tierces produisent les éléments de preuve les plus riches. Chaque application stocke ses données à sa manière, mais certaines constantes se retrouvent.

• Bases de données SQLite pour les messages, l'historique et les métadonnées.
• Listes de propriétés (plist) sur iOS et préférences XML partagées sur Android pour les paramètres et l'état.
• Blocs Protobuf / JSON intégrés dans les colonnes des bases de données.
• Dossiers de cache et de médias pour les miniatures et les pièces jointes.

Votre rôle consiste à les analyser de manière cohérente, à les attribuer à un utilisateur et à un moment donné, puis à les présenter de manière défendable.

Les applications de messagerie sont des sources fréquentes d'éléments de preuve. Chacune conserve un stockage principal des messages ainsi que des tables de contacts et de groupes.

• WhatsApp (Android) : msgstore.db (messages), wa.db (contacts).
• Signal : base SQLCipher chiffrée ; la clé est stockée dans le magasin de clés ou le trousseau.
• Telegram : cache4.db avec du contenu encodé en Protobuf.

Reconstituez une conversation WhatsApp à partir du stockage des messages :

Certaines applications chiffrent leur propre base de données avec SQLCipher (par exemple Signal et certaines applications bancaires). Vous ne pouvez pas les ouvrir avec sqlite3 ordinaire.

• La clé est généralement stockée dans le magasin de clés ou le trousseau de la plateforme et ne peut être récupérée qu'à partir d'une extraction suffisamment approfondie.
• Une fois la clé obtenue, ouvrez la base de données via PRAGMA SQLCipher avant de l'interroger.

Ouverture d'une base de données SQLCipher une fois la clé récupérée :

Les bases de données des applications dissimulent souvent des données structurées dans des colonnes BLOB sous forme de Protobuf, de plist ou de JSON. Les colonnes visibles ne représentent qu'une partie des informations.

• Les blocs BPLIST (liste de propriétés binaire d'Apple) se décodent avec plistlib ou plutil.
• Les blocs Protobuf se décodent avec protoc ou blackboxprotobuf.

Convertissez un bloc de liste de propriétés binaire extrait d'une colonne :

Les éléments de preuve de localisation relient une personne à un lieu et à un moment ; ils doivent donc être traités avec une rigueur particulière.

• Balises GPS des photos EXIF, historique de recherche des applications cartographiques, tuiles mises en cache.
• Lieux importants d'iOS (cache routined), historique de localisation d'Android et journaux Wi-Fi et de réseau cellulaire.

Distinguez l'endroit où se trouvait l'appareil d'un lieu que l'utilisateur s'est contenté de rechercher. Extrayez les données GPS EXIF d'une photo :

Les applications modernes se synchronisent entre plusieurs appareils ; les données présentes sur l'appareil peuvent donc être incomplètes ou dupliquées.

• Un message supprimé du téléphone peut subsister sur une tablette associée ou une session web.
• Les métadonnées de synchronisation peuvent indiquer quel appareil a créé un message.

Consignez l'attribution à l'appareil dans votre analyse et ne recherchez des données en ligne ou provenant d'appareils associés qu'avec une autorisation légale distincte et appropriée. Ne supposez jamais que le téléphone saisi contient l'intégralité des enregistrements.

Avant qu’un artefact ne soit intégré à un rapport, validez-le de trois façons.

• Source : confirmez le fichier, la table et la colonne exacts dont il provient.
• Décodage : vérifiez l’époque de l’horodatage et la signification des champs, idéalement en les comparant à un message de référence fiable.
• Corroboration : recoupez-le avec un deuxième artefact (par exemple, une entrée de journal d’appels correspondant à un contact).

Un artefact que vous ne pouvez pas corroborer indépendamment ou dont vous ne pouvez pas identifier précisément la source doit être signalé comme présentant un faible niveau de confiance, et non présenté comme un fait.

Une super-chronologie regroupe les événements provenant de nombreux artefacts en une seule vue chronologique, normalisée en UTC.

• Combinez les messages, les appels, l’utilisation des applications, les localisations et les événements système.
• Ajoutez à chaque ligne son artefact source afin d’assurer sa traçabilité.

Des outils comme log2timeline/plaso ou des programmes d’analyse assemblent ces données. En théorie, chaque ligne contient l’heure, l’événement et la provenance :

Un rapport d’expertise numérique doit permettre à un examinateur indépendant de reproduire et vérifier votre travail. Voici les sections habituelles :

• Synthèse — périmètre, autorisation, principales constatations.
• Éléments de preuve traités — appareils, identifiants, chaîne de conservation.
• Méthodologie — outils, versions, commandes exactes, empreintes.
• Résultats — artefacts accompagnés de références à leurs sources.
• Conclusions — interprétation clairement séparée des faits bruts.

Toute affirmation doit pouvoir être reliée à une source identifiée par son empreinte et à une étape documentée.

La crédibilité d’un rapport repose sur la distinction entre observation et interprétation.

• Fait : la ligne 482 de sms.db contient le texte X à la date Y (UTC).
• Interprétation : cela suggère que l’utilisateur avait prévu de se retrouver à l’endroit Z.

Énoncez les faits de manière neutre et présentez les déductions comme telles, en mentionnant également les explications alternatives. Affirmer avec trop de certitude (par exemple, déduire une intention d’un seul message) fragilise l’ensemble du rapport et peut être contesté devant un tribunal.

Les appareils mobiles contiennent des données extrêmement privées. Les professionnels doivent respecter les limites légales et éthiques.

• Travaillez uniquement dans le périmètre autorisé (termes du mandat ou du consentement).
• Limitez l’exposition des données privées non pertinentes.
• Faites preuve d’objectivité — présentez aussi les éléments à décharge, et pas uniquement ceux à charge.
• Protégez les données extraites avec autant de soin que l’appareil d’origine.

Une éthique rigoureuse n’est pas facultative : c’est elle qui rend les éléments de preuve numériques fiables et recevables.

Votre rapport affirme : « L’utilisateur avait l’intention de commettre l’acte, comme le montre le message 482. » Un évaluateur conteste cette affirmation. Quel est le problème fondamental ?

Vous pouvez désormais transformer des extractions brutes en un rapport défendable.

• Les données des applications reposent sur SQLite + plist/XML + objets binaires protobuf/JSON ; décodez explicitement ces objets.
• Les stockages chiffrés (SQLCipher) nécessitent des clés obtenues grâce à une extraction approfondie.
• Traitez les éléments de preuve de localisation avec prudence ; distinguez une présence d’une simple recherche.
• Tenez compte de la synchronisation entre plusieurs appareils et ne recherchez des données dans le cloud qu’avec l’autorisation requise.
• Validez la source, le décodage et la corroboration avant de les présenter dans un rapport.
• Construisez une super-chronologie en UTC, structurez le rapport pour permettre sa reproduction et gardez les faits séparés de l’opinion.
• Restez dans le périmètre autorisé et agissez avec éthique — c’est ce qui rend les éléments de preuve recevables.