Write blockers are not effective with SSDs

There is a significant difference between SSDs and HDDs, and bus-level write blockers (be it SATA, USB, or SAS) which work with HDDs are not effective when used to write-block SSDs. The write blocker will obviously block writes from the host PC, but the data may still change thanks to how SSD technology works.

What is the difference?

Externally, over the interface, both hard drives and SSDs accept read and write requests. SSDs additionally accept a special TRIM request, indicating that certain area on the media is no longer in use. Filesystem will typically issue a TRIM request for a content of a deleted file, indicating that it no longer needs data in the area formerly occupied by that now-deleted file.

Internally, hard drive implements the same read and write requests to the media. The ability of the hard drive to write data to a given sector does not depend on the content of that sector. On the contrary, SSDs cannot write data into an arbitrary location. SSD groups sectors into pages (4 KB to 16 KB per page), and further groups pages into blocks (256 KB to 4 MB per block). Reads and writes are page-granular, and erases are block-granular. Importantly, pages cannot be overwritten. To write data, a SSD needs a blank page to write to; pages filled with data, even partially, cannot be used. If there are no blank pages, the block of unused pages needs to be erased. To avoid a situation when there are no readily available blank pages, SSDs perform two types of cleanup

  1. Blocks which have few “dirty” pages are optimized so that all pages with data are copied into one of the empty blocks, and the other block, now empty, is erased. This is sometimes called garbage collection.
  2. If a SSD receives TRIM request from host, the pages referenced in the request are queued for eventual erasure.

The above two processes are executed inside an SSD and are thus completely invisible to the host PC and its operating system.

The maintenance is mostly performed in background, when a SSD is idle. There are various possible strategies SSD can employ to determine when to perform the maintenance.

  1. Immediately, if the free space is low and at least one blank writable page is needed right away. This rarely happens, because it means SSD is full to capacity and in heavy use.
  2. At first opportunity (immediately when idle state is detected).
  3. When certain thresholds are exceeded, thresholds being function of available space and a number of pages enqueued for erasure.
  4. On timer.

The above or other strategies can be combined in intricate ways. You should keep in mind that SSD does not have any mechanical parts which slow down its transition to and from idle state. Hard drive takes three seconds to spin up from what can be considered idle. SSD wakeup is instantaneous. So, SSD idle state happens pretty quick.

How does all this affect write blocking?

On a hard drive, if a file is deleted or a volume is formatted, the data which was not explicitly overwritten stays on the drive indefinitely. Also, data written to one area of a hard drive does not affect data written to any other area. If you have two partitions, A and B, on a hard drive, and you quick format the partition B, the data is still there. The data will still be there even if you write to the partition A. As long as you do not touch B, the original data is still there indefinitely1.

On a SSD, things are very different. Once the file is deleted, the data is still there, but for some undetermined amount of time. If the OS is TRIM-capable (and most OSes are), the data is completely erased as soon as blocks in TRIM queue are erased. The exact time when it happens depends on the specific flash memory controller. Even with TRIM disabled the data will still be erased during garbage collection as soon as demand for blank pages becomes high enough.

Worse yet, all this activity takes place inside the SSD without any request and in general case without any possibility of interference from the host. It does not matter if you have a hardware write blocker and no SATA writes can pass through it - garbage collection and TRIM processing are executed exclusively by the controller inside your SSD.

So if you are imaging a SSD over SATA, the data may change midway, or may change between two passes of the imager. If you make two images with write blocker applied, you may find that two images are not identical. There is no general way to avoid this, short of chip-off dumping. Obviously if you read flash memory chips directly, there is nothing controller can do about it - it is not even connected to the chips any longer. However, this seems to be overly expensive and impractical for everyday practical purposes. Just something to keep in mind, especially if you are doing forensic acquisition.

1 The rule of data recovery "do not write anything to the physical media you are recovering from" is so general because the interactions on the live volume are complex. You can sometimes write data on the drive you are recovering from without making the situation worse, but it is so hard to figure out when it is safe that you rather don’t.

Created Monday, April 16, 2018

Updated 20 May 2018