2

I want to use dd to overwrite a disk multiple times to destroy data beyond recovery.

I know I could use dd if=/dev/zero/ of=/dev/sdx/ to do a pass with zeros, or dd if=/dev/null/ of=/dev/sdx/ to accomplish similar (not exact same) result, but it will be slower.

I was wondering if there is a way to do something where I could write all zeros, then all ones to a disk using dd, or is there a better way to accomplish this?

9
  • 1
    Can you tell me how to recover data after a single pass with dd if=/dev/zero? I've never seen this done. There used to be a challenge, but I never saw the results: hostjury.com/blog/view/195/… Commented Jan 25, 2015 at 4:00
  • @umeboshi Certain standards of doing a "complete disk wipe" require doing it 7 times. I used a program before which had 7 passes, and it took about 8 hours to complete. This is why I was looking for another way of accomplishing this multiple times, without having to run that program. I am unsure if it is actually possible to recover it or not, but 7 times will make sure, even if there is less than a 1% chance. Commented Jan 25, 2015 at 4:19
  • @umeboshi superuser.com/a/512461 this appears to answer how to recover it as well Commented Jan 25, 2015 at 4:27
  • If you feel uncertain about dd's ability to wipe data without possibility of recovery, you need physical control over the disk, and physical destruction. Nothing else will help you ease your mind. If you can't be sure if one swipe will remove everything, doing it six more times won't help either. Those "standards" are for a nice little jedi mind trick for the phb's. What you need is absolute certainty. Commented Jan 25, 2015 at 4:56
  • 1
    Totally agree with parts of that. It is true that physical control is paramount, and only destruction is truly safe. The next best is improbability. askubuntu.com/a/100849/266923 It is possible, probably not probable unless you have expensive stuff according to these guys. It all depends on your data though too :) Although it does appear just a single zero pass really won't help as there are plenty of tools to get your disk back. A pass with urandom looks nice too. The problem is it can miss portions (do dd if=/dev/sdx | hexdump -C | grep [^00]) and you can see it misses sometimes Commented Jan 25, 2015 at 5:23

4 Answers 4

4

First, dd if=/dev/null of=/dev/sdx ( note there is no trailing / after either device name ) will do nothing, since reading from /dev/null always returns EOF. Rather than using dd, this task is more suited to shred /dev/sdx.

6
  • I like this. Can you explain shred a little more (like what it does)? I will look at it a little bit too research wise. It does say in the man, that it has limited effectiveness on ext3+ do journaling. It says you can get around this by messing with fstab. Would rather not have to do this though Commented Jan 25, 2015 at 4:28
  • 3
    Might want to add something like this security.stackexchange.com/a/62826/66922 as a foot note. As side notes it is perhaps worth mentioning security.stackexchange.com/q/5662/66922 (And perhaps things like forensicswiki.org/wiki/Recovering_Overwritten_Data, nber.org/sys-admin/overwritten-data-guttman.html) though the latter ones have no effect on a medium suspicious mind. +1 Commented Jan 25, 2015 at 5:26
  • @NoTime, shred overwrites the target with random data multiple times.. i.e. exactly what you are trying to do. Commented Jan 25, 2015 at 18:02
  • @user367890 Those are great links. And it appears dd would not be a good tool for this really, especially since it is a SSD, rather encrypting drive, or all data then losing the keys, or doing a Secure Erase. Commented Jan 25, 2015 at 18:02
  • @psusi After looking at the man page for shred, researching a bit more, and following some of the links in the comments. It appears this would be good probably 99% of the time. However if you have software which can read from the journal, and you have your file system in a certain way (with different mount options) there is a stronger possibility of data recovery. Commented Jan 25, 2015 at 18:19
1

The -kq option of wipe is specific for block devices:

wipe -kq /dev/hda3 
3
  • Is this for magnetic only or does it work well with SSD? Commented Jan 25, 2015 at 18:20
  • @NoTime That is a different question, and I have no idea whether the same precautions as with disc apply with SSDs. wipe has no special instructions for that, but I assume the block wipe would work, although probably overkill. Commented Jan 25, 2015 at 18:29
  • It appears that it is not meant for SSDs (HD and FD), but it is an efficient killer of data, so actually it won't matter (except some cases when using RFS). With different switch maybe -rcf will be even more effective, because it will do more passes. With the -q it does 4 passes using random data (from /dev/random). But with the -rcf it will recursively do 34 passes rename everything 10 times, then unlink it, and chmod things (-f forces). Commented Jan 25, 2015 at 18:33
1

Another option is to use Darik's Boot And Nuke (DBAN) from a live cd/dvd.

1

The better way is

cat /dev/zero >/dev/sdx 

It doesn't matter what you overwrite with. It did matter with 1980s disks, if you were concerned about attackers with expensive electronic equipment, but it doesn't matter with today's disks. See https://security.stackexchange.com/questions/10464/why-is-writing-zeros-or-random-data-over-a-hard-drive-multiple-times-better-th/10474#10474

Note that this applies to magnetic hard disks only, not to SSD. On SSD, overwriting a sector merely marks it as unused and writes a different sector. If you're concerned about attackers with access to the hardware, it's impossible to be sure that you've wiped the data from the flash memory. Instead, use the SSD's secure erase command, if it has one. But beware that not all SSD models have a secure erase command, and some that claim to have one implement it incorrectly.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.