Quand j’ai reçu cette mission du magistrat, elle m’a semblé classique, presque banale : je dois vérifier la présence (ou pas) d’un ensemble de données commerciales qui intéressent les enquêteurs.

Je reçois quelques jours plus tard le scellé judiciaire : un bel ordinateur fixe emballé dans du papier kraft d’un autre siècle. Je prends des photos, je brise le scellé, je prends des photos, je prends des notes, j’ouvre l’ordinateur, je prends des photos de ses entrailles : il y a plusieurs disques durs de grosses capacités. Aïe.

Trois disques durs de 3 To*.

Je commande rapidement quatre disques de 4 To que j’agrège en RAID0 sur un FreeNAS créé pour l’occasion. Mon bureau ressemble à un capharnaüm de câbles, de PC ouverts, de disques durs en vrac… Plus que tout, je crains une panne matérielle impromptu sur les disques du scellé. J’installe un grand ventilateur et je me dépêche de faire une copie bit à bit de chaque disque.

Je commence mon analyse en bootant une machine virtuelle sur une copie du disque système du scellé. Première étape : comprendre la logique de rangement de l’utilisateur de l’ordinateur. Où se trouvent les données non effacées, y a-t-il un système de chiffrement, quels sont les logiciels utilisés, quels sont les différents mots de passe, etc. Je lance quelques logiciels de recherche basiques pour voir si les données que l’on me demande sont présentes en clair sur l’un des disques durs. Rien.

Je travaille sur le dossier tous les soirs (je suis salarié d’une école d’ingénieurs, j’y travaille de 8h à 19h du lundi au vendredi, je ne peux consacrer du temps à cette analyse que les soirs après 21h et les week-ends). Entre le montage du FreeNAS, les copies des disques durs et les premières analyses des données, il s’est déjà écoulé trois semaines. Le magistrat m’a demandé de rendre mon rapport en deux mois. Je suis encore dans les temps.

Je commence une analyse plus en profondeur des données, avec le logiciel TSK (The Sleuth Kit) et son interface graphique Autopsy. Quelques jours de calculs plus tard, je trouve des traces de fichiers qui concernent le dossier.

Par contre, ces traces sont « bizarres ». Les fichiers ne sont pas détectés sur un système de fichiers Windows (alors que l’ordinateur que l’on m’a amené fonctionne sous Windows), mais sous un système GNU/Linux…

C’est curieux.

Je regarde de plus près la zone du disque où j’ai repéré ces traces. Il s’agit d’un gros fichier « vdi ». C’est un type de fichier qui, par convention, est utilisé par VirtualBox. Je vérifie : oui, ce logiciel est bien installé sur le scellé.

VirtualBox est un logiciel bien connu, qui permet de gérer et faire fonctionner des machines virtuelles sur un ordinateur. Je l’utilise couramment, surtout depuis que j’ai abandonné Windows 10 pour Mint (j’ai toujours un Windows 7 « sécurisé » que je fais tourner en machine virtuelle pour certains logiciels dont j’ai encore l’usage…).

Mon utilisateur est donc adepte de VirtualBox. Je fais la liste des machines virtuelles présentes sur le scellé (enfin sur les copies des disques, ça fait longtemps que j’ai remonté le scellé et qu’il est rangé, ainsi que mon gros ventilateur), ainsi que la liste des fichiers « vdi » et assimilés.

Il y a plein de fichiers « vdi », tous avec des noms plus ou moins farfelus…

Je récupère les informations des différentes machines virtuelles pour comprendre comment les disques virtuels sont organisés, quelle machine utilise quel(s) disque(s), et quels sont les différents systèmes d’exploitations installés.

Puis, je transfère toutes ces machines virtuelles pour les démarrer une par une sur un ordinateur fraîchement installé pour cela (avec la même version de VirtualBox que celle du scellé).

Et là, je tombe une configuration un peu surprenante : une machine virtuelle avec trois disques durs virtuels, qui, quand on la démarre, affiche une invite « openmediavault login »… OpenMediaVault est un projet open source de gestion de NAS.

Je teste les différents mots de passe récupérés sur l’hôte Windows, pour me connecter sur l’interface web, et je découvre un volume de stockage réparti en RAID1 sur deux fichiers virtuels, eux-même repartis sur deux des trois disques durs physiques. Le tout est accessible « à tout le monde » en mode SMB/CIFS depuis l’hôte Windows…

Évidemment, les données intéressantes étaient stockées à cet endroit là.

Donc je résume : l’utilisateur du scellé sur lequel est installé Windows, a installé un NAS virtuel qui propose du stockage local accessible à tous localement sans mot de passe.

Je n’ai pas compris la logique du truc. Quel est l’intérêt d’utiliser un NAS OpenMediaVault virtuel local pour stocker des données ? Quel est l’intérêt de proposer ensuite un accès « pour tous » à ces données, même localement ? Quel est l’intérêt de monter un RAID1 virtuel Debian sur deux fichiers gérés par Windows ?

J’ai eu beau tourner le problème dans ma tête, je n’ai pas compris la logique de l’autre. Parfois, il vaut mieux ne pas savoir…

J’ai évalué à 200h le temps passé sur ce dossier. Je n’en ai facturé
que 30… Et je n’ai pas fait payer le matériel acheté (essentiellement
les disques durs, que j’utilise maintenant dans mon système de
sauvegarde/stockage). Par contre, j’ai beaucoup galéré pour la rédaction du rapport. Pour rester le plus clair possible, j’ai repoussé mes investigations techniques (et les explications associées) en annexe.

Pas sur qu’elles aient été lues par grand monde 😉

——————————————

* : le dossier étant ancien, j’ai « actualisé » les valeurs citées, en particulier les capacités des disques.