[SOLVED] Recovery of data from encrypted partition
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 very much; the first non-zero line of output from hexdump /dev/sda | head was:
Code:
0000010 b906 0100 a5f3 eebe b007 ea08 0602 0000
I'm not sure how to interpret the this.
Last edited by Phorize; 01-14-2013 at 01:47 PM.
Reason: accuracy
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?
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?
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?
Code:
dd if=/dev/sda count=1 | hexdump -C
Yes, /dev/sda is the right disk. Here is the full output of hexdump /dev/sda | head:
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.
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
Maybe I'm out to lunch, but I don't understand the focus on the boot sector.
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.
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?
Code:
dd if=/dev/sda count=1 | hexdump -C
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.