[ale] erasing a hard drive
Jim Kinney
jim.kinney at gmail.com
Fri Aug 26 16:27:52 EDT 2011
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/e86a992e/attachment.html
More information about the Ale
mailing list