|
|
|
|
|
by stcredzero
5583 days ago
|
|
My read is that the devices are still unfamiliar to investigators. I bet it's just a matter of time before someone starts figuring out how to read blocks that are waiting to be actually erased (which is a time consuming and energy-intensive operation for SLC flash, and sometimes deferred) on particular popular devices. Of course, it's going to be unfamiliar to those who have been working closely with HDDs at a low level for years. EDIT: Speaking of which: http://sec.pn.to/pw/?plugin=attach&pcmd=open&file=ta... tl;dr - That's just security by obscurity. Someone will figure out how to read unerased data. (That said, those blocks eventually will be erased and recycled, it's just a matter of when.) |
|
The (a) case is likely OSes using the "trim" command and the (b) cases are inherent in how SSD firmware works (by necessity). WRT the (b) case, SSDs have to garbage collect. Their write speed, and thus user satisfaction, is dependent on it keeping a large number of erased blocks ready to be written to.
[1] http://www.forensicswiki.org/wiki/Write_Blockers - apparently simply a "man in the middle" hardware that filters out write commands, lets through read commands.
Obviously, there is no reasonable way for a SDD to even know that a "write blocker" is attached, so it is not surprising (to me) that the SDD garbage collects with it attached.