I take it for one of the two partitions you could do a LUKS setup and get it to dectypt. The means the LUKS header is fine and at last the keyslot you used is fine. That you get erors within the device is then not a LUKS problem. As to filesystem recovery, there are some tools available, depening on what filesystem is in there. I don't quite understand what you want with the MBR, that is in sector 1 of the disk. Or did you put an additional MBR into the LUKS container? If so, you have an ordinary MBR recovery priobrlam and would be lookting for filesystem signatures in the decrypted conntainer. As for finding the LUKS header for the second drive/partition, you can use the on disk format spefification here: http://code.google.com/p/cryptsetup/wiki/Specification Looking for the LUKS magic may already do it. The header should start on a 512 byte boundary, so the simples thing to find candidates would be something like hd /dev/<disk> | grep "4c 55 4b 73 ba be" Could take a while though, depending on CPU. Arno On Mon, Mar 08, 2010 at 10:16:32AM +0100, Thore Oltersdorf wrote: > 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 -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
