Thread: [sleuthkit-users] EXT2 superblock
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-users
|
From: Lisa M. <34....@gm...> - 2004-10-03 10:45:17
|
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. |
|
From: Brian C. <ca...@sl...> - 2004-10-03 14:49:00
|
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 |
|
From: Lisa M. <34....@gm...> - 2004-10-03 15:25:22
|
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 > > |
|
From: Brian C. <ca...@sl...> - 2004-10-03 23:47:43
|
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 |
|
From: Lisa M. <34....@gm...> - 2004-10-04 00:01:38
|
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 > > |
|
From: Brian C. <ca...@sl...> - 2004-10-04 00:43:58
|
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. > > |
|
From: Linux T. <lin...@ya...> - 2004-10-04 01:05:55
|
--- 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 |
|
From: Brian C. <ca...@sl...> - 2004-10-04 01:10:58
|
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 |
|
From: Linux T. <lin...@ya...> - 2004-10-04 01:16:45
|
--- 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 |
|
From: Brian C. <ca...@sl...> - 2004-10-04 01:24:59
|
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 |
|
From: Lisa M. <34....@gm...> - 2004-10-05 03:10:53
|
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- |
|
From: Linux T. <lin...@ya...> - 2004-10-05 04:35:35
|
--- 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 |
|
From: Lisa M. <34....@gm...> - 2004-10-06 13:49:52
|
Brian/LT, With LT's kind assistance and guidance, I was able to get access to the filesystem. I used the following process: # mk2fs -S /dev/hdb which wrote just the superblock. I ran e2fsck and after it had completed I was able to mount the filesystem and browse the filesystem. All files appeared to be there and appeared to be the correct size. #fdisk -lu disk.dd gave the error that there was no valid partition table. Also, when I did an md5sum on the image file, the md5 didn't match the original md5 of the drive that was imaged. So somewhere the file was altered. Now, in my case, I'm not sure if the process modified the file, or my screwing around with the entire thing modified the file..as I plodded through a few different things before going down this last path.....however, I'm going to replicate this secnario with two smaller drives, to see if it happens again. My thinking for a test is to format a drive, write 1k to the superblock. Make sure it's screwed and can't mount, the run the two commands again and see what occurs in a controlled manner. Thankfully, this was an unneeded file, and simply an experiment but it was a great learning experience. Thank you Brian and LT for your patience. On Mon, 4 Oct 2004 21:35:27 -0700 (PDT), Linux Tard <lin...@ya...> wrote: > > > --- 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 > |
|
From: Brian C. <ca...@sl...> - 2004-10-06 15:56:52
|
On Oct 6, 2004, at 8:48 AM, Lisa Muir wrote: > Brian/LT, > > With LT's kind assistance and guidance, I was able to get access to > the filesystem. I used the following process: > > # mk2fs -S /dev/hdb > > which wrote just the superblock. > > I ran e2fsck and after it had completed I was able to mount the > filesystem and browse the filesystem. All files appeared to be there > and appeared to be the correct size. > > #fdisk -lu disk.dd > > gave the error that there was no valid partition table. Did the disk ever have more than one partition? Was this a USB token or a real disk? brian |
|
From: Lisa M. <34....@gm...> - 2004-10-06 19:07:53
|
Brian, No, this was a 120 GB Hitachi IDE drive. The disk was formatted originally ext2 with one primary partition by moi. Any thoughts on how the Md5 might has been modified? Lisa, On Wed, 6 Oct 2004 10:55:27 -0500, Brian Carrier <ca...@sl...> wrote: > > On Oct 6, 2004, at 8:48 AM, Lisa Muir wrote: > > > Brian/LT, > > > > With LT's kind assistance and guidance, I was able to get access to > > the filesystem. I used the following process: > > > > # mk2fs -S /dev/hdb > > > > which wrote just the superblock. > > > > I ran e2fsck and after it had completed I was able to mount the > > filesystem and browse the filesystem. All files appeared to be there > > and appeared to be the correct size. > > > > #fdisk -lu disk.dd > > > > gave the error that there was no valid partition table. > > Did the disk ever have more than one partition? Was this a USB token > or a real disk? > > brian > > |
|
From: Brian C. <ca...@sl...> - 2004-10-07 02:07:17
|
On Oct 6, 2004, at 2:07 PM, Lisa Muir wrote: > Brian, > > No, this was a 120 GB Hitachi IDE drive. The disk was formatted > originally ext2 with one primary partition by moi. > > Any thoughts on how the Md5 might has been modified? Well, you ran fsck on the file system, which fixed what ever problems were causing it to not mount before. So, that would cause the MD5 to change. I find it very strange that you could run 'mke2fs' on the disk device and not a partition device and it would find the file system that was originally inside of a partition.... brian |
|
From: Linux T. <lin...@ya...> - 2004-10-04 01:04:12
|
> 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 |
|
From: Linux T. <lin...@ya...> - 2004-10-03 21:24:16
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X