Getting SMART(er) with Information

In a blog post I wrote about write blockers, I left this question for myself to return to:

SMART Attributes: After creating a forensic image of the drive, I may be able to check the SMART attributes of the NVMe SSD with a Linux OS via smartmontools. Will this work? What changes will be made? I don’t know, but that’s an experiment for another day. I appreciate how Tetra Defense and Arman Gungor offer information why SMART attributes may be relevant to an investigation.

From Scott Moulton’s class, Forensic Hard Drive Data Recovery, I learned Self-Monitoring, Analysis and Reporting Technology System (SMART) data in mechanical hard disk drives, along with other Utility Block Addressing (UBA) Modules, is stored in the Service Area or System Area (SA). Drive identifiers, e.g., drive serial number are also stored in the SA. Since the SA is not uniform or standard, this will vary by drive.

With regard to NVM Express Solid State Drives (NVMe SSDs), SMART information is documented in section 5.16.1.3 of the NVM Express® Base Specification (Revision 2.0c). Serial numbers and other drive identifiers are specified in section 5.17.2.1 regarding the Identify Controller Data Structure.

Considering SMART information is not stored in a location described as “user accessible space“, reviewing that data is not expected to impact a traditional forensic image. It may even be helpful to provide information of investigative value.

Tool sets like smartmontools can monitor SMART or control SMART features of a drive to assess its health. Gungor and Tetra Defense notes its investigative value, specifically calling out Power-On Hours and Power Cycles Count for SATA drives. For drives to that support it, Total LBAs Written and Total LBAs Read may also be of interest.

Samsung SATA SSD with SMART Attribute IDs 9, 12 and 241 (www.Cropel.com).

Samsung NVMe SSD with SMART information for Data Units Read, Data Units Written, Host Read Commands, Host Write Commands, Power Cycles, and Power On Hours. Data Units are the number of 512 bytes.

SMART attributes aren’t particularly standardized, especially for hard disk drives. Smartmontools uses a text file, drivedb.h, that maps these attributes; it may need to be updated from time to time (Chris Siebenmann). The drivedb.h file also provides auto-detection of various USB bridges if the USB ID can be obtained by the operating system .

Like smartmontools, nvme-cli is also capable of gathering SMART information from NVMe SSDs.

Retrieving SMART Information

To answer my own question about SMART data, I explored a few methods to review this information with smartmontools while protecting an NVMe SSD from write commands:

Bootable Linux distribution, Computer Aided Investigative Environment (CAINE)
Windows Forensic Environment build
USB Stabilizer Professional (Upgraded from Guardonix Professional)

Linux Distribution, CAINE

I created a live USB with Rufus and used the newly released CAINE v13 “warp”. CAINE “blocks all the block devices (e.g. /dev/sda), in Read-Only mode”. This distribution is already packaged with smartmontools 7.2 and nvme-1.16.

Using smartctl to print all SMART information for my OS drive.

Using nvme id-ctrl to print Identify Controller information.

Using nvme smart-log to print SMART Health Information log.

Printing all SMART information with smartctl primary includes data based on two Admin Commands.

