Smart Anti-Forensics

First published June 2005

by Steven McLeod
steven mcleod@ozemail com au
May 2005

EXECUTIVE SUMMARY

This paper highlights an oversight in the current industry best practice procedure for forensically duplicating a hard disk. A discussion is provided which demonstrates that although the forensic duplication process may not directly modify data on the evidence hard disk, a hard disk will usually modify itself during the forensic duplication process.

The paper highlights some consequences, for example that an attacker who has compromised the computer containing the hard disk can programmatically detect that the hard disk has been forensically duplicated, or otherwise powered on and accessed via a mechanism other than via the operating system installed on the hard disk.


Get The Latest DFIR News

Join the Forensic Focus newsletter for the best DFIR articles in your inbox every month.


Unsubscribe any time. We respect your privacy - read our privacy policy.

Suggestions are provided to help minimise the changes made to the hard disk during the forensic duplication process. These suggestions minimise the likelihood that an attacker will notice the system administrator or forensic analyst performing an investigation of the suspected compromised computer.

INTRODUCTION

Imagine the following scenario. You are the system administrator of a computer network, and you believe that a user’s computer has been compromised. The attacker may have complete control over the computer including the use of a back door communication mechanism. The back door allows the attacker to notice in realtime any behaviour on the computer indicating that the attacker’s presence is known to the system administrator.

You want to monitor the attacker to determine what actions they are performing and thereby gain an insight into the scope of the compromise and the initial vulnerability exploited by the attacker, but you need to investigate the apparent security incident without tipping off the attacker. Therefore you refrain from manually running programs such as root kit identification software, process listing utilities, netstat and other volatile information gathering programs. You resist the temptation to immediately turn the computer off since the attacker would notice this obvious action, and consider it suspicious that the computer was powered off before the close of business. You decide to wait until the end of the working day before taking a forensic copy of the computer’s hard disk to subsequently analyse the duplicate for evidence of a compromise.

You power off the computer, remove the hard disk and make a forensically sound duplicate using software such as dd or a purpose built hardware forensic duplicator, using MD5 or a similar hashing function to ensure that you don’t modify any data on the hard disk. You replace the original hard disk back in the user’s computer, and allow the user to continue using their computer the following day. In the meantime you begin performing forensic analysis of the duplicate copy of the hard disk. You also install a separate computer to capture network traffic sent to and received from the suspected compromised computer.

You have followed the current industry best practice procedure for forensically duplicating a hard disk, so there is no way that the attacker can detect that you have taken a copy of the hard disk and you are thereby aware of the attacker’s presence – right? WRONG!

THE PROBLEM

Self-Monitoring, Analysis and Reporting Technology (SMART) was pioneered by IBM in 1992 with their Predictive Failure Analysis mechanism, and was subsequently enhanced by Compaq’s IntelliSafe technology [1]. SMART has been implemented in the majority of ATA (IDE) and SCSI hard disks since 1995, and allows the hard disk to perform self-tests as well as track and store performance and statistical information which can help predict impending failure of the hard disk. This information includes the total amount of time the hard disk has been powered on for (referred to as Power_On_Hours, or Power_On_Minutes for some brands of hard disk), the number of times the hard disk has been powered on (referred to as Power_Cycle_Count), other attributes chosen by each hard disk vendor such as the hard disk’s current temperature, and a log of low level hard disk errors [2] [3]. SCSI hard disks typically do not provide the same detailed level of SMART information to the user as ATA/IDE hard disks [1], so this paper will focus on IDE hard disks.

Freely available utilities [4] complete with source code can be downloaded from the Internet which allow software to read the hard disk’s SMART information. Source code to access SMART information can be incorporated into an attacker’s back door program which executes when the operating system boots. This allows the attacker to keep track of the number of times the hard disk has been powered on via the Power_Cycle_Count SMART attribute value. Also, the attacker can keep track of the total amount of time the hard disk has been powered on for via the Power_On_Hours SMART attribute value, and compare this value with the total amount of time which the attacker’s back door program has been running. The current industry best practice procedure for forensically duplicating a hard disk typically results in the modification of the Power_Cycle_Count and/or the Power_On_Hours SMART attribute values. The attacker can therefore detect if the hard disk has been powered on or accessed for a length of time by a software or hardware mechanism other than the compromised operating system running on the compromised computer.

