Destructed Data Forensics- Part 3

 

data-destruction1

While we failed to use a write blocker for the first trials, we have learned from our errors and corrected our process for Destructed Data Forensics. All of our recent tests have included the write blocker, both in the before and after images. Upon review of the images we retrieved from the 10 min drive, we were able to learn new information. There were bad sectors on the hard drive, which ranged from 89,788,800 – 488,281,279. A bad sector indicates that all or part of the data in that area of the hard drive is corrupt or gone, and when FTK cannot read a drive it will write zeroes to fill the space, even if only a part of the sector was bad. This rendered many user-created documents, images, and other files unrecoverable. The water does indeed seem to damage the drive in this case; when the before and after hash values are compared, we see definite changes. The MD5 checksum (under [Computer Hashes] about ¾ the way down Figure 1) and the Computed hash (under MD5 Hash at the top of Figure 2) do not match either. This was due to our failure to use the write blocker, and the data was largely irrecoverable. Because the process was flawed, all of the data and the conclusions we were able to obtain from those tests are null.

 

Figure : Hashes Before

 

 

 

Figure : Hashes After

 

 

 

We restarted the ten minute test, making sure to follow the process precisely. For our second ten minute test we used an 80GB Western-Digital hard drive named “Data Destruction 1.”We attached the write blocker for the before image and then followed the same process as our previous tests. We placed the hard drive in a bucket of water (constant volume and height of water for all hard drives – 5.6 liters and 5.75 inches, respectively) and let it sit for ten minutes before taking it out and attempting to image it immediately. Our first test was unsuccessful, but upon trying again we were successful in obtaining the image. This trial yielded much better results. The hash values all match this time (see figure 3 and figure 4), which demonstrates how important a write blocker is in a forensic investigation. Even though we followed the same process as before, the results are astronomically different. In the side-by-side comparison of files in the first trial, many files were totally gone, overwritten with zeroes. However with Data Destruction 1’s side by side comparison, the hex values and text all match exactly. See Figure 5, 6, 7, and 8 below for the before and after text and hex of the file savecats.odt. Upon review, all files matched and there was no data loss. All data that was on the original image is still present in the drive after being in water for ten minutes. We also compared the “Last Written” date and time on different files, along with the “File Created” date and time and the “Last Accessed” date and time from before and after submersion. They all match..

 

Figure : DD1 Before

 

 

 

Figure : DD1 After

 

 

Figure : DD1 savecats.odt Document Hex – Before

 

 

Figure : DD1 savecats.odt Document Hex – After

 

 

Figure : DD1 savecats.odt Document Text – Before

 

 

Figure : DD1 savecats.odt Document Text – After

 

 

We are currently doing the after imaging for “Data Destruction 2,” which is our 30 minute test. Additionally, we are in the process of “Data Destruction 5,” our one hour test. We went from DD2 to DD5 to keep everything consistent and stay with the same model drive, so that we had as few variables as possible. Currently, for the one hour water test, we have imaged the drive both before and after submersion and are in process of reviewing the images. Originally we could not get the after image, but after letting the drive dry for four days we were successful. At this point, all we can say is that the hashes do indeed match up again (see figures 9 and 10 below) and that we were able to successfully image it. We have yet to do side-by-side file comparison, however. When comparing DD5 before and after, the time needed to image the drive was less for the after image. This is possibly due to us imaging more than one hard drive at once during the before image, while the after image for DD5 was the only hard drive being imaged, decreasing the work load on the computer and increasing the data transfer rate (10.938 MB/s versus 8.505 MB/s).

 

Figure : DD5 Before

 

 

 

Figure : DD5 After

 

 

 

More Research Projects
CyberRange Team: Creating The Perfect Sandbox Environment
The Internet of Things Team: An Inside Look
CyberTech: Creating a Safer Internet Through Education