antisèche: dd

Quelques petites choses utiles avec dd(1)

Créer un fichier d’une taille donnée:

en vitesse (un fichier sans données, rempli de \0):

dd if=/dev/zero of=monFichier bs=1024 count=S # S taille en KiB

plus lentement (le fichier sera rempli de données aléatoires):

dd if=/dev/random of=monFichier bs=1024 count=S

Trafiquer le MBR d’un disque:

La petite chose à savoir, le MBR correspond aux 512 premiers octets du disque, répartis comme suit:

  • les 446 premiers sont pour le gestionnaire de boot ;
  • les 64 suivants correspondent à la table de partition ;
  • les 2 derniers sont la signature du disque.

Effacer le secteur d’amorçage (sans toucher à la table de partition):

dd if=/dev/zero of=/dev/sdX bs=446 count=1

Effacer juste la table de partitions (sans toucher au MBR):

dd if=/dev/zero of=/dev/sdX bs=1 seek=446 count=64

note: pas testé 😉

Efface la table de partition et le MBR:

dd if=/dev/zero of=/dev/sdX bs=512 count=1

Pour finir, si on veut écraser et pas juste effacer, on remplace /dev/zero par /dev/random.

6 thoughts on “antisèche: dd

  1. Il n’a jamais été demontré qu’on pouvait reconstituer les données d’une partition (ou d’un disk entier) aprés l’execution d’un: dd if=/dev/zero of={ma_partition|disk}

    L’usage d’un “/dev/random” étant beaucoup plus lent, on pourra s’en passer.

    • Il y a pourtant des “gens” qui sont capables de récupérer des données sur des disques qui ont subit bien pire que ça…
      Quant au choix de /dev/zero ou /dev/random, tout dépend de ton but.

  2. N’est-ce pas dangereux d’utiliser /dev/random ? Les données aléatoires qui seront écrites pourraient être considérées comme valide par des outils tels que fdisk (et équivalents) et donc les rendre totalement imprévisibles.
    De manière général je doute qu’il soit judicieux de modifier le MBR à l’aide de dd. On peut en faire une sauvegarde. Il m’est déjà arrivé qu’un disque perde son MBR à cause d’une mauvaise manip ou d’un bug ce qui a rendu le disque totalement inutilisable puisque plus aucune partition n’était détectée et donc plus aucune données n’était accessible. Par chance j’avais sauvegardé le MBR via dd et je l’ai donc restauré toujours via dd, le disque est alors redevenu utilisable.

    • Disons qu’utiliser /dev/random est un moyen rapide de rendre le disque inutilisable 🙂
      Personnellement, je ne touche au MBR avec dd que lorsque je veux l’effacer: typiquement, quand je recycle une machine et que je ne veux pas être gêné par ce qui a pu être mis dessus avant.
      Sinon, pour le backup du MBR, je ne vois pas l’intérêt de le backuper en entier:
      – le secteur de boot est facilement réparable depuis un live CD ou un système de rescue ;
      – la table de partition ne sera utile que si les disques sont les mêmes (donc, pour restaurer celle du disque que l’on vient de flinguer).

      • L’intérêt est de rattraper une erreur. Il n’est pas question de sauvegarder le MBR d’un disque pour le mettre sur un autre disque.
        Par exemple, l’année dernière un ami à voulu modifier ses partitions. Il a sauvegardé ses données puis lancé fdisk pour refaire les partitions. Une fois les partition refaites, il s’apprêtait à lancer un mkfs lorsqu’il à réalisé qu’il avait commis une erreur, une des partition supprimée n’aurait pas du l’être.
        Il fallait donc recréer la partition qui ne devait pas être modifiée, mais pour cela il faut connaitre le secteur de départ, le secteur de fin, ainsi que conserver l’ordre (afin que sda1 ne devienne pas sda2 par exemple).
        C’est juste impossible à faire si on à pas pris des notes avant.
        Par contre, s’il avait sauvegardé le MBR, il aurait pu le restaurer, il n’y aurait alors eu aucune perte de données, il aurait juste eu à recommencer le nouveau partitionnement (sans se tromper cette fois-ci).

        • Je suis complètement d’accord sur l’utilité de sauvegarder le MBR avant de jouer avec fdisk, même si tout le MBR n’est pas utile dans ce cas (seule la table des partitions suffit).

Comments are closed.