The rest of this paper will focus on whether SMART attribute values can be prevented from being modified, since although there are some undocumented SMART functions [5] [6], the specifications do not provide a mechanism to set attribute values to an arbitrary number.

The specifications also state that the data structure containing returned SMART attribute values consists of read only attribute fields which cannot be modified [7]. It is unfortunate that SMART attribute values cannot easily be modified to arbitrary numbers, otherwise they could be reset to their original values once the forensic duplication process has been completed.

TESTING

A variety of testing was performed by the author of this paper to understand the circumstances which would cause a modification to the Power_Cycle_Count and the Power_On_Hours SMART attribute values. A Knoppix [8] boot CD was used to boot the author’s computer to perform these tests. The ultimate goal was to devise a forensic duplication process which would minimise the modification of these SMART attribute values. Detailed test results and the testing procedures are omitted from this paper for the sake of brevity.

The following hard disks were tested:

· Quantum Fireball ST 3.2GB, model number QUANTUM FIREBALL ST3.2A, ATA Version 3, ATA Standard Unknown, Firmware Version A0F.0800
· Quantum Fireball Plus KX 20.5GB, model number QUANTUM FIREBALLP KX20.5, ATA Version 4, ATA Standard ATA/ATAPI-4 T13 1153D revision 15, Firmware Version A1S.3700
· Seagate Barracuda ATA III 40GB, model number ST340824A, ATA Version 4, ATA Standard Unknown, Firmware Version 3.05
· Western Digital Caviar 45GB, model number WDC WD450AA-00BAA0, ATA Version 4, ATA Standard Unknown, Firmware Version 10.09K11
· IBM Deskstar 41GB, model number IC35L040AVER07-0, ATA Version 5, ATA Standard ATA/ATAPI-5 T13 1321D revision 1, Firmware Version ER4OA44A
· Seagate Barracuda 120GB, model number ST3120026A, ATA Version 6, ATA Standard ATA/ATAPI-6 T13 1410D revision 2, Firmware Version 8.54
· Western Digital Caviar SE 160GB, model number WDC WD1600JB-00GVA0, ATA Version 6, ATA Standard Unknown, Firmware Version 08.02D08

The following hard disks were briefly tested, but were quickly rejected and excluded from the tests since they did not support SMART, which first appeared in the ATA Version 3 specifications:

· Conner Peripherals 425MB, model number CFS425A, ATA Version 1, ATA Standard Unknown, Firmware Version 0.23.
· Seagate Medalist 2113MB, model number ST32140A, ATA Version 1, ATA Standard Unknown, Firmware Version 08.08.01.

Test Case 1 – Disabling SMART

According to both the SMART specifications and the ATA specifications for ATA versions 3 to 7, SMART functionality can be disabled by issuing the SMART DISABLE OPERATIONS command. This would thereby provide a simple solution to the problem and allow the hard disk to be duplicated without altering any of the SMART attribute values. The specifications state that “Sub-command DISABLE SMART OPERATIONS instructs the device to cease all monitoring and predicting of its health status” [9]. The specifications also state that:

“This command disables all SMART capabilities within the device including any and all timer functions. After receipt of this command the device will disable all SMART operations. Attribute values shall no longer be monitored or saved by the device. The state of SMART (either enabled or disabled) shall be preserved by the device across power cycles.” “If the SMART feature set is implemented, this command shall be implemented” [7] [10].

The specifications describe the ENABLE SMART OPERATIONS command as enabling “access to all SMART capabilities within the device. Prior to receipt of this command attribute values are neither monitored nor saved by the device. The state of SMART (either enabled or disabled) will be preserved by the device across power cycles” [7] [10].

To determine if disabling SMART prevented SMART attribute values from being modified, SMART attribute values were displayed and recorded using the smartmontools package [4] with the command “smartctl -s on /dev/hda;smartctl -a /dev/hda”. SMART was then disabled with the command “smartctl -o off -S off /dev/hda; smartctl -s off /dev/hda”. The computer was then powered off and powered on. Several hours later, SMART attribute values were displayed and compared to their previous values. The results were undesirable for all of the hard disks.

