18

Edited: do not run this to test it unless you want to destroy data.

Could someone help me understand what I got?

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

    Q: Why specifically 4096 for count?

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

    Q: What exactly does this do?

  • 4
    Where did you find this malicious code – Suici Doga Apr 9 '16 at 5:07
  • 10
    This is not malicious code. – Michael Hampton Apr 9 '16 at 18:08
  • 11
    @MichaelHampton: s/malicious/destructive/ While posting destructive code is not malicious per se, posting it without a clear warning that it can destroy data IS. – Ben Voigt Apr 10 '16 at 0:07
  • It's best to think of DD as 'Disk Destroyer' when someone on the internet tells you to run a command like this. – Bobby Sacamano Apr 10 '16 at 3:10
  • 3
    actually DD means data description – Suici Doga Apr 10 '16 at 5:33
38

dd if=/dev/zero of=/dev/sda bs=4096 count=4096 Q: why 4096 is particularly used for counter?

This will zero out the first 16 MiB of the drive. 16 MiB is probably more than enough to nuke any "start of disk" structures while being small enough that it won't take very long.

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

Q: What does this exactly?

blockdev --getsz gets the size of the block device in "512 byte sectors". So this command looks like it was intended to zero out the last 2 MiB of the drive.

Unfortunately this command is broken syntax wise. I expect the command was originally intended to be

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

and the backticks got lost somewhere along the line of people copy/pasting it between different environments.

Old partition tables, LVM metadata, raid metadata etc can cause problems when reusing a drive. Zeroing out sections at the start and end of the drive will generally avoid these problems while being much faster than zeroing out the whole drive.

  • 4
    Thank you. This answer seems to meet most for what I was looking for. The two commands are used after delpart. They are used for wiping a disk for reuse as clean. – J H Apr 11 '16 at 2:07
  • expr blockdev --getsz /dev/sda - 4096 would be a syntax error of expr. I think the intended command was ...seek="$(expr "$(blockdev --getsz /dev/sda)" - 4096)". Or better: ...seek="$(($(blockdev --getsz /dev/sda) - 4096))" – Stéphane Chazelas Jun 8 '17 at 14:44
  • 1
    My guess would be that there were originally backticks in the command and they got eaten at some point. – plugwash Jun 8 '17 at 14:57
16

This will erase the first 4096*4096=16MB and last 512*4096=2MB of your hard drive, which contain important structures useful for recovery. I assume this code was posted maliciously.

I've never encounter a situation where explicitly specifying a count other than 1 was useful. I have erased the first block if I wanted to ensure I wasn't leaving any traces of the MBR behind ...

  • 8
    This isn't neccisarily malicious, I've had some bad formatting programs that refuse to write a new label if the current one is damaged, and so had to manually zero out the first few bytes like this. – Shelvacu Apr 9 '16 at 5:21
  • 1
    @shelvacu I would be surprised if the drive manipulated this way was sda. More likely sdb or sdc. But I may be wrong of course... – yo' Apr 9 '16 at 17:45
  • 7
    This is not malicious. It erases the GPT at the beginning of the disk and the backup GPT at the end of the disk. – Michael Hampton Apr 9 '16 at 18:08
  • 2
    @shelvacu: It's destructive. If destructive commands were posted without an explanation of what it does, it's malicious. If they were accompanied by an explanation, why is OP asking about it here? – Ben Voigt Apr 10 '16 at 0:08
  • 1
    So who, in its perfect mind, will copy/paste codes found anywhere without knowing its purpose? Not malicious because I'll not shake any strange device I may found at the subway. – Magno C Sep 6 '16 at 13:34
4

Those commands will overwrite your sda device with zeroes -- the first one will do the first 16MB (block size of 4096 and count of 4096 blocks) and the 2nd one will overwrite the last 2MB (512 block size with 4096 blocks) with zeroes. (it's not technically erasing, and that relates to my first point below.)

(that was the part already mentioned in other answers, including it here for completeness)

Another thing that is worth mentioning is that the block size does have effects, but those are generally only seen on high-volume operations. The most efficient (fastest) way to execute the command is if the block size of the command matches the access size of the device, otherwise time is wasted.

If you're interested, you can try creating a file with a million 1-block chunks, and a file with 1 million block chunks and see the difference:

[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

As you can see, blocksize has a massive impact on efficiency. That's perhaps a sidebar to the OP, but I feel that it's still relevant.

TL;DR: Don't execute arbitrary code you find on the net, or that someone you don't trust gives you. It'll ruin your day.

  • 7
    +1 for the Don't execute arbitrary code you find on the net line – Sergiy Kolodyazhnyy Apr 9 '16 at 14:48
  • 7
    "Note that this process is extremely tedious and/or expensive and requires extremely specific equipment." Stop spreading this misinformation. The last time this was even theoretically possible was decades ago on technology that is many generations obsolete now. No one has ever demonstrated this kind of recover on modern drives, even in response to public challenges with prize money, e.g. hostjury.com/blog/view/195/… – Andrew Medico Apr 9 '16 at 17:57
  • I removed that section -- guess it's been a while since I first heard about that. I will say however, that "theoretically" was the operative word, but I digress. – Tim S. Apr 11 '16 at 13:59
2

Others have explained what they do, so I'll skip that.

The point in dd having seperate bs and count argument is that bs controls how much is written at a time. Specifying really large values for bs will require a really large buffer in the program, and specifying values less than the block size of the device will be slow because the kernel has to build an entire block to write to the device (in cases like this it can probably buffer the writes until there a complete block, in other cases it might have to read what's already on the disc). As the two commands use different values for bs, that leads me to think that you might have found them on two different sites. Hard discs used to have a block size of 512 bytes, corresponding to the bs=512 of the latter command, but some (6-8 I think) years ago they started making discs with a block size of 4096 bytes, making bs=4096 a better choice for modern discs.

  • 1
    The sweet spot for bs is much higher than that. A single SATA command can read or write multiple sectors, so the kernel merges I/Os before sending them out. Anywhere from bs=64k to bs=1024k is reasonable (L3 cache size is often 4-8MiB). I often use bs=128k, which is half of L2 cache size on modern Intel CPUs. (dd includes two memcpy operations: in the read(2) from the source (even if it's /dev/zero), and the write(2). IIRC, sdd had an option to write zeros, which would save a bit of CPU time. Really only relevant if the destination is something other than a disk). – Peter Cordes Apr 10 '16 at 2:32
  • To see I/O request merging happening, look at the output of iostat -x 4 or something, and note the rrqm/s (read-requests merged per second) and wrqm/s columns. – Peter Cordes Apr 10 '16 at 2:33
1

WARNING: dd if=/dev/zero of=/dev/ is used to clean a drive or device before forensically copying data. The drive or device must always be sanitized before copying information from a system under forensic investigation to mitigate cross contamination. Therefore, it is not a bad command, the end-user must understand what it is used for or they will destroy their data. If this is what you desire then to verify the zero write operation do dd if=/dev/sda | hexdump -C | head.

Source: A Practical Guide to Computer Forensics Investigations by Dr Darren Hayes

0

I use dd if=/dev/zero of=/dev/sdX oflag=sync to test quality of an inserted USB drive or MicroSD card BEFORE I actually use it with gparted, fdisk, or dd with a disk image. I think that this is a prudent idea, especially with MicroSD media which has a poor history of quality.

Of course, be careful with of=sdX because there is no forgiveness with an accidental disk wipe. Verify that X= drive letter of intended target.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.