[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
|