Re: How to permanently delete files?
curiou...@yahoo.com
So there's no chance of the uneraser recovering the data.
dar...@gmail.com
actually touching the bits. If you're going to delete a file, you might
want to write 0s to the file's bits at the physical location before
deleting it. This corrupts (well, empties) the file and makes it
unrecoverable (even if they can pull the extension.
Darsant
Olaf van der Spek
> Lets say I delete files with explorer and then empty the recycle bin.
> Then I use a program to wipe all unused disk space on all the drives.
> I verified this by watching the disk space on the drive go to zero.
> Then I had the swap file wiped on reboot. So I figure the deleted
> files are long go. Where else could they be? Then I start an unerase
> program, and presto, the files still exists somewhere because the
> unerase can restore them! Where is the unerase program getting the
> files and how can I permanently get rid of them? Does anyone have any
> code to do this? There must be some microsoft database that contains
> these deleted files. If I empty the recycle bin and then wipe all
> *unused* disk space on all drives then where else could the files data
> be? I restored a text file and it contained the correct text.
If it's a tiny file it could be stored inside the MFT.
Joseph M. Newcomer
(particularly if you are using the obsolete FAT file system) but the contents may not be
present...did you check that the contents are also restored?
When I donate old machines to various charities, I remove the hard drives. I have too much
sensitive data, and I have no guarantee that the files will actually be deleted.
A fellow I knew spent his entire summer of ROTC/Reserve activity putting thermite charges
on hard drives. As he described it, a large truck arrived in the desert with several armed
guards. He and another guy signed out one hard drive, signed for it by serial number, took
it out, dug a hole, put a 1lb thermite charge (that's BIG!) on top of it, fired the
charge, and then both signed that the drive had been melted to slag. Then they signed out
the next one. This was back when large hard drives cost real money.
joe
>Thanks for any help,
>Paul
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer
http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html
where he says, in the Epilogue,
"In the time since this paper was published, some people have treated the 35-pass
overwrite technique described in it more as a kind of voodoo incantation to banish evil
spirits than the result of a technical analysis of drive encoding techniques. As a result,
they advocate applying the voodoo to PRML and EPRML drives even though it will have no
more effect than a simple scrubbing with random data. In fact performing the full 35-pass
overwrite is pointless for any drive since it targets a blend of scenarios involving all
types of (normally-used) encoding technology, which covers everything back to 30+-year-old
MFM methods (if you don't understand that statement, re-read the paper). If you're using a
drive which uses encoding technology X, you only need to perform the passes specific to X,
and you never need to perform all 35 passes. For any modern PRML/EPRML drive, a few passes
of random scrubbing is the best you can do. As the paper says, "A good scrubbing with
random data will do about as well as can be expected". This was true in 1996, and is still
true now."
On 29 May 2005 10:21:27 -0700, curiou...@yahoo.com wrote:
>BTW, I used a Peter Gutmann 35 pass when wiping the unused disk space.
>So there's no chance of the uneraser recovering the data.
Joseph M. Newcomer [MVP]
curiou...@yahoo.com
sDelete I am now wondering if there's something else. I used sDelete
to clean free space on C drive. According to source code, sDelete also
cleans deleted files within the MFT. Unfortunetely it still does not
clean everything. There are a lot of files that are still restorable
on the C drive. I checked the text within the restorable files and
they are correct.
BTW, I'm using Win2K. I have 1 physical drive that is partitioned into
4 NTFS drives. The other day I cleaned all 4 partitions but not with
sDelete. sDelete is so slow that I think it would take days to clean
all 4. Luckily the C drive is a small partition. Is it possible that
the OS has somehow place some of the deleted C drive files on other
drives? Windows is installed on the C drive.
Any ideas why sDelete -z C: does not clean everything? Here is the
source code to sDelete
http://www.sysinternals.com/ntw2k/source/sdelete.shtml
// If we're just zapping free space, and this is NTFS, we have to take
care of
// deleted files within the MFT. We do this by creating as many of the
largest sized
// files we can (if there is space in the MFT, we'll be able to create
non-zero sized
// files, where the data is resident in the MFT record).
//
if( ZapFreeSpace ) {
mftFilesCreated = 0;
prevSize = 4096; // max MFT record size
while( 1 ) {
_stprintf( tempFileName, _T("%sSDELMFT%06d"), DrivePath,
mftFilesCreated++ );
hTempFile = CreateFile( tempFileName, GENERIC_WRITE,
0, NULL, CREATE_NEW,
FILE_FLAG_SEQUENTIAL_SCAN|FILE_FLAG_DELETE_ON_CLOSE|
FILE_ATTRIBUTE_HIDDEN, NULL );
if( hTempFile == INVALID_HANDLE_VALUE ) {
break;
}
//
// Mft record can be up to 4K in size
//
cleanSize = prevSize;
createdFile = FALSE;
while( cleanSize ) {
if( !SecureOverwrite( hTempFile, cleanSize )) {
cleanSize--;
} else {
prevSize = cleanSize;
createdFile = TRUE;
}
}
//
// If the only file we could create is length 0, then this is FAT
//
if( !createdFile ) break;
if( mftFilesCreated == 1 ) {
_tprintf( _T("\r
"));
}
_tprintf( _T("\rCleaning MFT...%c"),
progress[ mftFilesCreated % 8 ]);
// Don't close the file, since we want it to keep the space until
we're
// done.
}
}
curiou...@yahoo.com
confident that it cannot clean all of the MFT area. Has anyone seen
any code to scan the entire MFT and wipe all the files that are marked
as deleted?