Forensique des messageries : les fondamentaux

La forensique des messageries consiste à collecter, analyser, normaliser et interpréter des communications, de l'e-mail et des SMS jusqu'aux applications de chat et aux outils collaboratifs d'entreprise, afin de répondre à des questions de fait : qui a dit quoi, à qui, quand, par quel canal, et qu'est-ce qui a été partagé, modifié ou supprimé en chemin.

Elle se situe au carrefour de la forensique mobile, de la forensique informatique, de l'eDiscovery et de la réponse à incident. Une fraude au président exige d'examiner les en-têtes de messagerie. Une affaire de menace interne passe par Slack ou Teams. Une escroquerie mobilise WhatsApp, Telegram et les SMS, souvent les trois pour les mêmes personnes. La difficulté tient rarement à la lecture d'un message isolé. Elle consiste à fusionner des centaines de milliers de messages, issus de formats qui divergent sur presque tout, en une chronologie unique et défendable.

Ce guide présente les fondamentaux communs à toutes les sources : acquisition des preuves, forme d'un message normalisé, encodage des horodatages, préservation de l'intégrité, rapprochement des identités, et pièges dans lesquels tombent même les analystes chevronnés.

Acquisition : trois voies, trois compromis

La provenance des données détermine leur contenu. On distingue globalement trois voies.

Exports applicatifs

La plupart des plateformes proposent un export côté utilisateur : « Exporter la discussion » de WhatsApp, l'export JSON de Telegram Desktop, les exports d'espace de travail Slack, le paquet de données Discord, « Télécharger vos informations » chez Meta, Google Takeout, l'export de conversations Skype, l'export d'historique de LINE.

• Avantages : faciles à obtenir, souvent avec la coopération du titulaire du compte ; ni accès à l'appareil ni root nécessaires ; format structuré (JSON, CSV) ou au moins un texte prévisible.
• Inconvénients : l'éditeur décide de ce qui est inclus. Les exports omettent en général les messages supprimés, l'historique des modifications, les accusés de lecture et les identifiants internes. Certains sont de simples fichiers texte en heure locale de l'appareil, sans fuseau horaire. Beaucoup se limitent à ce qu'un seul compte peut voir.

Extraction de l'appareil et des bases de données

L'alternative consiste à récupérer la base propre à l'application depuis un appareil, une sauvegarde ou un profil de bureau : chat.db sur macOS, sms.db depuis une sauvegarde iOS, msgstore.db et wa.db sur Android, ChatStorage.sqlite sur iOS, db.sqlite de Signal Desktop, viber.db de Viber, l'ancien main.db de Skype, mmssms.db pour les SMS Android.

• Avantages : des données plus riches. On obtient les identifiants de ligne internes, les états de remise et de lecture, les horodatages de modification, les métadonnées des pièces jointes, et parfois des restes d'enregistrements supprimés dans les pages libres ou les journaux WAL (fichiers -wal).
• Inconvénients : l'accès pose problème. Les bases mobiles sont protégées par le bac à sable du système et souvent chiffrées : Signal Desktop utilise SQLCipher, les sauvegardes WhatsApp Android sont chiffrées, et le dossier tdata de Telegram Desktop est chiffré au repos. Les schémas changent en outre d'une version à l'autre sans préavis.

Fournisseur, voie judiciaire et eDiscovery

La troisième voie passe par l'opérateur du service : réquisition ou décision de justice adressée au fournisseur, ou export administratif depuis le tenant que vous contrôlez, comme Microsoft Purview eDiscovery pour Teams et Exchange, un export Slack Enterprise Grid ou Google Vault.

