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?

Warning; Above code will render some/all specified device/disk's data useless!

  • 4
    Where did you find this malicious code
    – Suici Doga
    Commented Apr 9, 2016 at 5:07
  • 13
    This is not malicious code. Commented Apr 9, 2016 at 18:08
  • 15
    @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
    Commented Apr 10, 2016 at 0:07
  • 3
    It's best to think of DD as 'Disk Destroyer' when someone on the internet tells you to run a command like this. Commented Apr 10, 2016 at 3:10
  • 5
    actually DD means data description
    – Suici Doga
    Commented Apr 10, 2016 at 5:33

7 Answers 7


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.

  • 5
    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
    Commented Apr 11, 2016 at 2:07
  • 1
    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))" Commented Jun 8, 2017 at 14:44
  • 2
    My guess would be that there were originally backticks in the command and they got eaten at some point.
    – plugwash
    Commented Jun 8, 2017 at 14:57

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 ...

  • 11
    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
    Commented Apr 9, 2016 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'
    Commented Apr 9, 2016 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. Commented Apr 9, 2016 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
    Commented Apr 10, 2016 at 0:08
  • 2
    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
    Commented Sep 6, 2016 at 13:34

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.

  • 9
    +1 for the Don't execute arbitrary code you find on the net line Commented Apr 9, 2016 at 14:48
  • 8
    "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/…
    – nobody
    Commented Apr 9, 2016 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.
    Commented Apr 11, 2016 at 13:59

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


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). Commented Apr 10, 2016 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. Commented Apr 10, 2016 at 2:33

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.

  • This is also a very good idea for security and photgraphy. It is much easier to rescue data from a disk that is not filled with pre-existing (steganographic as it may be) data. Nice contiguous files.
    – mckenzm
    Commented Feb 3, 2022 at 21:05

Yes it does wipe the beginning and end of the disk, to seemingly arbitrary boundaries. They seem overly complex and risk prone to be outside of a script. The zones are not copied to a file first, for instance.

As well as LVM and other schemes, there are third party products that copy allocation data to the end of the disk for redundancy. Without knowing what this disk was used for, the leading wipe seems excessive.

It is important to understand that disks do not always use standard partitioning and file systems. This may be a flash drive used with custom/proprietary hardware.

In a perfect world there would be a supervisor routine in the disk firmware to zero every "page", but then we would be assuming SSD.

4096 is a good block size, possibly the count is a typo, but there may be a good reason. Nobody using these should ever be asking what they do. You absolutely positively must know. Start with man dd.

Since the question was posted the backticks have been replaced with the equivalent (for the purpose) $(...) syntax.

Such arithmetic suggests the geometry of the disk is expected to vary, since a user of dd would be sophisticated enough to know the integer value, this is as unnecessary as "lines" arithmetic in a terminal.

It is also suggestive of this being copied. If it was copied, it has been modified. The count in the second statement? Why this limit and not 8? How far can it get?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .