Recovery from 750GB drives with two encrypted partitions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi dm-crypt users/developers.

a few days ago I tried to get a feedback on the possibilities of recovery for a RAID Level 1 encrpyted system. In which two different partitions are encrypted. LUKS passwords are still known and - as shown below - partial information where to find LUKS partition header information are available. Please reply even if your time is short just with some comments on these abstracted information in this first paragraph. I would be very happy. Thanks in advance for any help!

Thore

------------
Now the text of the last email:
I would be very happy about a feedback regarding a disastrous step on setting up my LUKS encrypted RAID Level 1 today.

After a mainboard breakdown I was forced to change the system. Out of stupidity I just thought setting up again the mainboard-integrated
RAID would be usable of setting up the same RAID hard disks again. But wrong: MBR is lost now for both hard disks at the same time, yeah.
I have undone this step immediately but partition information were of course lost already.

What are general information about the hard disks:
There are two partitions. Output of testdisk was for one of the hard disks:

------------------------------
----------------------
Partition table type (auto): Intel
/dev/sdb: Device Configuration Overlay (DCO) present.
Disk /dev/sdb - 750 GB / 698 GiB - ATA WDC WD7500AACS-0
Partition table type: Intel

Interface Advanced
New options :
 Dump : No
 Cylinder boundary : Yes
 Allow partial last cylinder : No
 Expert mode : No
A new copy of MBR Ask the user for vista mode
Allow partial last cylinder : No
search_vista_part: 0

search_part()
Disk /dev/sdb - 750 GB / 698 GiB - CHS 91201 255 63
     Linux Swap              87   1  1    99 254 41     208760
     SWAP2 version 1, 106 MB / 101 MiB

     Linux                  100   0  1   100  32 40       2056
     LUKS 1 (Data size unknown), 1052 KB / 1028 KiB

     Linux                45000   0  1 45000  32 40       2056
     LUKS
search_part()
Disk /dev/sdb - 750 GB / 698 GiB - CHS 91201 255 63

block_group_nr 3

recover_EXT2: "e2fsck -b 98304 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=3/5589, s_mnt_count=0/21, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 183143645
recover_EXT2: part_size 1465149160
     Linux                    0   0  1 91201  80 55 1465149160
     EXT3 Large file Sparse superblock Backup superblock, 750 GB / 698 GiB
Partition not added.
     Linux Swap              87   1  1    99 254 41     208760
     SWAP2 version 1, 106 MB / 101 MiB

     Linux                  100   0  1   100  32 40       2056
     LUKS 1 (Data size unknown), 1052 KB / 1028 KiB

block_group_nr 3

recover_EXT2: "e2fsck -b 98304 -B 4096 SIGHUP detected! TestDisk has been killed.
_group_nr=3/2751, s_mnt_count=0/28, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 90164812
recover_EXT2: part_size 721318496
     Linux                  100   0  1 44999 254 59  721318496
     EXT3 Large file Sparse superblock Backup superblock, 369 GB / 343 GiB

     Linux                45000   0  1 45000  32 40       2056
     LUKS 1 (Data size unknown), 1052 KB / 1028 KiB
get_geometry_from_list_part_aux head=255 nbr=6
get_geometry_from_list_part_aux head=8 nbr=1
get_geometry_from_list_part_aux head=255 nbr=6

Results
   L Linux Swap              87   1  1    99 254 63     208782
     SWAP2 version 1, 106 MB / 101 MiB
     Linux                  100   0  1   100 254 63      16065
     LUKS 1 (Data size unknown), 8225 KB / 8032 KiB
     Linux                  100   0  1 44999 254 63  721318500
     EXT3 Large file Sparse superblock Backup superblock, 369 GB / 343 GiB
   * Linux                45000   0  1 45000 254 63      16065
     LUKS 1 (Data size unknown), 8225 KB / 8032 KiB

interface_write()
 1 E extended                87   0  1    99 254 63     208845
 2 * Linux                45000   0  1 45000 254 63      16065
 5 L Linux Swap              87   1  1    99 254 63     208782

interface_write()
 1 E extended LBA             0   1  1 44999 254 63  722924937
 2 * Linux                45000   0  1 45000 254 63      16065
 5 L Linux Swap              87   1  1    99 254 63     208782

