If you’re doing forensic work today, odds are you’re imaging SSDs, not just spinning hard drives. And SSDs don’t behave like HDDs – especially when it comes to deleted files. One key reason: the TRIM command. TRIM makes SSDs behave different to magnetic hard drives when it comes to recovering deleted evidence. This article breaks down what TRIM actually does, how SSDs respond, and what forensic experts need to know when handling modern storage.

TRIM in layman’s terms

TRIM is just another command in the SATA or NVMe toolbox – like “read” or “write”, only TRIM is “deallocate”. The operating system (not the SSD itself) decides when to use it. Every time a file is deleted, a partition is formatted, or free space is cleared, the OS tells the SSD: “These blocks aren’t used anymore.”

The SSD controller takes that list of addresses (LBAs) and marks them as unused or free. That’s it – no actual erasure just yet. What happens next depends entirely on the drive’s internal logic.

So, is the data still there after TRIM?

Maybe. Maybe not. Most likely not. Depends entirely on the SSD controller.

After TRIM, the controller might erase the NAND cells immediately, might push them into spares, might recycle them later, or might do nothing at all – just mark them as unused. It might clean them up later, or never.

What influences this?

• The drive’s controller and firmware
• Internal garbage collection settings
• Whether it has a dynamic pSLC cache
• How busy it is at the time
• Even the wear level of the NAND

But here’s the part that matters for forensics: as soon as a block is TRIM’d, most SSDs stop giving you the data from that block – even if it hasn’t been physically erased yet. Instead, the controller will return zeros (or, theoretically, another pre-determined sequence) when you try to read it even a moment past TRIM.

TRIM modes and why they matter

Not all SSDs behave the same after a TRIM. There are three main modes:

• Undefined – No guarantees. You might get the original data, you might get zeros, or just random junk.
• DRAT (Deterministic Read After TRIM) – You always get the same result (usually zeros), even if the real data is still in NAND.
• DZAT (Deterministic Zeroes After TRIM) – The SSD guarantees it will return zeros, every time, immediately after TRIM.

Older and cheaper SATA SSDs often fall into the “undefined” camp. That’s bad news for repeatable hashes – imaging the same disk twice might give different results. Most modern SSDs, especially NVMe models, support at least DRAT. High-end and enterprise drives, especially those used in RAID arrays, often go further with DZAT.

On the other hand, today’s NVMe SSDs are built for speed. They often include dynamic pSLC caching and aggressive background cleanup. With today’s powerful NVMe controllers, TRIM commands can be processed almost instantly.

Wiping an entire 2TB NVMe drive might take mere seconds. Wiping just part of it? Practically immediate. Either way, the controller will start reading zeroes (or, theoretically, some other pre-defined data sequence in case of DRAT) immediately after receiving the TRIM command. So when someone tells you they tested the “read speed” of an empty SSD – and it was blazing fast – they weren’t reading NAND. They were benchmarking how fast the controller can fake-read zeros.

TRIM and RAID: why DZAT is necessary

If you’re building a RAID array with parity – think RAID 5 or RAID 6 – your storage needs to behave predictably. Every block matters when computing checksums, including the “empty” ones. That’s where the DZAT standard comes in.

Sure, you can technically use almost any SSD in a RAID. But if the drive doesn’t support DZAT, the controller won’t know what to expect from blocks that were TRIM’d. It might assume they contain useful data – and as a result, the array ends up treating everything, including free space, as if it’s full of meaningful bytes.

The outcome? Every single write operation ends up triggering writes across the array. Combine that with how SSDs work – slow block erasure followed by write – and you’ve got terrible write performance on what’s supposed to be a fast storage system.

Now, when TRIM is enabled (which it usually is), the RAID controller needs one key guarantee: if a block is marked as free, it must return zeroes. That’s exactly what DZAT ensures. This is why enterprise SSDs – the ones specifically designed for RAID arrays – are built with DZAT support. For exapmle, ASUSTOR, a NAS manufacturer, has the following information about TRIM on partiy RAID: “The Trim feature under RAID 5 and 6 configurations can only be enabled on the SATA SSDs with DZAT (Deterministic Read Zero after TRIM) support. Please contact your SSD manufacturers for details on DZAT support.”

