[2008] Destroy a file on disk (irrecoverable delete)

Deleting a file is one of the controversial matters of computing. When a user deletes a file (removing it also from the Recycle Bin), they assume that the file is indeed deleted. However, what happens is that only the reference to that file is deleted, so the system can no longer remember where the file is located, but the file itself is very much intact.

I am looking for a way to delete a file permanently, the way e.g. the application Wipefile would do it, by applying successive overwrites (up to 30) over the actual position of the file on the disk. There must be a way to do this through code (I just presented an example that this has indeed been done :bigyello: ), so I'd like to know how to do it. Any ideas? Anyone?

Cheers!:wave:

I'd be extremely surprised if you could do it using managed .NET code only... and I've never heard of any APIs that would help with that kind of thing (but then again, I havent heard of many APIs at all :) )

/Pointless post

If you want a completely irreversible delete this could work, make it shift to a new partition make it format that partition the join the partitions again :S only way i can think of

Quote:

---

Originally Posted by Ryan2406

If you want a completely irreversible delete this could work, make it shift to a new partition make it format that partition the join the partitions again :S only way i can think of

---

Ouch....Seems rather bulky, doesn't it? Ok, since it's the best solution so far, how would I do it? Any code is welcome.:wave:

Formatting a partition would erase everything on it... what if the user didnt have more than one partition or they didnt want to loose everything on their partition?

Oh and by the way, its still possible to recover data from a formatted partition..

I mean make a new partition on the disk the size needed for the file move the file to that partition format it or you could do like i do and get encryption on your drive so no one can get in without a password and due to law you can keep that password in your head and you don't have to tell anyone it oh yeah and theres this one type which you can't crack

This doesn't 'irrecoverable delete' the file, but what you could do is grab a really complex algorithm that'll take a string input (the contents of the file) or a filestream (again the contents of the file) and it'll randomly scramble all the data then write this random jibberish back to the file and delete it.

By doing this you're ensuring that if an undelete program is used, the recovered file is just random jibberish and not actual data.

Quote:

---

Originally Posted by JuggaloBrotha

This doesn't 'irrecoverable delete' the file, but what you could do is grab a really complex algorithm that'll take a string input (the contents of the file) or a filestream (again the contents of the file) and it'll randomly scramble all the data then write this random jibberish back to the file and delete it.

By doing this you're ensuring that if an undelete program is used, the recovered file is just random jibberish and not actual data.

---

that's quite a good idea

Quote:

---

Originally Posted by Ryan2406

I mean make a new partition on the disk the size needed for the file move the file to that partition format it or you could do like i do and get encryption on your drive so no one can get in without a password and due to law you can keep that password in your head and you don't have to tell anyone it oh yeah and theres this one type which you can't crack

---

Do you mean make a new partition on the disk temporarily via vb.net code? If so, how would you do that? I dont think creating and merging partitions is something that can be done while windows is running anyway, it would need to be done on bootup etc. Also, what if the user had a fairly full hard drive, you would be in danger of tearing a chunk out of their existing partition that had data on and then erasing it... I'm not saying its 100% impossible to do it the way you suggested but I really think it sounds like a bad idea.

EDIT: Juggalo Brotha's solution sounds like a better idea :)

JuggaloBruthas Idea is better anyway

what am i missing? why not just open the file and re-write every byte with random data as many times as you want. then delete it.


edit - JuggaloBruthas and I must have been typing at the same time.

Quote:

---

Originally Posted by dbasnett

what am i missing? why not just open the file and re-write every byte with random data as many times as you want. then delete it.

---

Isnt that pretty much what JB suggested?

Why fill it with random data from an advanced alrgorithm, when you can just replace all the bytes in the file with 0's, then delete it? It would have the same effect as JB's suggestion, but you wouldnt need any advanced alrogithm.

depends on what you are trying to do and who may be looking at it after the fact.

Quote:

---

Originally Posted by dbasnett

depends on what you are trying to do and who may be looking at it after the fact.

---

How do you mean?

my guess is that it is urban myth that data can be recovered when simply over-written, but why take a chance

Why would WipeFile overwrite the same place 30 times if no useable data remained in the sector after a single write?

Quote:

---

Originally Posted by dbasnett

my guess is that it is urban myth that data can be recovered when simply over-written, but why take a chance

---

I have seen data recovered from a drive that was formatted several times, and had an OS reinstalled several times. I had a customer who had a laptop given to them by their corporate job to keep (when they upgraded the staff to new laptops) but they formatted the machine and just installed the OEM license of XP. When they were having trouble with the machine, they reformatted it and reinstalled Windows again. They didn't know they were going to lose their files when they did this. So I took the drive and ran it through a few recovery apps I have, and we were able to recover data from the corporation from when the laptop had that data on it 2 formats ago.

Same here, I once ran a file recovery thingie on my old computer, and was surprised of all the old stuff it found lying around:D

Quote:

---

Originally Posted by dbasnett

depends on what you are trying to do and who may be looking at it after the fact.

---

Depending on what level of destruction you are aiming for a simple walking bit algorithm is generally used for this type of thing. You take each byte and repeatedly toggle each bit between 0 and 1. Some of these data recovery guys are extremely good at what they do though

