[ale] erasing a hard drive

[Michael Trausch]

Only if that "mp3" is a FIFO that is being fed the same actual mp3 over and
over again...

That could be interesting, actually, using a FIFO to wipe a drive by placing
random ASCII books onto it, one could use project gutenberg as such a
source. Could be amusing to whoever attempts to read the drive...
On Aug 26, 2011 4:28 PM, "Jim Kinney" <jim.kinney at gmail.com> wrote:
> Dd if=/randomladygaga.mp3 of=/dev/sda
> On Aug 26, 2011 3:15 PM, "Lightner, Jeff" <JLightner at water.com> wrote:
>> Yep - I started using /dev/urandom instead of /dev/zero when I read
> something that said if the overwrite data is predictable (e.g. all zeros)
it
> might be easier to decide what real data it was trying to mask.
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of David
> Tomaschik
>> Sent: Friday, August 26, 2011 2:52 PM
>> To: Atlanta Linux Enthusiasts
>> Subject: Re: [ale] erasing a hard drive
>>
>> On Fri, Aug 26, 2011 at 1:37 PM, Lightner, Jeff <JLightner at water.com>
> wrote:
>>> Of course you don't need a software at all.
>>>
>>> Erasing the data in a filesystem then unmounting the filesystem and
> running:
>>> dd if=/dev/urandom of=/dev/sda1/scramble bs=1M
>>>
>>> - will write random data on the partition (sda1 in the above - you can
> substitute other partitions/drive letters as necessary)
>>>
>>> However, any time I've seen this question come up someone invariably
> posts that it really isn't necessary for "modern drives". They never quite
> say what their definition of "modern" is.
>>>
>>> In the past it was required to do something like the above multiple
times
> but it really isn't necessary unless you're doing DOD or CIA work.
>>
>> It is necessary to do at least one overwrite pass. Recovering data
>> from a drive that has not been overwritten at all (e.g., mkfs or rm
>> only) is trivial.
>>
>> The theory behind multiple overwrites has to do with the fact that
>> data isn't really stored in discrete chunks on the drive, and there
>> are algorithms that can theoretically recover/rebuild data from the
>> "edges" of the tracks. However, this is substantially less of an
>> issue these days. For one, those techniques were developed against
>> MFM and RLL encoded drives. Drives using PRML and EPRML and
>> perpendicular recording are believed to be far more resistant to this
>> (as they have less area in which other traces are left.)
>>
>> For a better explanation than I could write, see
>> http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html (especially
>> the epilogue).
>>
>>
>> --
>> David Tomaschik, RHCE, LPIC-1
>> System Administrator/Open Source Advocate
>> OpenPGP: 0x5DEA789B
>> http://systemoverlord.com
>> david at systemoverlord.com
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>>
>>
>>
>> Proud partner. Susan G. Komen for the Cure.
>>
>>
>> Please consider our environment before printing this e-mail or
> attachments.
>>
>> ----------------------------------
>> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or
confidential
> information and is for the sole use of the intended recipient(s). If you
are
> not the intended recipient, any disclosure, copying, distribution, or use
of
> the contents of this information is prohibited and may be unlawful. If you
> have received this electronic transmission in error, please reply
> immediately to the sender that you have received the message in error, and
> delete it. Thank you.
>> ----------------------------------
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20110826/631f1d9e/attachment.html