Disabling SMART on all hard disks initially appeared to properly disable SMART. As per the specifications, the disabled status of SMART was preserved when the computer was powered off and powered on, and no other SMART commands could be issued to the hard disk until SMART was reenabled. However, further investigation revealed that all of the hard disks violated the specifications, specifically the sentence “Attribute values shall no longer be monitored or saved by the device”. Although SMART was disabled, all of the hard disks modified the Power_Cycle_Count SMART attribute value, and almost all of the hard disks modified the Power_On_Hours SMART attribute value. The modified Power_Cycle_Count and Power_On_Hours SMART attribute values were subsequently saved to the hard disks.

The IBM Deskstar hard disk was retested using the Hitachi/IBM Feature Tool version 1.97 [11] to ensure that smartmontools was issuing the correct command to disable SMART. The documentation provided with Feature Tool states that “on some system if SMART monitoring is enabled in the system BIOS then disabling SMART with this utility will be effective only until the next re-boot”. SMART was disabled with the command “smartctl -s off /dev/hda”, then the computer was powered off, then the computer was powered on and the Feature Tool was executed. This revealed that SMART was disabled, indicating the smartmontools issued the correct command to disable SMART, and also verifying that neither the author’s computer nor hard disk automatically modified the enabled/disabled status of SMART during the boot or reboot process.

This test revealed that none of the tested hard disks implemented the SMART specifications correctly – disabling SMART did not actually prevent all of the SMART attribute values from being modified and then saved (e.g. to a reserved area of the hard disk platter).

Test Case 2 – Rebooting the Computer

Rebooting the computer by pressing CTRL-ALT-DEL or the hardware reset button did not modify the Power_Cycle_Count value on any of the hard disks. This desirable test result means that the Power_Cycle_Count value can be maintained during the forensic duplication process by using the suspected compromised computer to perform the duplication from within a trusted environment. For example, while the suspected compromised computer is still powered on, reboot it into the Knoppix environment.

Test Case 3 – Denying a Clocking Mechanism

Hard disks require a clocking mechanism to know that an hour has elapsed and therefore the Power_On_Hours value should be incremented. This clocking mechanism may be derived from the computer’s software or hardware clock, or a signal sent from the computer to the hard disk via the IDE cable, or via a clock inbuilt to the hard disk. Several tests were performed to deny the hard disk these clocking mechanisms in an attempt to prevent modification of the Power_On_Hours value.

The script stop_clock.sh was executed to continually reset the computer’s software and hardware clock, where stop_clock.sh consisted of the code:

“while [ 1 ]; do date 05051100; hwclock –systohc –localtime –noadjfile; sleep 1; done”.

This technique failed and did not prevent the Power_On_Hours value from increasing, indicating that the clocking mechanism was derived from a signal sent over the IDE cable or via a clock inbuilt to the hard disk.

The hard disk IDE cable was then disconnected, which prevented the modification of the Power_On_Hours value for a small proportion of the hard disks. No general conclusions could be drawn as to the likely behaviour of an untested hard disk, since there was no obvious consistency in the behaviour of the tested hard disks even when the hard disks were the same ATA version or were manufactured by the same vendor. Also, forensically duplicating a hard disk is extremely difficult unless an IDE cable is connected. Perhaps a modified IDE cable could be used which suppresses the clocking signal. Alternatively, perhaps a minimal version of a computer without the associated clocking mechanism could be used, for example a purpose built hardware forensic duplicator. This is discussed further in Test Case 5.

This test revealed that most of the hard disks appeared to have an inbuilt clocking mechanism. Preventing the modification of the Power_On_Hours value may not be possible for such hard disks.

Test Case 4 – Storing Fractions of an Hour

If the hard disk did not store fractions of an hour as part of the Power_On_Hours value, as soon as a hard disk is powered on, 59 minutes worth of hard disk duplication could be performed without increasing the Power_On_Hours value. At a typical imaging rate of 2.7GB/minute this would allow a 150GB hard disk to be duplicated in less than an hour.

