Que ce soit suite à l’achat d’un nouveau disque, pour faire une sauvegarde, ou toute autre raison, vous souhaitez copier, à l’identique, le contenu d’un disque dur ou d’une clef USB. Mais, comme on n’est jamais trop prudent, le mieux est de s’assurer de ne rien toucher à l’original. On vous montre comment faire avec Ubuntu.
Lors d’une expertise, lorsque nous devons mener une investigation sur une pièce d’un dossier, il est important de la conserver intacte.
Imaginez-vous… Vous ouvrez votre scellé, vous branchez le disque dur qu’il contenait. Une fausse manipulation, et hop ! Des pièces à conviction disparaissent…
Avant toute action, il est donc indispensable de copier les disques durs et autres clés USB, afin de pouvoir travailler sur ces copies l’esprit tranquille.
Nous allons donc vous montrer comment vous y prendre en utilisant Ubuntu.

Désactiver montage automatique
⚠️ Ne branchez pas votre disque tout de suite !
Comme le but est de toucher le moins possible à l’original, la première chose à faire est de désactiver le montage automatique. Cela évitera de modifier quoique ce soit sur le support. Pour cela, on a besoin d’installer le paquet dconf-editor
Lancer ensuite dconf-editor
. Naviguez jusqu’à org.gnome.desktop.media-handling
. De là, vous pouvez désactiver le montage automatique des media amovibles, en passant automount de I à O.

