SSD Forensics

Definition

SSDs are a mass storage device that uses NAND-based flash memory chips

SSDs have gained significant popularity due to their decreasing prices and widespread use in mobile devices, particularly laptops. While SSDs may appear to be a straightforward replacement for traditional rotational drives (HDDs), there are several key differences to consider:

Limited Lifespan: SSDs have a finite lifespan due to the physical limitations of their cells, typically around 10,000 program-erase cycles. This means that each cell can only be written and erased a certain number of times before it becomes unreliable.
Block Rewriting: Unlike HDDs, where data can be rewritten at the sector level, SSDs require the entire block (ranging from 16 to 512kB) to be blanked and rewritten. This process, known as block rewriting, can impact the efficiency and performance of SSDs.
Flash Translation Layer (FTL): SSDs incorporate a crucial component called the Flash Translation Layer (FTL). The FTL acts as a bridge between the ATA channel and the memory chips in the SSD. It is responsible for managing various tasks, such as logical-to-physical block address translation, write caching, garbage collection, wear leveling, and data compression.

These differences highlight the unique characteristics and challenges associated with SSDs compared to HDDs. Understanding these distinctions is essential for effectively utilizing and managing SSDs in various computing environments.

Definition

The FTL (Flash Translation Layer) is an hardware component that translates Logical Block Addresses (LBA) as requested by the OS into the respective Physical Block Addresses (PBA) on memory chips. It is completely transparent to the OS. The FTL is responsible for all the management of the memory chips, like:

Write caching: some data is written to the cache memory before being written to the memory chips

Trimming: preemptive blanking of erased blocks marked for trimming by the OS

Garbage collection: reclaiming blocks that are no longer in use to make them available for new data

Data compression: transparently employed by some drives to use less physical blocks and reduce wear

Data encryption/obfuscation: some SSDs encrypt data before writing it to the memory chips

Bad block handling: managing blocks that are no longer usable

Wear leveling: spreads consumption of cells as evenly as possible across the drive

In traditional hard disk drives (HDDs), we can directly access and read a specific sector from the operating system. However, in solid-state drives (SSDs), the flash translation layer (FTL) translates logical block addresses (LBA) requested by the OS into physical block addresses (PBA) on the memory chips. This mapping is transparent and can be modified by the FTL at any time. The FTL may move or erase data even when the OS is not active. This poses challenges for forensic analysis on SSDs, as most forensic methods and tools rely on the OS’s ability to access the raw data on the disk.

The FTL can be bypassed by directly reading the memory chips, but this approach is highly time-consuming and expensive. It requires specialized tools, a hardware setup to interact with the memory chips using an FPGA and custom wing boards, and reverse engineering of the FTL implementation. This process is not easily repeatable, can alter or destroy the evidence, and is highly dependent on factors such as firmware and hardware. Additionally, information about the FTL is not publicly available and is heavily protected intellectual property of the vendors.

Black block SSD analysis

In order to analyze the impact of the FTL on black box forensic analysis, a testing methodology was developed to assess the behavior of the FTL under different conditions. The goal was to determine whether a SSD implements trimming, garbage collection, compression, and/or wear leveling. The testing methodology included the following steps:

Trimming: preemptive blanking of erased blocks marked for trimming by the OS. This can reduce data persistence and impact acquisition. The methodology can determine the percentage of blocks that get erased and how fast.
Garbage collection: hypothesized to work with a filesystem-aware controller that TRIMs blocks without OS support. The forensic impact is obvious. The methodology can determine whether it is employed by the SSD under examination.
Erasing patterns: peculiar behaviors shown by some SSDs when using TRIM.
Compression: transparently employed by some drives to use less physical blocks and reduce wear. The methodology can verify whether compression is active.
Wear leveling: spreads consumption of cells as evenly as possible across the drive. The methodology tests for the so-called “write amplification” effect, which is a direct consequence of wear leveling.
Files recoverability: a test on the efficacy of black box file recovery techniques.

Test drives

In the following analysis, three SSDs were tested: Corsair F60, Samsung S470, and Crucial M4. The available features on each SSD are listed in the table below.

