Re: [sleuthkit-users] filesystem recovery using sleuthkit

[Jim C. <jc...@di...>]

Rich Thompson wrote:

>You may have already tried, but I'll say it anyway -
>Did you try booting with an XP boot disk and doing an
>fdisk mbr???  That should return the mbr for windows
>allowing you to boot....
>
>Rich
>
>  
>
the XP recovery disk that shipped with the Dell
did not include fdisk IIRC, so I used what it did have;
fixmbr & fixboot.

These 2 tools each fixed something; they changed the error
message, but at the end of the boot attempt, it found
an empty FAT12 fs where the partition table told it to look.

At any rate, I re-installed XP, and have a 60 GB image
to play around with, and see if I can slice off that FAT12 slice,
or find an NTFS superblock later on the disk and copy it
onto the FAT12 sector.

If you know of any free (as beer) NTFS repair tools,
Im all ears.

thanks
jimc

>--- Jim Cromie <jc...@di...> wrote:
>
>  
>
>>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
>>
>>
>>
>>
>>    
>>
>
>  
>