by Chetan Gupta, NII Consulting
Well, last week was abuzz with activity when we had to recover data from a corrupt Linux hard disk. Thought it would be pretty easy but as soon as I loaded the hard disk, I knew something was amiss. I was in for a shock as the disk had severe damage in the beginning sectors. Still, encase was able to load the disk but could not show the file structure! Atleast it was showing the three partitions!
What do we do?
Well, the first step was to image the hard disk so that If I do mess up the hard disk, I can restore it to what was there originally. So, loaded FTK imager and used it to image it the hard disk into split raw files (since raw files are easier to use with Sleuthkit and other open source tools..)
I had in my mind that encase will allow me to load raw files and anlayze so I thought I was on safe grounds! Well, the raw files filled up most of my forensic disk since they amounted to about 120 Gb of space! Neways, the idea was to run disk repairing tools on the conked hard disk and side-by-side run data recovery tools on the image. Well, not all plans execute to perfection…. this one sure didn’t! As soon as I loaded the split raw image into Encase, it crashed! Sure, it has problems with large split files. Then, I said to myself, “No problem, There’s sleuth kit for me”. What was not expected was that sleuthkit did not recognise the file system on the three partitions.
A simple strings on the first split image showed up interesting results – most of the files were quite intact although their beginning and end hardly recognizable from the big junk of words…and I saw the last fsck log which clearly stated that both primary and secondary superblocks were corrupt! WoW!
Anyways I tried rebuilding the superblock and inode table but to no avail. However, after the repair operation, I could run fsstat on the third partition but again it showed up 99% of the inodes to be free! I tried using fsck and using one of the secondary superblocks but it did not help. I guess the secondary superblock structures had got corrupted too!
Then I said to myself,” May be data carving is the best option in this situaton”. I concatenated the split files, and created a huge raw file so as to feed my open source data carving monsters (read foremost and scalpel)! Foremost did carve out some data but largely false hits and scalpel never got going. It would stop midway during the all-important second pass! Next step was to use all available file carving tools (from winhex to encase to FTK) and collating valid files obtained from them. It was tedious but nevertheless, I could recover a lot of files (read gif, bmp, jpeg html, and mail files).
Data carving could be quite frustrating if the filesystem is hugely fragmented. I would discuss data carving in some more detail in my forthcoming article.
Hope you enjoyed reading this one though!