Admin Command > Identify > Controller (Defined by Identify Controller Data Structure (5.17.2.1)
Admin Command > Log Page > SMART / Health Information Log (5.14.1.3)

Printing similar SMART information using the nvme-cli package can be done by:

nvme id-ctrl /dev/nvme0n1 (metebalci AND sleeplessbeastie)
nvme smart-log /dev/nvme0n1 (sleeplessbeastie)

Yes. You can totally delete data from an NVMe SSD in CAINE using the nvme format command. Be cautious about those commands!

Wiping a PC300 NVMe SK hynix 256GB SSD that supports User Data Erase (001b) via the Format NVM command (5.14) using the nvme-cli package in CAINE 13.

smartctl before and after nvme format of an NVMe SK hynix 256GB SSD.

Windows Forensic Environment

WinFE is basically WinPE with two registry modifications that disables auto-mounting. I built a bootable WinFE external USB drive using Colin Ramsden‘s x86/x64 USB/CD Framework and guidance from Brett Shaver’s Ultimate DFIR Cheats! Windows Forensics Environment. I used Windows 10 Pro 19044.2604 with Windows ADK and the PE add-on (ver. 1903), and smartmontools version 7.3.

Printing SMART information using smartctl.exe with Ramsden’s Write Protect Tool on display.

DeepSpar Guardonix/USB Stabilizer Professional

Based on my observations, the Guardonix Professional control panel is only able to report on SCSI IDENTIFIER TYPE fields. For the few NVMe SSDs I tested, that information reported is often not complete.

Smartmontools is capable of using supported USB bridges to report SMART information and device identifiers for various disks using the SAT (SCSI/ATA Translation) or vendor specific pass-through commands. By using the appropriate smartctl device type option (automatically detected for supported USB bridges), the USB bridge translates the SCSI command to the corresponding ATA or NVMe command. However, Guardonix Professional does not permit all SCSI pass-through commands. DeepSpar noted it’s one of the features that separates the Guardonix Professional from the USB Stabilizer Professional. In an attempt to print all SMART information through the Guardonix Professional, the first command to read the NVMe Identify Controller Data Structure fails with the error, “IOCTL_SCSI_PASS_THROUGH_DIRECT failed, Error=5″.

Guardonix Professional blocking SCSI pass-through command.

While I believe the ability to retrieve SMART information from NVMe SSDs with the Guardonix Professional ought to be available (SMART attributes may be logged from SATA drives via the Commands menu), upgrading to the USB Stabilizer Professional allows the SCSI pass-through commands necessary to use smartctl.exe.

This is how I upgraded the Guardonix Professional:

Paid the difference between the Guardonix Professional and the USB Stabilizer Professional. DeepSpar will activate the license for the serial number of the Guardonix Professional and will issue a new serial number for the USB Stabilizer Professional upgrade.
Restarted the Guardonix control panel. It will silently upgrade itself over the internet.
Downloaded the Stabilizer panel from https://deepspar.com/usbstabilizer/download/ and entered the new serial number.
Installed the Stabilizer panel and rebooted machine.
Labeled the hardware unit with the new serial number.

USB Stabilizer Professional with R-Studio, ignoring write attempts, and retrieving device information using smartcrl.exe.

While you may still use the Guardonix control panel, be mindful to use one application to control the DeepSpar USB hardware unit at a time. One use-case where using the Guardonix control panel instead of the USB Stabilizer control panel might be beneficial is to absolutely avoid changing “Response to Write Attempts” from Ignore to Allow Write.

What SMART Information Changed?

Gungor notes despite being connected to a write blocker, SMART data is expected to change. Gungor also notes Power Cycle Count and Power-On Hours are two SMART attributes that are potentially useful to “detect if the drive continued to be used when it was supposed to be kept in storage”. What SMART information might be useful from NVMe SSDs for the same purpose?

In addition to Power Cycles and Power On Hours; Data Units Read, Data Units Written, Host Read Commands, and Host Write Commands are fields that may be of interest.

If an NVMe SSD is write protected, I expect the following observations:

NVMe SMART Information Log	Expectation
Data Units Read	Increase
Data Units Written	No Change
Host Read Commands	Increase
Host Write Commands	No Change
Power Cycles	Increase
Power On Hours	Increase

I gathered SMART information for my OS drive (Samsung 970 EVO Plus 2TB) by booting to CAINE and WinFE. Traversing the disk with a hex viewer, Host Read Commands and Data Units Read count increased. An additional Power Cycle was also recorded when I booted from CAINE to WinFE. The count for Host Write Commands and Data Units Written did not increase. All these observations were expected.

While Power On Hours was expected to change, it did not for this observation. I suspect it is because how little time passed when requesting SMART information from the NVMe controller between boots.

CAINE 13 smartctl baseline against the NVMe OS disk.

CAINE 13 smartctl after mounting, then traversing a read-only disk.

Terminal advising that the file I attempted to create cannot be done on a read-only disk.

Following a shutdown from CAINE, I booted to WinFE and executed smartctl.exe against the same disk.

WinFE smartctl.exe after mounting, then traversing a read-only disk.

With USB Stabilizer Professional and the option to ignore write attempts, I used the WiebeTech WriteBlocking Validation Utility against another NVMe SSD (Samsung PM981 256GB) housed in a Plugable USBC-NVME M.2 enclosure using the RTL9210 USB bridge. While Host Read Commands and Power Cycles did change, it was interesting that Data Units Read did not.

Noting changes to SMART information between the first WiebeTech WriteBlocking Validation Utility test and the third.

Write protected NVMe SSD passes WiebeTech’s WriteBlocking Validation Utility’s test.

Traversing the NVMe SSD with X-Ways Forensics, Data Units Read and Host Read Commands increased. Data Units Written and Host Write Commands remained the same across 9 additional Power Cycles.

Summary

When I wrote a post about write blockers for a compact and capable go-bag, I contemplated how SMART data may be a valuable source of information, and how I might collect it from a write protected NVMe SSD drive.

In this post, I revisited that question. I briefly described where SMART data is stored for SATA drives and NVMe SSDs, and considered specific SMART information that may interesting. Using the smartmontool tool set and write protection techniques, I retrieved SMART information from NVMe SSDs with CAINE, WinFE, and DeepSpar’s USB Stabilizer Professional. I also noted any changes to the SMART data along the way.

It was intriguing to observe how SMART information changed in my selection of NVMe SSDs, particularly for Data Units Read and Host Read Commands. It was like watching a vehicle’s odometer roll into a milestone. No change in Host Units Written and Host Write Commands also corroborates that the write protection techniques works as intended.

SMART information may retrieved from an NVMe SSD using a combination of smartmontools and a bootable forensic environment, or a hardware device that supports write blocking and SCSI pass-through commands like DeepSpar’s USB Stabilizer Professional.

Would recording SMART information before and after an acquisition of an NVMe SSD be a useful addition to the documentation process? In addition to reasons explained by Tetra Defense and Arman Gungor, I imagine it would to be helpful to document a drive’s health. Atola‘s products appears to have that functionality. Since Firmware update 2022.4, Atola supports NVMe diagnostics within the Imaging and View SMART features.

A topic I’d like to explore further are the commands storage devices are subject to. Currently, I’m using a free version of Bus Hound for Windows with limited, but interesting features. This is what was recorded on a Samsung NVMe SSD 970 Evo formatted with NTFS after I saved arbitrary text to a text document using notepad.exe.