摘要：天津鸿萌科贸发展有限公司从事数据安全服务二十余年，致力于为各领域客户提供专业的数据恢复、数据备份、数据取证、数据迁移、网络安全、数据清除等解决方案，并针对企业面临的数据安全风险，提供专业的相关数据安全培训。
天津鸿萌科贸发展有限公司从事数据安全服务二十余年，致力于为各领域客户提供专业的数据恢复、数据备份、数据取证、数据迁移、网络安全、数据清除等解决方案，并针对企业面临的数据安全风险，提供专业的相关数据安全培训。
天津鸿萌科贸发展有限公司是众多国际主流数据取证、数据恢复、数据备份及同步软件的授权代理商：Miray(HDClone/HDShRedder)、Killdisk、Passware、PassMark、ElcomSoft、R-Studio、Systools、GetData、Stellar、ReclaiMe、UFS Explorer、VNR、SyncBack Pro、ViceVersa Pro 等。
随着 SSD 固态硬盘应用逐渐普及，取证工作不再仅限于 HDD 机械硬盘，通常也会涉及到对固态硬盘提取镜像。SSD 的工作原理与 HDD 不同，尤其是在删除文件时。其中一个关键原因：TRIM 命令。TRIM 使 SSD 在恢复已删除的证据时表现与机械硬盘不同。本文将详细介绍 TRIM 的实际作用、SSD 的响应方式以及取证专家在处理现代存储时需要了解的内容。
TRIM 只是 SATA 或 NVMe 工具箱里的命令之一——就像“read”或“write”一样，只不过 TRIM 的功能是“释放资源”。操作系统（而不是 SSD 本身）决定何时使用它。每次删除文件、格式化分区或清除可用空间时，操作系统都会告诉 SSD：“这些块不再使用了”。
SSD 控制器获取该地址列表（LBA）并将其标记为未使用或空闲。就这样 - 截止目前数据还没有被真正地擦除。接下来会发生什么完全取决于驱动器的内部逻辑。
或许在。也许不在。很大可能不在了。这完全取决于 SSD 控制器。
在 TRIM 之后，控制器可能会立即擦除 NAND 单元，可能会将它们推入备用单元，可能会稍后回收它们，或者可能根本不执行任何操作——只需将它们标记为未使用。控制器可能会稍后清理它们，或者永远不会。
是什么影响了这一点？
驱动器的控制器和固件内部垃圾回收设置是否具有动态 pSLC 缓存控制器当时有多忙NAND 的磨损程度但对于取证来说，关键的是：一旦一个块被 TRIM 处理，大多数 SSD 就会停止提供该块中的数据——即使它还没有被物理擦除。哪怕是 TRIM 之后立即读取，控制器也仅返回零（或者，理论上，另一个预先确定的序列）。
并非所有 SSD 在 TRIM 后的行为都相同。有三种主要模式：
Undefined （未定义） – 无保证。您可能会得到原始数据，可能会得到零，或者只是随机的垃圾数据。DRAT （Deterministic Read After TRIM） – 即使实际数据仍在 NAND 中，你也总是得到相同的结果（通常为零）。DZAT（Deterministic Zeroes After TRIM）– SSD 保证它每次都会在 TRIM 之后立即返回零。较旧且更便宜的 SATA SSD 通常属于“未定义”阵营。这对于可重复哈希来说是个坏消息 – 对同一个磁盘提取两次镜像可能会得到不同的结果。大多数现代 SSD，尤其是 NVMe 型号，至少支持 DRAT。高端和企业驱动器，尤其是 RAID 阵列中使用的驱动器，通常更大程度地支持 DZAT。
另一方面，当今的 NVMe SSD 专为速度而打造。它们通常包括动态 pSLC 缓存和主动后台清理。借助当今强大的 NVMe 控制器，几乎可以立即处理 TRIM 命令。
擦除整个 2TB NVMe 驱动器可能只需几秒钟。如只擦除其中的一部分，那几乎是立竿见影的。无论哪种方式，控制器都将在收到 TRIM 命令后立即开始读取零（或者，理论上，在 DRAT 的情况下，其他一些预定义的数据序列）。因此，当有人告诉你他们测试了空 SSD 的“读取速度” - 而且速度非常快，其实他们并没有真正在读取 NAND。他们只是在对控制器伪造读取零的速度进行基准测试。
如果你正在构建具有奇偶校验的 RAID 阵列（如 RAID 5 或 RAID 6），你的存储设备需要以可预测的方式运行。在计算校验和时，每个块都很重要，包括 “空” 的块。这就是 DZAT 标准的用武之地。
当然，从技术上讲，几乎可以在 RAID 中使用任何 SSD。但是，如果驱动器不支持 DZAT，控制器将不知道 TRIM 后的块会读取出什么。它可能假设它们包含有用的数据——因此，阵列最终会将所有内容（包括空闲空间）视为充满有意义数据的字节。
结果呢？每个写入操作最终都会触发整个阵列的写入。将其与 SSD 的工作原理（慢速块擦除后写入）相结合，在本应是快速存储系统的系统上，写入性能会很糟糕。
现在，当启用 TRIM 时（通常是这样），RAID 控制器需要一个关键保证：如果一个块被标记为空闲，它必须返回零。这正是 DZAT 所保证的。这就是为什么企业级 SSD（专为 RAID 阵列设计的 SSD）构建了 DZAT 支持。例如，NAS 制造商 ASUSTOR 有以下有关奇偶校验 RAID 上的 TRIM 的信息：“RAID 5 和 6 配置中的 Trim 功能只能在支持 DZAT（TRIM 后的确定性读零）的 SATA SSD 上启用。请联系您的 SSD 制造商，了解有关 DZAT 支持的详细信息。”
一些制造商则更进一步。他们提供两个具有完全相同硬件的 SSD，但配置不同。例如，WD Red SSD 可直接用于 RAID。它们支持 DZAT 和 skip 功能，例如动态写入缓存，以确保 RAID 环境中的一致性和持久性。WD Blue SSD 适合日常使用。它们仅支持 DRAT（不支持 DZAT），包括用于加速突发写入的动态 pSLC 缓存，并且不适合 RAID。
它们之间的真正区别是什么？有时只是固件。事实上，它可能就像在工厂将一些配置设置刻录到驱动器中一样简单 - 而硬件并没有改变。
取证专家和系统设计人员都应该牢记这一点：并非所有 SSD 都是一样的，即使它们在字面上看起来相同。控制器行为 - 尤其是 TRIM - 可以构成或破坏 RAID 系统的性能和可靠性。
核心事实是：一旦发送了 TRIM，数据就等同于消失了 - 至少从用户的角度来看是这样。即使 NAND 单元仍然保存这些位，但是 SSD 不会将其中的数据提供给你，除非你深入研究专用工具和 SSD 出厂访问模式。如果你只是将 SSD 插入 PC，即使通过写入阻止硬件，它也只会返回零，从而无法通过正常读取方式进行恢复。
简而言之：
TRIM 来自操作系统，而不是 SSD 本身。大多数现代 SSD 在 TRIM（DRAT/DZAT）后的行为是可预测的，这有助于实现一致的镜像和哈希验证。较旧的 SSD（未定义模式）可能会以不可预测的方式运行 – 这就是为什么通过相同方法提取的镜像，其哈希值会有所不同的原因。我们将理论与实践结合起来看一下。如果你希望提取 100% 取证有效的镜像，那么你可能不会通电启动 SSD，因为从理论上讲，SSD 可以在通电并启动后的几秒钟内执行延迟的垃圾回收任务，从而悄无声息地销毁你的证据。你可能会采取以下措施：
使用工厂级界面和专用工具包完全绕过原厂 SSD 固件直接读取原始 NAND 内容但现实是：这种程度的努力不太值得。大多数情况下，使用硬件写入阻止程序并立即对驱动器提取镜像同等有效。花费数小时设置出厂读取路径不会带来机会 - 因为 TRIM 命令已经在瞬间完成。只有一些罕见案例或从损坏的 SSD 进行数据恢复尝试时，工厂模式和低级别工具才有可能派上用场。此时 NAND 中可能仍然保存着可恢复的数据。但是，如果他们只是删除了一个文件呢？它已经消失了。TRIM 瞬时就完成了这个任务。
对于取证工作，不仅要了解 TRIM 的工作原理，而且要验证你所采用的写入阻止程序是否确实阻止了它，这一点很重要。幸运的是，如果你可以访问 Linux 系统和非关键 SSD（可以安全地覆盖），那么可以很容易地测试这一点。
重要提示：将 /dev/sdX 替换为 SSD 的实际设备路径。确保驱动器不包含任何重要数据 – 这些测试将覆盖特定扇区并可能破坏数据。
测试 1：基本 TRIM 功能检查
此测试验证当前 SSD 是否支持并运行 TRIM。
# 1. Write a known signature to sector 1000 (512 bytes)echo "TESTDATA1234567890" | dd of=/dev/sdX bs=512 seek=1000 count=1# 2. Confirm the signature is presentdd if=/dev/sdX bs=512 skip=1000 count=1 | hexdump -C# 3. Issue a TRIM (discard) command on that specific sectorblkdiscard -o $((1000*512)) -l 512 /dev/sdX# 4. Read the same sector again and observe the resultdd if=/dev/sdX bs=512 skip=1000 count=1 | hexdump -C预期行为：
如果驱动器支持 TRIM 并确定性地响应（例如，在 DRAT 或 DZAT 模式下），则最终读取返回值应都是零（或固定模式）。如果数据仍然存在或不一致，SSD 可能是在未定义模式下运行，或者 TRIM 可能被禁用。
测试 2：您的写入阻止程序是否阻止 TRIM？
一些取证级写入阻止程序宣称它们会阻止写入操作，但它们可能无法阻止 TRIM，这是一个单独的命令。第二个测试有助于验证这一点。
与上面测试一样，使用非关键磁盘并验证 TRIM 是否立即工作，然后再通过写入阻止程序尝试。
1. 将 SSD 直接连接到 Linux计算机。
# Write a signature to a known sector:echo "TESTTRIM1234567890" | dd of=/dev/sdX bs=512 seek=1000 count=1# Confirm the signature is present:dd if=/dev/sdX bs=512 skip=1000 count=1 | hexdump -C2. 断开驱动器的连接，然后通过写入阻止工具重新连接。再次挂载它。
# Attempt to issue a TRIM command via blkdiscard:blkdiscard -o $((1000*512)) -l 512 /dev/sdX# Read back the sector to check if the data survived:dd if=/dev/sdX bs=512 skip=1000 count=1 | hexdump -C如果您的写入阻止程序运行正常，则表明 TRIM 命令被禁用，并且原始数据应仍然存在。
如果数据消失，则写入阻止程序或许没能阻止 TRIM，即使它可能会阻止正常的写入操作。
TRIM 不会“删除”数据 – 它只是告诉 SSD：“我不再使用此块。”，其余的完全取决于 SSD 控制器。因此，如果你正在对 SSD 提取镜像：
不要预期已删除的数据仍然存在了解 SSD 的行为小心使用可能不遵循 DRAT 或 DZAT 规则的旧 SSDSSD 的取证工作不仅仅是使用什么工具，还需要了解幕后发生的事情。来源：小肖科技观