However, testing revealed that the tested hard disks did store fractions of an hour. The attacker can keep track of the total amount of time the hard disk has been powered on for via the Power_On_Hours SMART attribute value, and compare this value with the total amount of time which the attacker’s back door program has been running. The attacker’s back door program can therefore accurately estimate when the Power_On_Hours value should be incremented, and can therefore detect even 1 minute’s worth of hard disk duplication.

Test Case 5 – Using a Purpose Built Hardware Forensic Duplicator

If the vendors of purpose built hardware forensic duplicators have done their homework, they should have addressed the problem of SMART attribute values being modified during the forensic duplication process. The Logicube SF-5000u is advertised as a “unidirectional, forensically sound, cloning tool is known for its duplication accuracy and legal reliability” [12].

Performing a forensic duplication using a Logicube SF-5000u resulted in an increase of the Power_Cycle_Count value. This undesirable result was not surprising since previous testing revealed that this value would be incremented even when SMART was disabled and the IDE cable was disconnected.

The Logicube did not appear to disable SMART as part of the duplication process, though this is not a significant issue since previous testing revealed that disabling SMART had no benefit for the majority of hard disks tested.

The Logicube denied the hard disk from having a clocking mechanism, which prevented the modification of the Power_On_Hours value for a small proportion of the hard disks which did not have an inbuilt clocking mechanism. It was not evident whether the clocking was denied because the Logicube is not a real computer and doesn’t generate the clocking signal, or because the Logicube used modified proprietary IDE cables instead of standard IDE cables.

It may be theoretically possible to use a Logicube to prevent both the Power_On_Hours and Power_Cycle_Count values from being modified for this small proportion of hard disks by hot swapping the IDE cable of the hard disk with the Logicube’s IDE cable while the hard disk is still powered on by the suspected compromised computer. This possibility was not tested since it may have caused damage to the hard disk, the computer’s motherboard or the Logicube.

Test Case 6 – Using a Purpose Built Hardware Write Blocker

If the vendors of purpose built hardware write blockers have done their homework, their device may be able to prevent some SMART attributes from being modified.

Connecting a hard disk to a USB-IDE write blocking bridge had similar results to the Logicube. Not surprisingly, the Power_Cycle_Count value increased. The hard disk was denied a clocking mechanism which prevented the modification of the Power_On_Hours value for a small proportion of the hard disks which did not have an inbuilt clocking mechanism. It was not evident whether the clocking was denied because of the write blocking functionality, or whether the clocking signal simply could not be propagated over a USB connection. It was not worthwhile clarifying this by repeating the test with a simple non-write-blocked USB caddy, considering the significant proportion of hard disks with an inbuilt clocking mechanism.

Test Case 7 – Identifying Where SMART Attribute Values are Stored

If SMART attribute values were stored on a hard disk’s printed circuit board in non-volatile memory, temporarily swapping the circuit board with that from an identical model hard disk for the duration of the forensic duplication process may mitigate the problem of changing SMART attribute values. This technique may especially be required to mitigate modification of SMART attribute values if the hard disk to forensically duplicate is already turned off and must remain powered off once the forensic duplication is completed.

However, the reference material states that “Attribute values are stored in the drive reserved data area with other drive operational parameters” [13]. Other reference material states that Seagate’s enhancements to SMART known as Enhanced Drive Self-Test technology stores diagnostic information “in an ATA error log, located on sectors of the drive that are inaccessible to the end-user” [14]. Finally, other reference material indicates that hard disk manufacturers are more likely to store SMART attribute values in reserved space on the hard disk platters, as opposed to using non-volatile RAM attached to the printed circuit board [15].

This theory was tested using two identical Seagate Barracuda 120GB ATA Version 6 hard disks, model number ST3120026A. The test confirmed the reference material and revealed that SMART attribute values were stored on the hard disk platters and not on the printed circuit board. Unfortunately, it appears very unlikely that the reserved disk areas containing SMART attribute values can be modified by the user. The ATA specifications for the SEEK, READ SECTOR and WRITE SECTOR low level commands state that the IDNF error register “shall be set to one if an address outside of the range of user-accessible addresses is requested” [16].

