sleuthkit-users — List to discuss Autopsy and The Sleuth Kit.

Re: [sleuthkit-users] EXT2 superblock

[Linux T. <lin...@ya...>]

--- Lisa Muir <34....@gm...> wrote:

> Here is the output of gpart: 
> 
> 
> Begin scan...
> Possible partition(DOS FAT), size(10mb),
> offset(338mb)
> End scan.
> 
> Checking partitions...
> Partition(Primary DOS with 12 bit FAT): primary 
> Ok.
> 
> Guessed primary partition table:
> Primary partition(1)
>    type: 001(0x01)(Primary DOS with 12 bit FAT)
>    size: 10mb #s(20739) s(693126-713864)
>    chs:  (43/37/1)-(44/111/12)d
> (43/37/1)-(44/111/12)r
> 
> Primary partition(2)
>    type: 000(0x00)(unused)
>    size: 0mb #s(0) s(0-0)
>    chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
> 
> Primary partition(3)
>    type: 000(0x00)(unused)
>    size: 0mb #s(0) s(0-0)
>    chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
> 
> Primary partition(4)
>    type: 000(0x00)(unused)
>    size: 0mb #s(0) s(0-0)
>    chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
> 
> Which is incorrect, since I know it was definitely
> an ext2 partition.
> 
> I didn't have too much time to play with it
> today.....
> 
> Lisa-
> 

yes Lisa, but because you dd from another device with
different partition.  gpart reads that info.

-lt



		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Re: [sleuthkit-users] EXT2 superblock

[Lisa M. <34....@gm...>]

Here is the output of gpart: 


Begin scan...
Possible partition(DOS FAT), size(10mb), offset(338mb)
End scan.

Checking partitions...
Partition(Primary DOS with 12 bit FAT): primary 
Ok.

Guessed primary partition table:
Primary partition(1)
   type: 001(0x01)(Primary DOS with 12 bit FAT)
   size: 10mb #s(20739) s(693126-713864)
   chs:  (43/37/1)-(44/111/12)d (43/37/1)-(44/111/12)r

Primary partition(2)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(3)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(4)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Which is incorrect, since I know it was definitely an ext2 partition.

I didn't have too much time to play with it today.....

Lisa-

Re: [sleuthkit-users] fsstat: Incorrect update sequence value in MFT entry

[Brian C. <ca...@sl...>]

Can you send me the data from running the following:

dd if=IMG.dd bs=512 skip=5069 count=2 of=mft.dat

This is the MFT that has the bad update values.

brian

On Oct 4, 2004, at 3:04 AM, Bergander Hans-Peter (DSB) * wrote:

> I am trying my first steps with TSK - unfortunately I rather quickly 
> faced a problem. Looking up the manuals and the web didn't give me an 
> answer - hope me question is not too silly.
>
> I have a dd image of /dev/hda1 with ntfs on it. md5's are ok.
>
> Running 'fsstat -v -f ntfs hda1.dd' fails, however, mounting the 
> dd-image as ntfs using a loop device works fine.
>
> Here is the output of fsstat:
>     ntfs_mft_lookup: Processing MFT 0
>     fs_read_random: read offs 2595328 len 1024 (mft read)
>     fsstat: Incorrect update sequence value in MFT entry
>     Update Value: 0x0 Actual Value: 0x3db Replacement Value: 0x0
>     This is typically because of a corrupted entry
>
> I am using TSK ver 1.72 on Debian sarge.
>
> What can I do? Any help would be appriciated.

[sleuthkit-users] fsstat: Incorrect update sequence value in MFT entry

[Bergander Hans-P. (D. * <Han...@de...>]

I am trying my first steps with TSK - unfortunately I rather quickly =
faced a problem. Looking up the manuals and the web didn't give me an =
answer - hope me question is not too silly.

I have a dd image of /dev/hda1 with ntfs on it. md5's are ok.

Running 'fsstat -v -f ntfs hda1.dd' fails, however, mounting the =
dd-image as ntfs using a loop device works fine.

Here is the output of fsstat:
    ntfs_mft_lookup: Processing MFT 0
    fs_read_random: read offs 2595328 len 1024 (mft read)
    fsstat: Incorrect update sequence value in MFT entry
    Update Value: 0x0 Actual Value: 0x3db Replacement Value: 0x0
    This is typically because of a corrupted entry

I am using TSK ver 1.72 on Debian sarge.

What can I do? Any help would be appriciated.

Thanks
Peter B.

Re: [sleuthkit-users] EXT2 superblock

[Brian C. <ca...@sl...>]

On Oct 3, 2004, at 8:16 PM, Linux Tard wrote:
>> So, Lisa's file system should still be intact, the
>> issue is finding out
>> where it starts and ends.

> This should be easy then, yes?  Use fdisk and create
> same exact partition layout.  Then fsck and specify
> good backup superblock?

Yea, if she knows what the original layout was.  Otherwise, she'll need 
'gpart -v' or testdisk to get the partition locations to plug into 
fdisk.

brian

Re: [sleuthkit-users] EXT2 superblock

[Linux T. <lin...@ya...>]

--- Brian Carrier <ca...@sl...> wrote:
 
> No, because the first partition is not typically
> until sector 63, which 
> is ~32K into the disk.  Sectors 1 to 62 may contain
> boot code and the 
> system will no longer boot, but the FS data should
> be fine.  Superblock 
> is two more sectors into the partition and the group
> descriptors are a 
> few more KB in after that (depending on the FS block
> size).


So using common 4k block size all should be left
alone.


> So, Lisa's file system should still be intact, the
> issue is finding out 
> where it starts and ends.
> 
> brian

This should be easy then, yes?  Use fdisk and create
same exact partition layout.  Then fsck and specify
good backup superblock?

-lt


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: [sleuthkit-users] EXT2 superblock

[Brian C. <ca...@sl...>]

On Oct 3, 2004, at 8:05 PM, Linux Tard wrote:
>>
> But fs info too, yes?  SHe dd 4K.
>

No, because the first partition is not typically until sector 63, which 
is ~32K into the disk.  Sectors 1 to 62 may contain boot code and the 
system will no longer boot, but the FS data should be fine.  Superblock 
is two more sectors into the partition and the group descriptors are a 
few more KB in after that (depending on the FS block size).

So, Lisa's file system should still be intact, the issue is finding out 
where it starts and ends.

brian

Re: [sleuthkit-users] EXT2 superblock

[Linux T. <lin...@ya...>]

--- Brian Carrier <ca...@sl...> wrote:

> Lisa,
> 
> You are confusing the disk master boot record
> (partition table) with 
> the file system superblock.   The MBR is located in
> the first sector of 
> the _disk_.  The superblock is located 1,024 bytes
> from the start of 
> the _partition_.  The first partition typically
> starts in sector 63 of 
> the disk.   So, the below commands changed the
> partition table of your 
> disk.  

But fs info too, yes?  SHe dd 4K.

-lt


If you rebooted, then the OS is going to use
> that partition 
> table for your disk, which may cause the OS to no
> longer associate a 
> device with an actual file system.
> 
> So, at this point a tool like testdisk or gpart will
> be your best 
> friends, but you said that testdisk did not find it.
>  Can you try 
> 'gpart'?
> 
> brian
> 
> 


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Re: [sleuthkit-users] EXT2 superblock

[Linux T. <lin...@ya...>]

> Testdisk didn't find the partitions either. I'm
> thinking this disk
> might have physical damage.


No Lisa, it most likely does not.  See more notes
below for more.


> I copied the superblock data using dd
> 
> # dd count=1 bs=4k if/dev/hda of=/dev/sda

Ouch.  That was bad.  Should have been bs=512 count=1
since boot code and partition table within that 512. 
you went way beyond that with your command above.

Then twice ouchies because you took an entirely
different hard drive, geometry and probably partitions
layout and wrote that to the one giving errors.  So
now you have bad geo and bad partition table.  It's
getting worse, Lisa, no better!  

Your data may be intact further down the drive. 
Depending upon type and size.  Problem we see now, how
to get to it easily?  You find file(s) inode(s) you
get pointers to data blocks, but that would be first
step for me now.  Quiting phunking up the partition
table stuff and looking for your data and grabbing it.


Had you not done 4k that would be one thing.  You
could have kept searching for good superblock.  gpart
may have helped you early on too Ms Muir.

And lastly, 'mke2fs' might have assisted.  The 'S'
flag would write superblock info again.  You could
have got block size of filesystem from dumpe2fs, but
probably have decent knowledge based on size. 
Anything over couple GB default to 4096.  Nice thing
here is only superblock is redone, your inode table
won't be changed.  

This interesting.  I iwsh you hadn't done 4k dd :(

Cuz most certinaly you destroyed inode table (and
inode bitmaps) :(

-lt


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: [sleuthkit-users] EXT2 superblock

[Brian C. <ca...@sl...>]

Lisa,

You are confusing the disk master boot record (partition table) with 
the file system superblock.   The MBR is located in the first sector of 
the _disk_.  The superblock is located 1,024 bytes from the start of 
the _partition_.  The first partition typically starts in sector 63 of 
the disk.   So, the below commands changed the partition table of your 
disk.  If you rebooted, then the OS is going to use that partition 
table for your disk, which may cause the OS to no longer associate a 
device with an actual file system.

So, at this point a tool like testdisk or gpart will be your best 
friends, but you said that testdisk did not find it.  Can you try 
'gpart'?

brian



On Oct 3, 2004, at 7:01 PM, Lisa Muir wrote:

> Brian, LT,
>
> Thank you. fsck and e2fsck don't work with any of the values you
> suggest. They both spit out the "bad superblock" error.
>
> I tried mounting under windows using an ext2 driver with no luck.
>
> Testdisk didn't find the partitions either. I'm thinking this disk
> might have physical damage.
>
> I copied the superblock data using dd
>
> # dd count=1 bs=4k if/dev/hda of=/dev/sda
>
>  Now, while this isn't the exact layout of the superblock here's what 
> I did:
>
> # od -x -N 64 /dev/sda +0x1000
>
> 0000000  1234 0234 0000 0000 0000 4000 0000 000a
> 0000020  0001 8000 1000 0000 2f6c 7633 0000 6c76
> 0000040  3300 0000 000a 0003 0100 0000 2f28 0383
> 0000060  0000 0001 0000 0200 0000 2000 0000 0000
> 0000100
>
> The very left column is exactly how it looked on my machine.
> The I ran the next command, to look at the next superblock copy:
>
> #  od -x -N 64 /dev/lv02 +0x1f000
>
> 0000000  1234 0234 0000 0000 0000 4000 0000 000a
> 0000020  0001 8000 1000 0000 2f6c 7633 0000 6c76
> 0000040  3300 0000 000a 0003 0100 0000 2f28 0383
> 0000060  0000 0001 0000 0200 0000 2000 0000 0000
> 0000100
>
> In other words, the copy was identical to the original. SO.....no
> point in copying that.  SO.....I ran:
>
> # od -x -N 64 /dev/hda 0x1000
>
> 0000000  4efb 3sc6 0000 0000 0000 4000 0000 000a
> 0000020  0001 8000 1000 0000 2f6c 7633 0000 6c76
> 0000040  3300 0000 000a 0003 0100 0000 2f28 0383
> 0000060  0000 0001 0000 0200 0000 2000 0000 0000
> 0000100
>
> Again not exactly what was on my machine, but the point is the top
> row, second column and third column entries were differentbut
> everything else stayed the same even the columns on the left. Only
> those two entries were different.  Soo....
>
> # dd count=1 bs=4k if/dev/hda of=/dev/sda
>
> (my thinking here was, well, hda boots just fine, so it's superblock
> must be intact....and it's ext2...
>
> and then running
>
> # od -x -N 64 /dev/sda +0x1000
>
> 0000000  4efb 3sc6 0000 0000 0000 4000 0000 000a
> 0000020  0001 8000 1000 0000 2f6c 7633 0000 6c76
> 0000040  3300 0000 000a 0003 0100 0000 2f28 0383
> 0000060  0000 0001 0000 0200 0000 2000 0000 0000
> 0000100
>
> So a successful change in the superblock...... Tried mounting
> /dev/sda1 but got no joy
>
> after running fdisk -l it told me the USB drive now contained the
> paritions that my main drive had, which of course it doesn't (but
> Brian, you say this doesn't matter).
>
> Now, I definitely need to read up on this. Most of the above was semi
> blindly following a help file I found via google. The main reason I'm
> sticking with this is that I'm curious if someone deliberately
> corrupted the superblock where one would go from there.
>
>

Re: [sleuthkit-users] EXT2 superblock

[Lisa M. <34....@gm...>]

Brian, LT, 

Thank you. fsck and e2fsck don't work with any of the values you
suggest. They both spit out the "bad superblock" error.

I tried mounting under windows using an ext2 driver with no luck. 

Testdisk didn't find the partitions either. I'm thinking this disk
might have physical damage.

I copied the superblock data using dd

# dd count=1 bs=4k if/dev/hda of=/dev/sda

 Now, while this isn't the exact layout of the superblock here's what I did: 
 
# od -x -N 64 /dev/sda +0x1000

0000000  1234 0234 0000 0000 0000 4000 0000 000a
0000020  0001 8000 1000 0000 2f6c 7633 0000 6c76
0000040  3300 0000 000a 0003 0100 0000 2f28 0383
0000060  0000 0001 0000 0200 0000 2000 0000 0000
0000100

The very left column is exactly how it looked on my machine. 
The I ran the next command, to look at the next superblock copy: 

#  od -x -N 64 /dev/lv02 +0x1f000

0000000  1234 0234 0000 0000 0000 4000 0000 000a
0000020  0001 8000 1000 0000 2f6c 7633 0000 6c76
0000040  3300 0000 000a 0003 0100 0000 2f28 0383
0000060  0000 0001 0000 0200 0000 2000 0000 0000
0000100 

In other words, the copy was identical to the original. SO.....no
point in copying that.  SO.....I ran:

# od -x -N 64 /dev/hda 0x1000    

0000000  4efb 3sc6 0000 0000 0000 4000 0000 000a
0000020  0001 8000 1000 0000 2f6c 7633 0000 6c76
0000040  3300 0000 000a 0003 0100 0000 2f28 0383
0000060  0000 0001 0000 0200 0000 2000 0000 0000
0000100 

Again not exactly what was on my machine, but the point is the top
row, second column and third column entries were differentbut
everything else stayed the same even the columns on the left. Only
those two entries were different.  Soo....

# dd count=1 bs=4k if/dev/hda of=/dev/sda 

(my thinking here was, well, hda boots just fine, so it's superblock
must be intact....and it's ext2...

and then running  

# od -x -N 64 /dev/sda +0x1000 

0000000  4efb 3sc6 0000 0000 0000 4000 0000 000a
0000020  0001 8000 1000 0000 2f6c 7633 0000 6c76
0000040  3300 0000 000a 0003 0100 0000 2f28 0383
0000060  0000 0001 0000 0200 0000 2000 0000 0000
0000100 

So a successful change in the superblock...... Tried mounting
/dev/sda1 but got no joy

after running fdisk -l it told me the USB drive now contained the
paritions that my main drive had, which of course it doesn't (but
Brian, you say this doesn't matter).

Now, I definitely need to read up on this. Most of the above was semi
blindly following a help file I found via google. The main reason I'm
sticking with this is that I'm curious if someone deliberately
corrupted the superblock where one would go from there.

Lisa. 




On Sun, 3 Oct 2004 18:47:28 -0500, Brian Carrier <ca...@sl...> wrote:
> 
> On Oct 3, 2004, at 10:24 AM, Lisa Muir wrote:
> 
> > Thank you Brian,
> >
> > I tried copying the "copy" of the superblock, but after I examined it,
> > the copies were identical to the the actual superblock.
> 
> How did you copy it?  The EXTxFS superblock is located 1,024 bytes from
> the start of the file system and is 1,024 bytes long.  Did you do a cut
> and paste with a hex editor?
> 
> > Is there  a command that displays all the "magic numbers" such as the
> > # newfs -N
> > command for sun?
> 
> As "lt" alluded to, the backup copies of the superblocks are located at
> the start of each block group.  The default size of each block group is
> based on the block size. So, if the file system had a 4,096-byte block
> size, then the backup copy would be located in block 32769 (multiply
> block size by 8 and add 1).    You can try the different block
> size-based locations. The signature value is 0xEF53 at byte offset 56
> to 57.
> 
> > I copied the superblock from another device, unfortunately a device
> > that multiple partitions on it so it didn't work.
> 
> That shouldn't be a problem.  The superblock is contained in one of the
> partitions and it does not care about any other partitions.
> 
> > I'm curious as to how one would tackle this in a forensics situtation,
> > if one didn't know the filesystem type, etc.
> 
> As "lt" mentioned, running a tool like 'fsck' is one way to approach
> it.  The issue is that 'fsck' may change a lot of things and move data
> around and overwrite stuff.  So, keep a backup copy of the pre-fsck
> data.
> 
> If it is just the magic value that is messed up, then I can show you
> how to change TSk so that it ignores that value.  But, in most cases
> there are many other problems in the image that are not fixed by
> ignoring them.
> 
> It is actually relatively easy for me to have TSK search for the backup
> copies. One of these days I will add that feature.
> 
> brian
> 
>

Re: [sleuthkit-users] EXT2 superblock

[Brian C. <ca...@sl...>]

On Oct 3, 2004, at 10:24 AM, Lisa Muir wrote:

> Thank you Brian,
>
> I tried copying the "copy" of the superblock, but after I examined it,
> the copies were identical to the the actual superblock.

How did you copy it?  The EXTxFS superblock is located 1,024 bytes from 
the start of the file system and is 1,024 bytes long.  Did you do a cut 
and paste with a hex editor?

> Is there  a command that displays all the "magic numbers" such as the
> # newfs -N
> command for sun?

As "lt" alluded to, the backup copies of the superblocks are located at 
the start of each block group.  The default size of each block group is 
based on the block size. So, if the file system had a 4,096-byte block 
size, then the backup copy would be located in block 32769 (multiply 
block size by 8 and add 1).    You can try the different block 
size-based locations. The signature value is 0xEF53 at byte offset 56 
to 57.

> I copied the superblock from another device, unfortunately a device
> that multiple partitions on it so it didn't work.

That shouldn't be a problem.  The superblock is contained in one of the 
partitions and it does not care about any other partitions.

> I'm curious as to how one would tackle this in a forensics situtation,
> if one didn't know the filesystem type, etc.

As "lt" mentioned, running a tool like 'fsck' is one way to approach 
it.  The issue is that 'fsck' may change a lot of things and move data 
around and overwrite stuff.  So, keep a backup copy of the pre-fsck 
data.

If it is just the magic value that is messed up, then I can show you 
how to change TSk so that it ignores that value.  But, in most cases 
there are many other problems in the image that are not fixed by 
ignoring them.

It is actually relatively easy for me to have TSK search for the backup 
copies. One of these days I will add that feature.

brian

Re: [sleuthkit-users] EXT2 superblock

[Linux T. <lin...@ya...>]

Yes Lisa,

I think perhaps you should purchase oreilly book
understanding linux kernel, or visit their site. 
Sample chapter for download from this book happens to
be ex2/3 filesystem chaper.  Much information
contained there to help you.

To assisst here for you, Superblock for ext2 contain;
# of inodes, FS size in blocks, # reserved blocks,
free block counter, free inode counter, the FS block
size, the FS fragment size, the # blocks/group, the #
of fragments/group, and # inodes/group, time last
mount, time last write, # mount before fschk, status
flag, magic signature, operating system FS was
created, and much more!

You use e2fsck to copy backup superblock to fix your
error.  You use dumpe2fs with 'h' flag to find block
size if you don't know.  1024 BS set at creation is
what you tried, 8193.  But 2048 BS would be 16384 and
standard 4K BS is 32768.  


-lt

--- Lisa Muir <34....@gm...> wrote:

> What information is contained in the ext2
> superblock?
> 
> I have a drive which I can't mount because it has a
> damaged
> superblock, and I'm wondering if I copy the
> superblock off another
> drive with the same partitioning and size, will I be
> able to get
> access to my file.
> 
> All I want to do is get a single dd image file off
> the drive, but I
> can't even mount the drive in Autopsy, says not a
> vald linux
> filesystem.
> 
> If I mount the filesystem as raw, I can't see any
> files.
> 
> Surely there has got to be a way to analyse a disk
> partition if the
> superblock was intentionally damaged?? all that
> other information on
> the disk couldn't be now unreachable?
> 
> Any help / advice much appreciated!
> 
> Lisa.
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide
> on ITManagersJournal
> Use IT products in your business? Tell us what you
> think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates!
> Click to find out more
>
http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> sleuthkit-users mailing list
>
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Re: [sleuthkit-users] EXT2 superblock

[Lisa M. <34....@gm...>]

Thank you Brian, 

I tried copying the "copy" of the superblock, but after I examined it,
the copies were identical to the the actual superblock.

I'm not well versed in this area, so I'm sort of plugging around. 

Is there  a command that displays all the "magic numbers" such as the 

# newfs -N 

command for sun? 

I'm using a knoppix CD to examine this drive. 

And yes, I pointed Autopsy to 

/dev/sda1

The filesystem, not the device. 

I copied the superblock from another device, unfortunately a device
that multiple partitions on it so it didn't work.

I'm curious as to how one would tackle this in a forensics situtation,
if one didn't know the filesystem type, etc.

I'm running testdisk now, to see if that can produce any more relevant results. 

I'll have to wait until that's finished to try to copy another
superblock form another drive that I know only has oen ext2 partition.

On Sun, 3 Oct 2004 09:48:00 -0500, Brian Carrier <ca...@sl...> wrote:
> 
> On Oct 3, 2004, at 5:44 AM, Lisa Muir wrote:
> 
> > What information is contained in the ext2 superblock?
> 
> There is a lot of size and layout information in there.
> 
> > I have a drive which I can't mount because it has a damaged
> > superblock, and I'm wondering if I copy the superblock off another
> > drive with the same partitioning and size, will I be able to get
> > access to my file.
> >
> > All I want to do is get a single dd image file off the drive, but I
> > can't even mount the drive in Autopsy, says not a vald linux
> > filesystem.
> 
> You are using the file system image and not the disk image right?
> Autopsy needs the file system image (i.e. hda1) and checks only that
> the magic value is there, so I would first check that you are using the
> actual file system image.  Otherwise, you can try and copy a superblock
> from another system.  There are also many backup copies of the
> superblock in the file system, which is not always easy to restore.
> 
> brian
> 
>

Re: [sleuthkit-users] EXT2 superblock

[Brian C. <ca...@sl...>]

On Oct 3, 2004, at 5:44 AM, Lisa Muir wrote:

> What information is contained in the ext2 superblock?

There is a lot of size and layout information in there.

> I have a drive which I can't mount because it has a damaged
> superblock, and I'm wondering if I copy the superblock off another
> drive with the same partitioning and size, will I be able to get
> access to my file.
>
> All I want to do is get a single dd image file off the drive, but I
> can't even mount the drive in Autopsy, says not a vald linux
> filesystem.

You are using the file system image and not the disk image right? 
Autopsy needs the file system image (i.e. hda1) and checks only that 
the magic value is there, so I would first check that you are using the 
actual file system image.  Otherwise, you can try and copy a superblock 
from another system.  There are also many backup copies of the 
superblock in the file system, which is not always easy to restore.

brian

[sleuthkit-users] EXT2 superblock

[Lisa M. <34....@gm...>]

What information is contained in the ext2 superblock?

I have a drive which I can't mount because it has a damaged
superblock, and I'm wondering if I copy the superblock off another
drive with the same partitioning and size, will I be able to get
access to my file.

All I want to do is get a single dd image file off the drive, but I
can't even mount the drive in Autopsy, says not a vald linux
filesystem.

If I mount the filesystem as raw, I can't see any files.

Surely there has got to be a way to analyse a disk partition if the
superblock was intentionally damaged?? all that other information on
the disk couldn't be now unreachable?

Any help / advice much appreciated!

Lisa.

Re: [sleuthkit-users] Itanium System

[Paul S. <pa...@vn...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have an AMD64 system if that helps.

Paul

On September 25, 2004 12:20, Brian Carrier wrote:
> Does anyone on this list have a 64-bit Intel Itanium system?  I need to
> find a GUID Partition Table (GPT) from an actual system and have not
> had much luck.  I made one using 'gpart', but it was pretty boring.  I
> need only the partition table information, which is in the first
> hundred or so sectors.
>
> thanks,
> brian
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBVi/Mbu2E+kpEvNgRAt+fAJ4x5ZGP2HeHENfF6UV4+N5iTHMlCQCfVVen
2V7pOUwXC4DU09vdJnKUuRI=
=kDoR
-----END PGP SIGNATURE-----

[sleuthkit-users] Itanium System

[Brian C. <ca...@sl...>]

Does anyone on this list have a 64-bit Intel Itanium system?  I need to 
find a GUID Partition Table (GPT) from an actual system and have not 
had much luck.  I made one using 'gpart', but it was pretty boring.  I 
need only the partition table information, which is in the first 
hundred or so sectors.

thanks,
brian

Re: [sleuthkit-users] File/Directories Names using alternate enco ding formats?

[Brian C. <ca...@sl...>]

If we are considering an NTFS file system, then all names are stored as 
UTF-16 Unicode, but TSK takes only the lower byte and turns it into 
ASCII.  With FAT, the original 8.3 directory entry has only ASCII and 
those can have characters from various code pages (I don't think the 
actual page is defined in the file system though).  FAT long file names 
are stored in UTF-16 and are Unicode so they can use the Unicode name.  
  Therefore, if you have a FAT file system with Arabic then (I think) 
the short name will use a code page and the long name will use Unicode.

In either case, TSK may not even show you the non-ASCII name because it 
requires the name to be valid ASCII.  This is obviously too restrictive 
in light of code pages and such.  Once TSK becomes Unicode-aware then 
this will also change.

brian




On Sep 22, 2004, at 2:00 PM, Kucenski, Matthew A. wrote:

> Although I have only limited understanding on this subject (I have 
> spent the
> last several days studying and trying to understand the character set 
> mess),
> I don't know that support of UNICODE is enough (at least for what I'm 
> trying
> to do).
>
> I know that the ASCII character set maps directly (same bit values) to 
> the
> UTF-8 version of UNICODE.  However, other languages do not necessarily 
> map
> directly to UNICODE.  For example, a Win95 drive used in an Arab 
> country
> will be using either the MS Win 1256 codepage or the MS DOS 720 
> codepage.
> Under ASCII or UNICODE, filenames using the language specific 
> characters in
> those codepages will be garbage.
>
> Again, my knowledge of this subject is limited.  I am also still 
> trying to
> get my FreeBSD system to recognize althernate character sets when 
> mounting a
> foreign disk image.  This whole subject is just a big steaming pile of 
> crap.
> Unicode is great, but there is a ton of legacy stuff behind it that is 
> still
> floating around causing problems.

RE: [sleuthkit-users] File/Directories Names using alternate enco ding formats?

[Kucenski, M. A. <Mat...@di...>]

Although I have only limited understanding on this subject (I have spent the
last several days studying and trying to understand the character set mess),
I don't know that support of UNICODE is enough (at least for what I'm trying
to do).

I know that the ASCII character set maps directly (same bit values) to the
UTF-8 version of UNICODE.  However, other languages do not necessarily map
directly to UNICODE.  For example, a Win95 drive used in an Arab country
will be using either the MS Win 1256 codepage or the MS DOS 720 codepage.
Under ASCII or UNICODE, filenames using the language specific characters in
those codepages will be garbage.

Again, my knowledge of this subject is limited.  I am also still trying to
get my FreeBSD system to recognize althernate character sets when mounting a
foreign disk image.  This whole subject is just a big steaming pile of crap.
Unicode is great, but there is a ton of legacy stuff behind it that is still
floating around causing problems.

-Matt

-----Original Message-----
From: Brian Carrier [mailto:ca...@sl...] 
Sent: Wednesday, September 22, 2004 2:37 PM
To: Kucenski, Matthew A.
Cc: 'sle...@li...'
Subject: Re: [sleuthkit-users] File/Directories Names using alternate
encoding formats?



On Sep 22, 2004, at 12:41 PM, Kucenski, Matthew A. wrote:

> If I have a drive that was used in a foreign country and the filenames
> are
> encoded using a different codepage, what will Sleuthkit do with those 
> file
> names?  Should it just display garbage?  Has any thought been put into
> allowing the user to change the codepage when running the various 
> tools?
> Just looking to find out where the tool stands on this subject.

The current version changes all Unicode characters into ASCII, so you 
will lose the special characters.  There is a patch for an older 
version of TSK at:

http://www.monyo.com/technical/unix/TASK/

My plan is to store both versions of the name in TSK v2 and display 
which ever one is specified on the command line.  But, that may not be 
for a while.

brian

Re: [sleuthkit-users] File/Directories Names using alternate encoding formats?

[Brian C. <ca...@sl...>]

On Sep 22, 2004, at 12:41 PM, Kucenski, Matthew A. wrote:

> If I have a drive that was used in a foreign country and the filenames 
> are
> encoded using a different codepage, what will Sleuthkit do with those 
> file
> names?  Should it just display garbage?  Has any thought been put into
> allowing the user to change the codepage when running the various 
> tools?
> Just looking to find out where the tool stands on this subject.

The current version changes all Unicode characters into ASCII, so you 
will lose the special characters.  There is a patch for an older 
version of TSK at:

http://www.monyo.com/technical/unix/TASK/

My plan is to store both versions of the name in TSK v2 and display 
which ever one is specified on the command line.  But, that may not be 
for a while.

brian

[sleuthkit-users] File/Directories Names using alternate encoding formats?

[Kucenski, M. A. <Mat...@di...>]

If I have a drive that was used in a foreign country and the filenames are
encoded using a different codepage, what will Sleuthkit do with those file
names?  Should it just display garbage?  Has any thought been put into
allowing the user to change the codepage when running the various tools?
Just looking to find out where the tool stands on this subject.

Thanks,
-Matt

Re: [sleuthkit-users] Showing HEX or ASCII in Autopsy?????

[Brian C. <ca...@sl...>]

On Sep 21, 2004, at 9:09 PM, Rich Thompson wrote:
> I am working a web email case.  When I look at the web
> pages or fragments in Autopsy - sometimes they show in
> ASCII and sometimes they show in garblygook which
> looks like HEX.  The files are live files in the
> directory and $MFT (Win XP machine) - show one would
> think they should show, right...
>
> example: looking at showmsg[1].htm  - looks fine
>                     showmsg[4].htm  - looks fine
>                     showmsg[6].htm  - junk
>                     showmsg[9].htm  - junk
>                     showmsg[11].htm - looks fine

What 'File Type' is being reported for the "junk" files.  If you change 
to the "Metadata" mode for those files, are they resident or 
non-resident?  I know that some of the free e-mail sites cause cached 
files to be gziped.

brian

[sleuthkit-users] Showing HEX or ASCII in Autopsy?????

[Rich T. <te...@ya...>]

Howdy,

I am working a web email case.  When I look at the web
pages or fragments in Autopsy - sometimes they show in
ASCII and sometimes they show in garblygook which
looks like HEX.  The files are live files in the
directory and $MFT (Win XP machine) - show one would
think they should show, right...

example: looking at showmsg[1].htm  - looks fine
                    showmsg[4].htm  - looks fine
                    showmsg[6].htm  - junk
                    showmsg[9].htm  - junk
                    showmsg[11].htm - looks fine

could this be right, or is this a bug.  Using
Sleuthkit-1.72 and Autopsy-2.03 on RH9 using Gnome and
Mozilla.

If this could be normal and I'm being a retard, then
set me straight and help me untard!

Thanks in advance,
Rich

Re: [sleuthkit-users] Novice question String Search

[Brian C. <ca...@sl...>]

On Sep 21, 2004, at 1:38 PM, Charlie Fraser wrote:

> Hello, I am performing an investigation and am preparing a report. In 
> the images.srch file which is created from a keyword search. What is 
> the significance of the second value? For example
>
> Cluster    2nd value     text match found
> 771098 | 1866              stringresult
>
> This is from a WIndows XP system. Is the second value the INODE?

It is the byte offset of the string in the cluster.

brian