Que fait `dd if = / dev / zero of = / dev / sda` do

19

Modifié: ne l'exécutez pas pour le tester, sauf si vous souhaitez détruire des données.

Quelqu'un pourrait-il m'aider à comprendre ce que j'ai obtenu?

  1. dd if=/dev/zero of=/dev/sda bs=4096 count=4096

    Q: Pourquoi spécifiquement 4096 pour count?

  2. dd if=/dev/zero of=/dev/sda bs=512 count=4096 seek=$(expr blockdev --getsz /dev/sda - 4096)

    Q: Qu'est-ce que cela fait exactement?

udev dd disk JH
la source
4
Où avez-vous trouvé ce code malveillant
Suici Doga
10
Ce n'est pas du code malveillant.
Michael Hampton
12
@MichaelHampton: s / malveillant / destructif / Bien que la publication de code destructeur ne soit pas malveillante en soi, la publier sans avertissement clair qu'elle peut détruire des données EST.
Ben Voigt
1
Il est préférable de considérer DD comme «Destructeur de disque» lorsque quelqu'un sur Internet vous dit d'exécuter une commande comme celle-ci.
Bobby Sacamano
3
DD signifie en fait la description des données
Suici Doga

Réponses:

43

dd if = / dev / zero of = / dev / sda bs = 4096 count = 4096 Q: pourquoi 4096 est particulièrement utilisé pour le compteur?

Cela mettra à zéro les 16 premiers Mo du lecteur. 16 Mio est probablement plus que suffisant pour neutraliser toute structure de "début de disque" tout en étant suffisamment petit pour ne pas prendre très longtemps.

dd if = / dev / zero of = / dev / sda bs = 512 count = 4096 cherche = $ (expr blockdev --getsz / dev / sda - 4096)

Q: Qu'est-ce que c'est exactement?

blockdev --getszobtient la taille du périphérique de bloc dans "secteurs de 512 octets". Cette commande semble donc destinée à mettre à zéro les 2 derniers Mo du lecteur.

Malheureusement, cette commande est rompue en termes de syntaxe. Je suppose que la commande était initialement destinée à être

dd if=/dev/zero of=/dev/sda bs=512 count=4096 seek=$(expr `blockdev --getsz /dev/sda` - 4096)

et les retours en arrière se sont perdus quelque part le long de la ligne des gens qui le copient / collent entre différents environnements.

Les anciennes tables de partition, les métadonnées LVM, les métadonnées de raid, etc. peuvent causer des problèmes lors de la réutilisation d'un lecteur. La remise à zéro des sections au début et à la fin du lecteur évite généralement ces problèmes tout en étant beaucoup plus rapide que la remise à zéro complète du lecteur.

plugwash
la source
4
Je vous remercie. Cette réponse semble répondre le plus à ce que je cherchais. Les deux commandes sont utilisées après delpart. Ils sont utilisés pour essuyer un disque pour une réutilisation aussi propre.
JH
expr blockdev --getsz /dev/sda - 4096serait une erreur de syntaxe de expr. Je pense que la commande prévue était ...seek="$(expr "$(blockdev --getsz /dev/sda)" - 4096)". Ou mieux:...seek="$(($(blockdev --getsz /dev/sda) - 4096))"
Stéphane Chazelas
1
J'imagine qu'il y avait à l'origine des retours en arrière dans la commande et qu'ils ont été mangés à un moment donné.
plugwash
16

Cela effacera le premier 4096*4096=16MBet le dernier 512*4096=2MBde votre disque dur, qui contiennent des structures importantes utiles pour la récupération. Je suppose que ce code a été affiché avec malveillance.

Je n'ai jamais rencontré de situation où spécifier explicitement un countautre qu'était 1utile. J'ai effacé le premier bloc si je voulais assurer que je ne partais pas de traces de derrière MBR ...

o11c
la source
8
Ce n'est pas forcément malveillant, j'ai eu de mauvais programmes de formatage qui refusent d'écrire une nouvelle étiquette si celle-ci est endommagée, et j'ai donc dû remettre à zéro manuellement les premiers octets comme celui-ci.
Shelvacu
1
@shelvacu Je serais surpris si le lecteur manipulé de cette façon l'était sda. Plus probable sdbou sdc. Mais je peux me tromper bien sûr ...
yo '
7
Ce n'est pas malveillant. Il efface le GPT au début du disque et le GPT de sauvegarde à la fin du disque.
Michael Hampton
2
@shelvacu: C'est destructeur. Si des commandes destructrices ont été publiées sans explication de ce qu'elles font, c'est malveillant. S'ils étaient accompagnés d'une explication, pourquoi OP pose-t-il une question à ce sujet ici?
Ben Voigt
2
Alors, qui, dans son esprit parfait, va copier / coller des codes trouvés n'importe où sans connaître son objectif? Pas malicieux car je ne secouerai aucun appareil étrange que j'ai trouvé dans le métro.
Magno C
4

Ces commandes écraseront votre appareil sda avec des zéros - la première fera les 16 premiers Mo (taille de bloc de 4096 et compte de 4096 blocs) et la seconde remplacera les 2 Mo derniers (taille de 512 blocs avec 4096 blocs) avec des zéros. (il ne s'agit pas d'effacement technique, et cela se rapporte à mon premier point ci-dessous.)

(c'était la partie déjà mentionnée dans d'autres réponses, y compris ici pour être complet)

Une autre chose qui mérite d'être mentionnée est que la taille du bloc a des effets, mais ceux-ci ne sont généralement visibles que sur les opérations à volume élevé. La façon la plus efficace (la plus rapide) d'exécuter la commande est si la taille de bloc de la commande correspond à la taille d'accès du périphérique, sinon le temps est perdu.

