Sstrhsrtj

So I'm creating this training scenario whereby participants have to take an image of a broken disk, loop mount and recover the data. It's supposed to be fairly basic, but I've come accross this weird issue.

There's this drive /dev/vdb:

[root@training ~]# fdisk -l /dev/vdb



Disk /dev/vdb: 21.5 GB, 21474836480 bytes, 41943040 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

First I take an image and make sure the md5sum of both the image and drive match:

[root@disk-training ~]# dd if=/dev/vdb of=/recovery/recovery.img conv=sync,notrunc,noerror

10485760+0 records in

10485760+0 records out

5368709120 bytes (5.4 GB) copied, 64.6406 s, 83.1 MB/s



[root@disk-training ~]# md5sum /dev/vdb

08452c6ca60007e69694e7e96258554d  /dev/vdb



[root@disk-training ~]# md5sum /recovery/recovery.img

08452c6ca60007e69694e7e96258554d  /recovery/recovery.img

Next, to ensure no caches confuse the situation, I drop them:

[root@disk-training ~]# sync; echo 1 > /proc/sys/vm/drop_caches

[root@disk-training ~]# sync; echo 2 > /proc/sys/vm/drop_caches

[root@disk-training ~]# sync; echo 3 > /proc/sys/vm/drop_caches

Using a mix of testdisk to recover the partition and fsck to recover the filesystem, I can retrieve the file:

[root@disk-training ~]# testdisk /dev/vdb

TestDisk 7.0, Data Recovery Utility, April 2015

Christophe GRENIER <grenier@cgsecurity.org>

http://www.cgsecurity.org

You have to reboot for the change to take effect.



[root@disk-training ~]# partprobe /dev/vdb



[root@disk-training ~]# fsck -y /dev/vdb1

fsck from util-linux 2.23.2

e2fsck 1.42.9 (28-Dec-2013)

ext2fs_open2: Bad magic number in super-block

fsck.ext2: Superblock invalid, trying backup blocks...

/dev/vdb1 was not cleanly unmounted, check forced.

Resize inode not valid.  Recreate? yes

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

Free blocks count wrong for group #0 (23896, counted=23897).

Fix? yes

Free blocks count wrong for group #1 (32127, counted=32126).

Fix? yes

Free inodes count wrong for group #0 (8181, counted=8180).

Fix? yes

Free inodes count wrong (327669, counted=327668).

Fix? yes

/dev/vdb1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/vdb1: 12/327680 files (0.0% non-contiguous), 58463/1309696 blocks



[root@disk-training ~]# mount /dev/vdb1 /mnt/



[root@disk-training ~]# ls -l /mnt/file

-rw-r--r-- 1 root root 10 Dec 12 15:41 /mnt/file

So that's all good. So I set up the image as a loop device and do another md5sum to be sure:

[root@disk-training ~]# losetup /dev/loop0 /recovery/recovery.img



[root@disk-training ~]# md5sum /dev/loop0

08452c6ca60007e69694e7e96258554d  /dev/loop0

Now if I run the same process on this, it doesn't succeed:

[root@disk-training ~]# testdisk /dev/loop0

TestDisk 7.0, Data Recovery Utility, April 2015

Christophe GRENIER <grenier@cgsecurity.org>

http://www.cgsecurity.org

You have to reboot for the change to take effect.



[root@disk-training ~]# partprobe /dev/loop0



[root@disk-training ~]# fsck -y /dev/loop0p1

fsck from util-linux 2.23.2

e2fsck 1.42.9 (28-Dec-2013)

ext2fs_open2: Bad magic number in super-block

fsck.ext2: Superblock invalid, trying backup blocks...

fsck.ext2: Bad magic number in super-block while trying to open /dev/loop0p1



The superblock could not be read or does not describe a correct ext2

filesystem.  If the device is valid and it really contains an ext2

filesystem (and not swap or ufs or something else), then the superblock

is corrupt, and you might try running e2fsck with an alternate superblock:

    e2fsck -b 8193 <device>

And here's some basic troubleshooting I've done:

[root@disk-training ~]# dumpe2fs /dev/loop0p1

dumpe2fs 1.42.9 (28-Dec-2013)

dumpe2fs: Bad magic number in super-block while trying to open /dev/loop0p1

Couldn't find valid filesystem superblock.



[root@disk-training ~]# mke2fs -n /dev/loop0p1

mke2fs 1.42.9 (28-Dec-2013)

Filesystem label=

OS type: Linux

Block size=4096 (log=2)

Fragment size=4096 (log=2)

Stride=0 blocks, Stripe width=0 blocks

327680 inodes, 1309696 blocks

65484 blocks (5.00%) reserved for the super user

First data block=0

Maximum filesystem blocks=1342177280

40 block groups

32768 blocks per group, 32768 fragments per group

8192 inodes per group

Superblock backups stored on blocks:

        32768, 98304, 163840, 229376, 294912, 819200, 884736





[root@disk-training ~]# for i in {32768,98304,163840,229376,294912,819200,884736}; do e2fsck -b $i /dev/loop0p1; done

e2fsck 1.42.9 (28-Dec-2013)

e2fsck: Bad magic number in super-block while trying to open /dev/loop0p1



The superblock could not be read or does not describe a correct ext2

filesystem.  If the device is valid and it really contains an ext2

filesystem (and not swap or ufs or something else), then the superblock

is corrupt, and you might try running e2fsck with an alternate superblock:

    e2fsck -b 8193 <device>



e2fsck 1.42.9 (28-Dec-2013)

e2fsck: Invalid argument while trying to open /dev/loop0p1



The superblock could not be read or does not describe a correct ext2

filesystem.  If the device is valid and it really contains an ext2



......

I'm really confused by the results of this and wonder if someone can explain to me what is going on.

Turns out that the image loses its drive geometery, causing testdisk to recover an incorrect partition. Using testdisk to set the number of heads above 1 seemed to fix it.