SSD file deletion

Ok I have read the paper and a most interesting read it is too. Far be it for me to precis it here as i am neither clever enough or have the time for a 21 page document.

But suffice to say the crux of the research is regarding the Garbage collection utility on SSD's rahter than the deliberate obfuscation by the criminally minded. However it would appear, to me at least, that given the process employed by the garbage collection routine the end result would most likely be the same.

I may of course be misinterpreting the whole paper (refer to my clever comment) but it seems to me that this really represents an issue that has faced investigators, crime scene investigators and experts since time imemoriam that is to say it will be one of accepting that you may not get what you hope for and so need to have a well developed and clearly documented process that mitigates the "holes" in your evidence. There will potentially be a much greater inference on opinion.

Then once the forensic technology has caught up and thought of a way to prevent the garbage colelction the technology companies those dreadful bad guys will think of another way to keep us awake at night!

these are some initial thoughts which i reserve the right to change at will once i have thought more about it )

I apologise if we have had this discussion on the forum previously but i thought it was worth resurrecting in light of this news story.

cheers

In the spirit of wiping disks…

Magnetic media, you can "fully erase" by writing zero's or random 1's 0's. Your best bet with SSD's, is to write a file to the disk which takes up all the disk space.

This is because of the logical layer that exists, which doesn't actually "point" to the physical location (or all the locations) of data on an SSD or flash memory, apparently. There was a white paper out there just recently. They subscribe to the multi-pass myth on magnetic media, so I can't actually put that much faith into their methods. One that that should work though, is writing a large file to the SSD until all space is used up.

Now I am going to read the paper upon which the first article was based and i have a suspicion that there may be some lazy journalism but I would be interested in anyones views and observations on this issue.

My first reaction after reading the original paper was 'not proven', though that's probably partly a knee-j**k reaction. The reason was that the only device they tested was a 64GB Corsair device, which, as far as I can find, also uses the Samsung firmware that they also say does something clever with NTFS bitmaps to know what clusters can be be garbage-collected. So … is their conclusion one that is valid for all flash drives, or valid only for Samsung-firmware devices or perhaps only this particular device? Until other devices have been tested, I don't see that there is any way to decide. For that reason, I found the conclusions just a bit too strong.

Another interesting question – which I couldn't see the paper adressed – is what causes the garbage collection cycle. The position of the paper is that the flash drive does it all by itself, but I can't see that the possibility that the disk driver or any other support software does it has been properly eliminated. There is no mention that a special disk driver or other disk software was installed, so perhaps there is no such connection. On the other hand, Windows XP (which is what the testing system used) has no support for TRIM, so any such support must be placed in a disk driver or similar drive support software – and these flash drives do need that support. (On the other hand, if Samsung's bitmap-inspecting code gets the job done without TRIM, driver support may not be needed.)A bit more information on that particular point – was any device-specific code installed? - would have been welcome.

If the device needs an external command to start the garbage collection, then it seems possible to avoid that by using default ATA drivers. If the device does the job all by itself, it seems as if it might be possible to prevent it from doing so by installing new firmware immediately when the drive is powered on.

The first article talks about erasing the drive, and not just deleting files.

Deleting files is something the operating system does, typically by removing the directory entry, clearing down FAT / bitmap tables etc. The only way to clear data is to overwrite sectors. Logically a SSD is the same as a physical drive.

However when it comes to a format command, this is hardware based and I see no reason why this could not act as a physical reset button, and maybe all memory bytes are cleared within seconds. With a physical drive, the only way to do this is to spend a few hours overwriting every track/sector.

Without looking at the spec sheets I do not know if this is the case, but for drives there is normally a 'SCSI' Format command, and the drive then does the rest.

The inconsistency is not IF the SSD uses TRIM, but when. The controller is not required to zero the "sectors" immediately after a TRIM command is called. Some, for example, store them in cache and only run them in periods of inactivity - which is most liklely the "garbage collection" the paper refers to.

The paper states that we, as users, cannot know when these periods are, and we cannot control it. So although you may think it doesn't make much difference to us, it most certainly DOES - when you connect a SSD to a write-blocker, it is entirely possible that it may commit it's cached TRIM commands and so your data will change. You also cannot guarantee it won't run them after imaging either. It makes any evidence obtained from unallocated extremely volatile.

So it is most definitely something to bear in mind. Of course, in the future we may have smarter write-blockers which inform the SSD not to commit any TRIM commands or garbage collection routines. I guess we can only cross our fingers and hope!

Greetings,

Even if our writeblockers can control the SSD's TRIM behavior somehow it will be too late in the vast majority of the cases. Anything deleted weeks, days, and probably even hours before the drive was collected will be gone.

The only benefit to disabling the garbage collection that I can see is that you'd be able to get identical hashes if you image the drive multiple times. And I can't see anyone going to the expense of enabling that coordination between a writeblocker and an SSD just for that purpose.

I think we need to accept that our hard drives are going to look a lot more like RAM in the sense that they're both highly volatile.

-David

I think we need to accept that our hard drives are going to look a lot more like RAM in the sense that they're both highly volatile.

-David

Well put!

It's very interesting to me that the SSD, while a discrete package like any typical hard drive, is exhibiting attributes (particularly the aforementioned volatility) which resemble those of a completely virtualized disk object, spread pseudo-randomly over one or more storage arrays in a multi-tenancy solution.

The memory chips on flash drives can be read directly with 100% success in my experience.