Many years ago someone told me that there was no way to detect the surreptitious imaging of a hard drive. This idea is reinforced in forensics classes that remind you to use a write-blocker during imaging to guarantee that nothing is changed on the drive. I believed that for a while, but then really focused on a what possible changes would happen to drives that are being imaged. I finally discovered what I was looking for: SMART.
From Wikipedia (https://en.wikipedia.org/wiki/S.M.A.R.T.):
$ sudo smartctl -a /dev/sda
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.19.0-30-generic] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Device Model: LITEONIT LMT-512L9M-11 MSATA 512GB
Serial Number: TW0099H45508553A1029
Firmware Version: HM9110E
User Capacity: 512'110'190'592 bytes [512 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
[...]
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0003 100 100 000 Pre-fail Always - 0
9 Power_On_Hours 0x0002 100 100 000 Old_age Always - 587
12 Power_Cycle_Count 0x0003 100 100 000 Pre-fail Always - 9145
This post really should have been written long ago, but it was only this week that I met someone discussing the same problem during a forensics class. This inspired me to finally write this idea down. Thanks Erik!
From Wikipedia (https://en.wikipedia.org/wiki/S.M.A.R.T.):
S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology; often written as SMART) is a monitoring system included in computer hard disk drives (HDDs) and solid-state drives (SSDs) that detects and reports on various indicators of drive reliability, with the intent of enabling the anticipation of hardware failures.What is really great about SMART is that it exists inside the drive hardware - not in the computer. While each drive manufacturer will record different data, there are some that are fairly common that can be used to track the hard drive's use:
- 0x0C Power Cycle Count
- 0x09 Power-On Hours (POH)
Consider if at every single boot if you could log these kind of events. If you can protect the data (either by cryptography or otherwise), one could detect if a drive has ever been imaged. Regardless of the disk being removed and used on a drive duplicator, or if alternate media is used to boot the computer and image the drive, the drive has to be powered on - causing an increment of the Power Cycle Count value. What I think is even more interesting, is that the number of power-on hours is recorded. The combination of the legitimate boot events with timestamps, combined with the number of power cycles and hours powered on between these events, one could make an educated guess about when a disk may have been tampered with and if it was imaged or just perhaps modified or quickly inspected.
In case you're interested in seeing these values, there are tons of tools for the job, including smartctl. For those in a hurry, I can verify that the WiebeTech Forensic Ultra Dock can read out the power-cycles without the need for a PC. Of course, it will increment the power cycle too. :-)
$ sudo smartctl -a /dev/sda
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.19.0-30-generic] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Device Model: LITEONIT LMT-512L9M-11 MSATA 512GB
Serial Number: TW0099H45508553A1029
Firmware Version: HM9110E
User Capacity: 512'110'190'592 bytes [512 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
[...]
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0003 100 100 000 Pre-fail Always - 0
9 Power_On_Hours 0x0002 100 100 000 Old_age Always - 587
12 Power_Cycle_Count 0x0003 100 100 000 Pre-fail Always - 9145
This post really should have been written long ago, but it was only this week that I met someone discussing the same problem during a forensics class. This inspired me to finally write this idea down. Thanks Erik!
No comments:
Post a Comment