Ce que contient vraiment une extraction Full File System, et pourquoi l'essentiel n'est jamais exploité
La question intéressante n'est pas la taille d'une extraction. C'est la proportion sur laquelle un outil quelconque a un avis.
Demandez à quelqu’un d’extérieur au métier ce qu’il y a sur un téléphone saisi, il répondra des messages, des photos et des contacts. Demandez-le à un analyste, il marquera une pause, parce que la réponse honnête est que personne ne le sait entièrement, et que le découvrir constitue le travail.
Une extraction Full File System est une copie du système de fichiers de l’appareil tel que le système d’exploitation le voit. Pas un export trié, pas le sous-ensemble qu’une application accepte de livrer par une interface de sauvegarde. L’arborescence entière.
Il vaut la peine de détailler ce qui s’y trouve réellement, parce que la forme de ces données explique presque tout de la répartition du temps d’exploitation.
Quatre couches, par ordre d’attention décroissante
La couche à laquelle tout le monde pense. Messages, journaux d’appels, contacts, pellicule. C’est réellement important, c’est en général ce sur quoi l’affaire se joue, et c’est une petite fraction de l’extraction en volume. C’est aussi la partie que tous les outils décodent bien, parce que c’est la partie pour laquelle ils ont été construits d’abord.
Le stockage applicatif. Chaque application installée conserve son propre état : bases de messages et leurs métadonnées, caches de photos de profil, brouillons, historique de notifications, historique de recherche, traces de localisation, état de synchronisation. Un téléphone avec soixante applications en contient soixante, dans soixante organisations, en plusieurs formats, certains versionnés et d’autres non.
C’est dans cette couche que se trouvent de plus en plus les éléments intéressants, et c’est là que la couverture est la plus inégale. L’outil d’un analyste décodera le stockage des applications que l’éditeur a implémentées, et le reste est une liste de répertoires.
Les traces système. Le système d’exploitation consigne une quantité remarquable d’informations sur lui-même dans le cours normal de son fonctionnement : quelles applications ont tourné et quand, quels réseaux l’appareil a rejoints, quand il a été allumé, quels comptes sont configurés, ce qui a été ouvert récemment. Rien de tout cela n’a été conçu comme preuve. Une bonne part constitue une très bonne preuve, précisément parce que c’est difficile à maquiller et que cela corrobore ou contredit le récit humain.
Le sédiment. Caches de vignettes, fichiers temporaires, journaux d’écriture anticipée contenant encore des lignes supprimées de la base principale, espace non alloué où subsistent les restes d’enregistrements effacés. C’est la couche où le contenu supprimé est récupéré, et c’est aussi celle où l’analyste doit être le plus attentif, parce qu’un enregistrement récupéré et un enregistrement vivant n’ont pas la même valeur probante et ne doivent jamais être présentés comme équivalents.
Le problème de volume n’en est pas vraiment un
Un téléphone haut de gamme récent produira une extraction de quelques dizaines à quelques centaines de gigaoctets. Mais le stockage coûte peu et la lecture est rapide, donc la taille brute n’est pas la contrainte.
La contrainte est que le contenu utile est dispersé dans un grand nombre de formats, majoritairement non documentés, dont plusieurs changent entre deux versions de l’application qui les a écrits, et dont aucun n’a été conçu pour être lu par quelqu’un d’autre que cette application.
C’est pourquoi la question pertinente n’est pas la taille d’une extraction. C’est la proportion sur laquelle un outil quelconque a un avis. Tout le reste est présent, lisible en principe, et inexploitable en pratique.
Où passent les heures
Observez un analyste expérimenté traverser une extraction et la répartition du temps n’est pas celle qu’un profane imagine.
Très peu de temps est passé à lire des messages. Beaucoup est passé à déterminer quelles parties de l’extraction méritent d’être lues, puis à amener ces parties dans un état où la lecture est possible. Ouvrir une base inconnue, comprendre ce que signifient ses tables, découvrir que les horodatages utilisent une époque inhabituelle, réaliser que le corps du message est dans une table et le participant dans une autre sans jointure évidente. C’est là qu’est le travail.
C’est aussi un travail qualifié qui ne produit rien de durable. La compréhension qu’un analyste construit mardi sur le stockage d’une application vit dans sa tête, ou au mieux dans un fichier de notes personnel, et devra être reconstruite par la personne suivante qui rencontrera la même application dans un autre service six mois plus tard.
La part qui n’est jamais exploitée
Chaque laboratoire a une règle informelle sur l’endroit où s’arrêter. Elle est rarement écrite et elle est en général raisonnable : exploiter ce que l’outil a décodé, exploiter ce que l’enquêteur a expressément demandé, mentionner le reste comme non analysé.
Le résultat est une réduction de périmètre constante et invisible. Ni négligence, ni quelque chose qu’une revue de qualité signalerait, puisque le rapport décrit exactement ce qui a été exploité. Mais l’effet sur une charge de travail entière est qu’une large fraction des données saisies n’est jamais regardée par personne, et cette fraction est la plus importante précisément dans les applications qu’un éditeur a jugées commercialement inintéressantes.
Ce qui changerait la donne
Trois choses feraient bouger cela, par ordre d’effet décroissant.
La première est une couverture qui ne dépende pas du calendrier de publication d’un tiers. Si une application inhabituelle peut être structurée le jour où l’affaire en a besoin, la règle informelle de périmètre cesse d’écarter les mêmes catégories d’éléments à chaque fois.
La deuxième est une recherche qui porte sur le sens et pas seulement sur des chaînes de caractères. L’essentiel d’une extraction reste illisible parce que personne n’a de raison de l’ouvrir. Une question posée à l’échelle du scellé entier fournit la raison.
La troisième est une vérification assez peu coûteuse pour être réellement effectuée. Un analyste qui doit passer une après-midi à confirmer l’origine d’un constat en confirmera moins. Celui qui le fait en un clic les confirmera tous, ce que le prétoire est en droit d’attendre.
Ce dernier point compte plus qu’il n’y paraît. Accélérer l’exploitation n’est utile que si cela ne la rend pas plus superficielle, et la seule protection contre cela est de rendre le contrôle si peu coûteux que le sauter ne fasse rien gagner.
VERA
VERA est un logiciel d'analyse criminalistique pour supports numériques saisis. Il structure une extraction Full File System brute, la rend consultable et interrogeable avec citation des sources, et fonctionne entièrement hors ligne sur votre infrastructure.
Demander une démonstrationÀ lire aussi
Vérifier les sorties d'IA en criminalistique numérique : ce qu'une juridiction doit pouvoir voir
Un assistant IA dans un outil de criminalistique n'est utilisable que si sa sortie peut être contrôlée contre l'enregistrement d'origine. Cette exigence n'est pas un détail de conformité, c'est la contrainte de conception dont tout le reste découle.
Pourquoi l'hébergement sur site compte pour les données de supports saisis
Pour un laboratoire de criminalistique, faire tourner un logiciel d'analyse sur sa propre infrastructure n'est pas une préférence d'architecture informatique. C'est en général la différence entre pouvoir acheter un produit et ne pas pouvoir.