0

Should I delete the important files of the disk and then boot into live disk and run dd command or is it okay to run dd on /dev/sda without having to delete?

I'm asking this because I've already started running dd if=/dev/urandom of=/dev/sda bs=1M. Just wanted to be safe, I kinda know either way its the same but wondered if dd does more damage to files that are already deleted or the ones that aren't deleted yet. I can restart dd command but just need a confirmation.

user630702
  • 495
  • 10
  • 32

1 Answers1

1

dd is a low-level utility for reading or writing chunks of data to the disk. It doesn't know about (or care about) file systems, directory structures, permissions or any other high level file details. It's basically a spatula for smearing or wiping data to/from any area on the disk.

The rm, cp, mv or other high level file utilities take great pains to make sure the file(s) you are manipulating have their allocated areas and file system pointers on the disk perfectly updated, wherever they may be. When you remove a file, it's quite possible the data area of the disk is simply marked as being "available for use" and not actually cleared of any previous data. If you have a file containing social security numbers, even after you rm it, the data area may still be readable by utilities such as dd.

So, in a way, the answer to your question is "yes". dd "does more damage" in that whatever it writes is pretty much gone forever. There may be specialized forensic equipment that could recover it but I would imagine the price for such services puts it out of reach of most people.

UPDATE: How to confirm dd has overwritten the disk. BE SURE that you use the correct device. The write example below renders your data irrecoverable:

Read in 1 chunk of data from the boot sector (512 bytes) of the target device:

# dd if=/dev/sdX of=/tmp/dd_example/chunk.bin bs=512 count=1
1+0 records in
1+0 records out
512 bytes copied, 0.00162606 s, 315 kB/s

Use the od command to inspect the data which was read (truncated for brevity).

# od -t x1 /tmp/dd_example/chunk.bin 
0000000 eb 63 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0
0000020 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00
...

If you want, use the strings command to view any readable ascii in the chunk. (NOTE: values having "unprintable" ascii, such as 00. will not shown so the output from strings will not necessarily correlate with the hex output shown above). Since this is a GRUB boot sector, the boot signature is easily seen. Other operating systems will likely have something similar.

# strings /tmp/dd_example/chunk.bin 
ZRr=
`|f 
\|f1
GRUB 
Geom
Hard Disk
Read
 Error

Now wipe out the boot sector by writing 512 zeros to the device.

# dd if=/dev/zero of=/dev/sdX bs=512 count=1
1+0 records in
1+0 records out

Now read the chunk of the boot sector back in

# dd if=/dev/sdX of=/tmp/dd_example/chunk.bin bs=512 count=1
1+0 records in
1+0 records out
512 bytes copied, 0.00144648 s, 354 kB/s

od shows all that is in the chunk now is 00s

# od -t x1 /tmp/dd_example/chunk.bin 
0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0001000

Strings confirms there is no longer any printable ascii on the disk

# strings /tmp/dd_example/chunk.bin 
#
Server Fault
  • 3,714
  • 12
  • 54
  • 89
  • So it doesn't matter if I delete the files before running `dd` command, either way its gone forever? – user630702 Oct 29 '19 at 14:12
  • Does it make a difference if I delete the files and then run dd command or without deleting the files and then run dd command? like for example they can see the file names if someone tries to recover since I did not delete the files before running `dd` command. – user630702 Oct 29 '19 at 14:15
  • Deleting the files before running `dd` is technically unnecessary since `dd` is going to overwrite the disk areas with whatever you tell it to. I'll update my answer with some ways to verify `dd` has actually overwritten the data. – Server Fault Oct 29 '19 at 15:24