Hi 2008/10/3 mbm <mbm@rlogin.net>:

On Fri, 03 Oct 2008 15:43:57 +0100 Barrys linux mail <bazubuntumail@tiscali.co.uk> allegedly wrote:

/But/ I recall reading somewhere that no file shredder will completely obliterate your files if you are using a journaling FS such as ext3.

Nothing to stop you remounting the filesystem as ext2, then shred your files, do multiple syncs, then remount as ext3.

Modern disk forensics may allow a skilled operator to recover your "deleted" data.

They might be able to recover the data because AFAIR ext3 does not clear the data blocks - it only resets the metadata to a state that shows that/those data block[s] as unused. On disk, the data does exist, until it is eventually overwritten. - Srdjan

There is an undiscussed question lurking behind all this. What is the process when one "overwrites" an existing file? [A] For instance, if I have an existing file file.foo (say 14253 bytes) and I do cat file.bar > file.foo [file.bar also 14253 bytes] does it first write to a new disk region, delete the old filename file.foo from its inode, and then name the new inode file.bar? Or does it start writing the bytes in file.bar into the same disk space as file.foo, i.e. literally overwriting the same disk space? [B] Whatever the answer to [A], what happens if you do dd if=file.bar of=file.foo I would presume that a utility like 'shred' would first take the trouble to locate the disk-space used by file.foo, in detail, and then directly access the HD hardware to write directly to the target sectors. Depending on the answers to these questions, it may or may not be effective to do, say, dd if=file.bar of=file.foo Ted. On 03-Oct-08 17:37:05, Srdjan Todorovic wrote:

Hi

2008/10/3 Anthony Anson <tony.anson@zetnet.co.uk>:

...

The message <48E62FAD.9080704@tiscali.co.uk> from Barrys linux mail <bazubuntumail@tiscali.co.uk> contains these words:

...

Lifted from a post in one of the Zetnet newsgroups:

dd if=/dev/zero of=/dev/hda

Which is OK if you want to nuke everything on the disk (or partition of you give it a partition number). But if you want to shred specific files... it won't do unless you call dd on each file (adjusting bs and count to match filesize).

...

but from the point of view of getting rid of data, it'd be better to run

dd if=/dev/random of=/dev/hda

Which is extremely slow (at least here...)

[srdjant@tigerclaw ~]$ dd if=/dev/urandom of=/dev/null bs=1M count=10 10+0 records in 10+0 records out 10485760 bytes (10 MB) copied, 2.50551 s, 4.2 MB/s

/dev/zero is much faster. You could do one pass of dding from /dev/zero, and then several passes of urandom (if you were that paranoid).

- Srdjan

_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!

-------------------------------------------------------------------- E-Mail: (Ted Harding) <Ted.Harding@manchester.ac.uk> Fax-to-email: +44 (0)870 094 0861 Date: 03-Oct-08 Time: 18:54:21 ------------------------------ XFMail ------------------------------

On Sat, 4 Oct 2008 10:17:44 +0100 Anthony Anson <tony.anson@zetnet.co.uk> allegedly wrote:

I'm putting a 'new' box together and I have a number of large (well, larger than most of the ones in this box) secondhand drives which I want to incorporate (fiver each from a local pootershop).

You never know what might be on them innit.

I can recommend "Forensic Recovery" by Farmer and Venema..... Best disk wiper is a bloody great degausser, followed by an angle grinder, then a 20 lb hammer, then a furnace. (But still worry) Mick --------------------------------------------------------------------- The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this? Douglas E Comer - Internetworking with TCP/IP Volume 1 http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------