For the hundreth time! There is a difference between a file being deleted
from a filesystem and it being truly OVERWRITTEN. If you are sanitizing
the drive, you will OVERWRITE it with data from the first sector to the
very last PHYSICAL sector of the drive. OVERWRITTEN. Period. Unless you
wish to pursue other PHYSICAL RECOVERY methods such as the use of Scanning
Tunneling Microscopy or recovery of tiny fragments of data from the cache
chip found on the drive's circuit board, it's for all intents and purposes
GONE.

_________________________________________
John Daniele
Technical Security & Intelligence
Toronto, ON
Voice:  (416) 605-2041
E-mail: [EMAIL PROTECTED]
Web:    http://www.tsintel.com

On Fri, 8 Mar 2002, Marnix Petrarca wrote:

> didn't the coroners toolkit from wietse venema and consorts do something
> like that?
> There's other interesting reading there, too.
> http://www.porcupine.org/forensics/tct.html
> -M
>
> ----- Original Message -----
> From: "John Daniele" <[EMAIL PROTECTED]>
> To: "Mike Donovan" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: 06 March, 2002 6:07 PM
> Subject: RE: Unclassified Disk "Sanitizers"
>
>
> >
> > Could you point me towards SOFTWARE (not STM equipment) that would be able
> > to recover data that had been OVERWRITTEN from a sector of a drive?
> >
> > i.e. dd if=/dev/zero of=/dev/dsk/c0t0*
> >
> > Read each physical sector of the drive and explain to me how meaningful
> > data is recovered from 00's using software recovery tools?
> >
> > Sorry for my abrasive response, but you are out of line. I was not
> > referring to a scenario where portions of a deleted file may be recovered
> > from file slack, or swap space but rather in the case that it had truly
> > been OVERWRITTEN!
> >
> > _________________________________________
> > John Daniele
> > Technical Security & Intelligence
> > Toronto, ON
> > Voice:  (416) 605-2041
> > E-mail: [EMAIL PROTECTED]
> > Web:    http://www.tsintel.com
> >
> > On Wed, 6 Mar 2002, Mike Donovan wrote:
> >
> > > >===== Original Message From John Daniele <[EMAIL PROTECTED]> =====
> > > >The data only has to be overwritten once such that it is unrecoverable
> > > >using standard forensic recovery methods.
> >
> > --------------------------------------------------------------------------
> -
> > > This is false. Completely. A one-time pass --- making data
> "unrecoverable?"
> > > Why is it that Bruce Schneier and others are constantly harping on how
> we
> > > can't assume ANYTHING is truly "unrecoverable" using software methods?
> Period!
> > > Even Gutmann's paper questions his own method! John, in referring others
> for
> > > more information to the over-used "Gutmann Paper" (which is going now on
> > > six-years old), need I remind you how recovery capabilities have changed
> in
> > > SIX years? Let me refer you to something more current and more realistic
> from
> > > SANS:
> > > http://rr.sans.org/incident/deletion.php
> > > It must be remembered the Gutmann 35-pass method is *completely*
> different in
> > > what a "pass" is than, say, the D.O.D 7-pass method. Gutmann's method
> takes
> > > into account various encoding methods used my makers of the drives. It's
> > > totally different. Hard drive slack space and unallocated space? Not
> even
> > > mentioned in John's all-inclusive sentence above. How can anything be
> securely
> > > deleted without even touching these data storage hogs that a simple
> one-pass
> > > method will NOT touch? In the very paper John referred to, Peter Gutmann
> says
> > > in the opening sentence of his conclusion,(point 9)"Data overwritten
> once or
> > > twice may be recovered by subtracting what is expected to be read from a
> > > storage location from what is actually read."
> > >
> > > The kind of misinformation in John's post is dangerous - especially in
> today's
> > > world. Bottom line: Stick with Department of Defense regulations for
> secure
> > > deletion or use the 35-pass Gutmann method. Please, don't let **anyone**
> tell
> > > you a one-time pass will make data "unrecoverable."
> > >
> > > Mike Donovan
> > >
> > >
> >
>
>

Reply via email to