Re: [sleuthkit-users] filesystem recovery using sleuthkit

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

Brian Carrier wrote:

>
> On Jan 9, 2005, at 12:50 PM, Jim Cromie wrote:
>
>> Qs:
>

>> is the choice of filesystem completely dictated by the root-directory ?
>
>
> The other way around.  Each file system has its own way of storing 
> the  contents of a directory and FAT and NTFS are MUCH different.
>
poorly stated question.  In your tool, which will work on an image file, 
there is no
partition type.  So Im assuming that the code looks for magic bytes in 
1st few sectors
of the image.  Id expect that magic would be part of the root directory.

So rephrasing;  does your tool have any mechanizm to look for a backup 
superblock ?
(they exist in ext2 anyway)


>> is the choice overridable ?
>> is there a reason its not automatic - since it seems to reject the  
>> 'wrong' choices ?
>
>
> Autopsy does some sanity checks when you import the image so that you  
> can more quickly determine when you select the wrong one (I am  
> currently working on autodetect for the next version).   

Ill check for the sourceforge CVS

> FAT and NTFS  (and partition tables) are difficult because they all 
> use the same  signature value in the last two bytes of the first 
> sector.  FYI -  choosing just fat will autodetect which type of FAT.
>
>> 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.
>
>
> I have no clue what happened during the Windows recovery stuff.  TSK 
> /  Autopsy does not fix damaged file systems.  It only shows what is  
> there.  I think you need to look into some FAT/NTFS fixing tools.
>
:-(  my opensource options appear quite limited.
anybody know of anything that *might* help ?

> Just to confirm, you did import the partition image and not the disk  
> image right?  The current version supports only partition images.  
> The  '$Data not found while loading the MFT' is sometimes found when 
> you try  to process a disk image as NTFS (because they share the same 
> magic  value).
>
>
yes - I double checked that when I saw the NTFS 'superblock' in there.
the script was definitely using /dev/hda2

for my $chunk (0..60) {
    print "dd bs=1K if=/dev/hda2 of=part.$chunk skip=${chunk}M count=1M\n";
    print `dd bs=1K if=/dev/hda2 of=part.$chunk skip=${chunk}M count=1M`;
    print `ls`;
}

At this point, I think Im gonna try slicing off that FAT12 chunk,
much like Id do if the big image were the whole of /hda.

If it works, I will *certainly* report back.

>
> brian
>
thanks
Jim Cromie