CODEWITHSUNDEEP
androidlinuxfilefile-iofilesystems
Barmaley
Barmaley

Reputation: 16363

Deleting file (including content cleaning)

In my application I need to delete file with sensitive information. For that I'm writing to file some garbage generated by random bytes and then deleting using File.delete() method, like here:

long size=file.length();
Random r=new SecureRandom();
OutputStream os=new BufferedOutputStream(new FileOutputStream(file));
while(size > 0)
{
    os.write(r.nextInt());
    size--;
}
os.close();
file.delete();

So the question is: does this method guarantee that if someone will undelete file one will find only garbage instead of real content? I'm not completely sure that writing to file would guarantee that the same sectors in underline Linux filesystem will be overwritten... Please give a hint - what to do - to be sure that file content is destroyed.

Upvotes: 2

Views: 587

Answers (2)

FrankH.
FrankH.

Reputation: 18217

No, it doesn't guarantee that. The reason for that is the filesystem implementation underneath - it is not forced by any standards to ever overwrite existing data. A fully valid, (POSIX-)standard-conforming way of implementing a write operation for a filesystem is to allocate a brand new block of storage, put your "new" data into there, and then change the block structure of the file in such a way that the new data block is referenced for the location you write in the file and the previously-used data block is "released" - whatever that means in detail. After that, you can't access the old data anymore (through the filesystem) but it's still on disk, so save erasing the entire storage medium you're not erasing the traces.

Many filesystem implementations of functionality like snapshots or replication rely on this mechanism (Copy-On-Write). Linux Btrfs or Solaris ZFS use it extensively. I think Android's YAFFS does too. As Chris mentioned, the wear leveling FTL in any flash memory will behave like that as well.

The answer that's usually given how to deal with this problem on filesytems employing copy-on-write is to never have it occur in the first place. I.e. encrypt the file when writing it, and "throw away the key" when deleting the file. What you can't decrypt you can't recover ... but I agree there's the chicken-egg problem of where/how to store the encryption key.

Upvotes: 4

Chris Stratton
Chris Stratton

Reputation: 40357

No, it does not guarantee that the original blocks are overwritten - on a flash device it's extremely unlikely that they would be, though one might need tools below the O/S level or even below the chip data sheet interface level to do the recovery.

You really cannot guarantee erasure except if you have flash memory with no on-board controller that can substitute blocks and repeatedly erase and overwrite it from its low level driver, or you physically destroy the media.

If you are talking about the SDcard with a fat filesystem, I believe based on past recovery of an accidentally saved back picture edit that linux doesn't even try to write back to the same blocks of the file system.

You can confirm that the data is still recoverable by putting the card in a linux box and grepping the raw device file for something known to be in the deleted file; unfortunately this will not prove that the data might not still be there in a block that's been re-mapped by the device driver or an on-chip controller, and potential accessible by a lower-level tool.

Upvotes: 4

Related Questions