Score:1

How to delete recoverable files?

in flag
Nav

I see a lot of posts about how to recover deleted files. But I'm asking about how to make sure that deleted files are un-recoverable. On an HDD and/or SSD. Sometimes we end up doing a delete instead of a shred, and need to ensure that nobody can access the file if the device is stolen or lost.

This would basically follow the steps:

  1. Search for recoverable files.
  2. Overwrite them with zeroes or random bits.

Any way to do this?

Reason: It is just not practical to do a full disk/partition wipe or even a free space wipe for every time I want to get rid of a few recoverable files that I deleted instead of remembering to shred it. Even if an encrypted partition is used, the files would be recoverable by anyone who has access to the password, or can guess or brute-force the password.

in flag
For HDDs you would need to overwrite the same sectors of the disk. For an SSD, TRIM will generally take care of this automatically on modern hardware. Is this something you want to do from time to time? Or is this just at a devices end-of-life?
vanadium avatar
cn flag
https://superuser.com/questions/19326/how-to-wipe-free-disk-space-in-linux With modern drives and file systems not always 100% reliable. Just wipe the entire disk to be sure your nuclear secrets cannot be retrieved.
FedKad avatar
cn flag
If you plan to keep some secret info on your storage device, it is always good idea to use full disk encryption or at least encrypt the files that contain such sensitive information. This way your secrets are always safe while on rest.
Nav avatar
in flag
Nav
I see that `TRIM` is programmed to run weekly by default. The thing is, doing a full-disk or full-partition wipe takes long...and reduces SSD life. I had enabled full-disk encryption once, but it eventually made things noticeably slower. Moreover, full-disk encryption isn't possible for a dual-boot Windows-Linux system. Finding recoverable files is already possible. We know where the file starts and ends. I hope someone implements the simple functionality of overwriting bits of such files that are found.
in flag
You seem to be adding more conditions to the question, which makes a complete answer very difficult to provide. If you need something that can be read across multiple OSes while also being irrecoverable on delete, then you will want to use one of those specially-encrypted USB keys that cost $200 for 64GB. They are designed for this very purpose. Otherwise, an encrypted LUKS container is an option, but will only get you 80% of the way to the goal. If you have data that is *that* sensitive, you probably want to avoid putting the machine on any sort of network as data in memory can be scooped
Nav avatar
in flag
Nav
All I'm asking for, is a software that can detect a recoverable file and overwrite some of the bits of the file, to make it un-recoverable. The remaining things I mentioned about full-disk encryption is just a reply to some of your questions, where I'm mentioning why I don't want full-disk encryption...or encryption as a solution. I just want to run a software that can find recoverable files and make them un-recoverable. Could the downvoter please remove the downvote? I don't see why a genuine question had to be downvoted.
John David avatar
in flag
Good point, Nav. You seem comfy with C/C++, so modifying the source of software like TestDisk may be the fastest approach: https://github.com/cgsecurity/testdisk/blob/master/INSTALL. Hopefully, someone would integrate this feature into TestDisk permanently.
Nav avatar
in flag
Nav
Well John, TestDisk's creators don't seem to be interested: https://github.com/cgsecurity/testdisk/issues/116. Thanks for the pointer though. It'll be interesting to work on the source code. The main reason is that it is just not practical to do a full disk wipe or even a free space wipe for every time I want to get rid of a few recoverable files that I deleted instead of remembering to shred.
Score:0
in flag

All I'm asking for, is a software that can detect a recoverable file and overwrite some of the bits of the file

I don't think this is possible.

The file is still on the disk, but you deleted the information where the file is located. So a software does not know what to delete.

There could be a software to search and locate the file, then wipe only this part. If the file is located in the beginning of the empty space, that could speed up the process a lot. But you need information what the file looks like (have parts of the content or a duplicate to compare, etc.).

Anyways, I don't know of a software like that.

Testdisks photorec can locate files (not a specific though). Instead of recovering, it could also delete the finds if there was an option to do so.


To prevent situations like this, the best option would be to use Full Disk Encryption.

Nav avatar
in flag
Nav
Even with full disk encryption, the files would be recoverable by anyone who has access or can guess/brute-force the password. If photorec can locate all the bits of (perhaps even a fragmented) file (which is obviously how it manages to recover the file), I'm hoping it'd be possible to get the addresses of those locations on disk (or at least some of the bits) and overwrite them with random bits.
pLumo avatar
in flag
Yes. Anyone with access can do a lot of things. But if you use good passwords, no one can guess or brute-force it. If you are still not convinced, use keyfiles.
Nav avatar
in flag
Nav
Perhaps another way would be to modify Nautilus' and Bash's delete function to invoke shred, so I wont have to remember to shred files. I assume this would require learning how to make changes to Ubuntu source code and apply the patch to my installed Ubuntu.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.