4

This article on forensicfocus.com says the following about Deterministic Read After TRIM (emphasis mine):

As a result, the data returned by SSD drives supporting DRAT as opposed to DZAT can be all zeroes or other words of data, or it could be the original pre-trim data stored in that logical page.

The sentence makes it sound like trimmed data could be recovered on some SSDs by simply asking the SSD controller for it.

hdparm tells me that my SSD (SanDisk SSD PLUS 1000GB) has DRAT enabled:

Data Set Management TRIM supported (limit 8 blocks)
Deterministic read data after TRIM

I'd like to find out which word the SSD deterministically returns for trimmed data.

Matthias Braun
  • 421
  • 3
  • 12
  • what do you mean by this "which word the SSD deterministically returns for trimmed data"? – Life is complex May 04 '21 at 02:34
  • @Lifeiscomplex: The SSD has a certain byte sequence (word) that it reports as the contents of a page after that page was deleted. It could be all zeros, a different byte sequence that's hardcoded into the SSD's controller, or, according to the article, the contents of the page before it was "deleted". I'd like to know a way to find out which of those possibilities it is. – Matthias Braun May 09 '21 at 11:18
  • 1
    I'm sorry that I never got back this question. I was busy writing code for StackOverflow questions. Concerning your question, I know that every disk reports differently. I was looking for more tech data for your SanDisk, which allegedly does Trimming correctly. Let me do some more research to see what I can find for your disk. – Life is complex May 09 '21 at 14:09

1 Answers1

1

The DRAT word seems to be zeros

I used the following experiment to conclude that the DRAT word of the SSD in question is zeros:

  1. Create a small file and get the block number of its file contents.
  2. Delete the file.
  3. Run fstrim to send the TRIM command to the SSD's controller. My OS (Arch Linux 5.12.9) doesn't trim SSDs automatically, discussion here.
  4. Read the contents of the deleted file's block with debugfs: It's all zeros.

Here's a script performing those steps:

#!/bin/sh

file=test_file
echo "Current date: $(date)" > "$file"; sync
# Get the device of our test file, for example "/dev/sda1"
device=$(df -P "$file" | awk 'END{print $1}')
# The block of the file's contents, stat gets the inode number
block=$(sudo debugfs -R "blocks <$(stat -c %i "$file")>" "$device")
# fstrim needs the mountpoint of the file system, e.g. "/"
mountpoint=$(stat -c %m "$file")
rm $file; sync
# Send TRIM to make the SSD delete unused blocks. Might take a while
sudo fstrim "$mountpoint"
# Read the contents of the deleted file, -D bypasses the buffer cache
sudo debugfs -D -R "block_dump $block" "$device"
Matthias Braun
  • 421
  • 3
  • 12