Test Case 8 – Disable SMART Related CMOS Options

The reference material notes that “In some personal computers, SMART is checked on computer bootup by the CMOS/BIOS firmware” [13]. The specifications state that “BIOS and driver developers should ensure that SMART and attribute autosaving are enabled immediately after device initialization” [9]. Other reference material states that “S.M.A.R.T. monitoring can only be disabled from the system BIOS (Basic Input/Output System). If S.M.A.R.T. is disabled from the system BIOS it will not poll the hard drive for S.M.A.R.T. attributes during system startup” [17].

The Athlon 2600 test computer belonging to the author of this paper did not have any SMART related CMOS settings. A friend’s computer was used for this test, which had the CMOS setting “HDD SMART Capability”. When this value was set to “enabled”, SMART was enabled on the hard disk as part of the bootup process. When this value was set to “disabled”, SMART was disabled on the hard disk as part of the bootup process. Disabling SMART via this mechanism appeared to be functionally equivalent to running the command “smartctl -s off /dev/hda”. Powering on the computer with this CMOS option set to “disabled” and leaving the computer on for several hours revealed that the Power_On_Hours value and the Power_Cycle_Count value still increased.

Proposed Test Case

Vendor firmware could be reverse engineered, modified, and transferred to the hard disk to gain complete control over SMART attribute values. According to the specifications the DOWNLOAD MICROCODE command can be issued to the hard disk with a parameter so that the new microcode is for immediate but temporary use, instead of being saved for immediate and future use [16].

Firmware is available for download for some vendor hard disks such as IBM [18]. Unfortunately however, firmware is generally only provided when it is required to fix a specific problem, and some vendors do not make firmware available for download from the Internet. Seagate note that “There is no firmware available for our standard distribution ATA/SATA drive models” [19].

Even if the relevant firmware was obtained and disassembled, the microcode may not disassemble to meaningful instructions since it is executed by the hard disk’s microprocessor and not by the CPU. Finally, making custom modifications to the firmware would destroy the forensic integrity of the hard disk.

CONCLUSION AND SUGGESTED FORENSIC DUPLICATION PROCESS

None of the hard disks tested conformed to the specifications, making it extremely difficult to forensically duplicate a hard disk without the hard disk being modified. Disabling SMART, unplugging the IDE cable, and powering up a hard disk for several hours resulted in the modification of SMART attribute values such as Power_Cycle_Count and/or Power_On_Hours for all of the hard disks tested. It was therefore not surprising that a purpose built hardware forensic duplicator or purpose built hardware write blocker could not guarantee to prevent the modification of these values.

There is no universal solution to prevent SMART attribute values from being modified, although a limited number of specific hard disk models may have a partial solution, for example by denying the hard disk a clocking mechanism to prevent modification of the Power_On_Hours value.

The following suggested universal forensic duplication process is designed to duplicate a powered on hard disk while minimising the modification of SMART attribute values.

1. Determine the Amount of Data to Copy

While the suspected compromised computer is still powered on, determine the size of the hard disk partition and also the total amount of data on the hard disk. If the partition size is greater than 10GB but there are only a few GB of data and you are not concerned about copying unused/deleted space or the forensic integrity of the hard disk, consider running a defragmentation utility to move the data to the beginning of the partition.

2. Reboot into Knoppix

To prevent modification of the Power_Cycle_Count value, the hard disk should not be turned off as part of the forensic duplication process. An unexpected increase in the Power_Cycle_Count value would be very suspicious to a reasonably paranoid attacker. A less skilled attacker might possibly believe that the extra hard disk power on was due to the operating system failing to boot properly, and the user powered off their computer and then powered it on instead of pressing CTRL-ALT-DEL or the reset button.

