Recovery of data from encrypted partition
 

I need some help on recovering data from a hard drive with damage to the mbr,the first partition and maybe the encrypted partition. The issue is as follows:

1) Starting point
This install was a full Slackware64 14 install on a 500gb wd veloceraptor. I had an encrypted partition setup using luks and LVM as per the guide available on the root of the slackware tree. The partition setup (done with cfdisk) was:

/dev/sda
/dev/sda1 100mb /boot
/dev/sda5 rest of disk encrypted partition

2) How I messed things up.
First, there is no backup of the data concerned-unfortunately my wife had been using it to organise her photos and I was unaware that she didn't have a backup.

I had intended to to the following to an external drive:

dd if=/dev/zero of=/dev/sdc bs=1M

Unfortunately I was in a rush and did:

dd if=/dev/zero of=/dev/sda bs=1M

I managed to kill the dd write almost immediately (less than a couple of seconds) so am optimistic (but not certain) that I didn't write beyond /dev/sda1 space (the drive wrote before at about 15 mb per second from /dev/urandom, and I don't think that it would go much faster than that even with bs=1M involved.

3) What I'd like to do

I haven't used recovery tools before, but would imagine that I would need to either restore the mbr based on the right assumptions about the precise locations of the partitions (not sure how I would ascertain this) or locate the encrypted partition and mount it.

Advice appreciated.

Boot a Live or rescue CD and check if 'testdisk' can recover the partition table? If it can then chances are your LUKS partition may be accessible too as the LUKS header is written at the start of its partition.

You can easily find out how much was overwritten:Note the address of the first non-zero line that shows up. (Only the first of the many all-zero lines will have been shown.) If that hex address is less than 0x6400000 (100MiB) you're in luck. But, I'm not optimistic.

1. Writing from /dev/urandom is slowed by the pseudo-random number generator in the kernel. Writing from /dev/zero will go at the full speed of the device, probably 80MB/s at the outer cylinders.
2. Even if you interrupted the process before the device had written very much, dd will have been running at RAM speeds until the kernel ran out of buffer space, and all of that buffered data will still be written to the device.
3. The LUKS header is at the very beginning of its partition, and if you've overwritten that, you've destroyed the LUKS master key. That would eliminate any possibility of recovery.

Thanks for this, testdisk is running as I write.

Thanks very much; the first non-zero line of output from hexdump /dev/sda | head was:

I'm not sure how to interpret the this.

It would mean that only the first 16 bytes of your disk have been zeroed. Which would mean that testdisk should probably be able to re-create the partition table. Did it do anything when you ran it?

Eric

If only the first 16 bytes were overwritten the partition table should be untouched (it begins at byte 446), only the bootloader would be destroyed. Would be very unusual to only have 16 bytes written in this situation (the Velociraptors are very fast for a mechanical disk, about 200MB/s sequential write speed) , but nothing is impossible.
In that case you should be able to use your Slackware install medium to start the system (instructions at the bootloader page).
Have you tried that?

Looks to me like it is pretty much impossible. Writes to the device can only be whole sectors, and dd was instructed to issue write() calls for blocks of 1 Megabyte.

Are you sure you are looking at the right disk? A change in the boot environment can cause the drives to be detected in a different order. What does that whole first sector look like?

Yes, /dev/sda is the right disk. Here is the full output of hexdump /dev/sda | head:

testdisk doesn't find anything.

Are you sure that is the whole output of that command? It seems that you snipped it at the end, which is the crucial part to determine if this is a proper MBR.

That's not really what I asked forand I don't see anything recognizable in that small portion of the first sector.

kirstizz, have you tried vgscan?

Maybe I'm out to lunch, but I don't understand the focus on the boot sector.
My first action in this situation would be to slave the drive in question into another system,
and work on it from there.
I would check:
Does fdisk -l show the partitions?
I would simply try to mount /dev/sda5 with cryptsetup. Recovery of /dev/sda5
should have nothing to do with the boot sector. At this point, kristizz, you're only interested in data recovery, no?
Even running an Ubuntu liveCD might help, if the partitions are visible. Heck, trying to mount /dev/sda5 under the GUI should actually prompt you for the password.
HTH

The focus is not on the boot sector itself, but rather on trying to determine how much of the drive has been overwritten with zeros and seeing a result that suggests that the drive was not zeroed at all (the boot sector is not all zero).

Better said, the focus is not on the bootsector, the focus lies on the MBR, which contains the partition table, something very essential when you try to recover partitions.

thanks...tired eyes weren't reading well last night!

I should point out that I tried to restore the mdr with tstdisk and wrote testdisk code to the mbr. I've re-zero'd the mdr to erase the test disk code, whicih I'm farirly sure doesn't make the situation worse as I'm certain it was zero'd to begin with.

gives:

hexdump /dev/sda | head currently gives:


0000000 31fc 8ec0 31d0 8ee4 8ed8 bec0 7c00 00bf
0000010 b906 0100 a5f3 eebe b007 ea08 0620 0000
0000020 3e80 07b3 75ff 8804 b316 8007 003c 0474
0000030 0608 07af ee83 d010 73e8 90f0 9090 9090
0000040 9090 9090 9090 9090 9090 9090 9090 9090
*
0000070 9090 9090 9090 9090 9090 9090 9090 bebe
0000080 b007 b900 0004 3c80 7500 fe6e 83c0 10c6
0000090 f4e2 db31 0eb4 9dbe 8a07 af0e ac07 e9d0
00000a0 0273 10cd c908 f575 3ab0 10cd c031 16cd