0

Command line tools, like "shred", come with many disclaimers about situations where they may not securely delete files. I had an idea for a cheap'n'easy way to do it and wanted advice.

How about running a "dd" from /dev/zero and trying to create a file bigger than the remaining space on the partition. Surely this will fill the underlying blocks with all zeros and, once it dies for running out of disk space, you'd simply delete this file.

This way, I'm thinking, any recovery utility that tries to examine the underlying disk would only see zeros no matter where it looks...

Yes, this would be inefficient on a large partition, but that aside - how sane is this?....

Improve this question
2
  • What disclaimers? Maybe you need to come up with a way to specifically address those disclaimers. However the best way to ensure no-one can read old data on your disk is to use an axe or a sledgehammer or something like that. Seriously. Old computers should have their hard disks dismantled and the disks shredded. – AlastairG Dec 3 '10 at 12:52
  • 1
    The main disclaimer, IIRC, is that overwriting a file does not destroy the content when using a journaled filesystem. I'm not sure if the OP's solution will counter that. – larsmans Dec 3 '10 at 12:58
1

If you had a system with no other processes running that might need to access (or cause access) to the disk, then yes that might work but it's hugely inefficient. Ideally you'd identify the disk blocks being used, ensure that none of the blocks had been remapped by the drive controller and write over the data block with a wide variety of values, multiple times to ensure no residual imprint remains.

Improve this answer
0

Won't work.

What programs like "shred" do is write random garbage all over the disk used by the file - several times.

Just writing zeros will still leave an "imprint" of the original data. Even if you do it several times.

It's also inefficient. You may have HUGE areas of disk that have never been written to that you spend hours writing zeros to for no reason. It's much more efficient to just overwrite the areas actually used by a given file.

Improve this answer
3
  • 2
    I remember my IT forensics professor claim that this imprint thing wrt to hard disks is merely a (wide-spread) myth, possibly having been true for the very first generation of (hard) disks. Today's densities would, according to him, make that even physically impossible, i.e. occurence of "imprints" would by today's standards necessarily mean reading errors/overlapping bits. Of course, I have no idea which is true. Do you have, by chance, a conclusive source handy? – dennycrane Dec 3 '10 at 12:54
  • No. I am far from an expert. I just know that the current military strength (as reported by various "shred" like programs) is about 3 re-writes. Also my knowledge of HD technology may well be out of date but my understanding was that it's a pattern of magnetic imprints on a disc and these are read; strengths above X are 1s and below are 0s. However if you write all 0s to a sector, the higher level (just under X) values used to be 1s and the very low strengths used to be 0s. However, like I say, my information may be out of date. – AlastairG Dec 3 '10 at 13:28
  • 2
    And military strength is because foreign governments will spend un-calculable time and money to crack a hard drive. They can afford electron microscopes and all those fancy tools. The Meth addict that grabs your laptop, or the guy that buys your old computer off ebay are not.. – Brian Dec 3 '10 at 16:18
0

The imprints problem, if it exists, can be addressed by sourcing from /dev/urandom instead of /dev/zero. Or even, since performance does not seem to have any importance at all in the premise, source it from /dev/random.

You would still have a problem with remapped disk blocks, especially in ssds. If one of the blocks you've written your sensitive data to is considered faulty by the firmware, it will be replaced by a reserve block and retired, the contents copied to the replacement block. The file system sees nothing from this, your sensitive data is inaccessible from your software, but still accessible by forensic methods. You won't be able to reach and overwrite this retired block with your sensitive data on it by any software-based approach.

Improve this answer
0

DD would be a very bad choice. It is a sector based copy tool. It does not care what data is in those sectors. As far as I know, DD has no concept of free space, or files. I upgraded from a 120GB to a 320GB HD in my laptop, and DD copied 120GB of data, even though I really had 30GB free. (it was really pretty cool, didn't even need to partition it, it just copied all the partitions, deleted files, swap, etc)

Not to mention, free space is not contiguous, its often scattered all over the drive. So you can't just say "overwrite the second half of the drive" because its only half full, because the data will be all over the drive.

Improve this answer

Your Answer

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