[Bulk] Re:Writing over a drive using /dev/zero

[Christopher Browne]

On Wed, Dec 1, 2010 at 12:19 PM, Yanni Chiu <yanni-bJEeYj9oJeDQT0dZR+AlfA at public.gmane.org> wrote:
> On 30/11/10 11:42 AM, William Muriithi wrote:
>>
>> This is something I am very doubtful about.  In fact, I am reasonably
>> as in 80 % sure it impossible to extract data from a drive that has
>> been overwritten with zeros using dd.  You do not have to fill it,
>> lets say overwrite 60% of the drive.
>
> Back when 1.2M floppies were common, the recording surface used for each bit
> of data was huge. Also, the write head alignment was not very tight. The
> result was that if you "looked" around the recording surface (i.e. off the
> track), you could recover what was there, before the zeros were written.
> That's the explanation I remember. Of course, with today's densities, the
> chance of finding the old data is much slimmer than before.

Here lies the non-intuitive part of digital technology, namely the
fact that it is implemented using what really are inherently analog
technologies.  0 and 1 aren't absolutes - they represent things like:
- 0 = signal below some threshold, 1 = signal above that threshold
- 1 = enough of the region of magnetic surface "charged up," 0 = not
enough "charged"

As you observe, looking at the edges of tracks provides some ability
to analyze what might have been recorded there before.

A number of things are likely to worsen chances of getting out useful
data, including all of the following sorts of things...

- The filesystem is filled with linkages where a file may be scattered
in pieces across the disk, with pointers to show where each chunk is.
If any of those pointers wind up hard to get, the data may be
"shattered" (rather like the shards resulting if you drop a glass
object) such that you can't figure out what pieces to put together.

- Beyond that, the applications that use the contents may have further
structure within the files.  Microsoft Office is infamous for this
sort of thing; Word docs and such consist of dumps of COM objects,
where parts of the file reference other parts of the file.  But that's
but one of a list of such things...

 - MS Office-like applications may dump binary forms of the objects
stored in memory by the application
 - Database systems are filled with pointers-pointing-to-pointers,
whether that be DBM, SQLite, MySQL(tm), Postgres
 - Compressed files do their compressing via having pointers pointing
to pointers
 - Encrypted data often uses "cipher feedback mode" where subsequent
blocks are seeded using data from the previous block

It's entirely possible that losing a few crucial bytes of pointer data
can shatter the ability to get anything back from the document or
database.

Someone trying to hide things could likely get some milage by, rather
than simply zeroing things out, instead running mkfs, and strewing the
disk with a completely different set of kinds of pointers.  I suspect
it's a cool idea to kill off that ext3 disk by running mkfs.xfs or
mkfs.reiserfs, and running an I/O test that writes a whole lot of
files, small and large.

Maximize the chances of things being as wildly shattered as possible...
-- 
http://linuxfinances.info/info/linuxdistributions.html
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists