Am I missing something? (SMART attributes)

I think it is not that SMART exists, but he finally realized he can use the power-on-cycles and power-on hours in SMART to postulate the age of the drive.

You are just a hater because you did not write about this 10 years ago… mrgreen

I think it is not that SMART exists, but he finally realized he can use the power-on-cycles and power-on hours in SMART to postulate the age of the drive.

Provided that

• these data are reliable (which is seems like not)
• the initial value set by the manufacturer is known (some are set to non-zero values)

You are just a hater because you did not write about this 10 years ago… mrgreen

And being marked forever with the scarlet ? letters 😯 "CO" (Captain Obvious)?
No thanks.

What I did write (and not 10 years ago, only a couple ones) is this, however
http//www.msfn.org/board/topic/153191-does-copying-several-giga-bytes-on-a-daily-base-screw-the-hard-drive/?p=975216

I am surprised wink , how come that noone from GSN or other primary online magazine ever interviewed me about

Flip-a-coin©
A semi-deterministic approach to planning hard disk replacements in middle to large organizations

?

jaclaz

I see the point the article in GSN Magazine could be read as if the author is claiming to have discovered the wheel. But there are other points in the article that could be helpful to students if they were discussed.

The author (Branigan) states on page 2 of the article

On the other hand, Branigan issued a cautionary piece of advice to his fellow forensic experts. One of the cardinal rules of forensic examinations of computers is that nothing the examiner does should alter the data on the original computer in any way. However, simply by turning on the hard-drive will cause the SMART function to register another instance in which the drive has been turned “On,” and will start recording the number of hours that the drive has been used. Branigan does not think this minor truth will invalidate the results presented by most forensic investigators, but he advises his fellow investigators to report this truth carefully and accurately whenever they submit their forensic reports.

It remains to be seen how often these two important pieces of information – hidden on a hard-drive’s SMART function – will trip up the bad guys in the future.

http//www.gsnmagazine.com/article/30055/computer_forensics_expert_reveals_%E2%80%98hidden%E2%80%99_source_?page=0,1&c=cyber_security

The observation the author makes is that the SMART record will change, but it isn't a major problem by making disclosure of the fact.

However, the author (McLeod) of Smart Anti-Forensics states

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).

http//www.forensicfocus.com/Content/pid=53/page=4/

So the above confirms that SMART records alter even where SMART has been switched OFF. And this is echo'ed again (below) by the author in the conclusion, but with the possible resolution to the problem that some other task might offer a viable solution.

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.

http//www.forensicfocus.com/Content/pid=53/page=9/

A further author (Yaeger) wrote in Forensics and Hard Drive Data Imaging & Recovery The Perils and Pitfalls of Working with Defective Hard Drives

“A similar problem exists with Self-Monitoring Analysis and Reporting Technology (S.M.A.R.T.) attributes," he continued. "The drive firmware constantly recalculates S.M.A.R.T. attributes, and this process creates a large amount of overhead that increases imaging time and the possibility of further drive degradation. Imaging software should be able to disable S.M.A.R.T. attribute processing.”

http//www.datasaversllc.com/wp-content/uploads/Forensics-and-Hard-Drive-Recovery.pdf

A benefit for switching OFF SMART is the suggestion of an aggregated improvement with imaging that would be hampered if SMART was left switched ON. Yaeger though makes no mention about SMART updating when switched OFF?

McLeod and Branigan appear to hold similar views that SMART records change (albeit both arrive at their conclusions from different angles). This still leaves open the old logic conundrum often postulated regarding the 'ringing telephone'. If the phone rings and the called party does not answer, is that because the called party cannot or will not answer the phone? This logic conundrum might be useful in applying it to SMART in that SMART either may not be switched OFF entirely or can never be able to be switched OFF? It could be where McLeod suggests "denying the hard disk a clocking mechanism to prevent modification" this might be a useful process to follow, too, but that may have impact elsewhere as it may not address whether other tasks require a clock, and without a clock may fail.

Yaeger's reference to SMART record is made in company with "auto-reallocation". There may be no relevance between SMART record times updating or not and auto-reallocation, but the thought struck me that it might be useful to find out

In other words, a failing drive will constantly try to update the logs, and because it is failing, it might not be able to update them successfully. Thus, the drive gets caught in a vicious cycle that interferes with imaging and can lead to complete drive failure.

and

Note that commands to turn off defect auto-reallocation are vendor-specific and often unpublished.

