6

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.

3
  • what do you mean by this "which word the SSD deterministically returns for trimmed data"? May 4, 2021 at 2: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. May 9, 2021 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. May 9, 2021 at 14:09

1 Answer 1

2

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}')
file_abs_path="$(realpath "$file")"
# The block of the file's contents
block=$(sudo debugfs -R "blocks \"$file_abs_path\"" "$device")
echo "Block used by "$file": $block"
# 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"

As a side note, if you remove the call to fstrim in this script, as shown here, you can see that the contents of the deleted file can be recovered.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .