Lessons from Data Recovery – Part 1 (Repost)


I originally posted this entry over on the Disklabs computer forensic forum (http://www.computer-forensics.co.uk/computer-forensics-forums/forum.php) but also thought a lot of people would benefit from it being repeated here too.

I’ve been working at Disklabs for a few weeks now. I’ve mostly been confined to the digital forensics lab but I’ve been able to poke my head out from time to time and see what the data recovery department are up to. I’m happy for this opportunity as it has taught me some interesting things that are useful for computer forensics, and some things that are potentially dangerous.

Over the next few weeks I’ll be posting articles about how data recovery has the potential to impact computer forensics in ways that few have thought possible.

A scenario occurred recently in which an employee left a company on less than gracious terms. The next day the employee’s former colleagues showed up for work and realised that the file server was inoperable. Upon closer inspection they found that all of the server’s drives were blank. Forensic analysis was conducted and nothing was found. If the drive had been wiped it had been done so with undetectable software. The forensic investigator, and the tools at his disposal, had failed to provide an adequate answer.

What would you do in a situation like this? I imagine that my report would be very sparse and contain very little information at all. You could look at wiping software artefacts, such as the sequence of bytes used, in order to determine if this individual had maliciously wiped the data from the drive but, failing this, what other avenues of investigation could be followed?

One of the first things I learned after starting at Disklabs was that each hard drive contains certain information that is not stored on the platters, but on the system area of the drive. The two items that I found to be of most interest are the number of times the drive has been powered on and the number of hours that the drive has been active. This may not seem like a huge finding but the implications are awesome.

Going back to our scenario the hard disk drives were turned over to a data recovery expert who was able to unequivocally state that the drive had only been powered on a handful of times and only had only been in operation for a few hours. What does this means in terms of this investigation? We can draw one of two conclusions either the drives had been replaced as a result of drive failure or they were replaced as a deliberate act intended to deceive. As it turns out the IT department of this company stated that the original drives should still be in operation inside the file server and that the information provided by the data recovery expert contradicted their own opinions.

The original drives were recovered from the former employee’s home a few days later.

My short time at Disklabs has proven to me that we need to educate ourselves on these matters. How can we offer opinion or facts in our reports if we haven’t covered every possibility?


5 responses to “Lessons from Data Recovery – Part 1 (Repost)”

  1. Very interesting. Thanks for sharing. So what tools are used to query the drives for this information? Are there ATA or SCSI commands that are used?

  2. Most of these tools are freeware as well (Windows and Linux)… Very useful info, but be conscious that SMART is a BIOS activated setting that can sometimes be deactivated which can decrease the accuracy of this monitoring tool.

Leave a Reply to ivan Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.