Some manufacturers take things a step further. They ship two SSDs with the exact same hardware, but configure them differently. For example, WD Red SSDs are RAID-ready. They support DZAT and skip features like dynamic write caching to ensure consistency and durability in RAID environments. WD Blue SSDs are for everyday use. They support only DRAT (not DZAT), include dynamic pSLC caching for speeding up burst writes, and aren’t fit for RAID.

What’s the real difference between them? Sometimes just firmware. In fact, it might be as simple as a few configuration settings burned into the drive at the factory – the hardware’s the same.

Forensics experts and system designers alike should keep this in mind: not all SSDs are equal, even if they look identical on paper. The controller behavior – especially with TRIM – can make or break a RAID system’s performance and reliability.

Forensic Implications of SSD Trimming

Here’s the core truth: once TRIM has been sent, the data is as good gone – at least from your point of view. Even if the NAND cells still hold the bits, the SSD won’t give them to you unless you dive into specialized tools and SSD factory mode. If you just plug in the SSD to a PC, even through write-blocking hardware, it just returns zeros, making recovery impossible via normal reads.

TL&DR:

• TRIM comes from the OS, not the SSD itself.
• Most modern SSDs behave predictably after TRIM (DRAT/DZAT), which helps with consistent imaging and hash validation.
• Older SSDs (undefined mode) might act unpredictably – that’s where hashes may differ across identical imaging attempts.

Real-World Tradeoffs

Let’s talk theory versus practice. If you want your extraction 100% forensically sound, you wouldn’t even power on the SSD. You’d:

• Use a factory-level interface and a specialized toolkit (like PC-3000)
• Bypass stock SSD firmware entirely
• Read the raw NAND contents directly

Because in theory, the SSD can perform delayed garbage collection tasks in seconds after boot, silently destroying your evidence.

But here’s reality: that level of effort is rarely worth it. Most of the time, using a hardware write blocker and imaging the drive immediately is just as effective. Spending hours setting up a factory read path gives you the same result – because the TRIM was already completed in a split second. The only time the factory mode and low-level tools might help are the rare timing-critical cases and data recovery attempts from damaged SSDs. Then maybe the NAND still holds recoverable data. But if they just deleted a file? It’s already gone. TRIM handled that instantly.

How to test TRIM support and write blocker behavior

If you’re working in a forensic environment, it’s important not only to understand how TRIM works, but also to verify your write blocker actually blocks it. Fortunately, testing this is straightforward if you have access to a Linux system and a non-critical SSD (one you can safely overwrite).

Important: replace /dev/sdX with the actual device path of your SSD. Make sure the drive does not contain any important data – these tests will overwrite specific sectors and may destroy data.

Test 1: Basic TRIM Functionality Check

This test verifies whether TRIM is supported and functioning on a given SSD.

# 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 present
dd if=/dev/sdX bs=512 skip=1000 count=1 | hexdump -C

# 3. Issue a TRIM (discard) command on that specific sector
blkdiscard -o $((1000*512)) -l 512 /dev/sdX

# 4. Read the same sector again and observe the result
dd if=/dev/sdX bs=512 skip=1000 count=1 | hexdump -C

Expected behavior:

If the drive supports TRIM and responds deterministically (e.g., in DRAT or DZAT mode), the final read should return all zeroes (or a fixed pattern). If the data remains or is inconsistent, the SSD may operate in undefined mode – or TRIM may be disabled.

Test 2: Does your write blocker block TRIM?

Some forensic-grade write blockers advertise that they block write operations, but they may fail to block TRIM, which is a separate command. This second test helps verify that.

As before, use a non-critical disk and verify that TRIM works directly before trying it through the write blocker.

1. Connect the SSD directly to your Linux machine.

# 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 -C

2. Disconnect the drive and reconnect it via the write blocker. Mount it again.

# 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

If your write blocker is functioning properly, the TRIM command should be blocked, and the original data should still be present.

If the data is gone, your write blocker may not block TRIM – even though it might be blocking normal write operations.

Final thoughts

TRIM doesn’t “delete” data – it just tells the SSD: “I’m no longer using this block.” The rest is entirely up to the SSD controller. So if you’re imaging an SSD:

• Don’t assume deleted data is still there
• Understand the SSD’s behavior
• Be cautious with older drives that might not follow DRAT or DZAT rules
• Forensic work on SSDs isn’t just about tools – it’s about understanding what happens under the hood.