I have a file on android phone which I would like to securely wipe it.
I read this.
It mentions This is especially true on mobile devices containing flash, which has wear-leveling to prolong its life and isn't guaranteed to overwrite the same block internally when you overwrite a block on the filesystem.
So, if I would to use the code on.Would it securely wiped on android phone ? Or when I use RandomAccessFile to write data to the file, it would be on a new block instead of the original block ?
Is it totally 100% impossible to get known of the exact block pointer on android ?
Or I have to recursively create a file, write with random data until the storage space hits the max. Then I try to edit the file I wish to delete. Which the flash will be force to use the original block while I rewrite the content and delete it.
Try to read the documentation about the Objects and Methods used in the code you mentioned This , nothing points that you write over the real Blocks used to save the file, and note the file can be written in Non-Sequential blocks, i think my friend told me about article discuss this issue, and they solved it using C++.
Related
FileUtils.copyDirectory doesn't write date modified correctly unless the Android SD card is unmounted. Using this simple bit of code from FileUtils:
try {
FileUtils.copyDirectory(srcDir2, destDir2);
} catch (IOException e) {
I can copy a directory from the internal storage on the phone to the sd card preserving the date modified information on the files in the directory which is essential for my app.
Sadly if the SD card is removed without ejecting it all the date modified information on the files in the copied dir is set to the time the files were copied. if the SD is unmounted correctly then the date modified information is preserved correctly.
I have tried the flush and close functions but they are not relevant to this kind of file. What code am I missing to finalize the directories without unmounting? I am using an android device will a full size SD slot and I cant risk loosing all the information if it gets knocked out without a proper eject
There's a version of this method that accepts a flag as third parameter to try to control the date of last modification. You can check the docs here. But looks like the method you are using also tries to preserve the date by default. In fact, reading the source code, the method you are using just calls this method with the third parameter set to true.
In the docs for your method it is said:
Note: This method tries to preserve the files' last modified date/times using File.setLastModified(long), however it is not guaranteed that those operations will succeed. If the modification operation fails, no indication is provided.
In the end what this library does each time it copies a file or dir is to call File.setLastModified over the destination file with the last modified date of the source file. This method has been reported to be unreliable in Android, as you can see in these other questions:
Android set last modified time for the file
file.lastModified() is never what was set with file.setLastModified()
Is it possible to reset the last modified date of an Android file?
But in your case, I think you are trying to provide a workaround for something that is just designed that way. I'm no expert, but this is managed by either the OS or the FileSystem. The unmounting mechanism serves a purpose, I think you can't do much about it as an app developer.
I have function to read image file az byte array.
Performance analisys gives to me interesting facts.
I have check if file exists and then read as byte array.
File.exists spent 69.7% of time in function ?????
Open read and close spent only 30,3% of time.
I cant't explaint to mysefl why?
Is this depend on something or it is default behaviour?
If this check is always slow - may be better approach is to open file without check for existing. And of cource use catch to solve case with missing file.
UPDATE:
Files are stored in internal SD card. More than 20000 files.
When test with 30 files percent is reduced to 23%.
Finally I'm using file open without check 'exists'. Working with files I have to catch exceptions - so my code security isn't compromised.
I'm writing a purge function for our software that removes all image files that haven't been used in over a month. To do this, I am checking two things:
the last-modified date of the file
a query on a database that shows recently viewed files.
The query is much slower than the file check. So I would ideally like to be able to reset the last modified date on any files that fail the first check, but pass the second, so that (for example) a list of venerable but often-used files aren't gradually increasing the processing load of the management system.
Is there a way to do this without recourse to something crude (and possibly even slower), like renaming each file to a temporary label, then itself?
As Nik said the setLastModified() method on the File class may not always work depending where you are in the Android file system. If on the SD Card then some devices will return false from that call and thus not change the date.
There are more details about it here:
http://code.google.com/p/android/issues/detail?id=1992
http://code.google.com/p/android/issues/detail?id=1699
Plus some other stackoverflow thread here:
file.lastModified() is never what was set with file.setLastModified()
setLastModified() is a standard method on any Java File object that you can use to update this value.
SDK Documentation.
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.
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.
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.
So, largely for debugging purposes, I want to be able to write an image at arbitrary points in my code, and look at it later. I figured this would be easiest if I just wrote a my bitmap to a file and read it back later, but I cannot seem to figure out where to find the file after I write it, or how to open an image that is not in res/drawable with a corresponding handle in R.
You can use openFileOutput() and openFileInput(). These pull up data streams that point to files in your app's directory, and are (as far as I know), the suggested way to handle files that your app makes.