LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Recovery of data from encrypted partition (http://www.linuxquestions.org/questions/slackware-14/recovery-of-data-from-encrypted-partition-4175445571/)

Phorize 01-14-2013 12:36 PM

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.

unSpawn 01-14-2013 12:55 PM

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.

rknichols 01-14-2013 01:13 PM

You can easily find out how much was overwritten:
Code:

hexdump /dev/sda | head
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.

Phorize 01-14-2013 01:39 PM

Quote:

Originally Posted by unSpawn (Post 4869858)
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.

Thanks for this, testdisk is running as I write.

Phorize 01-14-2013 01:47 PM

Quote:

Originally Posted by rknichols (Post 4869870)
You can easily find out how much was overwritten:
Code:

hexdump /dev/sda | head
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 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.

Alien Bob 01-14-2013 02:18 PM

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

TobiSGD 01-14-2013 03:35 PM

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?

rknichols 01-14-2013 04:42 PM

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

Phorize 01-14-2013 05:12 PM

Quote:

Originally Posted by rknichols (Post 4870030)
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:

Code:

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

testdisk doesn't find anything.

TobiSGD 01-14-2013 05:25 PM

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.

rknichols 01-14-2013 05:36 PM

That's not really what I asked for
Code:

dd if=/dev/sda count=1 | hexdump -C
and I don't see anything recognizable in that small portion of the first sector.

STDOUBT 01-14-2013 06:56 PM

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

rknichols 01-14-2013 07:09 PM

Quote:

Originally Posted by STDOUBT (Post 4870096)
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).

TobiSGD 01-14-2013 07:28 PM

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.

Phorize 01-15-2013 02:59 AM

Quote:

Originally Posted by rknichols (Post 4870030)
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.

Code:

dd if=/dev/sda count=1 | hexdump -C
gives:

Code:

1+0 records in
1+0 records out
512 bytes (512 B) copied00000000  fc 31 c0 8e d0 31 e4 8e  d8 8e c0 be 00 7c bf 00  |.1...1.......|..|
, 0.000232811 s, 2.2 MB/s
00000010  06 b9 00 01 f3 a5 be ee  07 b0 08 ea 20 06 00 00000000 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 16cd0  |............ ...|
00000020  80 3e b3 07 ff 75 04 88  16 b3 07 80 3c 00 74 04  |.>...u......<.t.|
00000030  08 06 af 07 83 ee 10 d0  e8 73 f0 90 90 90 90 90  |.........s......|
00000040  90 90 90 90 90 90 90 90  90 90 90 90 90 90 90 90  |................|
*
00000070  90 90 90 90 90 90 90 90  90 90 90 90 90 90 be be  |................|
00000080  07 b0 00 b9 04 00 80 3c  00 75 6e fe c0 83 c6 10  |.......<.un.....|
00000090  e2 f4 31 db b4 0e be 9d  07 8a 0e af 07 ac d0 e9  |..1.............|
000000a0  73 02 cd 10 08 c9 75 f5  b0 3a cd 10 31 c0 cd 16  |s.....u..:..1...|
000000b0  3c 00 74 f8 be 8b 07 b9  02 00 e8 ba 00 3c 0d 74  |<.t..........<.t|
000000c0  b4 3c 61 72 06 3c 7a 77  02 2c 20 88 c3 be 9d 07  |.<ar.<zw., .....|
000000d0  8a 0e af 07 ac d0 e9 73  04 38 c3 74 06 08 c9 75  |.......s.8.t...u|
000000e0  f3 eb af b8 0d 0e 31 db  cd 10 8d 84 62 00 3c 07  |......1.....b.<.|
000000f0  75 07 b0 1f a2 af 07 eb  99 31 d2 b9 01 00 3c 04  |u........1....<.|
00000100  74 11 73 f3 30 e4 b1 04  d2 e0 be be 07 01 c6 8a  |t.s.0...........|
00000110  16 b3 07 bf 05 00 56 f6  c2 80 74 31 b4 41 bb aa  |......V...t1.A..|
00000120  55 52 cd 13 5a 5e 56 72  1e 81 fb 55 aa 75 18 f6  |UR..Z^Vr...U.u..|
00000130  c1 01 74 13 8b 44 08 8b  5c 0a be 8d 07 89 44 08  |..t..D..\.....D.|
00000140  89 5c 0a b4 42 eb 0c 8a  74 01 8b 4c 02 b8 01 02  |.\..B...t..L....|
00000150  bb 00 7c 50 c6 06 8f 07  01 cd 13 58 5e 73 05 4f  |..|P.......X^s.O|
00000160  75 b4 eb 93 81 3e fe 7d  55 aa 75 f6 ea 00 7c 00  |u....>.}U.u...|.|
00000170  00 be 83 07 b9 0a 00 50  b4 0e 31 db ac cd 10 e2  |.......P..1.....|
00000180  fb 58 c3 54 65 73 74 44  69 73 6b 0d 0a 10 00 01  |.X.TestDisk.....|
00000190  00 00 7c 00 00 00 00 00  00 00 00 00 00 31 32 33  |..|..........123|
000001a0  34 46 00 00 41 4e 44 54  6d 62 72 00 02 02 02 1f  |4F..ANDTmbr.....|
000001b0  c7 00 00 80 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|

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


All times are GMT -5. The time now is 04:36 AM.