Therefore, a purpose built hardware forensic duplicator cannot be used, but rather the suspected compromised computer itself must be used to perform the forensic duplication. The suspected compromised computer can be rebooted into a known good forensic duplication environment such as Knoppix. Knoppix should be booted with the “noswap 2” parameters so that Knoppix loads as fast as possible and does not access any linux swap partitions. Running “fdisk -l” will identify the hard disk partition to copy, and the following instructions assume that the hard disk partition of interest is /dev/hda1.

3. Determine the ATA Version

Run “smartctl -a /dev/hda” to identify the ATA version of the hard disk. If this command succeeds, then SMART is enabled on the hard disk. If this command fails, the error message will allow you to determine whether SMART is disabled or if SMART is not supported. If the ATA version is 1 or 2, then any forensic duplication process can be used without concern of modifying SMART attribute values since SMART was not supported until ATA version 3.

4. Disable SMART

If SMART is enabled, disable it with the command “smartctl -s off /dev/hda”. This step is only somewhat useful since none of the hard disks tested conformed to the SMART specifications and did not cease updating all of the SMART attribute values while SMART was disabled.

5. Connect a Destination Hard Disk to the Suspected Compromised Computer The forensic duplicate could be placed onto a blank hard disk connected via USB or firewire, or sent via a crossover network cable to another computer via piping the output of dd to md5sum and nc (via tee). It is not advisable to physically connect a new blank hard disk via the IDE cable to the suspected compromised computer since the blank hard disk would have to be present for an entire working day, and the attacker may notice the presence of an extra hard disk. The best tradeoff between speed and stealth may be to insert a firewire 800 card into the computer and copy data to an external disk via firewire 800.

6. Keep the Hard Disk Cool

A fan should be used to help keep the hard disk cool during the duplication process. The duplication process places an incredible strain on the hard disk, causing it to reach a very high temperature. This high temperature is recorded permanently by some hard disks [20] including the author’s IBM Deskstar hard disk which stores the minimum and maximum temperature ever reached in addition to the current temperature.

The author duplicated a hard disk which increased the temperature from 29 degrees Celsius to 64 degrees Celsius. The value 64 was permanently recorded as the hard disk’s lifetime maximum temperature, which is a sure sign that the hard disk has been forensically duplicated. The hard disk manufacturer states that “The operating temperature range for most Seagate hard drives is 5 to 50 degrees Celsius. With our newer model drives the maximum temperature is now at 60 degrees Celsius” [21].

Finally, the duplication should not be made in the morning just prior to the start of business since the attacker could notice that the hard disk’s temperature is higher than expected for a hard disk which has supposedly just been powered on.

7. Be Gentle with the Hard Disk

The hard disk should not be subjected to physical mishandling during the duplication process, in case an error occurs and is logged, which would subsequently be visible to the attacker. The specifications state that “If error logging it supported, it shall not be disabled when SMART is disabled. Error log information shall be gathered at all times the device is powered on” [16].

8. Image as Much as Possible in the Shortest Timeframe

The duplication process should be completed as quickly as possible to minimise the effect on the Power_On_Hours SMART attribute value. The UNIX dd command with a block size of 64k can read data from modern hard disks at a typical rate of 2.7GB per minute. A typical corporate workstation would contain less than 3.5GB of files on the local hard disk. If the partition size is less than 10GB then the entire partition can be duplicated using dd without significantly affecting the Power_On_Hours SMART attribute value. However, if the partition is larger than 10GB and if for example there are 4GB of (defragmented) data on the disk, there is a tradeoff between forensic integrity and risking the attacker becoming aware of the investigation – it may be advisable to just duplicate the first 10GB of the partition, or to copy the files at the file system level.

Don’t waste time, and do not allow the forensic duplication mechanism to put the hard disk into sleep mode after a period of disk inactivity, otherwise the Start_Stop_Count SMART attribute value may be modified.

9. Restore SMART Status

If SMART was disabled in step 4, reenable it with the command “smartctl -s on /dev/hda”.

10. Power Off the Computer

Run “poweroff” and hope that the approximately four minutes consumed by this suggested forensic duplication process is not noticed by the attacker.

11. Begin Analysis of the Copied Data

Analyse the copied data, deploy a network sniffer etc.

REFERENCES