SSD WL TRIM GC Compression
Corsair F60 ✓ ✓ ✓ ✓
Samsung S470 ✓ ✓ ✓
Crucial M4 ✓ ✓

SSD	WL	TRIM	GC	Compression
Corsair F60	✓	✓	✓	✓
Samsung S470	✓	✓	✓
Crucial M4	✓	✓

Nowadays, SSDs are equipped with a small amount of DRAM-based cache memory to reduce physical writes. This cache memory can bias any test using small files (i.e., smaller than 512MB-1GB, typical cache size). To avoid this bias, the cache can be disabled or large files can be used, that in Linux can be done via hdparm -W 0.

Trimming

flowchart TD
    A(Disk formatting)
	B((NTFS or ext4)) 
	C(Disk filling at<br>different percentages)
    D((25%, 50%,<br>75%, 100%))
	E(Start real-time analysis<br>of disk zeroed space)
    F(Quick format in<br>OS with TRIM support)
    G(Single files deletion)
    H((Win7 for NTFS\nUbuntu for ext4)) 
	I(Zeroing percentage verification)
    J(Check state of<br>deleted file's sectors)
    K{{hdparm --fibmap <filename>}}
    L{{hdparm --read-sector <address> </dev/sdx>}}

	A --- B
	A --> C --- D
	C --> E
	E --> F --- H
	F --> I
	E --> G --> J
	J --- K --- L

If TRIM is enabled and active on an SSD, it typically takes 1-10 seconds for the TRIM operation to occur. On the NTFS file system (used in Windows), the Samsung S470 and Crucial M4 SSDs aggressively perform TRIM, quickly wiping the disk or file in under 10 seconds. However, the Corsair F60 SSD exhibits a peculiar behavior, where erased blocks seem to be proportional to the amount of used space. Some files are wiped within 3 seconds after deletion, while others remain untouched.

On the ext4 file system (used in Linux), all SSDs take approximately 15 seconds to erase the entire disk during a format operation. The Samsung S470 does not perform immediate erasure upon file deletion, and the Crucial M4 only triggers TRIM when the disk is unmounted. In contrast, the Corsair F60 SSD correctly erases all files in this scenario.

Garbage collection

flowchart TD
    A(Disk formatting)
    B((NTFS or ext4))
    C(Disk filling at<br>different percentages)
    D((25%, 50%,<br>75%, 100%))
    E(Disk image acquisition)
    F(Quick format in<br>OS with TRIM support)
    G((Win7 for NTFS\nUbuntu for ext4))
    H(Disk image acquisition)
    I(Comparison to<br>find zeroing patterns)

    A --- B
    A --> C --- D
    C --> E
    E --> F --- G
    F --> H
    H --> I
    E --> I

In a previous study, it was found that garbage collection triggers in almost 3 minutes, while non-authoritative sources state 3 to 12 hours. In the tests, none of the SSDs performed garbage collection. Even when trying to replicate the exact test of the previous study, with identical hardware, software, and firmware version, garbage collection was not triggered.

Erasing patterns

flowchart TD
    A(OS write cache disabling)
    B(Creation of data blocks of equal size)
    C((10 GB))
    D{{/dev/zero/}}
    E(Creation of low entropy data)
    F(Copy data in main memory)
    G(Write time calculation)
    H(iostat)
    I(Write time comparison)
    J{{/dev/urandom/}}
    K(Creation of high entropy data)
    L(Copy data in main memory)
    M(Write time calculation)

    A --> B
    B --- C
    B --> E --- D
    E --> F
    F --> G
    G --> H
    B --> K --- J
    K --> L
    L --> M
    M --> H
    H --> I

Certain SSD controllers may exhibit unexpected trimming patterns. In the case of the Corsair F60 SSD, the target of interest, the erasing patterns were validated on file recovery. Files in green stripes were recoverable only 0.34% of the times, outside 99%.

Compression

flowchart TD

    A(OS write cache<br>disabling) --> B{Creation of data<br>blocks of equal size} --- Z((10GB))

    E --> C{{/dev/zero}}

    F --> D{{/dev/urandom}}

    B --> E(Creation of<br>low entropy data)

    B --> F(Creation of<br>high entropy data)

    E --> G(Copy data in<br>main memory)

    F --> H(Copy data in<br>main memory)

    G --> I(Write time<br>calculation)

    H --> J(Write time<br>calculation)

    I --> K((iostat))

    J --> K

    K --> L(Write time<br>comparison)

In the tests, with repeated transfer of 10GB low and high entropy files, Samsung and Crucial SSDs showed no compression, while the Corsair SSD performs hardware compression.

Wear leveling

flowchart TD

    A(OS write cache<br>disabling)

    B(Partial disk filling at different percentages)

    C((25%,50%,75%))

    D(Creation of a file with known pattern)

    E(Start real-time analysis of disk free space)

    F(Multiple overwrites of file with known pattern)

    G((10000 writes))

    H(Periodic verification of zeroed space)

    I(Disk image acquisition)

    J(Carving to find multiple copies of known file)

  

    A --> B --> D --> E --> F

    D --> F --> I --> J

    F --> H

    B --- C

    F --- G

The wear leveling was not tested for presence (as it is almost default) but for usefulness for forensic analysis. From a black box point of view, if write amplification does not happen or is completely masked, there is no difference between having or not wear leveling processes. In the tests, no drives showed write amplification from an external point of view.

Files recoverability

flowchart TD

    A(Choice of a file easy to recover -<br>to eliminate weight of carver errors)

    B(Disk filling)

    C(Quick format)

    D(Disk image acquisition)

    E(Carving)

    F(Recovered files hash calculation)

    G(File hash calculation)

    H(Integrity check on recovered files)

    I{{md5sum <file>}}

    J{{sha1sum <file>}}

  

    A --> B --> C --> D --> E --> F --> H

    A --> G --> H

    G -.- I

    G -.- J

The files recoverability was tested on different file systems (NTFS and ext4) for each SSD. The results are shown in the table below:

SSD	FS	Written	Recovered	%
Samsung	NTFS	112,790	0	0
	ext4	110,322	0	0
Corsair	NTFS	101,155	71,607	70.79
	ext4	99,475	0	0
Crucial	NTFS	112,192	0	0
	ext4	110,124	0	0

The results show that drives implementing an aggressive TRIM policy, did not allow the recovery of any file after the format procedure. The Corsair SSD on NTFS has a non-null recovery rate due to the erasing patterns that make some files recoverable. On ext4, the recovery rate is 0% for all SSDs.

Limitations and conclusions

flowchart TD

    A(TRIM) --> C{Zeroing <br>detected?}

    B(Garbage Collection) --> C

    C -- No --> D((Class A))

    C -- Yes --> E(Files recoverability - single file removal) --> F{Intact files <br>recovered?}

    C -- Yes --> G(Erasing patterns) --> H{Pattern <br>detected?} -- Yes --> I((Antiforensics <br>feasible))

    C -- Yes --> J(Files recoverability - quick format) --> K{Intact files <br>recovered?}

  

    F -- None --> L((Class D))

    F -- Some files --> M((Class B))

    F -- Some files --> N((Class C))

    K -- Partially --> M

    K -- Partially --> N

    K -- No --> L

The study conducted on SSD forensics has identified several limitations. One limitation is that the study did not test multiple firmware versions, as firmware upgrades are typically irreversible, making it difficult to replicate the experiments. Additionally, the study did not explore the impact of different device drivers and AHCI commands for the sake of simplicity. This means that if the investigator is unaware of the specific OS version being used, the methodology may not provide useful insights.

In conclusion, the study reveals that SSDs employ techniques that can potentially disrupt black box forensics. To better understand the impact and potential benefits of a white-box approach, the study proposes a triage workflow. It emphasizes that the combination of the SSD controller, operating system, filesystem, and disk usage can significantly influence forensic procedures. Notably, the study found that leading drives currently do not offer garbage collection functionality.

Polimi CS - Notes

Explorer

SSD Forensics

Table of Contents

Black block SSD analysis

Trimming

Garbage collection

Erasing patterns

Compression

Wear leveling

Files recoverability

Limitations and conclusions

Graph View

Table of Contents