interface_write()
 1 E extended                87   0  1    99 254 63     208845
 2 * Linux                45000   0  1 45000 254 63      16065
 5 L Linux Swap              87   1  1    99 254 63     208782

interface_write()
 1 E extended LBA             0   1  1 44999 254 63  722924937
 2 * Linux                45000   0  1 45000 254 63      16065
 5 L Linux Swap              87   1  1    99 254 63     208782

interface_write()
 1 E extended                87   0  1    99 254 63     208845
 2 * Linux                45000   0  1 45000 254 63      16065
 5 L Linux Swap              87   1  1    99 254 63     208782

interface_write()
 1 E extended LBA             0   1  1 44999 254 63  722924937
 2 * Linux                45000   0  1 45000 254 63      16065
 5 L Linux Swap              87   1  1    99 254 63     208782

interface_write()
 1 E extended                87   0  1    99 254 63     208845
 2 * Linux                45000   0  1 45000 254 63      16065
 5 L Linux Swap              87   1  1    99 254 63     208782

interface_write()
 1 E extended LBA             0   1  1 44999 254 63  722924937
 2 * Linux                45000   0  1 45000 254 63      16065
 5 L Linux Swap              87   1  1    99 254 63     208782
write!

write_mbr_i386: starting...
write_all_log_i386: starting...
write_all_log_i386: CHS: 0/1/1,lba=63
You will have to reboot for the change to take effect.
A new copy of MBR code has been written.
You have to reboot for the change to take effect.

TestDisk exited normally.
----------------------------------------------------

I suppose that LUKS partition headers are still available since running testdisk at least recovered partly the partitions.
And output of testdisk informs about the LUKS partition headers. But luksDump was until now only successful for the partition header  in sdb2 in sector 100.
See output below:

----------------------------------------------------
LUKS header information for /dev/sdb2

Version:           1
Cipher name:       aes
Cipher mode:       cbc-essiv:sha256
Hash spec:         sha1
Payload offset:    2056
MK bits:           256
MK digest:         0e 88 8d 6a 08 53 35 35 2e aa fa b9 3c b5 6c 91 c6 0a ed b6
MK salt:           96 72 0a 5a 8f ec 6f ba 17 d2 f0 2f 34 55 7c 74
                   c1 30 3e b5 b1 a9 48 5f d7 af 65 ed 12 6b f3 03
MK iterations:     10
UUID:              983ca94c-5c97-4bd2-af44-17b85933f487

Key Slot 0: ENABLED
    Iterations:             245476
    Salt:                   2b 2f c9 05 de f2 37 9e d6 7c bd f8 f1 51 63 46
                              38 8a 58 39 53 4a 16 6b e3 6f 3c a9 63 93 8a b9
    Key material offset:    8
    AF stripes:                4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
----------------------------------------------------

But opening this with luksOpen to /dev/mapper and the following mounting did result only into the low base directories already
followed by input/output error statements. I suppose that sectors of the found data partition is still not found correctly.
And I failed trying to cd into the subdirectories.
---

What I need or think what I need - please suggest better next steps if known! - from you:

1. Is it possible to recover MBR information after the BIOS has overwritten it?
Since I did not set up the RAID any further until now I just rewrote the MBR suggested by testdisk today on one of the mirrored disks.
Is there any tool which can be used to recover MBR information on the other not yet touched hard disk doing this like i.e. photorec for common other file types?
2. Since luksDump failed for the second partition header information on sector 45000: is there something like the program "strings" useful to be used to find these information?
I would like to grep the whole 750GB disk for it.
3. How are partition headers in their structure? All the time only one block? Readable by any other console tools except luksDump thus I could grep the whole disk for example to see why second header information was not recovered in sector 45000. Is the LUKS partition header usually in front of an encrypted data partition or behind?
4. When I got all informations about the partitions sizes and locations of their beginnings and end: what are usable tools for the easy manual creation of the MBR?
5. Do you see any other possibilities to grep for the partitions limits except done by testdisk already? Maybe something more fitting for LUKS encrypted partitions/disks?!?


Thanks in advance for your help and kindly regards,
Thore
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux