Pourquoi l'écriture de données aléatoires à l'aide de dd entraîne-t-elle des partitions de disque?

Avant d'exécuter la ddcommande, la commande a lsblkrenvoyé la sortie ci-dessous:

NAME              MAJ:MIN  RM   SIZE    RO TYPE  MOUNTPOINT
sda               8:0       0    931.5G  0  disk  

La commande dd if=/dev/urandom of=/dev/sda conv=fsync status=progressest exécutée. L'appareil perd cependant de la puissance et s'arrête. Lorsque l'alimentation est rétablie, la commande lsblkrenvoie la sortie suivante:

NAME              MAJ:MIN     RM   SIZE    RO TYPE  MOUNTPOINT
    sda           8:0          0   931.5G  0  disk 
      sda2        8:2          0   487.5G  0  disk

Plusieurs possibilités:

• Linux prend en charge de nombreux types de table de partition différents, dont certains utilisent très peu d'octets magiques, et il est ensuite facile d'identifier de manière erronée les données aléatoires (*) [il est donc possible de générer aléatoirement une table de partition quelque peu "valide"].

• Certains types de tables de partition ont également des sauvegardes à la fin du disque (notamment GPT) et qui pourraient être récupérées si le début du lecteur était remplacé par des déchets aléatoires.

• Le périphérique ne fonctionne pas correctement et il a été déconnecté avant la fin de l'écriture des données, ou continue de renvoyer les anciennes données, de sorte que la table de partition survit. Parfois, cela se produit avec des clés USB.

• ...

(*) Créez 1000 fichiers avec des données aléatoires et voyez ce qui en sort:

$ truncate -s 8K {0001..1000}
$ shred -n 1 {0001..1000}
$ file -s {0001..1000} | grep -v data
0099: COM executable for DOS
0300: DOS executable (COM)
0302: TTComp archive, binary, 4K dictionary
0389: Dyalog APL component file 64-bit level 1 journaled checksummed version 192.192
0407: COM executable for DOS
0475: PGP\011Secret Sub-key -
....

Le but du déchiquetage aléatoire d'un lecteur est de faire disparaître définitivement les anciennes données. Il n'y a aucune promesse que le lecteur apparaîtra vide, inutilisé, en parfait état par la suite.

Il est courant de suivre avec un effacement nul pour y parvenir. Si vous utilisez LVM, il est normal que LVM remette à zéro les premiers secteurs de tout LV que vous créez afin que les anciennes données n'interfèrent pas.

Il existe également un utilitaire dédié ( wipefs) pour se débarrasser des anciennes signatures d'octets magiques que vous pouvez utiliser pour vous débarrasser des métadonnées du système de fichiers et de la table de partition.

Comme on le voit ici, le MBR (Master Boot Record) est relativement simple; https://en.wikipedia.org/wiki/Master_boot_record .

Lorsque vous utilisez, /dev/urandomvous pouvez toujours créer quelque chose qui ressemble à une table de partition. La solution consiste à remplir les régions de la table de partition avec zéro et à utiliser dev/urandompour le reste.

Linux prend également en charge d'autres formats de disque supplémentaires qui peuvent également potentiellement être déclenchés, provoquant l'apparition de partitions «non valides» lors du remplissage avec des données aléatoires.

La chose qui définit une collection de 512 octets comme étant un enregistrement de démarrage principal est la présence des valeurs 0x55 0xAAà la fin. Il y a 1 chance sur 65 536 de /dev/urandomproduire une telle valeur: pas trop probable, mais des choses tout aussi improbables se produisent tout le temps.

(Certaines autres tables de partition, telles que la carte de partition Apple , ont des signatures également courtes. Il est possible que vous en ayez plutôt généré une.)

Cette partition était-elle présente quelque temps auparavant sur ce disque? Si le disque utilise GPT, l'en-tête GPT secondaire a peut-être été restauré et il y avait toujours l'ancienne table de partition.

https://en.wikipedia.org/wiki/GUID_Partition_Table