Chaque mission est un défi, et puisque les magistrats me confient plutôt des missions techniques, il s’agit souvent pour moi d’un défi technique. Mais comme je le répète assez souvent sur ce blog, à l’impossible nul n’est tenu. Quoique.
Deux entreprises sont en conflit commercial, et l’une accuse l’autre d’avoir récupéré par l’intermédiaire d’un transfuge un certain nombre d’informations confidentielles. Les dites informations sont contenues dans des fichiers PDF qui auraient été emmenés par le salarié débauché sur son ordinateur portable personnel. Le salarié concerné nie les faits et affirme n’avoir jamais manipulé ces fichiers sur son ordinateur personnel.
La justice a fait saisir l’ordinateur en question et comme les enquêteurs disponibles sont occupés ailleurs à faire monter le taux d’enquêtes résolues, je suis désigné pour mener à bien l’investigation. Ma mission: trouver trace du fichier “SuperConf.pdf”. Me voici donc à la maison dans mon bureau à faire l’analyse du matériel saisi. J’ai déjà expliqué ici comment je procède pour copier le disque dur afin de créer une copie parfaite (aux secteurs défectueux près). J’ai déjà raconté aussi ici les galères rencontrées dans certains démontages d’ordinateurs portables.
Dans le cas présent, une fois l’image du disque dur effectuée et transformée en machine virtuelle, je commence par me “promener” dans le système de fichiers, pour “sentir” un peu le profil de l’utilisateur de l’ordinateur: quels sont les logiciels installés, les raccourcis, l’organisation général de la machine, etc.
Très vite, je tombe sur un effaceur de traces redoutable: Eraser. Là, je me dis tout de suite que mes chances de retrouver des traces du fichier PDF recherché sont assez minces. Mais, le travail devant être fait, je lance une recherche du nom de fichier dans la zone allouée du disque dur, dans la zone non allouée, dans la table des fichiers effacés/non effacés, et partout où je peux retrouver un fragment de fichier PDF.
Comme prévu, aucun fichier “SuperConf.pdf”. Par ailleurs, la liste des fichiers effacés est parfaite vide.
Par contre, je découvre un fichier non effacé qui s’appelle “SuperConf.myd” qui se trouve dans le répertoire “Documents and SettingscépasmoiApplication DataAdobeAcrobat”…
Étrange.
Une petite recherche sur Internet me laisse penser qu’il s’agit d’un fichier associé au système de gestion de base de données MySQL. Mais que vient faire ce SGBD dans le logiciel Acrobat? Je fouille un petit peu plus sur le disque dur pour finalement réaliser qu’il ne s’agit pas de l’habituel “Reader” gratuit mais bien de la version complète du logiciel phare de chez Adobe. Une recherche plus approfondie sur Internet ne donne pas grand chose (à l’époque;) sur l’association Acrobat/MySQL…
Comme je n’ai rien d’autre à me mettre sous la dent, je décide d’installer MySQL et ses outils sur une machine vierge et d’y transférer l’ensemble des fichiers .MYD récupérés sur le scellé (enfin sur son image). Je ne m’étendrai pas ici sur la configuration d’une instance MySQL et sur les différents échauffements toujours nécessaires pour dérouiller mes connaissances sur ce merveilleux langage qu’est SQL. J’arrive à “monter” les différents fichiers .MYD dans le SGBD et à lancer quelques commandes SELECT * dans le requéteur.
Et là, avec une certaine surprise je dois dire, je découvre que le logiciel Acrobat garde trace de tous les fichiers qu’il a manipulés, avec les informations associées: Auteur, mots clefs, nom du fichier, chemin d’accès, taille du fichier, dates diverses, sujet et d’autres encore. Et en l’espèce, tout ce qui concernait mon fichier “SuperConf.pdf”: Erazer avait effacé toute trace du fichier d’origine, mais n’avait rien retiré des traces laissées dans la base de données interne d’Acrobat.
J’ai pu ainsi rendre un rapport précisant bien que le fichier “SuperConf.pdf” avait bien été présent sur l’ordinateur mis sous scellé. Avec bien entendu toutes les réserves que je fais à chaque fois et que je rencontre trop rarement autour de moi: les dates ne prouvent pas grand chose, la présence du fichier ne signifie pas nécessairement que sa manipulation ait été faite par le propriétaire de l’ordinateur, etc.
J’ai ainsi pu vérifier une fois encore le principe de l’échange de Locard, ou son équivalent informatique:
On ne peut chiffrer ou déchiffrer une donnée, l’inscrire ou la supprimer d’une mémoire, sans apporter et déposer une trace sur l’ordinateur, sans modifier et prendre quelque chose qui s’y trouvait auparavant.
Je dois admettre que j’ai au final passé beaucoup plus de temps à essayer de rédiger un rapport clair et facilement compréhensible qu’à mener les investigations techniques…
Hyper intéressant. Donc Acrobat s'encombre d'une base MySQL et garde toutes les traces, surement pour un moteur de recherche interne, ou des fonctions d'undo/redo.
Dans les systèmes modernes, c'est une fonction complètement vestigal, ça peut être amusant de savoir dans quelles proportions les logiciels très courants mais avec une histoire assez longue disposent ainsi de fonctions de log/archives/storage qui auraient pu être intégrées à l'OS et qui finalement plombent les machines. Tout en faisant l'honneur aux forensics d'une utilité inattendue///
C'est étrange quand même un fichier dans un format mysql utilisé par adobe…
Utiliserait-il le moteur de mysql en interne?
Bizarre…
«J'ai pu ainsi rendre un rapport précisant bien que le fichier "SuperConf.pdf" »
Comment ça LE fichier ?
ne serait-ce pas UN fichier nommé "SuperConf.pdf" ? 🙂
Cette remarque doit bien sur se trouver dans le rapport d'expertise 😉
Je suis bien curieux de savoir quel version d'Adobe est utilisé. Je ne trouve chez moi, aucune trace d'une base MySQL…
@Anonyme L'anecdote est assez ancienne pour que je puisse en parler ici.
@anonyme : relisez le passage décrivant les "métadonnées" se trouvant dans la BD : "avec les informations associées: Auteur, mots clefs, nom du fichier, chemin d'accès, taille du fichier, dates diverses, sujet et d'autres encore".
A mon avis, en comparant des informations avec celles concernant le fichier d'origine, il devrait être possible de préciser un peu plus.
Ça ne m'étonne pas outre mesure qu'Acrobat utilise une base de données en interne. Je ne sais pas exactement ce qu'Acrobat pouvait bien y mettre mais pour stocker des données on peut toujours bidouiller des solutions à base de fichiers csv, xml ou autres mais le plus efficace reste une base de données. En se focalisant sur un OS particulier on peut probablement trouver une solution fournie par l'OS mais sachant qu'Acrobat est sensé tourner sous XP, Vista, 7 et Mac OS (je crois que Linux n'est pas supporté pour Acrobat) c'est une position qui n'est pas tenable. D'ailleurs Firefox utilise une base de données pour y stocker l'historique des sites visités: SQLite.
@Christophe: Ce n'est pas la BdD d'Acrobat qui m'a étonné, c'est la croyance en l'infaillibilité d'un outil d'effacement de fichier.
Les bases de données des différents logiciels présents sur les différents Os sont le régal quotidien des experts judiciaires en informatique.
@Zythom oui j'ai oublié le @ puisqu'il s'agissait plus d'une réponse à Da Scritch qui s'étonnait de ne pas utiliser les fonctionnalités de l'OS.
D'ailleurs j'ai pas mal réfléchi à ce billet en me mettant dans la peau de l'employé en question et de voir à la lueur de cette anecdote comment il aurait été possible d'éviter ça. Et bien j'en suis arrivé à une courte réponse : "c'est difficile". Même en mettant le fichier SuperConf.pdf sur une partition cachée TrueCrypt les traces auraient été là. En créant une VM dont le disque aurait été sur cette partition cachée on aurait pu retrouver des traces de cette VM dans les logs.
Je découvre ce blog fort intéressant même si me laissant un peu sceptique sur les méthodes utilisées parfois.
@Christophe
En utilisant un ramdisk, un liveCD et le fichier sur une clé usb, et la clé usb ça se cache plus facilement qu'un pc même au dernier moment, ils font des modèles tout petit maintenant (même y'a 2 ans).
Vu que de toutes façons ils font pas appel à l'expert avant mais après, le PC s'éteindra bien, y'aura pas de dump à chaud de la RAM et zou
Des traces de la VM peut-être, mais ces traces auraient elles révélé la présence du fichier en question dans la VM?
Ce qui est également intéressant ce sont vos réserves qui sont à mon avis pleinement justifiées.
Au final, je me demande comment vos rapports sont exploités.
Donc, il arrive que votre mission consiste à rechercher un fichier dont la seule info qu'on vous donne est le nom, sans aucune précision sur son contenu? Imaginons un cas plus simple où le disque n'est pas chiffré: si le gars avait pris soin de simplement renommer le fichier avant de le copier sur son disque dur, vous n'auriez jamais pu le retrouver?
Je ne garde dans mes billets que la partie des missions en rapport avec le billet, celles-ci étant souvent beaucoup plus complètes.
Sinon, oui, il arrive que l'on ne trouve rien, sans savoir si c'est parce que l'utilisateur est plus malin, ou simplement parce qu'il est innocent.