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