I could not find a reference to "auto-reallocation" in the document 'Working Draft Project American National Standard T13/1699-D Revision 3f December 11, 2006 Information technology -AT Attachment 8 - ATA/ATAPI Command Set (ATA8-ACS)' [ http//t13.org/Documents/UploadedDocuments/docs2006/D1699r3f-ATA8-ACS.pdf ]

It maybe a requirement exists that "auto-reallocation" needs a clock and thus might use SMART records to display results even if SMART has been switched OFF (as noted by McLeod), which might be a reason it gets updated when SMART is OFF? By way of illustration would the clock be needed for assisting the reporting of Bad Sectors? (e.g. http//smartmontools.sourceforge.net/man5/smartd.conf.5.html )

I accept my observations maybe speculative. I have not run any tests or tasks to see if my last observation would be relevant. I am merely discussing the subject.

The fact there appears to be quite a variety of views out there as to the forensic benefits of SMART suggests to me, at any rate, that an overall resolution may still be some way off.

Allow me to add some "philosophical" thoughts.

We are (or at least so it seems) in a strange condition, where we have this closed box that hums and clicks when we power it, but we have no real idea on what is inside it.

We cannot actually "open" it.

All our peeks inside the box go through an additional "layer", the disk interface.

Until the disks were "dummy", there was a rather close resemblance between the actual contents of the box and the representation of them that we could receive from the interface, good ol' SCSI disks were little more than an electromechanical device.

With the advent of IDE, and thus "intelligent" disk, this intermediate layer has become thicker, further "insulating" the actual contents from the representation we can have of them.

We have a few recent proofs on how big is this distance, a very noticeable one being this nice experiment
http//www.forensicfocus.com/Forums/viewtopic/t=10910/
and the implied consequences of it.

Though not strictly related, the findings about some SSD's being not compliant with the ATA SafeErase command in the nice research
http//www.usenix.org/events/fast11/tech/full_papers/Wei.pdf
is another confirmation of this fact.

What was stated here
http//articles.forensicfocus.com/2012/10/23/why-ssd-drives-destroy-court-evidence-and-what-can-be-done-about-it/
applies to "rotating" hard disks, we have lots of Schroedinger's boxes and we don't really know if the cats inside them are alive or not (actually we don't even know if what is inside it is a cat or not).

The (relative) "advantage" with SSD's is that with a relatively simple device like the "Ming the Merciless" board the good guys at UCSD built
http//www.usenix.org/events/fast11/tech/full_papers/Wei.pdf
we can have a form of "direct access" to the actual storage media which is "standard" or at least documented.

But with an actual hard disk platter we completely miss this possibility, and we have not really a chance to understand if a given behaviour (right or wrong as it might be) is connected with a hard disk brand/make, to the specific hard disk "family", to the specific hard disk model, or even, on an exact same model/make, with the actual factory where (and/or period in which) it was manufactured, and even on the actual firmware release.

The same kind of (according to Seagate, whose reliability is IMHO not so high specifically) issue that led to the known 7200.11 brickings was connected to one or more lines of production in a given factory and in a given period of time that due to an incorrect software of the automated testing hardware left a "register" in the disk pointing to an entry in a "log" that due to another small defect in the drive firmware could "brick" the thingy by making the controller enter a loop.

For all we know, the firmware of a given make/model may change values in the SMART registers even if SMART is turned off, or do it only on wednesday nights (if the moon is full).

jaclaz

For all we know, the firmware of a given make/model may change values in the SMART registers even if SMART is turned off, or do it only on wednesday nights (if the moon is full).
jaclaz

But that doesn't exclude finding out determining the source(s) that causes changes to SMART registers whilst SMART is switched OFF and, from the forensics angle, surely it is better to have the answer, even if we do not like the answer, as opposed to just leaving it open and operating on the basis of the never, never.

But that doesn't exclude finding out determining the source(s) that causes changes to SMART registers whilst SMART is switched OFF and, from the forensics angle, surely it is better to have the answer, even if we do not like the answer, as opposed to just leaving it open and operating on the basis of the never, never.

Sure it doesn't ) , but as long as you speculate, I am allowed to speculate as well wink , the point I was trying to make was that very likely we won't have a "same behaviour" on *any* disk, and likely not even on disks by the same manufacturer, and possibly not even on disks by the same manufacturer and belonging to the same "family", and there is additionally the possibility that an exact same model may differ from another one of the same model because it has been built/assembled/tested in different factories or even if in the same factory on different lines. (at least this is what emerged by the cited Seagate mishap with the 7200.11).
The same kind of "corruption" that made the pointer get to a "wrong" log entry may affect one (or more than one or all) of the SMART settings, and since we are talking more specifically about the Attribute 0x9 POH, it has been already determined that the "initial value" can be different (thus making the calculations about "time in use" not really like "exact science"), and, example here
http//sourceforge.net/mailarchive/forum.php?forum_name=smartmontools-support&max_rows=25&style=nested&viewmonth=201004
where a WD seemingly counts POH in a much different way from Hitachi and Samsung, we cannot really be sure-sure of *anything* 😯 .

In a nutshell, this is not a reason to not be curious about these and other behaviours of hard disks (or storage devices), but we need to always remember Socrates
http//en.wikipedia.org/wiki/I_know_that_I_know_nothing

jaclaz

But that doesn't exclude finding out determining the source(s) that causes changes to SMART registers whilst SMART is switched OFF and, from the forensics angle, surely it is better to have the answer, even if we do not like the answer, as opposed to just leaving it open and operating on the basis of the never, never.

Sure it doesn't ) , but as long as you speculate, I am allowed to speculate as well wink

Sure, I have no problem with that.

the point I was trying to make was that very likely we won't have a "same behaviour" on *any* disk, and likely not even on disks by the same manufacturer, and possibly not even on disks by the same manufacturer and belonging to the same "family", and there is additionally the possibility that an exact same model may differ from another one of the same model because it has been built/assembled/tested in different factories or even if in the same factory on different lines. (at least this is what emerged by the cited Seagate mishap with the 7200.11).

I do see your point as this situation is common to mobile/smart phone examination that means each phone requires to be dealt with on a case-by-case basis and therefore reasonably should apply to how a disk is examined and understand its behaviour.