Hi,
several things:
1. Never, ever, ever do this type of work without full backup.
2. Once you broke it, never, ever, ever write anything to the device.
Make a full binary copy (dd, dd_recue, cat from /dev/sdx, ...)
and only work on that. Many people only make their LUKS
containers irretrivable when trying to repair them. (At
least I suspect that. It is hard to tell, but some people
have had success in recovery, while people that try it your
way typically do nto get their data back.)
3. The cryptsetup package contains a keyslot-checker tool.
(I wrote it, but forgot to do an FAQ entry on it, maybe
I will find time this week.) You find it in
misc/keyslot_checker/ with instructions. It will find
overwritten areas in the active keyslots. It requires
installation of the cyrrent cryptsetup libraries (1.6.x)
but runs itself without installation.
Arno
On Tue, Apr 02, 2013 at 03:15:16AM -0400, Jim wrote:
> I made a silly mistake and realize that I probably will not recover
> this data. My goal is an exercise to better understand dm-crypt,
> LUKS, and the rest of the stack.
>
> I have, or had, a computer running Ubuntu 12.10 on an SSD with full
> disk encryption as configured by the standard installer. The drive
> contains an unencrypted /boot partition (sda1) and a LUKS/dm-crypt
> encrypted partition (sda5) that was a physical volume for a single
> volume group. That vg holds the lvs for an ext4 root file system and
> swap space.
>
> The problem started when I attempted to use gparted to repartition a
> usb flash drive without changing the selected device from /dev/sda
> (internal hdd) to /dev/sdb (usb flash drive)! I deleted the existing
> partitions and told gparted to apply my changes. Of course, I chose
> to ignore all warning prompts and continue. Instant regret. I left
> gparted open for a while hoping to find some way to undo my change
> and rewrite the old partition table. No luck.
>
> It would seem that gparted was somewhat successful in asking the
> kernel to reload the partition table as /sys/block/sda/ contained
> evidence of the sda5 partition but none of the primary partitions. I
> was able to grab the starting position and size from:
> $ cat /sys/block/sda/sda5/start
> 501760
> $ cat /sys/block/sda/sda5/size
> 233938944
> $ cat /sys/block/sda/sda5/alignment_offset
> 0
>
> Apt-get installed TestDisk 6.13 from and it found the /boot
> partition which I wrote to disk as the new partition table. I then
> used fdisk and added the sda5 partition. Fdisk's default starting
> position matched the above which I took to be a positive sign.
>
> A little more info from after the mistake but before rebooting:
> $ cryptsetup status /dev/sda5
> /dev/mapper/sda5_crypt is active and is in use.
> type: LUKS1
> cipher: aes-xts-plain64
> keysize: 512 bits
> device: /dev/sda5
> offset: 4096 sectors
> size: 233934848 sectors
> mode: read/write
>
> $ cryptsetup status cryptswap1
> /dev/mapper/cryptswap1 is active and is in use.
> type: PLAIN
> cipher: aes-cbc-essiv:sha256
> keysize: 256 bits
> device: /dev/mapper/cryptswap1
> offset: 0 sectors
> size: 16572416 sectors
> mode: read/write
>
> $ vgdisplay
> --- Volume group ---
> VG Name ubuntu
> System ID
> Format lvm2
> Metadata Areas 1
> Metadata Sequence No 3
> VG Access read/write
> VG Status resizable
> Max LV 0
> Cur LV 2
> Open LV 2
> Max PV 0
> Cur PV 1
> Act PV 1
> VG Size 111.55 GiB
> PE Size 4.00 MiB
> Total PE 28556
> Alloc PE / Size 28556 / 111.55 GiB
> Free PE / Size 0 / 0
> VG UUID bfEpfv-*omitted*
>
> $ lvdisplay
> --- Logical volume ---
> LV Path /dev/ubuntu/root
> LV Name root
> VG Name ubuntu
> LV UUID TYhvhI-*omitted*
> LV Write Access read/write
> LV Creation host, time ubuntu, 2013-01-09...
> LV Status available
> # open 1
> LV Size 103.64 GiB
> Current LE 26533
> Segments 1
> Allocation inherit
> Read ahead sectors auto
> - currently set to 256
> Block device 252:1
>
> --- Logical volume ---
> LV Path /dev/ubuntu/swap_1
> LV Name swap_1
> VG Name ubuntu
> LV UUID S0pUq6-*omitted*
> LV Write Access read/write
> LV Creation host, time ubuntu, 2013-01-09...
> LV Status available
> # open 1
> LV Size 7.90 GiB
> Current LE 2023
> Segments 1
> Allocation inherit
> Read ahead sectors auto
> - currently set to 256
> Block device 252:1
>
> $ fdisk -l /dev/sda
>
> Disk /dev/sda: 120.0 GB, 120034123776 bytes
> 255 heads, 63 sectors/track, 14593 cylinders, total 23441648 sectors
> Unites = sectors of 1 * 512 = 512 bytes
> Sectors size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier:
>
> Device Boot Start End Blocks ID System
> /dev/sda1 * 2048 499711 248832 83 Linux
> /dev/sda2 499712 23440703 116970496 5 Extended
> /dev/sda5 501760 23440703 116969472 83 Linux
>
> I was able to mount /boot which led me to believe I was on track. It
> seemed that sda5 was positioned correctly in this recreated
> partition table so I went ahead and rebooted.
>
> The grub2 menu loaded as usual and then I was prompted for the
> cryptsetup password. Everything seemed normal but it would not
> accept my password! I tried dozens of times while being careful with
> caps,num,fn lock keys. As a sanity check, I loaded the computer with
> a backup disk that is an out of date dd replicatoin of this SSD and
> my password was accepted there.
>
> Running the computer from a live cd I have examined the disk further.
>
> $ blkid -p /dev/sda5
> /dev/sda5: UUID="9c9e0774-*omitted*" VERSION="1" TYPE="crypto_LUKS"
> USAGE="crypto" PART_ENTRY_SCHEME="dos" PART_ENTRY_TYPE="0x83"
> PART_ENTRY_NUMBER="5" PART_ENTRY_OFFSET="501760"
> PART_ENTRY_SIZE="233938944" PART_ENTRY_DISK="8:0"
>
> $ cryptsetup -v isLuks /dev/sda5
> Command successful.
>
> That seems good as the starting position and size exactly match the
> value from the open volume before rebooting. I don't see why
> deleting and restoring the partition table would affect the volume.
> Why does luksOpen no longer like my password?
>
> After repeated failure to unlock the volume at boot time I was
> dropped to an initramfs prompt where I performed a luksDump. If I
> messed up on repartitioning I would expect luksDump to complain.
>
> (initramfs) cryptsetup -v luksDump /dev/sda5
> Version: 1
> Cipher name: aes
> Cipher mode: xts-plain64
> Hash spec: sha1
> Payload offset: 4096
> MK bits: 512
> MK digest: *omitted*
> MK salt: *omitted*
> MK iterations: *omitted*
> UUID: 9c9e0774-*omitted*
>
> Key Slot 0: ENABLED
> Iterations: *omitted*
> Salt: *omitted*
> 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
> Command successful.
>
> I may have missed something obvious but reading through the FAQ,
> searching the list and the web hasn't yielded the answer so I hope
> one of you can help or offer closure :)
>
> Thanks!
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@xxxxxxxx
> http://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
