[sleuthkit-users] filesystem recovery using sleuthkit
Brought to you by:
carrier
From: Jim C. <jc...@di...> - 2005-01-09 17:50:44
|
Im trying to recover contents of a 60GB Windows XP installation after a grub accident. A short 'how I got here' follows, then the Questions. I recently screwed up (technical jargon) my dads winXP box while trying to put grub on a usb-drive. (grub went onto /dev/hda, but linux was on /dev/sda, so it wouldnt boot anything) I recovered using the recovery disk, tried the repair option: fixmbr - to restore the MBR, and fixboot (I think) These tools apparently trashed the root of C:\, they showed me a mostly empty root-dir, with 4 (empty) files with names that were evidently unreadable by the OS (they were represnted by ?, all 4 of them) with a knoppix disk and a 3 line perl prog, I took 1GB at a time off it, and NFS'd it to my laptop, then onto the USB drive (knoppix dd wouldnt handle > 2GB files) (knoppix 3.6 wouldnt mount the usb directly - some versioning prob w the usb-* modules) I catted all the 1gb chunks together, and have started autopsy-2.03 and sleuthkit-1.73 on it. Evidence Locker: /mnt/u2/forensics Start Time: Sun Jan 9 09:32:31 2005 Remote Host: localhost Local Port: 9999 Open an HTML browser on the remote host and paste this URL in it: http://localhost:9999/autopsy Keep this process running and use <ctrl-c> to exit ..//bin/fsstat: $Data not found while loading the MFT ..//bin/fsstat: Invalid FAT32 image (numroot != 0) ..//bin/fsstat: Invalid FAT32 image (numroot != 0) ..//bin/fsstat: $Data not found while loading the MFT ..//bin/fsstat: Invalid FAT32 image (numroot != 0) ..//bin/fsstat: getFAT: return FAT16 cluster too large fsstat seems to be having trouble with this partition, and its unclear to me what kind of filesystem is *really* there. fdisk told me it was NTFS/HPFS mount told me it was vfat autopsy thinks its FAT16, would *not* accept choice of NTFS or FAT32 it appears that this is due to the root directory, which appears to have been overwritten by the MS tools. Ive inspected other parts of the 60 GB, they appear to have the original content. Qs: is it common on MS OSs that partition type and fs type are different ? is the choice of filesystem completely dictated by the root-directory ? is the choice overridable ? is there a reason its not automatic - since it seems to reject the 'wrong' choices ? is it possible to not care ? in my case, I hope to find that the vast majority of directories look to be uncorrupted - ie the directory entries are legal, and point to files that match whatever metadata is stored in the directory entry itself, and link to each other properly. IOW, if 59.9 GB of data look consistent with each other, then clearly the root folder is hosed, and is only thing to fix. wrt: Calculating MD5 of images/whole.img (this could take a while) +----+----+----+----+----+----+----+----+----+----+----+----+----+----+- it would be nice to have some estimate of ' a while', ie how big the ticks are, my other attempts to extract some of the original filesystem have also run afoul on this FAT16 choice: ..//bin/ils: getFAT: return FAT16 cluster too large ..//bin/dls: getFAT: return FAT16 cluster too large Im gonna continue poking, 1st thru autopsy, then the sleuthkit tools, but Im also contemplating trying to remove/zero out the root directory so that something else in the partition has a chance to influence the mount. Please advise me on this course of action b4 I do something (else) stupid tia jimc |