File deletion and/or restore

[bally1001]

As an ex Windows (10) user I was accustomed to secure confidential file deletion using PrivaZer software which used to corrupt the file at binary level making it nonsense. And then during their clean-up process it removed any trace in the MFTs and other logs. Equally, Piriform's Recuva software facilitated file restoration in the event of deletion in error, always supposing PrivaZer hadn't been used to delete the file.

So, my question, is in two parts:- In Mint, when it states "this file will be permanently deleted".....does this mean what it says, or does the file still exist on the drive (in my case an SSD)?. If it does still exist somewhere (as it would do on Windows), how can I either remove it at binary level (including it's traces) or start a recovery process?.

Thanks.

[xenopeek]

Seeing as you have a SSD, you can't reliably erase the data of a single file. You can only erase the data of the entire disk. Any 3rd party program that claims it can erase the data of a single file is a scam. Windows or otherwise.

When you overwrite a file on a SSD, the SSD firmware just marks the current blocks of the file as available, leaves the data on it, and assigns other, less often written to, previously available blocks to the file and writes the new data to that instead. This is part of SSD's wear leveling algorithms. Only the SSD firmware knows how logical disk blocks map to actual physical locations on the flash chips. Eventually the data may get overwritten, or the blocks may be swapped with those in the spare area in which case the data is retained indefinitely. Data would be recoverable in that case by reading the flash chips directly with a flash chip reader.

In short, if you want to reliably delete data on your SSD you have to issue the ATA Secure Erase command to the disk which makes the SSD firmware erase the contents of all the flash chips. That's the only reliable way to erase data from a SSD. More trivial then is to just set up Linux Mint with disk encryption at time of installation. That way it doesn't matter that disk blocks with confidential data could be recovered as the data would be encrypted. Hence I always recommend to use disk encryption with SSDs.

You can recover deleted files using TestDisk and/or PhotoRec: https://www.cgsecurity.org/.

[bally1001]

Thanks for your reply, and for the link to file restoration that supports Linux.

The 3rd party program I mentioned (PrivaZer) doesn't actually delete any targeted file until free space (including that labeled for overwriting) is securely wiped. That process is an option within the software. As you say, the characteristics of an SSD does not permit that in order to facilitate wear spreading.....But what it does do is screw up the binary values of that file. Either all zeros, or 1s or random...For example, A JPEG or any other image/document file header will always be left in one place together with the first few clusters. With those binary values corrupted, even if the program misses a few locations where parts of such files have been scattered, the possibility of restoration is severely reduced. That was my experience with Windows (7 &10)......Not knowing if such software was available that is compatible with Linux distros I submitted my question.

[xenopeek]

As long as you're clear that any change of byte values in a file has the following effect:
- the data on the affected disk blocks is not changed and will remain recoverable in clear text for an undefined period
- the changed data is instead written to new disk blocks
- file type can be identified from any part of the file, not just the header
- and this is what file recover programs also do to recover only parts of files

I know there is such software specifically for HDDs, where shred for example is reliable, but I don't know of anything like what you describe for SSDs but it's the first time I hear of it. Leaving everything but the header of confidential files recoverable in clear text seems strange approach to me. I'll reiterate that using disk encryption seems the more logical approach to me as that doesn't leave any part of deleted confidential files recoverable in clear text, unless the attacker has the mount passphrase.

[Termy]

In Mint, when it states "this file will be permanently deleted".....does this mean what it says, or does the file still exist on the drive (in my case an SSD)?

Still exists.

If it does still exist somewhere (as it would do on Windows), how can I either remove it at binary level (including it's traces) or start a recovery process?.

Apparently not that thorough if using a journaling file system, but the shred command is a good option for a fuller deletion, especially with the -z flag; it's usually always available, but I'm sure there are plenty of other, fuller-featured solutions; look in the Software Center, or equivalent. As for recovery, testdisk is a fantastic option.

[phd21]

Hi bally1001, xenopeek, Termy, & Anyone Else Interested in this,

I just read your post and the good replies to it. Here are my thoughts on this as well.

+1 for using an encryption option for any truly secure needs.

I have been thinking about this secure delete for a long time in regards to an SSDrive.

Obviously, with older mechanical platter hard drives, the various secure delete options work very well.

My question is: With the newer SSDrives, could you not still run a secure delete program, and then just run the "Trim" command manually to make sure what you deleted is gone, and then reboot the computer, or reboot and then run the "Trim"?

Code: Select all

sudo fstrim -v /

...

[xenopeek]

Trim is just a way for the operating system to inform the SSD firmware which logical blocks on the disk (as the operating system sees it) are no longer in use by it. This lets the firmware mark the associated physical blocks (only the firmware knows which logical block goes with which physical block) as available. Trim does not do a security erase.

[bally1001]

Interesting replies to my initial question. Thanks.

So, having concluded that, with Linux distros, even after using Bleachbit (root) there is no totally secure way to eliminate all traces of unwanted files from either HDD or SSD, the only way is to, before any deletion process, save a copy of the file in question onto an encrypted pendrive (just in case) and then, with documents, remove the content, save and then rename, then delete. With images, using GIMP (for example) merge a 'one colour' layer with the original then save, rename, then delete. True, if anyone is so determined to try, and using some pretty sophisticated kit, they could, in theory restore some remnants, especially from an HDD (not so much SSD) of the file. And manipulation of same. Although on this last point, I'm not sure because in Windows such info was held in the various registry hives and I'm not yet conversant with such matters in Mint.

To be honest, in my past 'Windows days' although I had faith in PrivaZer and Ccleaner, this is the method I employed to secure delete.

[Mute Ant]

"remove the content, save and then rename, then delete." No. That might be what you want to happen, but it doesn't happen like that. When you write something to a store, assume it's permanent, for anyone to copy, forever, until you secure-delete the hardware.

[Termy]

there is no totally secure way to eliminate all traces of unwanted files from either HDD or SSD

I think that probably applies generally, rather than just to Linux. When it comes time to get rid of the drive, you can take it to a place in which they physically trash the drive, like one of those big industrial crushers.

[bally1001]

@ Mute Ant....Thanks for your reply....But I'm not too sure I follow and more info would be appreciated.....A lengthy ODF spreadsheet document, for example, which is updated frequently (such as bank account tracking) over a long period cannot, logically, retain a copy at each update event even under derivatives of the original file name, otherwise any form of file deletion would be meaningless. Equally, a large image file that has had photoshop software used on it to do whatever will have been 'saved' on numerous occasions to avoid making errors that would screw up previous (and quite possibly lengthy) work....Again, on such a large image file, a copy saved at every 'save' event would consume an enormous amount of disc space.

@ Termy.....I agree, in fact I have used an angle grinder to destroy an old HDD on two occasions.....That was before I discovered Acronis software which was included in their cloning device......And unless someone has been really naughty, necessitating high powered investigations, that is more than adequate.

[xenopeek]

on such a large image file, a copy saved at every 'save' event would consume an enormous amount of disc space.

And still, this is how SSDs work. Every time you overwrite a file, it gets written to different physical storage blocks, leaving the data on the original blocks intact. That's how SSD wear leveling works. Such blocks don't get overwritten by new data until they are among the least written to blocks. And even then, the firmware may swap these blocks out with fresh blocks from the spare area and then they never get overwritten.

I'll say once more: regardless of which operating system you use or what 3rd party software you use to wipe files, that puts up demonstrable false claims that it can wipe files from SSDs, the only reliable way to ensure file data is not recoverable in clear text is to use disk encryption. Be that on Windows, Linux, macOS or other.

[phd21]

Hi bally1001,

So, having concluded that, with Linux distros, even after using Bleachbit (root) there is no totally secure way to eliminate all traces of unwanted files from either HDD or SSD...

Your comment is not an accurate or true statement. There are various excellent methods in Linux to securely delete files and or folders and or to "wipe" typical HDD drives (hard drives). It is with SSDrives (solid state drives) that the secure delete and or "wipe" drive options are in question on Linux, MS Windows, or Mac operating systems. As was already stated, If you use reliable encryption options for sensitive files (data), then that is not an issue either.

Be very careful using "Bleachbit" as a root user, which is usually not necessary in order to use its secure delete option.

There are many good posts already in this forum on various secure delete options for regular mechanical platter hard drives.


Solid State Drive/Memory cell clearing - ArchWiki
https://wiki.archlinux.org/index.php/So ... l_clearing

SSD Secure Erase - Thomas-Krenn-Wiki
https://www.thomas-krenn.com/en/wiki/SSD_Secure_Erase

ssd - I need to run a security erase tool on my drive - Ask Ubuntu
https://askubuntu.com/questions/604426/ ... n-my-drive

Do SSDs Really Ever Securely Delete Your Data?
https://www.makeuseof.com/tag/ssd-secure-delete-data/


Hope this helps ...

[Mute Ant]

"...copy saved at every 'save' event would consume..." Yes, it does exactly that. Every write goes into least-used free space, leaving the old data intact but marked as free-space. Eventually, when the block storing the old data qualifies as least-used, it will be erased by new data. How long does that take... one full write of the unused storage capacity is my guess.

[bally1001]

@ Mute Ant

"""Every write goes into least-used free space, leaving the old data intact but marked as free-space."""

Yes, I understand that (now)....It therefore means that if the BleachBit option 'wipe free space' (in either basic or root mode) is activated, its interpretation of ''free space' is somewhat at odds with the stated objective. That is to say, space occupied by redundant writes of updated files is not, in actual fact, 'free space' at all until the space qualifies as 'least used'.

This formed the basis of my original remark, in that software for Windows (PrivaZer) gives you the option of either wiping (at bit level) the whole "free space" (literally) which takes a while depending on how many passes are configured, or just wiping last used....That, used in conjunction with Piriform's Recuva (paid) gives the option of 'deep scan' whose context menu afterwards offers multiple wipes of any oddments that PrivaZer misses. It may be that Windows NTFS characteristics permits that process, I don't know.

In any event, thank you for your information....I am now a bit wiser.