• Avantages : couverture complète du tenant, conservation côté serveur (y compris des éléments supprimés localement par les utilisateurs, si des stratégies de rétention s'appliquent), et chaîne de possession claire depuis une source faisant autorité.
• Inconvénients : réservée à la bonne partie (employeur, forces de l'ordre, partie au litige), lente, et livrée au format du fournisseur, qui peut aplatir les fils de discussion ou présenter les chats comme des e-mails. Les exports eDiscovery de Teams, par exemple, représentent les messages de chat sous forme d'éléments .msg de classe IPM.SkypeTeams.Message.

En pratique, on combine ces voies. Un export utilisateur comble les lacunes d'une extraction impossible sur l'appareil, et un export eDiscovery corrobore ce qui a été trouvé sur un ordinateur portable.

Un modèle de message normalisé

Pour placer un e-mail, un message Slack et une ligne WhatsApp sur la même chronologie, il faut projeter chaque source sur un schéma unique. L'outil MessagingForensics utilise les champs suivants pour chaque message ; ils constituent une bonne base pour n'importe quelle boîte à outils :

Deux règles de conception comptent. D'abord, ne jamais jeter une donnée propre à la source au motif qu'elle ne rentre dans aucune colonne ; la ranger dans une table extra pour qu'un relecteur puisse y revenir. Ensuite, chaque ligne doit renvoyer au fichier de preuve exact et au parseur qui l'ont produite. Une entrée de chronologie qu'on ne peut pas rattacher à son origine est une affirmation, pas une preuve.

Le zoo des horodatages

Rien ne casse une chronologie de messagerie comme le temps. Chaque plateforme choisit son époque de référence, son unité et sa convention de fuseau horaire, parfois plusieurs au sein d'une même base. Le tableau encode le même instant, le 2024-02-01 à 10:15:00 UTC, dans chaque format.

Une fois l'époque connue, les conversions relèvent de l'arithmétique simple :

unix_seconds = cocoa_seconds + 978307200
unix_seconds = cocoa_nanoseconds / 1e9 + 978307200
unix_seconds = filetime / 1e7 - 11644473600

L'outil applique ces règles et ajuste automatiquement l'échelle des valeurs Unix : tout ce qui dépasse 1e13 est ramené depuis des micro- ou nanosecondes, et tout ce qui est inférieur à 1e11 est traité comme des secondes. Les valeurs qui tombent avant 1990 ou après 2100 sont rejetées comme invraisemblables, et l'horodatage reste vide plutôt qu'inventé. Ce garde-fou compte : un zéro, une confusion de colonnes ou une valeur Cocoa lue comme de l'Unix produisent des dates en 1970 ou 2001 qui ont l'air réelles sur un graphique.

Les formats texte méritent une méfiance particulière. Les exports texte WhatsApp et LINE impriment l'horloge locale du téléphone sans fuseau, et l'ordre de la date (jour/mois ou mois/jour) dépend des paramètres régionaux de l'appareil. Une valeur comme 03/04/2024 reste ambiguë tant qu'on ne voit pas ailleurs dans le fichier un jour supérieur à 12. L'outil déduit l'ordre à partir du fichier entier, affiche l'heure locale telle quelle en l'étiquetant UTC, et émet un avertissement pour que personne ne la confonde avec un véritable UTC. De même, les chaînes de type ISO sans fuseau comme 2024-01-02 10:00:00 sont lues comme de l'UTC, ce que signifient la plupart des exports, mais pas tous. Consignez votre hypothèse et le réglage de fuseau horaire de l'appareil dans vos notes.

L'e-mail pose le problème inverse : chaque en-tête porte un décalage explicite, mais l'en-tête Date: est écrit par le client de l'expéditeur et peut contenir n'importe quoi. La chaîne Received:, horodatée par chaque relais, constitue l'horloge indépendante à laquelle se comparer.

Intégrité des preuves

Les preuves issues des messageries sont légères, essentiellement textuelles et faciles à modifier. C'est pourquoi les pratiques d'intégrité doivent être rigoureuses et systématiques, quitte à paraître fastidieuses.

1. Hacher avant d'analyser. Calculez une empreinte cryptographique (SHA-256 est aujourd'hui la norme) de chaque fichier tel que reçu, avant qu'un outil ne l'ouvre. MessagingForensics commence par là : chaque fichier fourni est haché dans le navigateur avant la décompression des archives et toute analyse, et l'empreinte figure dans le tableau des preuves et dans les rapports.
2. Travailler sur des copies. SQLite en particulier modifie volontiers un fichier ouvert en lecture-écriture : il peut rejouer un journal -wal et le reporter dans la base principale, détruisant l'état antérieur. Conservez ensemble l'original, le -wal et le -shm, et analysez des copies.
3. Consigner le parseur et le format de chaque fichier. « Analysé comme export d'espace de travail Slack » ou « Analysé comme WhatsApp iOS (ChatStorage.sqlite) » a sa place à côté de l'empreinte. Si un fichier n'a pas été reconnu, dites-le explicitement ; les omissions silencieuses sont la façon dont les lacunes passent inaperçues.
4. Conserver les chemins d'archive. Les messages contenus dans un ZIP doivent citer le chemin du membre (export.zip!/Messages/c123/messages.json), et pas seulement l'archive, afin qu'un relecteur retrouve les octets exacts.
5. Traiter en local quand c'est possible. Téléverser des preuves vers un service tiers crée une nouvelle copie que vous ne maîtrisez pas. Un parseur exécuté dans le navigateur garde les données sur la machine de l'analyste.

Rapprocher les identités entre plateformes

La même personne apparaît comme +1 202 555 0143 dans les SMS, 12025550143@s.whatsapp.net dans WhatsApp, jdoe dans Slack, un snowflake numérique dans Discord et j.doe@example.test dans l'e-mail. Les noms affichés se télescopent et changent ; ce sont les identifiants qui servent de pivot.

Points d'ancrage utiles :

• Numéros de téléphone normalisés au format E.164 (+12025550143). Les JID WhatsApp, Signal, Viber, les identifiants iMessage et les adresses SMS s'y ramènent tous.
• Adresses e-mail, en minuscules. Elles relient l'e-mail, iMessage (identifiants Apple ID), les profils Teams et Slack, et Google Chat.
• Identifiants utilisateur des plateformes tirés des champs extra : identifiants Slack U…, snowflakes Discord, identifiants Telegram user…. Ils survivent aux changements de nom.
• Indicateurs partagés dans le contenu : la même URL, le même portefeuille crypto ou le même IBAN apparaissant sur plusieurs plateformes constitue souvent le lien le plus solide entre des comptes.

MessagingForensics extrait du texte et des objets des messages les URL, adresses e-mail, numéros de téléphone au format international, adresses IPv4, adresses Bitcoin et Ethereum et IBAN, et compte le nombre de messages qui contiennent chacun d'eux. Les motifs sont volontairement prudents : un numéro de téléphone doit commencer par +, si bien que les numéros au format national ne sont pas capturés. Considérez cette liste comme un point de départ pour pivoter, pas comme un inventaire exhaustif. Les listes de surveillance (des mots-clés, un par ligne) filtrent ensuite la chronologie combinée pour ne garder que les messages pertinents.

Pièges courants

Bases chiffrées. La base de Signal Desktop est chiffrée avec SQLCipher ; il faut la clé issue du profil pour la déchiffrer avant qu'un parseur puisse la lire. Les sauvegardes WhatsApp Android (.crypt14, .crypt15) exigent le fichier de clé ou le mot de passe de la sauvegarde chiffrée de bout en bout. Le cache de Telegram Desktop est chiffré. Si vous ne disposez que du fichier chiffré, la solution relève de l'acquisition, pas de l'analyse.

Exports limités au titulaire. Le paquet de données Discord ne contient que les messages envoyés par le compte demandeur, pas l'autre côté de la conversation. Les exports Messenger et Instagram reflètent ce que ce compte pouvait voir au moment de l'export. Indiquez toujours de quel point de vue un export rend compte.

Messages supprimés. Les exports les incluent rarement ; les bases de données parfois, sous forme de lignes marquées comme supprimées ou dans des pages non allouées. Un indicateur « supprimé » dans le modèle normalisé signifie que la source a enregistré une suppression. L'absence d'un message ne prouve rien quant à son existence.

Fuseaux horaires. Mélanger des exports texte en heure locale avec des horodatages UTC issus de bases de données peut décaler des événements de plusieurs heures et réordonner une conversation. Normalisez tout en UTC, signalez les lignes qui n'ont pas pu l'être, et notez les changements d'heure été/hiver sur la période.

Doublons entre sources. Le même message peut figurer dans un export WhatsApp, dans msgstore.db et sur le téléphone de l'interlocuteur ; le même e-mail dans deux boîtes aux lettres et un MBOX. Dédoublonnez sur des identifiants stables (Message-ID, identifiants de message des plateformes) lorsqu'ils existent, et sinon sur horodatage plus expéditeur plus empreinte du texte, mais conservez chaque référence de source : un message retrouvé sur les deux appareils constitue une preuve plus forte qu'un message retrouvé sur un seul.

Modifications. Un message modifié peut ne porter que son texte final. Si la source enregistre une heure de modification, conservez-la ; si la plateforme garde un historique, il se trouve dans une autre table ou un autre fichier.

Dérive des noms affichés. Les contacts sont renommés, les groupes changent de titre, et les exports impriment le nom en vigueur au moment de l'export, pas au moment de l'envoi.

Pour aller plus loin

Essayez le parseur MessagingForensics : déposez des exports ou des bases de données dans le navigateur et obtenez des empreintes SHA-256 pour chaque fichier, une chronologie UTC unifiée, les indicateurs extraits et des rapports CSV, JSON ou HTML, sans rien téléverser.

Approfondissez ensuite source par source (articles en anglais) :

• Forensique des en-têtes e-mail
• Forensique Microsoft Teams
• Forensique des exports Slack
• Forensique WhatsApp
• Forensique du paquet de données Discord
• Forensique de chat.db (iMessage)