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 block writes from the host PC, but the data may still change, thanks to how SSD technology works.

What is the difference?

Externally, hard drives and SSDs accept read and write requests over the interface. SSDs additionally accept a special TRIM request, indicating that a specific area on the media is no longer in use. The 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, a hard drive implements the same read and write requests to the media. The hard drive's ability 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; erase is block-granular. Importantly, pages cannot be overwritten. To write data, an 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 with few "dirty" pages are optimized so that all pages with data are copied into one of the empty blocks, and the other, now empty, is erased. This is sometimes called garbage collection.
  2. If an SSD receives a TRIM request from the 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 the background when an 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 immediately. This rarely happens because it means SSD is full and in heavy use.
  2. At the first opportunity (immediately when the idle state is detected).
  3. When certain thresholds are exceeded, thresholds being a function of available space and the number of pages enqueued for erasure.
  4. On timer.

The firmware can combine the above or other strategies in intricate ways. You should remember that SSD does not have any mechanical parts that slow down its transition to and from an idle state. A hard drive takes three seconds to spin up from what can be considered idle. SSD wakeup is instantaneous. So, SSD idle state happens pretty quickly.

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 partition B, the data is still there. The data will still be there even if you write to partition A. As long as you do not touch B, the original data is still there indefinitely1.

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

Worse yet, all this activity takes place inside the SSD without any request and, in the 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 an SSD over SATA, the data may change midway or between two imager passes. If you make two images with a write blocker applied, you may find that the two images are different. There is no general way to avoid this short of chip-off dumping. If you read flash memory chips directly, there is nothing the controller can do about it - it is no longer connected to the chips. However, this seems overly expensive and impractical for everyday practical purposes. Just something to keep in mind, especially if you are doing a 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