often times the files are incomplete or corrupt, but obviously if someone is looking to "totally delete" data of a disk, it is probably because there is sensitive info in these files, so even recovering part of the file and being able to view part of it is bad news.

Also I won't pretend like I know how the intricacies of the lowest level of the Windows file system work, but I am pretty sure if you do something like open a file, blank out its data, and save it back to disk, it is not a guarantee that the saved data even goes to the same exact physical sectors on the hard drive. So that being said, even blanking out a file may not actually erase its original contents.

i think it is urban myth, but you be the judge

http://en.wikipedia.org/wiki/Data_recovery

How is repeatedly toggling each bit going to work? I suppose you could do a defragment to pull all of your data to one part of the drive, then split that part off as a separate partition and format the rest..

Rewriting the data is exactly what WipeFile does, so I guess it's the right direction to go. But are you sure that rewriting the file through code actually writes on the positions of the original file's data? I mean, could it write to another location and then change the references in the FAT? How can I make sure that the file's data has indeed been overwritten?

Data recovery of an overwritten file is indeed possible, I know it as a fact that NATO uses 7 passes and a special (and secret) algorithm to overwrite and delete their sensitive data.

@Maximiilian: Yeah it may be possible, but I'm looking for a fast, sleek solution and pulling a drive defragmentation is not it :D Defrag is notoriously slow, so I'd like to explore all possibilities and then choose the best one.

This is the only true way to know people wont get at the data

http://www.cdrecyclingforfree.com/ha...hard_drive.jpg

I know some companies can recover data from smashed up hard drive disks... but maybe smashing it into hundreds of peices is going to make it a bit hard for them :P

Twelve gauge using slugs or buckshot is generally considered an acceptable security standard for the destruction of Federal hard drives. Of course, it has been appearing lately that taking them home has also been considered an acceptable method.

At one point, each sequential write of a file to a disk would write to the next available slot rather than overwriting the old slot. This was prevalent in DOS and early Windows days to my understanding, but I recently heard that better algorithms were being used in modern file systems. That original coding left files around for a looooooooong time on big disks, but it also lead to some pretty serious fragmentation, which isn't as big an issue these days.

Quote:

---

Originally Posted by MaximilianMayrhofer

How is repeatedly toggling each bit going to work? I suppose you could do a defragment to pull all of your data to one part of the drive, then split that part off as a separate partition and format the rest..

---

Why on earth would you use defrag for that?

It is called residual data

Formatting is useless

Kleinma is correct but I would suggest the sledgehammer and then an acid bath to be sure

You not only have RAID and other systems to worry about but there is also a cache on modern drives. It is flash ram and retains its data. Copying it to another partition just means you have created yet another copy of the file to retrieve.

Just check this out..

http://www.engadget.com/2008/05/06/h...complete-expe/


Another article I read about it said the reason the data was able to be preserved was like Shaggy said, the machine housing the HD was running DOS, so the worst parts of the HD destruction were in spots where no data was written. Since they had beamed half the data down before the shuttle exploded, they were able to recover most of the other half and put it to good use.

I didn't get it...:( Will a rewrite of the file through code write to the old slots or will it use new slots? Or will it do parts of both?

If you go through windows it will write to new slots and retain the data. AFAIK all OS's do this. You have to go through your BIOS and write directly to the disk. This still leaves the cache but if you dont copy your file it should not even be in there

I found a piece of code on this website which claims to delete files by overwriting them. Is it a hoax?

Code:

---

  // nTimes intentionally not yet implemented
  public void WipeFile(string strFilename, int nTimes)
  {
    if (! File.Exists(strFilename))
    {
      throw new ArgumentException("The file does not exist");
    }
   
    FileStream fsFile2Wipe = File.OpenWrite(strFilename);
    long nBytesInFile = fsFile2Wipe.Length;
   
    int nBufferSize = 1000, nWritten = 0;
    int nWriteNow = nBufferSize;
    byte[] abBuffer = new Byte[nBufferSize];
    for (int i=0; i < nBufferSize; i++) abBuffer[i]=0;
   
    for (nWritten = 0; nWritten <= nBytesInFile; nWritten += nBufferSize)
    {
      if ((nWritten + nBufferSize) > nBytesInFile)
              nWriteNow = Convert.ToInt32(nBytesInFile - nWritten);
      fsFile2Wipe.Write(abBuffer, 0, nWriteNow);
    }
    fsFile2Wipe.Close();
  }

---

I also found a classic VB project (open-source) here which, at least to me, looks legit. Unfortunately, my knowledge of pre .Net VB is very limited, so I'm asking the more experienced members of this forum to please have a look.

You should know that windows does not grant users (programmers in this case) direct access to hardware. Even when you are overwriting something, it can simply be saved somewhere else and the previous location marked as free.

One should first look for a way to get the physical address of a byte and then look for ways to write a byte exactly there.

Thanks for the heads-up. I thought of the same thing, but I wanted to consult the ppl with more experience than myself.

Btw, the VB project I mentioned in post #33 seems to do exactly that, at least to me. From the brief look I had, I figured that it was retrieving the locations of data on the hard drive via some API calls and then writing bytes on that same location. But, as I said, I am not very familiar with classic VB and APIs, so it would be better if someone more experienced cast a glance at the code.