Repérer son disque
Vous êtes à présent sûr que votre disque ne va pas se monter tout seul, et qu’une mauvaise manipulation ne pourra pas modifier quoique ce soit. Vous pouvez donc brancher votre disque.
Éteignez votre PC, branchez votre disque, redémarrez.
Vous allez devoir repérer à quel périphérique correspond votre disque. Pour cela, on utilise fdisk.
Les disques dur SATA et SSD sont dans dev/sd…
, les disques IDE /dev/hd…
. Servez-vous de vos connaissances sur votre disque dur pour le retrouver (en utilisant sa taille, l’OS installé…).
Par exemple : je cherche à repérer une clef USB de 32Go contenant mes données à investiguer…
Après avoir faire un fdisk, je repère deux périphériques intéressants, l’un dans
/dev/sda
et l’autre dansdev/sdb
. En observant les détails, je peux me rendre compte que le disque dur SSD de 240Go sur lequel tourne mon linux se trouve dans/dev/sda
et que ma clef USB qui fait 32Gb se trouve dans/dev/sdb
. L’affichage utilisant des GiB, soit des Gibibytes, les valeurs sont légèrement inférieures à celles en Go.Disque /dev/sda : 223,6 GiB, 240057409536 octets, 468862128 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Type d'étiquette de disque : dos Identifiant de disque : ---- Périphérique Amorçage Début Fin Secteurs Taille Id Type /dev/sda1 * 2048 468860927 468858880 223,6G 83 Linux Disque /dev/sdb : 29,3 GiB, 31457280000 octets, 61440000 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Type d'étiquette de disque : dos Identifiant de disque : ---- Périphérique Amorçage Début Fin Secteurs Taille Id Type /dev/sdb1 * 64 61439999 61439936 29,3G b W95 FAT32
Calculer la somme de contrôle
Afin de pouvoir vérifier si des données ont été modifiée, on va en calculer la somme de contrôle. En comparant le résultat avant et après la manipulation, on contrôlera qu’aucune donnée n’a été altérée.
De base, dans le Référentiel Général de Sécurité, on nous dit que les fonctions de hachage doivent générer des empreintes de 200bits (avant 2020). Mais comme chez les arsouyes, on est en avance sur notre temps, on utilise la recommandations durcie pour après 2020, c’est à dire 256 bits[^anssi].
Toujours dans le RGS, SHA-256 est recommandée… Ce qui tombe bien, car sur Ubuntu, sha256sum
est installé par défaut. On peut l’utiliser pour faire l’empreinte d’un périphérique en le couplant à dd.
En mettant en entrée (if
) votre périphérique et en envoyant la sortie sur sha256sum, on obtient l’empreinte SHA-256 du périphérique.
time sudo dd if=/dev/sdb |sha256sum
61440000+0 enregistrements lus
61440000+0 enregistrements écrits
31457280000 bytes (31 GB, 29 GiB) copied, 1773,13 s, 17,7 MB/s
e3375bb22d59233757cbcb24d7f4ffa7b25eaff40e60e40f42f3a22435bf2655 -
real 29m33,203s
user 12m44,728s
sys 4m15,840s
En utilisant
time
, on peut se rendre compte que pour calculer l’empreinte de ma clef de 32Go, il a fallu 30 minutes environ. Bon à savoir lorsque l’on aura un disque de 1To.
Copier le disque
On a branché le périphérique, en s’assurant qu’on ne pouvait pas faire de bêtises, on a fait une empreinte, il ne nous reste plus qu’à le cloner. Pour cela, on utilise encore une fois dd
avec la commande suivante :
Où les paramètres ont le sens suivant :
- device est votre périphérique, dans le cas de ma clef USB,
/dev/sdb
- fichier.iso est le fichier image dans lequel sera cloné mon périphérique
- conv=notrunc,noerror signifient de ne pas tronquer le fichier en sortie et de continuer en cas d’erreur
- status=progress me permet de savoir où j’en suis dans ma copie.
time sudo dd if=/dev/sdb of=clef.iso conv=notrunc,noerror status=progress
31444406272 bytes (31 GB, 29 GiB) copied, 1981 s, 15,9 MB/s
61440000+0 enregistrements lus
61440000+0 enregistrements écrits
31457280000 bytes (31 GB, 29 GiB) copied, 1981,74 s, 15,9 MB/s
real 33m4,898s
user 1m36,367s
sys 11m27,615s
Notez que ça m’a pris encore une demie heure…
Vérifier l’intégrité
Notre copie est faite, nous allons calculer une nouvelle empreinte du périphérique, afin de vérifier que celui-ci n’a pas été altéré pendant la copie. Profitons-en également pour vérifier que la copie est bien conforme à l’originale.
On refait l’empreinte du périphérique. Même commande que tout à l’heure :
time sudo dd if=/dev/sdb |sha256sum
[sudo] Mot de passe de arsouyes :
61440000+0 enregistrements lus
61440000+0 enregistrements écrits
31457280000 bytes (31 GB, 29 GiB) copied, 1755,58 s, 17,9 MB/s
e3375bb22d59233757cbcb24d7f4ffa7b25eaff40e60e40f42f3a22435bf2655 -
real 29m18,712s
user 10m34,172s
sys 3m37,959s
Puis, on fait le SHA 256 de l‘iso (pour vérifier que la copie est bien conforme à l’original) :
time sudo dd if=clef.iso |sha256sum
[sudo] Mot de passe de arsouyes :
61440000+0 enregistrements lus
61440000+0 enregistrements écrits
31457280000 bytes (31 GB, 29 GiB) copied, 1111,31 s, 28,3 MB/s
e3375bb22d59233757cbcb24d7f4ffa7b25eaff40e60e40f42f3a22435bf2655 -
real 18m34,487s
user 10m2,526s
sys 3m56,255s
Et enfin on compare les empreintes. Ici, bingo, elles sont bien identiques.
Une donnée altérée serait détectée par un sha256 différent :
- Si celle du fichier iso est différente, je vous conseil de refaire la copie.
- Si celle du disque après copie est différente, votre disque a été altéré, vous pourriez utiliser l’ISO pour réécrire le disque original.
- Si les deux diffèrent, c’est trop tard et si c’est important, il faudra peut être regarder où ils diffèrent.
Vous pouvez aussi mettre l’empreinte initiale dans un fichier (par exemple Initial_CHECKSUM) et calculer l’empreinte avec l’option
-c
comme suit :sudo dd if=device | sha256sum -c Initial_CHECKSUM
Où
device
est soit votre fichier iso, soit votre périphérique (en fonction de ce que vous voulez faire).Si l’empreinte est la même, vous aurez un joli petit
OK
en sortie, mais si l’empreinte diffère, vous obtiendrez unFAILED
suivit desha256sum: WARNING: 1 computed checksum did NOT match
.
Et après
Maintenant que vous avez une copie toute belle de votre périphérique, vous allez pouvoir replacer votre original dans son petit sachet et refermer votre scellé.
Si vous n’êtes pas expert judiciaire et que vous n’avez pas à gérer de scellés, vous pouvez quand même être fier de ne rien avoir modifié sur votre disque original.
- Backup de données chez OVH avec duplicity
11 février 2019 Il serait dommage de perdre nos données personnelles. Grâce aux serveurs de OVH et à duplicity, il est facile de mettre en place un système de sauvegarde automatique.
- Récupération des données sauvegardées chez OVH avec duplicity
18 mars 2019 Les commandes utiles pour lister et récupérer ses fichers une fois que l’on a sauvegardé ses données dans le Public Cloud OVH avec duplicity.
- Backup de dépôt gitlab
4 mars 2019 Afin de sauvegarder ses dépôts gitlab, il peut être utile de faire un miroir de son dépôt afin de conserver sur un serveur distant ses fichiers, mais également toutes les modifications