[1] Get SMART for Reliability, Seagate Product Marketing Technology Paper, July 1999, http://www.seagate.com/docs/pdf/whitepaper/enhanced_smart.pdf
[2] SMART Attributes, Bruce Allen, http://smartlinux.sourceforge.net/smart/attributes.php
[3] Example Output from smartmontools smartctl Utility, Bruce Allen, 20 April 2005, http://smartmontools.sourceforge.net/#sampleoutput
[4] smartmontools Home Page, Bruce Allen, 20 April 2005, http://smartmontools.sourceforge.net/
[5] S.M.A.R.T. Monitoring Tools: Mailing Lists, Bruce Allen, 19 May 2004, http://sourceforge.net/mailarchive/forum.php?thread_id=4207352&forum_id=12495
[6] S.M.A.R.T. Monitoring Tools: Mailing Lists, Bruce Allen, 4 June 2004, http://sourceforge.net/mailarchive/forum.php?thread_id=4825518&forum_id=12495
[7] SFF Committee Specification for Self-Monitoring, Analysis and Reporting Technology (SMART) SFF-8035i Revision 2.0, 1 April 1996, ftp://ftp3.ds.pg.gda.pl/people/macro/S.M.A.R.T./8035R2_0.PDF
[8] Knoppix, Klaus Knopper, http://www.knopper.net/knoppix-info/index-en.html
[9] Small Form Factor Committee Specification Draft for SMART Applications Guide for the ATA and SCSI Interfaces SFF-8055i Revision 1.4, 5 June 1996, ftp://ftp3.ds.pg.gda.pl/people/macro/S.M.A.R.T./8055.PDF
[10] Information Technology – AT Attachment-3 Interface (ATA-3) Revision 7b, X3T13 Technical Committee, 27 January 1997, http://www.t13.org/project/d2008r7b-ATA-3.pdf
[11] Hitachi Global Storage Technologies Downloads and Utilities, http://www.hitachigst.com/hdd/support/download.htm
[12] Logicube Forensic SF-5000, http://www.logicube.com/products/hd_duplication/sf5000.asp [13] Improved Disk Drive Failure Warnings, IEEE Transactions On Reliability, G Hughes et al, September 2002, http://cmrr.ucsd.edu/smart/tech_papr/SmtPapTransReliFinalWeb.pdf
[14] Enhanced Drive Self-Test – Winning the War Against Unnecessary Drive Returns, June 2000, http://www.seagate.com/docs/pdf/whitepaper/Enhanced_DST_Tech_Paper.pdf
[15] S.M.A.R.T. Monitoring Tools: Mailing Lists, John Gilmore, 21 November 2004, http://sourceforge.net/mailarchive/forum.php?thread_id=6005846&forum_id=12495
[16] Information Technology – AT Attachment with Packet Interface – 5 (ATA/ATAPI-5) Revision 3, T13 Technical Committee, 29 February 2000, http://www.t13.org/project/d1321r3-ATA-ATAPI-5.pdf
[17] S.M.A.R.T. Frequently Asked Questions, http://smartlinux.sourceforge.net/smart/faq.php
[18] IBM DeskStar hard disk drive firmware update, http://www-1.ibm.com/support/docview.wss?uid=psg1MIGR-42215
[19] How do I find out what firmware version I have on my drive?, http://www.seagate.com/support/kb/disc/faq/firmware_rev.html
[20] IBM Hard Disk Example smartctl Output, 15 June 2004, http://smartmontools.sourceforge.net/examples/IC35L120AVV207-1.txt
[21] What is the normal operating temperature for Seagate disc drives?, http://www.seagate.com/support/kb/disc/faq/temperature.html

Leave a Comment

Latest Videos

Digital Forensics News Round Up, March 27 2024 #dfir #digitalforensics

Forensic Focus 27th March 2024 6:06 pm

Digital Forensics News Round-Up, March 21 2024 #digitalforensics #dfir

Forensic Focus 21st March 2024 6:15 pm

This error message is only visible to WordPress admins

Important: No API Key Entered.

Many features are not available without adding an API Key. Please go to the YouTube Feeds settings page to add an API key after following these instructions.

Latest Articles