Si vous êtes intéressé, vous pouvez essayer de créer un fichier avec un million de blocs de 1 bloc et un fichier avec 1 million de blocs et voir la différence:

[user@host tmp]$ time dd if=/dev/zero of=/tmp/test1 bs=1 count=1000000
1000000+0 records in
1000000+0 records out
1000000 bytes (1.0 MB) copied, 2.44439 s, 409 kB/s

real    0m2.447s
user    0m0.177s
sys     0m2.269s
[user@host tmp]$ time dd if=/dev/zero of=/tmp/test2 bs=1000000 count=1
1+0 records in
1+0 records out
1000000 bytes (1.0 MB) copied, 0.00155357 s, 644 MB/s

real    0m0.003s
user    0m0.001s
sys     0m0.002s
[user@host tmp]$ ls -al test*
-rw-rw---- 1 user grp 1000000 Apr  8 15:51 test1
-rw-rw---- 1 user grp 1000000 Apr  8 15:51 test2

Comme vous pouvez le voir, la taille de bloc a un impact énorme sur l'efficacité. C'est peut-être une barre latérale pour le PO, mais je pense que c'est toujours pertinent.

TL; DR: N'exécutez pas de code arbitraire que vous trouvez sur le net, ou que quelqu'un à qui vous ne faites pas confiance vous donne. Ça va gâcher ta journée.

Tim S.
la source
7
+1 pour la Don't execute arbitrary code you find on the netligne
Sergiy Kolodyazhnyy
7
"Notez que ce processus est extrêmement fastidieux et / ou coûteux et nécessite un équipement extrêmement spécifique." Arrêtez de diffuser cette désinformation. La dernière fois que cela était même théoriquement possible, c'était il y a des décennies avec une technologie obsolète depuis de nombreuses générations. Personne n'a jamais démontré ce type de récupération sur des disques modernes, même en réponse à des défis publics avec des prix en argent, par exemple hostjury.com/blog/view/195/…
Andrew Medico
J'ai supprimé cette section - je suppose que cela fait un moment que je n'en ai pas entendu parler. Je dirai cependant que "théoriquement" était le mot clé, mais je m'égare.
Tim S.
2

D'autres ont expliqué ce qu'ils font, alors je vais sauter cela.

Le point d' ddavoir séparé bset countargument est que bscontrôle la quantité écrite à la fois . Spécifier des valeurs très grandes pour bsnécessitera un très grand tampon dans le programme, et spécifier des valeurs inférieures à la taille de bloc du périphérique sera lent car le noyau doit construire un bloc entier pour écrire sur le périphérique (dans des cas comme celui-ci, il peut probablement tamponner les écritures jusqu'à ce qu'il y ait un bloc complet, dans d'autres cas, il faudra peut-être lire ce qui est déjà sur le disque). Comme les deux commandes utilisent des valeurs différentes pour bs, cela m'amène à penser que vous les avez peut-être trouvées sur deux sites différents. Les disques durs avaient auparavant une taille de bloc de 512 octets, correspondant à labs=512de cette dernière commande, mais il y a quelques années (6-8 je pense), ils ont commencé à faire des disques avec une taille de bloc de 4096 octets, faisant bs=4096un meilleur choix pour les disques modernes.

Henrik - arrêtez de blesser Monica
la source
1
Le sweet spot for bsest beaucoup plus élevé que cela . Une seule commande SATA peut lire ou écrire plusieurs secteurs, de sorte que le noyau fusionne les E / S avant de les envoyer. Partout de bs=64kà bs=1024kest raisonnable (la taille du cache L3 est souvent de 4 à 8 Mo). J'utilise souvent bs=128k, ce qui représente la moitié de la taille du cache L2 sur les processeurs Intel modernes. ( ddcomprend deux opérations memcpy: dans la read(2)source (même si c'est / dev / zero), et le write(2).IIRC, sddavait une option pour écrire des zéros, ce qui économiserait un peu de temps CPU. Vraiment seulement pertinent si la destination est quelque chose autre qu'un disque).
Peter Cordes
Pour voir la fusion des demandes d'E / S se produire, regardez la sortie de iostat -x 4quelque chose et notez les colonnes rrqm / s (demandes de lecture fusionnées par seconde) et wrqm / s.
Peter Cordes
1

AVERTISSEMENT: dd if=/dev/zero of=/dev/ est utilisé pour nettoyer un lecteur ou un périphérique avant de copier des données de manière légale. Le lecteur ou le périphérique doit toujours être nettoyé avant de copier les informations d'un système soumis à une enquête médico-légale afin d'atténuer la contamination croisée. Par conséquent, ce n'est pas une mauvaise commande, l'utilisateur final doit comprendre à quoi il sert ou il détruira ses données. Si c'est ce que vous désirez, vérifiez l'opération d'écriture zéro dd if=/dev/sda | hexdump -C | head.

Source: Un guide pratique des enquêtes en informatique légale par le Dr Darren Hayes

SierraJuliet
la source
1

J'utilise dd if=/dev/zero of=/dev/sdX oflag=syncpour tester la qualité d'une clé USB ou d'une carte MicroSD insérée AVANT de l'utiliser réellement avec gparted, fdisk ou dd avec une image disque. Je pense que c'est une idée prudente, en particulier avec les supports MicroSD qui ont une mauvaise histoire de qualité.

Bien sûr, soyez prudent avec of = sdX car il n'y a pas de pardon avec un effacement de disque accidentel. Vérifiez que X = lettre de lecteur de la cible prévue.

Richard
la source