Solid State Drives & Forensic Data Acquisition

Have you seen the presentation that was given by Gareth Davies at the F3 this year?

I haven't no, any idea how I can find out more about it……….

I haven't no, any idea how I can find out more about it……….

I would suggest some research. The topic has been really widely covered on pretty much ever major IT site.

Here let me do a Google Search for you.

theregister
http//www.theregister.co.uk/2011/03/01/self_destructing_flash_drives/

The Journal of Digital Forensics, Security and Law
http//www.jdfsl.org/subscriptions/JDFSL-V5N3-Bell.pdf

Wikipedia
http//en.wikipedia.org/wiki/Data_remanence#Data_on_solid-state_drives

Slashdot
http//hardware.slashdot.org/story/11/03/01/1740240/ssds-cause-crisis-for-digital-forensics

Scott Moulton of myharddrivedied.com has given multiple talks on SSDs and their impact on forensics/data recovery. Just do search on him (or go to his site) and there are plenty of links to past presentations he's given.

As I understand the issue SSDs do garbage collection, so unused sectors are blanked out, ready for use at a later date.

For a long time I could not entirely understand how this can work with the drive not knowning all current and all future file systems. However, I think the answer is that current device drivers know what they are doing, and when deleting the file, also tell the device which sectors are now free. In it's own time, the device will quietly blank these sectors. When idle, this is typically a period of minutes not hours or weeks. (obviously size dependant).

As the device has been told what to clear, no write blocker will have any effect. At the F3 talk, one possible solution is a chip off approach. Rather distructive and then requires knowledge to reconstruct the data from possible multiple flash chips.

The write blocker may control future events, but not past events.

At last years F3, there was a talk about write blockers and these are not perfect. If a new command is created to control the SSD, an old write blocker may not necessily block it or enable it as required.

Key words to google are "Trim" and "Garbage collection"

Have fun!!

Scott Moulton of myharddrivedied.com has given multiple talks on SSDs and their impact on forensics/data recovery. Just do search on him (or go to his site) and there are plenty of links to past presentations he's given.

Agreed - and what I was about to post! Scott has also been on the forensic podcasts over the past year or so and discussed issues. His work would be my first start as it gives you a good base to branch out from.

I have had issues with duplicators (TD1) and SSDs - stop reading and operation fails. Get with better luck on write blocker to PC (typically T35es via E-SATA to Win 7 x64 with FTK imager) but havent had enough of a sample set nor time to really get enough information as to why.

For a long time I could not entirely understand how this can work with the drive not knowning all current and all future file systems.

I think some of the early implementations (i.e. pre-TRIM) did it only for some specific file system (or systems) where the bitmap over allocated sectors was known and could be checked. If the file system wasn't of that type/those types, nothing happened.

It is my understanding that SSDs which implement this only do so in quiet periods. Therefore if a specialist write-blocker could be developed which constantly requests reads from the device, would that solve the issue?

This was discussed at F3 as a possibility, but I don't know if t has been tried. The suggestion was that it would have to be plugged in with a continous read running.