I know that when files are deleted they aren't really completely erased. The drive just says hey this space is free and you can overwrite it. With programs like Boot and Nuke and Eraser .etc. you can write over those sections with random bytes.
How does this process differ with SSDs? Does trimming the drive with disk optimizer remove the files completely?
SSD flash memory cannot overwrite existing data in a classic manner. In an HDD system, the Operating System can request that new data be written to the same location where data is already stored, and the drive will directly overwrite the old data (magnetically). In an SSD, however, the target area must first be erased before it can be written to locations previously holding data. This is happening because of the internal structure. Flash memory is divided into blocks, sub-divided in pages. Data can be written directly into an empty page, but only whole blocks can be erased. So if you want to erase some of the data in a block, the rest of the data will be copied to another and the initial block will be erased or marked usable/empty.
The process is handled by FTL (flash translation layer) which has to do something like this when you change a very small amount of data: read one whole physical block (which let's say contains 64 pages - it can be up to 256), replace what you edited (let's say 4 pages) while keeping the rest intact (60 pages), erase a new block somewhere on the device and finally write the new set of 64 pages on that block.
TRIM support enables the old blocks to be considered empty, even if they have not been erased yet, which improves endurance.
The result of all that is that physically, some data still exists in marked-as-empty blocks and may be theoretically recovered by special means.
But this also simplifies a lot free space erase. You can just make a self-expanding file to occupy all space or copy any random data just to reach 0 free space and at that point all your previous blocks are practically irreversibly erased.
If you want to completely wipe the drive, you can use any tool supporting ATA Secure Erase, which electrically nullifies all data in the blocks. The tools are vendor specific (Corsair SSD Toolbox, OCZ Toolbox, Intel Solid State Toolbox, Samsung Magician Software). These essentially set all available blocks to the “erase” state (electrically), which is what TRIM uses for garbage collection purposes (and with which erases the blocks with before usage). The blocks remain empty with no information on their initial content.
So, to clean an SSD you just have to follow one rule: use all it's space for something. If a simple copy-a-big-file seems strange, you can always create an encrypted partition taking all the space, copy data there, then erase it and re-create it. But taking all the space with junk data is enough for a complete clean-up.
How does this process differ with SSDs? Does trimming the drive with disk optimizer remove the files completely?
We need to consider:
If we consider a 240 GB SSD for example one might expect if we zero-fill that 240 GB we have overwritten every LBA block with zero and thus the data being unrecoverable.
This is incorrect, we're more likely dealing with a 256 GB SSD drive however that missing space is reserved for over-provisioning at the firmware level.
Many mistake 'trimming' for erasing data. This is not correct. TRIM is a 'command' that allows the OS or a utility to message to the drive: "I will not be needing these LBA blocks anymore, do with them as you please".
Typically the SSD firmware un-maps these LBA addresses. This means if you read from them, the drive does not actually read the data from these sectors, but typically returns zero filled sectors (RZAT). If you write to them, available sectors are mapped to these BA addresses.
The unmapped sectors are part of pages. A page is the smallest area an SSD can write to, and it is only after the SSD firmware actually erased the data from these, the data is not securely erased and could be recoverable.
Linux tools exist that allow 'trimming' a drive, Windows ports for these exist too and although these allow to zero a drive quickly, it does not guarantee data is actually erased even though you may only be able to read zeros back from the drive.
A data recovery lab may be able to recover data using equipment like the PC3000.
Compressing data at the firmware level before writing it to the NAND memory has been an idea for a while and is now actually being implemented. I'm not saying every SSD does it, but it's something you should consider as a possibility when settling for a secure erase method.
One practical implication is, that if we use a so called zero-filler to overwrite existing data with, zeros tend to compress pretty good. And so the amount the data that is actually written to the drive may be far less than you might expect.
From the above we can distill we we need to write non-compressible (high entropy) data to the drive to overwrite existing data, and we need to write, say twice the amount of data of LBA addressable space to have some certainty over-provisioned space is overwritten too.
Even if we do that, this still isn't a guarantee all data is overwritten if we consider discarded blocks (removed from the pool due to media errors) for example.
Alternatively we can rely on built-in secure erasing methods as specified in various specifications (ATA, NVMe etc.).
https://www.usenix.org/system/files/conference/inflow14/inflow14-zuck.pdf - on firmware level compression https://www.intel.com/content/dam/www/public/us/en/documents/technology-briefs/ssd-520-tech-brief.pdf - on firmware level compression https://en.wikipedia.org/wiki/Entropy_(information_theory) - On 'entropy' https://blog.elcomsoft.com/2019/01/life-after-trim-using-factory-access-mode-for-imaging-ssd-drives/ - Recover data after TRIM
There are many tools to erase a drive but most are rather slow.
The fastest way I found to securely erase a drive (SSD or HDD) is to write random data to it by using cryptsetup.
On Linux you can easily do it like this:
DEVICE=/dev/??? # put your device ID here
cryptsetup create cryptedDEV $DEVICE # use any pass, no need to remember it
DEVSIZE=$(cryptsetup status $DEVICE | grep "size:.*sectors" | awk '{print $2}')
pv -s $DEVSIZE /dev/zero > /dev/manpper/cryptedDEV
cryptsetup remove cryptedDEV
