* [dm-crypt] Problem recovering encrypted partitions @ 2012-01-14 20:40 Luis P. Mendes 2012-01-14 21:17 ` Arno Wagner 0 siblings, 1 reply; 9+ messages in thread From: Luis P. Mendes @ 2012-01-14 20:40 UTC (permalink / raw) To: dm-crypt Hi, Maybe you can help me on this. My problem started when I booted my laptop with an OpenBSD CD that I was trying to install to a SD card. OpenBSD installer didn't detect my SD card, but went to partition my disk (/dev/sda). I didnt' confirm any change to the partition table of my disk but the installer changed the partition table of /dev/sda and I lost the configuration. As I didn't have a backup for the MBR of /dev/sda, I used testdisk http://www.cgsecurity.org/ and recovered the structure of the disk. Right now, fdisk reports: # fdisk -l /dev/sda Disk /dev/sda: 320.1 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x4483617d Device Boot Start End Blocks Id System /dev/sda1 63 16064 8001 83 Linux /dev/sda2 * 81915435 112631714 15358140 83 Linux /dev/sda3 112631715 259080254 73224270 f W95 Ext'd (LBA) /dev/sda5 112631778 115700129 1534176 82 Linux swap /dev/sda6 115700193 115716194 8001 83 Linux /dev/sda7 259064253 259080254 8001 83 Linux and cfdisk reports: cfdisk (util-linux 2.19) Disk Drive: /dev/sda Size: 320072933376 bytes, 320.0 GB Heads: 255 Sectors per Track: 63 Cylinders: 38913 Name Flags Part Type FS Type [Label] Size (MB) -------------------------------------------------------------------------- sda1 Primary crypto_LUKS 8.23 Primary Free Space 41932.48 sda2 Boot Primary ext3 15726.74 sda5 Logical Linux swap 1571.03 sda6 Logical crypto_LUKS 8.23 Logical Free Space 73394.18 sda7 Logical crypto_LUKS 8.23 Pri/Log Free Space 187423.85* I can boot the machine (/dev/sda2) but the encrypted partitions are not available: /home (/dev/sda6), /opt (/dev/sda7) and /mnt/cr1 (/dev/sda1). As you can see, for each of the three encrypted partitions, testdisk recovered the partition as having only circa 8MB and left the rest of the original partition as 'Free Space'. What can I do to have each one of these partitions consider all the 'Free Space" next to them as belonging to them? As a note, I did a 'dd' of the whole disk before using testdisk to a file. Luis ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dm-crypt] Problem recovering encrypted partitions 2012-01-14 20:40 [dm-crypt] Problem recovering encrypted partitions Luis P. Mendes @ 2012-01-14 21:17 ` Arno Wagner 2012-01-14 23:00 ` Luis P. Mendes 2012-01-15 14:13 ` Milan Broz 0 siblings, 2 replies; 9+ messages in thread From: Arno Wagner @ 2012-01-14 21:17 UTC (permalink / raw) To: dm-crypt Hi Luis, first thing is to check that the LUKS headers are still there: cryptsetup isLuks <device> If that succeeds, you can still manually map the LUKS containers and mount the filesystems inside (best only as "ro", i.e. read-only) to get your data off. LUKS and the filesystems actually do not care about the partitioning (well, the filesystems care about it but only on creation). Your partitioning is shot to hell though, so after you rescue your data, you should at the very least remove sda6/7/8 and recreate them (with fsidk or cfsisk). This may or may not repair the damage. To be on the safe side, I would recommend you to with the whole installation and recreate it from backup. If the isLuks test fails, then there are several options, making an image before running testdisk was definitely the right thing to do. One option will be to seach the LUKS headers and map them with offset (no partitions needed for that). Arno On Sat, Jan 14, 2012 at 08:40:19PM +0000, Luis P. Mendes wrote: > Hi, > > Maybe you can help me on this. > > My problem started when I booted my laptop with an OpenBSD CD that I > was trying to install to a SD card. OpenBSD installer didn't detect my > SD card, but went to partition my disk (/dev/sda). > I didnt' confirm any change to the partition table of my disk but the > installer changed the partition table of /dev/sda and I lost the > configuration. > As I didn't have a backup for the MBR of /dev/sda, I used testdisk > http://www.cgsecurity.org/ and recovered the structure of the disk. > > Right now, fdisk reports: > # fdisk -l /dev/sda > > Disk /dev/sda: 320.1 GB, 320072933376 bytes > 255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors > Units = sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x4483617d > > Device Boot Start End Blocks Id System > /dev/sda1 63 16064 8001 83 Linux > /dev/sda2 * 81915435 112631714 15358140 83 Linux > /dev/sda3 112631715 259080254 73224270 f W95 Ext'd (LBA) > /dev/sda5 112631778 115700129 1534176 82 Linux swap > /dev/sda6 115700193 115716194 8001 83 Linux > /dev/sda7 259064253 259080254 8001 83 Linux > > and cfdisk reports: > cfdisk (util-linux 2.19) > > Disk Drive: /dev/sda > Size: 320072933376 bytes, 320.0 GB > Heads: 255 Sectors per Track: 63 Cylinders: 38913 > > Name Flags Part Type FS Type [Label] Size (MB) > -------------------------------------------------------------------------- > sda1 Primary crypto_LUKS 8.23 > Primary Free Space 41932.48 > sda2 Boot Primary ext3 15726.74 > sda5 Logical Linux swap 1571.03 > sda6 Logical crypto_LUKS 8.23 > Logical Free Space 73394.18 > sda7 Logical crypto_LUKS 8.23 > Pri/Log Free Space 187423.85* > > > I can boot the machine (/dev/sda2) but the encrypted partitions are > not available: /home (/dev/sda6), /opt (/dev/sda7) and /mnt/cr1 > (/dev/sda1). > > As you can see, for each of the three encrypted partitions, testdisk > recovered the partition as having only circa 8MB and left the rest of > the original partition as 'Free Space'. > > What can I do to have each one of these partitions consider all the > 'Free Space" next to them as belonging to them? > > As a note, I did a 'dd' of the whole disk before using testdisk to a file. > > Luis > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt > -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dm-crypt] Problem recovering encrypted partitions 2012-01-14 21:17 ` Arno Wagner @ 2012-01-14 23:00 ` Luis P. Mendes 2012-01-14 23:15 ` Arno Wagner 2012-01-15 14:13 ` Milan Broz 1 sibling, 1 reply; 9+ messages in thread From: Luis P. Mendes @ 2012-01-14 23:00 UTC (permalink / raw) To: dm-crypt Thank you Arno for your help. I didn't write it before, but my config is: distro: Slackware64 13.37, with kernel 2.6.37.6, cryptsetup 1.2.0. For the three partitions, /dev/sda{1,6,7}, the command cryptsetup isLuks /dev/sda{1,6,7} returns nothing. If I'm not mistanken, this happened before during normal times. But if I try it in sda2 (root, not encrypted), the command returns: """Device /dev/sda2 is not a valid LUKS device.""" If I issue: root@localhost ~ # cryptsetup luksOpen /dev/sda6 encriptado Enter passphrase for /dev/sda6: root@localhost ~ # mount /dev/mapper/encriptado /encriptado/ # ll /encriptado/ ls: cannot access /encriptado/lost+found: Input/output error ls: cannot access /encriptado/home: Input/output error total 0 d????????? ? ? ? ? ? home d????????? ? ? ? ? ? lost+found For /dev/sda7, the situation is identical to /dev/sda6. For /dev/sda1, the situation is different, because I cannot mount the partition: # ll /encriptado/ root@localhost ~ # cryptsetup luksOpen /dev/sda1 crypt1 Enter passphrase for /dev/sda1: root@localhost ~ # mount /dev/mapper/crypt1 /mnt/crypt1/ mount: wrong fs type, bad option, bad superblock on /dev/mapper/crypt1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so root@localhost ~ # dmesg | tail [ 2068.599148] attempt to access beyond end of device [ 2068.599152] dm-3: rw=32, want=237241368, limit=14970 [ 2068.599155] EXT3-fs error (device dm-3): ext3_get_inode_loc: unable to read inode block - inode=7415815, block=29655170 [ 2068.610267] attempt to access beyond end of device [ 2068.610271] dm-3: rw=32, want=178782240, limit=14970 [ 2068.610274] EXT3-fs error (device dm-3): ext3_get_inode_loc: unable to read inode block - inode=5586969, block=22347779 [ 2068.621411] attempt to access beyond end of device [ 2068.621416] dm-3: rw=32, want=91226136, limit=14970 [ 2068.621418] EXT3-fs error (device dm-3): ext3_get_inode_loc: unable to read inode block - inode=2850817, block=11403266 [ 2169.844345] EXT4-fs (dm-1): bad geometry: block count 10239164 exceeds size of device (1743 blocks) So, what should I do next? Luis 2012/1/14 Arno Wagner <arno@wagner.name>: > Hi Luis, > > first thing is to check that the LUKS headers are still there: > > cryptsetup isLuks <device> > > If that succeeds, you can still manually map the LUKS containers > and mount the filesystems inside (best only as "ro", i.e. > read-only) to get your data off. LUKS and the filesystems > actually do not care about the partitioning (well, the > filesystems care about it but only on creation). Your > partitioning is shot to hell though, so after you rescue your > data, you should at the very least remove sda6/7/8 and recreate > them (with fsidk or cfsisk). This may or may not repair the damage. > To be on the safe side, I would recommend you to with the whole > installation and recreate it from backup. > > If the isLuks test fails, then there are several options, > making an image before running testdisk was definitely the > right thing to do. One option will be to seach the LUKS > headers and map them with offset (no partitions needed > for that). > > Arno > > > On Sat, Jan 14, 2012 at 08:40:19PM +0000, Luis P. Mendes wrote: >> Hi, >> >> Maybe you can help me on this. >> >> My problem started when I booted my laptop with an OpenBSD CD that I >> was trying to install to a SD card. OpenBSD installer didn't detect my >> SD card, but went to partition my disk (/dev/sda). >> I didnt' confirm any change to the partition table of my disk but the >> installer changed the partition table of /dev/sda and I lost the >> configuration. >> As I didn't have a backup for the MBR of /dev/sda, I used testdisk >> http://www.cgsecurity.org/ and recovered the structure of the disk. >> >> Right now, fdisk reports: >> # fdisk -l /dev/sda >> >> Disk /dev/sda: 320.1 GB, 320072933376 bytes >> 255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors >> Units = sectors of 1 * 512 = 512 bytes >> Sector size (logical/physical): 512 bytes / 512 bytes >> I/O size (minimum/optimal): 512 bytes / 512 bytes >> Disk identifier: 0x4483617d >> >> Device Boot Start End Blocks Id System >> /dev/sda1 63 16064 8001 83 Linux >> /dev/sda2 * 81915435 112631714 15358140 83 Linux >> /dev/sda3 112631715 259080254 73224270 f W95 Ext'd (LBA) >> /dev/sda5 112631778 115700129 1534176 82 Linux swap >> /dev/sda6 115700193 115716194 8001 83 Linux >> /dev/sda7 259064253 259080254 8001 83 Linux >> >> and cfdisk reports: >> cfdisk (util-linux 2.19) >> >> Disk Drive: /dev/sda >> Size: 320072933376 bytes, 320.0 GB >> Heads: 255 Sectors per Track: 63 Cylinders: 38913 >> >> Name Flags Part Type FS Type [Label] Size (MB) >> -------------------------------------------------------------------------- >> sda1 Primary crypto_LUKS 8.23 >> Primary Free Space 41932.48 >> sda2 Boot Primary ext3 15726.74 >> sda5 Logical Linux swap 1571.03 >> sda6 Logical crypto_LUKS 8.23 >> Logical Free Space 73394.18 >> sda7 Logical crypto_LUKS 8.23 >> Pri/Log Free Space 187423.85* >> >> >> I can boot the machine (/dev/sda2) but the encrypted partitions are >> not available: /home (/dev/sda6), /opt (/dev/sda7) and /mnt/cr1 >> (/dev/sda1). >> >> As you can see, for each of the three encrypted partitions, testdisk >> recovered the partition as having only circa 8MB and left the rest of >> the original partition as 'Free Space'. >> >> What can I do to have each one of these partitions consider all the >> 'Free Space" next to them as belonging to them? >> >> As a note, I did a 'dd' of the whole disk before using testdisk to a file. >> >> Luis >> _______________________________________________ >> dm-crypt mailing list >> dm-crypt@saout.de >> http://www.saout.de/mailman/listinfo/dm-crypt >> > > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name > GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F > ---- > 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@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dm-crypt] Problem recovering encrypted partitions 2012-01-14 23:00 ` Luis P. Mendes @ 2012-01-14 23:15 ` Arno Wagner 2012-01-14 23:46 ` Luis P. Mendes 0 siblings, 1 reply; 9+ messages in thread From: Arno Wagner @ 2012-01-14 23:15 UTC (permalink / raw) To: dm-crypt On Sat, Jan 14, 2012 at 11:00:17PM +0000, Luis P. Mendes wrote: > Thank you Arno for your help. > I didn't write it before, but my config is: distro: Slackware64 13.37, > with kernel 2.6.37.6, cryptsetup 1.2.0. > > For the three partitions, /dev/sda{1,6,7}, the command > cryptsetup isLuks /dev/sda{1,6,7} returns nothing. Ah, sorry. You need to use "cryptsetup -v isLuks <device>", as this command is intended to be used in scripts. > If I'm not mistanken, this happened before during normal times. > But if I try it in sda2 (root, not encrypted), the command returns: > """Device /dev/sda2 is not a valid LUKS device.""" Well, that would indicate it gives an error if it is not LUKS. However 1.4.1 does not give output either way, better re-run with "-v" to be sure. > If I issue: > root@localhost ~ # cryptsetup luksOpen /dev/sda6 encriptado > Enter passphrase for /dev/sda6: > root@localhost ~ # mount /dev/mapper/encriptado /encriptado/ > > # ll /encriptado/ > > ls: cannot access /encriptado/lost+found: Input/output error > ls: cannot access /encriptado/home: Input/output error > total 0 > d????????? ? ? ? ? ? home > d????????? ? ? ? ? ? lost+found > > For /dev/sda7, the situation is identical to /dev/sda6. Ok, this means the decryption worked. First, because LUKS would have complained (it does not do wrong mappings as plain dm-crypt would, it refuses to map instead) and second, because the filesystem signature has to be intact in order for the mount to work and that will only work with the correct decryption key. > For /dev/sda1, the situation is different, because I cannot mount the > # partition: ll /encriptado/ > > root@localhost ~ # cryptsetup luksOpen /dev/sda1 crypt1 > Enter passphrase for /dev/sda1: So LUKS header intact. > root@localhost ~ # mount /dev/mapper/crypt1 /mnt/crypt1/ > mount: wrong fs type, bad option, bad superblock on /dev/mapper/crypt1, > missing codepage or helper program, or other error > In some cases useful info is found in syslog - try > dmesg | tail or so But filesystem signarture damaged/overwritten. > root@localhost ~ # dmesg | tail > [ 2068.599148] attempt to access beyond end of device > [ 2068.599152] dm-3: rw=32, want=237241368, limit=14970 > [ 2068.599155] EXT3-fs error (device dm-3): ext3_get_inode_loc: unable > to read inode block - inode=7415815, block=29655170 > [ 2068.610267] attempt to access beyond end of device Hmm. > [ 2068.610271] dm-3: rw=32, want=178782240, limit=14970 > [ 2068.610274] EXT3-fs error (device dm-3): ext3_get_inode_loc: unable > to read inode block - inode=5586969, block=22347779 > [ 2068.621411] attempt to access beyond end of device > [ 2068.621416] dm-3: rw=32, want=91226136, limit=14970 > [ 2068.621418] EXT3-fs error (device dm-3): ext3_get_inode_loc: unable > to read inode block - inode=2850817, block=11403266 > [ 2169.844345] EXT4-fs (dm-1): bad geometry: block count 10239164 > exceeds size of device (1743 blocks) > > So, what should I do next? Good question. Did you do the damage while the LUKS containers were mapped? Otherwise the LUKS headers should have been overwritten. Lets jdo more tests first. Look at hexdumps of the LUKS-opened devices, e.g. with hd /dev/mapper/<dev> | less or some other hexdump tool. If this all (!) looks random, then decryption did actually not work. If there is some structure in, then this is not a LUKS problem, but normal filesystem damage caused by overwriting. But it depends on the actuall damage. Anything non-random looking means the LUKS mapping is intact. Arno > > Luis > > > 2012/1/14 Arno Wagner <arno@wagner.name>: > > Hi Luis, > > > > first thing is to check that the LUKS headers are still there: > > > > ??cryptsetup isLuks <device> > > > > If that succeeds, you can still manually map the LUKS containers > > and mount the filesystems inside (best only as "ro", i.e. > > read-only) to get your data off. ??LUKS and the filesystems > > actually do not care about the partitioning (well, the > > filesystems care about it but only on creation). Your > > partitioning is shot to hell though, so after you rescue your > > data, you should at the very least remove sda6/7/8 and recreate > > them (with fsidk or cfsisk). ??This may or may not repair the damage. > > To be on the safe side, I would recommend you to with the whole > > installation and recreate it from backup. > > > > If the isLuks test fails, then there are several options, > > making an image before running testdisk was definitely the > > right thing to do. One option will be to seach the LUKS > > headers and map them with offset (no partitions needed > > for that). > > > > Arno > > > > > > On Sat, Jan 14, 2012 at 08:40:19PM +0000, Luis P. Mendes wrote: > >> Hi, > >> > >> Maybe you can help me on this. > >> > >> My problem started when I booted my laptop with an OpenBSD CD that I > >> was trying to install to a SD card. OpenBSD installer didn't detect my > >> SD card, but went to partition my disk (/dev/sda). > >> I didnt' confirm any change to the partition table of my disk but the > >> installer changed the partition table of /dev/sda and I lost the > >> configuration. > >> As I didn't have a backup for the MBR of /dev/sda, I used testdisk > >> http://www.cgsecurity.org/ and recovered the structure of the disk. > >> > >> Right now, fdisk reports: > >> # fdisk -l /dev/sda > >> > >> Disk /dev/sda: 320.1 GB, 320072933376 bytes > >> 255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors > >> Units = sectors of 1 * 512 = 512 bytes > >> Sector size (logical/physical): 512 bytes / 512 bytes > >> I/O size (minimum/optimal): 512 bytes / 512 bytes > >> Disk identifier: 0x4483617d > >> > >> Device Boot Start End Blocks Id System > >> /dev/sda1 63 16064 8001 83 Linux > >> /dev/sda2 * 81915435 112631714 15358140 83 Linux > >> /dev/sda3 112631715 259080254 73224270 f W95 Ext'd (LBA) > >> /dev/sda5 112631778 115700129 1534176 82 Linux swap > >> /dev/sda6 115700193 115716194 8001 83 Linux > >> /dev/sda7 259064253 259080254 8001 83 Linux > >> > >> and cfdisk reports: > >> cfdisk (util-linux 2.19) > >> > >> Disk Drive: /dev/sda > >> Size: 320072933376 bytes, 320.0 GB > >> Heads: 255 Sectors per Track: 63 Cylinders: 38913 > >> > >> Name Flags Part Type FS Type [Label] Size (MB) > >> -------------------------------------------------------------------------- > >> sda1 Primary crypto_LUKS 8.23 > >> Primary Free Space 41932.48 > >> sda2 Boot Primary ext3 15726.74 > >> sda5 Logical Linux swap 1571.03 > >> sda6 Logical crypto_LUKS 8.23 > >> Logical Free Space 73394.18 > >> sda7 Logical crypto_LUKS 8.23 > >> Pri/Log Free Space 187423.85* > >> > >> > >> I can boot the machine (/dev/sda2) but the encrypted partitions are > >> not available: /home (/dev/sda6), /opt (/dev/sda7) and /mnt/cr1 > >> (/dev/sda1). > >> > >> As you can see, for each of the three encrypted partitions, testdisk > >> recovered the partition as having only circa 8MB and left the rest of > >> the original partition as 'Free Space'. > >> > >> What can I do to have each one of these partitions consider all the > >> 'Free Space" next to them as belonging to them? > >> > >> As a note, I did a 'dd' of the whole disk before using testdisk to a file. > >> > >> Luis > >> _______________________________________________ > >> dm-crypt mailing list > >> dm-crypt@saout.de > >> http://www.saout.de/mailman/listinfo/dm-crypt > >> > > > > -- > > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name > > GnuPG: ??ID: 1E25338F ??FP: 0C30 5782 9D93 F785 E79C ??0296 797F 6B50 1E25 338F > > ---- > > 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@saout.de > > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dm-crypt] Problem recovering encrypted partitions 2012-01-14 23:15 ` Arno Wagner @ 2012-01-14 23:46 ` Luis P. Mendes 2012-01-15 1:03 ` Arno Wagner 0 siblings, 1 reply; 9+ messages in thread From: Luis P. Mendes @ 2012-01-14 23:46 UTC (permalink / raw) To: dm-crypt 2012/1/14 Arno Wagner <arno@wagner.name>: > On Sat, Jan 14, 2012 at 11:00:17PM +0000, Luis P. Mendes wrote: >> Thank you Arno for your help. >> I didn't write it before, but my config is: distro: Slackware64 13.37, >> with kernel 2.6.37.6, cryptsetup 1.2.0. >> >> For the three partitions, /dev/sda{1,6,7}, the command >> cryptsetup isLuks /dev/sda{1,6,7} returns nothing. > > Ah, sorry. You need to use "cryptsetup -v isLuks <device>", as > this command is intended to be used in scripts. Ok, now I get some verbosity: # cryptsetup -v isLuks /dev/sda1 Command successful. # cryptsetup -v isLuks /dev/sda6 Command successful. # cryptsetup -v isLuks /dev/sda7 Command successful. >> If I issue: >> root@localhost ~ # cryptsetup luksOpen /dev/sda6 encriptado >> Enter passphrase for /dev/sda6: >> root@localhost ~ # mount /dev/mapper/encriptado /encriptado/ >> >> # ll /encriptado/ >> >> ls: cannot access /encriptado/lost+found: Input/output error >> ls: cannot access /encriptado/home: Input/output error >> total 0 >> d????????? ? ? ? ? ? home >> d????????? ? ? ? ? ? lost+found >> >> For /dev/sda7, the situation is identical to /dev/sda6. > > Ok, this means the decryption worked. First, because LUKS > would have complained (it does not do wrong mappings as > plain dm-crypt would, it refuses to map instead) and second, > because the filesystem signature has to be intact in order > for the mount to work and that will only work with the correct > decryption key. > >> For /dev/sda1, the situation is different, because I cannot mount the >> # partition: ll /encriptado/ >> >> root@localhost ~ # cryptsetup luksOpen /dev/sda1 crypt1 >> Enter passphrase for /dev/sda1: > > So LUKS header intact. > >> root@localhost ~ # mount /dev/mapper/crypt1 /mnt/crypt1/ >> mount: wrong fs type, bad option, bad superblock on /dev/mapper/crypt1, >> missing codepage or helper program, or other error >> In some cases useful info is found in syslog - try >> dmesg | tail or so > > But filesystem signarture damaged/overwritten. > >> root@localhost ~ # dmesg | tail >> [ 2068.599148] attempt to access beyond end of device >> [ 2068.599152] dm-3: rw=32, want=237241368, limit=14970 >> [ 2068.599155] EXT3-fs error (device dm-3): ext3_get_inode_loc: unable >> to read inode block - inode=7415815, block=29655170 >> [ 2068.610267] attempt to access beyond end of device > > Hmm. > >> [ 2068.610271] dm-3: rw=32, want=178782240, limit=14970 >> [ 2068.610274] EXT3-fs error (device dm-3): ext3_get_inode_loc: unable >> to read inode block - inode=5586969, block=22347779 >> [ 2068.621411] attempt to access beyond end of device >> [ 2068.621416] dm-3: rw=32, want=91226136, limit=14970 >> [ 2068.621418] EXT3-fs error (device dm-3): ext3_get_inode_loc: unable >> to read inode block - inode=2850817, block=11403266 >> [ 2169.844345] EXT4-fs (dm-1): bad geometry: block count 10239164 >> exceeds size of device (1743 blocks) >> >> So, what should I do next? > > Good question. Did you do the damage while the LUKS containers > were mapped? Otherwise the LUKS headers should have been > overwritten. The damage was done when I booted the laptop with OpenBSD distro. All the partitions of /dev/sda were not mounted, and /dev/sda{1,6,7} were also not decrypted. > > Lets jdo more tests first. Look at hexdumps of the LUKS-opened > devices, e.g. with > hd /dev/mapper/<dev> | less > or some other hexdump tool. > > If this all (!) looks random, then decryption did actually not work. > If there is some structure in, then this is not a LUKS problem, > but normal filesystem damage caused by overwriting. But it depends > on the actuall damage. Anything non-random looking means > the LUKS mapping is intact. For /dev/sda6, I found many examples of text, like this: # hexdump -C /dev/mapper/encriptado | less 0070e030 78 6d 70 70 2d 63 61 70 73 2e 78 6d 6c 00 00 00 |xmpp-caps.xml...| 0070e040 1d 40 20 00 14 00 09 01 62 6c 69 73 74 2e 78 6d |.@ .....blist.xm| 0070e050 6c 00 00 00 82 89 12 00 14 00 0a 01 73 74 61 74 |l...........stat| 0070e060 75 73 2e 78 6d 6c 00 00 c0 83 12 00 14 00 0c 01 |us.xml..�.......| 0070e070 61 63 63 6f 75 6e 74 73 2e 78 6d 6c 95 81 12 00 |accounts.xml....| 0070e080 10 00 06 01 61 63 63 65 6c 73 00 00 96 81 12 00 |....accels......| 0070e090 14 00 0c 02 63 65 72 74 69 66 69 63 61 74 65 73 |....certificates| 0070e0a0 b3 83 12 00 14 00 09 01 70 72 65 66 73 2e 78 6d |�.......prefs.xm| 0070e0b0 6c 00 00 00 9f 81 12 00 10 00 07 02 73 6d 69 6c |l...........smil| 0070e0c0 65 79 73 00 06 a1 12 00 0c 00 04 02 6c 6f 67 73 |eys..�......logs| 0070e0d0 5b 40 20 00 0c 00 02 01 69 64 65 65 c9 a1 12 00 |[@ .....ideeɡ..| 0070e0e0 14 00 0b 01 70 6f 75 6e 63 65 73 2e 78 6d 6c 00 |....pounces.xml.| 0070e0f0 67 40 20 00 10 00 07 01 69 64 2e 70 72 69 76 6d |g@ .....id.privm| 0070e100 68 40 20 00 14 00 0a 01 6b 6e 6f 77 6e 5f 6b 65 |h@ .....known_ke| 0070e110 79 73 0e 01 40 40 20 00 ec 0e 0e 01 62 6c 69 73 |ys..@@ .�...blis| 0070e120 74 2e 78 6d 6c 2e 73 61 76 65 61 76 65 65 12 00 |t.xml.saveavee..| 0070e130 d4 0e 0e 01 70 72 65 66 73 2e 78 6d 6c 2e 73 61 |�...prefs.xml.sa| 0070e140 76 65 61 76 65 89 12 00 24 89 12 00 b8 0e 0e 01 |veave...$...�...| 0070e150 70 72 65 66 73 2e 78 6d 6c 2e 73 61 76 65 00 00 |prefs.xml.save..| 0070e160 36 40 20 00 a0 0e 10 01 70 6f 75 6e 63 65 73 2e |6@ .�...pounces.| 0070e170 78 6d 6c 2e 73 61 76 65 00 00 00 00 00 00 00 00 |xml.save........| 0070e180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| For /dev/sda7, I only found recognizable text in some places, like this: # hexdump -C /dev/mapper/opt | less 00603040 01 40 a3 00 0c 00 02 02 67 61 37 31 01 20 02 00 |.@�.....ga71. ..| 00603050 14 00 03 07 62 69 6e 00 0c 00 03 02 62 69 6e 00 |....bin.....bin.| 00603060 01 c0 6f 00 20 00 06 02 73 65 64 61 69 74 00 00 |.�o. ...sedait..| 00603070 01 60 00 00 10 00 05 07 6c 61 6d 70 70 00 00 00 |.`......lampp...| 00603080 02 80 70 00 0c 00 03 02 6e 66 73 00 1e a5 71 00 |..p.....nfs..�q.| 00603090 10 00 08 02 6f 70 65 6e 66 69 72 65 29 c0 0b 00 |....openfire)�..| 006030a0 30 00 10 02 6d 79 73 71 6c 5f 69 6d 70 6f 72 74 |0...mysql_import| 006030b0 61 64 6f 73 01 a0 40 00 18 00 10 02 6d 79 73 71 |ados.�@.....mysq| 006030c0 6c 5f 64 61 74 61 62 61 73 65 73 32 05 80 70 00 |l_databases2..p.| 006030d0 1c 00 12 02 4f 70 65 6e 50 72 69 6e 74 69 6e 67 |....OpenPrinting| 006030e0 2d 53 70 6c 69 58 00 00 01 40 64 00 10 00 07 02 |-SpliX...@d.....| For /dev/sda1, the one I cannot mount, I cannot find text. But I had two virtual machines in this partition and maybe no other files. # hexdump -C /dev/mapper/crypt1 | less 003a6000 a6 83 00 00 a6 83 01 00 a6 83 02 00 a6 83 03 00 |�...�...�...�...| 003a6010 a6 83 04 00 a6 83 0c 00 a6 83 0d 00 a6 83 18 00 |�...�...�...�...| 003a6020 a6 83 28 00 a6 83 3e 00 a6 83 79 00 00 00 00 00 |�.(.�.>.�.y.....| 003a6030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| Luis >> 2012/1/14 Arno Wagner <arno@wagner.name>: >> > Hi Luis, >> > >> > first thing is to check that the LUKS headers are still there: >> > >> > ??cryptsetup isLuks <device> >> > >> > If that succeeds, you can still manually map the LUKS containers >> > and mount the filesystems inside (best only as "ro", i.e. >> > read-only) to get your data off. ??LUKS and the filesystems >> > actually do not care about the partitioning (well, the >> > filesystems care about it but only on creation). Your >> > partitioning is shot to hell though, so after you rescue your >> > data, you should at the very least remove sda6/7/8 and recreate >> > them (with fsidk or cfsisk). ??This may or may not repair the damage. >> > To be on the safe side, I would recommend you to with the whole >> > installation and recreate it from backup. >> > >> > If the isLuks test fails, then there are several options, >> > making an image before running testdisk was definitely the >> > right thing to do. One option will be to seach the LUKS >> > headers and map them with offset (no partitions needed >> > for that). >> > >> > Arno >> > >> > >> > On Sat, Jan 14, 2012 at 08:40:19PM +0000, Luis P. Mendes wrote: >> >> Hi, >> >> >> >> Maybe you can help me on this. >> >> >> >> My problem started when I booted my laptop with an OpenBSD CD that I >> >> was trying to install to a SD card. OpenBSD installer didn't detect my >> >> SD card, but went to partition my disk (/dev/sda). >> >> I didnt' confirm any change to the partition table of my disk but the >> >> installer changed the partition table of /dev/sda and I lost the >> >> configuration. >> >> As I didn't have a backup for the MBR of /dev/sda, I used testdisk >> >> http://www.cgsecurity.org/ and recovered the structure of the disk. >> >> >> >> Right now, fdisk reports: >> >> # fdisk -l /dev/sda >> >> >> >> Disk /dev/sda: 320.1 GB, 320072933376 bytes >> >> 255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors >> >> Units = sectors of 1 * 512 = 512 bytes >> >> Sector size (logical/physical): 512 bytes / 512 bytes >> >> I/O size (minimum/optimal): 512 bytes / 512 bytes >> >> Disk identifier: 0x4483617d >> >> >> >> Device Boot Start End Blocks Id System >> >> /dev/sda1 63 16064 8001 83 Linux >> >> /dev/sda2 * 81915435 112631714 15358140 83 Linux >> >> /dev/sda3 112631715 259080254 73224270 f W95 Ext'd (LBA) >> >> /dev/sda5 112631778 115700129 1534176 82 Linux swap >> >> /dev/sda6 115700193 115716194 8001 83 Linux >> >> /dev/sda7 259064253 259080254 8001 83 Linux >> >> >> >> and cfdisk reports: >> >> cfdisk (util-linux 2.19) >> >> >> >> Disk Drive: /dev/sda >> >> Size: 320072933376 bytes, 320.0 GB >> >> Heads: 255 Sectors per Track: 63 Cylinders: 38913 >> >> >> >> Name Flags Part Type FS Type [Label] Size (MB) >> >> -------------------------------------------------------------------------- >> >> sda1 Primary crypto_LUKS 8.23 >> >> Primary Free Space 41932.48 >> >> sda2 Boot Primary ext3 15726.74 >> >> sda5 Logical Linux swap 1571.03 >> >> sda6 Logical crypto_LUKS 8.23 >> >> Logical Free Space 73394.18 >> >> sda7 Logical crypto_LUKS 8.23 >> >> Pri/Log Free Space 187423.85* >> >> >> >> >> >> I can boot the machine (/dev/sda2) but the encrypted partitions are >> >> not available: /home (/dev/sda6), /opt (/dev/sda7) and /mnt/cr1 >> >> (/dev/sda1). >> >> >> >> As you can see, for each of the three encrypted partitions, testdisk >> >> recovered the partition as having only circa 8MB and left the rest of >> >> the original partition as 'Free Space'. >> >> >> >> What can I do to have each one of these partitions consider all the >> >> 'Free Space" next to them as belonging to them? >> >> >> >> As a note, I did a 'dd' of the whole disk before using testdisk to a file. >> >> >> >> Luis >> >> _______________________________________________ >> >> dm-crypt mailing list >> >> dm-crypt@saout.de >> >> http://www.saout.de/mailman/listinfo/dm-crypt >> >> >> > >> > -- >> > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name >> > GnuPG: ??ID: 1E25338F ??FP: 0C30 5782 9D93 F785 E79C ??0296 797F 6B50 1E25 338F >> > ---- >> > 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@saout.de >> > http://www.saout.de/mailman/listinfo/dm-crypt >> _______________________________________________ >> dm-crypt mailing list >> dm-crypt@saout.de >> http://www.saout.de/mailman/listinfo/dm-crypt > > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name > GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F > ---- > 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@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dm-crypt] Problem recovering encrypted partitions 2012-01-14 23:46 ` Luis P. Mendes @ 2012-01-15 1:03 ` Arno Wagner 2012-01-15 11:08 ` Luis P. Mendes 0 siblings, 1 reply; 9+ messages in thread From: Arno Wagner @ 2012-01-15 1:03 UTC (permalink / raw) To: dm-crypt On Sat, Jan 14, 2012 at 11:46:13PM +0000, Luis P. Mendes wrote: [...] > > Good question. Did you do the damage while the LUKS containers > > were mapped? Otherwise the LUKS headers should have been > > overwritten. > The damage was done when I booted the laptop with OpenBSD distro. > All the partitions of /dev/sda were not mounted, and /dev/sda{1,6,7} > were also not decrypted. Ok. > > > > Lets jdo more tests first. Look at hexdumps of the LUKS-opened > > devices, e.g. with > > ?? hd /dev/mapper/<dev> | less > > or some other hexdump tool. > > > > If this all (!) looks random, then decryption did actually not work. > > If there is some structure in, then this is not a LUKS problem, > > but normal filesystem damage caused by overwriting. But it depends > > on the actuall damage. Anything non-random looking means > > the LUKS mapping is intact. > > For /dev/sda6, I found many examples of text, like this: > # hexdump -C /dev/mapper/encriptado | less > 0070e030 78 6d 70 70 2d 63 61 70 73 2e 78 6d 6c 00 00 00 |xmpp-caps.xml...| > 0070e040 1d 40 20 00 14 00 09 01 62 6c 69 73 74 2e 78 6d |.@ .....blist.xm| > 0070e050 6c 00 00 00 82 89 12 00 14 00 0a 01 73 74 61 74 |l...........stat| > 0070e060 75 73 2e 78 6d 6c 00 00 c0 83 12 00 14 00 0c 01 |us.xml..???.......| > 0070e070 61 63 63 6f 75 6e 74 73 2e 78 6d 6c 95 81 12 00 |accounts.xml....| > 0070e080 10 00 06 01 61 63 63 65 6c 73 00 00 96 81 12 00 |....accels......| > 0070e090 14 00 0c 02 63 65 72 74 69 66 69 63 61 74 65 73 |....certificates| > 0070e0a0 b3 83 12 00 14 00 09 01 70 72 65 66 73 2e 78 6d |???.......prefs.xm| > 0070e0b0 6c 00 00 00 9f 81 12 00 10 00 07 02 73 6d 69 6c |l...........smil| > 0070e0c0 65 79 73 00 06 a1 12 00 0c 00 04 02 6c 6f 67 73 |eys..???......logs| > 0070e0d0 5b 40 20 00 0c 00 02 01 69 64 65 65 c9 a1 12 00 |[@ .....idee??..| > 0070e0e0 14 00 0b 01 70 6f 75 6e 63 65 73 2e 78 6d 6c 00 |....pounces.xml.| > 0070e0f0 67 40 20 00 10 00 07 01 69 64 2e 70 72 69 76 6d |g@ .....id.privm| > 0070e100 68 40 20 00 14 00 0a 01 6b 6e 6f 77 6e 5f 6b 65 |h@ .....known_ke| > 0070e110 79 73 0e 01 40 40 20 00 ec 0e 0e 01 62 6c 69 73 |ys..@@ .???...blis| > 0070e120 74 2e 78 6d 6c 2e 73 61 76 65 61 76 65 65 12 00 |t.xml.saveavee..| > 0070e130 d4 0e 0e 01 70 72 65 66 73 2e 78 6d 6c 2e 73 61 |???...prefs.xml.sa| > 0070e140 76 65 61 76 65 89 12 00 24 89 12 00 b8 0e 0e 01 |veave...$...???...| > 0070e150 70 72 65 66 73 2e 78 6d 6c 2e 73 61 76 65 00 00 |prefs.xml.save..| > 0070e160 36 40 20 00 a0 0e 10 01 70 6f 75 6e 63 65 73 2e |6@ .???...pounces.| > 0070e170 78 6d 6c 2e 73 61 76 65 00 00 00 00 00 00 00 00 |xml.save........| > 0070e180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > > For /dev/sda7, I only found recognizable text in some places, like this: > # hexdump -C /dev/mapper/opt | less > 00603040 01 40 a3 00 0c 00 02 02 67 61 37 31 01 20 02 00 |.@???.....ga71. ..| > 00603050 14 00 03 07 62 69 6e 00 0c 00 03 02 62 69 6e 00 |....bin.....bin.| > 00603060 01 c0 6f 00 20 00 06 02 73 65 64 61 69 74 00 00 |.???o. ...sedait..| > 00603070 01 60 00 00 10 00 05 07 6c 61 6d 70 70 00 00 00 |.`......lampp...| > 00603080 02 80 70 00 0c 00 03 02 6e 66 73 00 1e a5 71 00 |..p.....nfs..???q.| > 00603090 10 00 08 02 6f 70 65 6e 66 69 72 65 29 c0 0b 00 |....openfire)???..| > 006030a0 30 00 10 02 6d 79 73 71 6c 5f 69 6d 70 6f 72 74 |0...mysql_import| > 006030b0 61 64 6f 73 01 a0 40 00 18 00 10 02 6d 79 73 71 |ados.???@.....mysq| > 006030c0 6c 5f 64 61 74 61 62 61 73 65 73 32 05 80 70 00 |l_databases2..p.| > 006030d0 1c 00 12 02 4f 70 65 6e 50 72 69 6e 74 69 6e 67 |....OpenPrinting| > 006030e0 2d 53 70 6c 69 58 00 00 01 40 64 00 10 00 07 02 |-SpliX...@d.....| > > For /dev/sda1, the one I cannot mount, I cannot find text. But I had > two virtual machines in this partition and maybe no other files. > # hexdump -C /dev/mapper/crypt1 | less > 003a6000 a6 83 00 00 a6 83 01 00 a6 83 02 00 a6 83 03 00 |???...???...???...???...| > 003a6010 a6 83 04 00 a6 83 0c 00 a6 83 0d 00 a6 83 18 00 |???...???...???...???...| > 003a6020 a6 83 28 00 a6 83 3e 00 a6 83 79 00 00 00 00 00 |???.(.???.>.???.y.....| > 003a6030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > Ok, for all three, this is not a LUKS problem, LUKS header and at least the keyslots you used are intact. Decrypting anything but data encrypted with the same key results in random data, i.e. equally distributed, no patterns. We have clear patterns in all three, so they get decrypted with the right keys. I suspect that OpenBSD wrote stuff somewhere in the encrypted partitions. The further steps are now as you would do on non-encrypted partitions, but on the /dev/mapper/<somthing> containers. I am sorry, but I cannot really help here, this never has happened to me so far. Best guess is to look into what e2fsck and maybe other ext2 recovery tools can do for you. There is also the possibility that the small partitions do create problems. To check that, use dd to copy the decrypted devices to files (right size or a bit lather than the original partition), losetup them and try to mount. Come to think of it, that would probably also be easiest for anything else from here onwards, as keeping the decryption layer is not necessary. Arno > > Luis > > > > >> 2012/1/14 Arno Wagner <arno@wagner.name>: > >> > Hi Luis, > >> > > >> > first thing is to check that the LUKS headers are still there: > >> > > >> > ??cryptsetup isLuks <device> > >> > > >> > If that succeeds, you can still manually map the LUKS containers > >> > and mount the filesystems inside (best only as "ro", i.e. > >> > read-only) to get your data off. ??LUKS and the filesystems > >> > actually do not care about the partitioning (well, the > >> > filesystems care about it but only on creation). Your > >> > partitioning is shot to hell though, so after you rescue your > >> > data, you should at the very least remove sda6/7/8 and recreate > >> > them (with fsidk or cfsisk). ??This may or may not repair the damage. > >> > To be on the safe side, I would recommend you to with the whole > >> > installation and recreate it from backup. > >> > > >> > If the isLuks test fails, then there are several options, > >> > making an image before running testdisk was definitely the > >> > right thing to do. One option will be to seach the LUKS > >> > headers and map them with offset (no partitions needed > >> > for that). > >> > > >> > Arno > >> > > >> > > >> > On Sat, Jan 14, 2012 at 08:40:19PM +0000, Luis P. Mendes wrote: > >> >> Hi, > >> >> > >> >> Maybe you can help me on this. > >> >> > >> >> My problem started when I booted my laptop with an OpenBSD CD that I > >> >> was trying to install to a SD card. OpenBSD installer didn't detect my > >> >> SD card, but went to partition my disk (/dev/sda). > >> >> I didnt' confirm any change to the partition table of my disk but the > >> >> installer changed the partition table of /dev/sda and I lost the > >> >> configuration. > >> >> As I didn't have a backup for the MBR of /dev/sda, I used testdisk > >> >> http://www.cgsecurity.org/ and recovered the structure of the disk. > >> >> > >> >> Right now, fdisk reports: > >> >> # fdisk -l /dev/sda > >> >> > >> >> Disk /dev/sda: 320.1 GB, 320072933376 bytes > >> >> 255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors > >> >> Units = sectors of 1 * 512 = 512 bytes > >> >> Sector size (logical/physical): 512 bytes / 512 bytes > >> >> I/O size (minimum/optimal): 512 bytes / 512 bytes > >> >> Disk identifier: 0x4483617d > >> >> > >> >> Device Boot Start End Blocks Id System > >> >> /dev/sda1 63 16064 8001 83 Linux > >> >> /dev/sda2 * 81915435 112631714 15358140 83 Linux > >> >> /dev/sda3 112631715 259080254 73224270 f W95 Ext'd (LBA) > >> >> /dev/sda5 112631778 115700129 1534176 82 Linux swap > >> >> /dev/sda6 115700193 115716194 8001 83 Linux > >> >> /dev/sda7 259064253 259080254 8001 83 Linux > >> >> > >> >> and cfdisk reports: > >> >> cfdisk (util-linux 2.19) > >> >> > >> >> Disk Drive: /dev/sda > >> >> Size: 320072933376 bytes, 320.0 GB > >> >> Heads: 255 Sectors per Track: 63 Cylinders: 38913 > >> >> > >> >> Name Flags Part Type FS Type [Label] Size (MB) > >> >> -------------------------------------------------------------------------- > >> >> sda1 Primary crypto_LUKS 8.23 > >> >> Primary Free Space 41932.48 > >> >> sda2 Boot Primary ext3 15726.74 > >> >> sda5 Logical Linux swap 1571.03 > >> >> sda6 Logical crypto_LUKS 8.23 > >> >> Logical Free Space 73394.18 > >> >> sda7 Logical crypto_LUKS 8.23 > >> >> Pri/Log Free Space 187423.85* > >> >> > >> >> > >> >> I can boot the machine (/dev/sda2) but the encrypted partitions are > >> >> not available: /home (/dev/sda6), /opt (/dev/sda7) and /mnt/cr1 > >> >> (/dev/sda1). > >> >> > >> >> As you can see, for each of the three encrypted partitions, testdisk > >> >> recovered the partition as having only circa 8MB and left the rest of > >> >> the original partition as 'Free Space'. > >> >> > >> >> What can I do to have each one of these partitions consider all the > >> >> 'Free Space" next to them as belonging to them? > >> >> > >> >> As a note, I did a 'dd' of the whole disk before using testdisk to a file. > >> >> > >> >> Luis > >> >> _______________________________________________ > >> >> dm-crypt mailing list > >> >> dm-crypt@saout.de > >> >> http://www.saout.de/mailman/listinfo/dm-crypt > >> >> > >> > > >> > -- > >> > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name > >> > GnuPG: ??ID: 1E25338F ??FP: 0C30 5782 9D93 F785 E79C ??0296 797F 6B50 1E25 338F > >> > ---- > >> > 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@saout.de > >> > http://www.saout.de/mailman/listinfo/dm-crypt > >> _______________________________________________ > >> dm-crypt mailing list > >> dm-crypt@saout.de > >> http://www.saout.de/mailman/listinfo/dm-crypt > > > > -- > > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name > > GnuPG: ??ID: 1E25338F ??FP: 0C30 5782 9D93 F785 E79C ??0296 797F 6B50 1E25 338F > > ---- > > 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@saout.de > > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dm-crypt] Problem recovering encrypted partitions 2012-01-15 1:03 ` Arno Wagner @ 2012-01-15 11:08 ` Luis P. Mendes 0 siblings, 0 replies; 9+ messages in thread From: Luis P. Mendes @ 2012-01-15 11:08 UTC (permalink / raw) To: dm-crypt Thank you very much Arno, you've been of great help! Since luks headers are fine, my next step will be to try to modify the partition end information, to make it end where it should and not only 8MB far from the beginning. Luis 2012/1/15 Arno Wagner <arno@wagner.name>: > On Sat, Jan 14, 2012 at 11:46:13PM +0000, Luis P. Mendes wrote: > [...] >> > Good question. Did you do the damage while the LUKS containers >> > were mapped? Otherwise the LUKS headers should have been >> > overwritten. >> The damage was done when I booted the laptop with OpenBSD distro. >> All the partitions of /dev/sda were not mounted, and /dev/sda{1,6,7} >> were also not decrypted. > > Ok. > >> > >> > Lets jdo more tests first. Look at hexdumps of the LUKS-opened >> > devices, e.g. with >> > ?? hd /dev/mapper/<dev> | less >> > or some other hexdump tool. >> > >> > If this all (!) looks random, then decryption did actually not work. >> > If there is some structure in, then this is not a LUKS problem, >> > but normal filesystem damage caused by overwriting. But it depends >> > on the actuall damage. Anything non-random looking means >> > the LUKS mapping is intact. >> >> For /dev/sda6, I found many examples of text, like this: >> # hexdump -C /dev/mapper/encriptado | less >> 0070e030 78 6d 70 70 2d 63 61 70 73 2e 78 6d 6c 00 00 00 |xmpp-caps.xml...| >> 0070e040 1d 40 20 00 14 00 09 01 62 6c 69 73 74 2e 78 6d |.@ .....blist.xm| >> 0070e050 6c 00 00 00 82 89 12 00 14 00 0a 01 73 74 61 74 |l...........stat| >> 0070e060 75 73 2e 78 6d 6c 00 00 c0 83 12 00 14 00 0c 01 |us.xml..???.......| >> 0070e070 61 63 63 6f 75 6e 74 73 2e 78 6d 6c 95 81 12 00 |accounts.xml....| >> 0070e080 10 00 06 01 61 63 63 65 6c 73 00 00 96 81 12 00 |....accels......| >> 0070e090 14 00 0c 02 63 65 72 74 69 66 69 63 61 74 65 73 |....certificates| >> 0070e0a0 b3 83 12 00 14 00 09 01 70 72 65 66 73 2e 78 6d |???.......prefs.xm| >> 0070e0b0 6c 00 00 00 9f 81 12 00 10 00 07 02 73 6d 69 6c |l...........smil| >> 0070e0c0 65 79 73 00 06 a1 12 00 0c 00 04 02 6c 6f 67 73 |eys..???......logs| >> 0070e0d0 5b 40 20 00 0c 00 02 01 69 64 65 65 c9 a1 12 00 |[@ .....idee??..| >> 0070e0e0 14 00 0b 01 70 6f 75 6e 63 65 73 2e 78 6d 6c 00 |....pounces.xml.| >> 0070e0f0 67 40 20 00 10 00 07 01 69 64 2e 70 72 69 76 6d |g@ .....id.privm| >> 0070e100 68 40 20 00 14 00 0a 01 6b 6e 6f 77 6e 5f 6b 65 |h@ .....known_ke| >> 0070e110 79 73 0e 01 40 40 20 00 ec 0e 0e 01 62 6c 69 73 |ys..@@ .???...blis| >> 0070e120 74 2e 78 6d 6c 2e 73 61 76 65 61 76 65 65 12 00 |t.xml.saveavee..| >> 0070e130 d4 0e 0e 01 70 72 65 66 73 2e 78 6d 6c 2e 73 61 |???...prefs.xml.sa| >> 0070e140 76 65 61 76 65 89 12 00 24 89 12 00 b8 0e 0e 01 |veave...$...???...| >> 0070e150 70 72 65 66 73 2e 78 6d 6c 2e 73 61 76 65 00 00 |prefs.xml.save..| >> 0070e160 36 40 20 00 a0 0e 10 01 70 6f 75 6e 63 65 73 2e |6@ .???...pounces.| >> 0070e170 78 6d 6c 2e 73 61 76 65 00 00 00 00 00 00 00 00 |xml.save........| >> 0070e180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| >> >> For /dev/sda7, I only found recognizable text in some places, like this: >> # hexdump -C /dev/mapper/opt | less >> 00603040 01 40 a3 00 0c 00 02 02 67 61 37 31 01 20 02 00 |.@???.....ga71. ..| >> 00603050 14 00 03 07 62 69 6e 00 0c 00 03 02 62 69 6e 00 |....bin.....bin.| >> 00603060 01 c0 6f 00 20 00 06 02 73 65 64 61 69 74 00 00 |.???o. ...sedait..| >> 00603070 01 60 00 00 10 00 05 07 6c 61 6d 70 70 00 00 00 |.`......lampp...| >> 00603080 02 80 70 00 0c 00 03 02 6e 66 73 00 1e a5 71 00 |..p.....nfs..???q.| >> 00603090 10 00 08 02 6f 70 65 6e 66 69 72 65 29 c0 0b 00 |....openfire)???..| >> 006030a0 30 00 10 02 6d 79 73 71 6c 5f 69 6d 70 6f 72 74 |0...mysql_import| >> 006030b0 61 64 6f 73 01 a0 40 00 18 00 10 02 6d 79 73 71 |ados.???@.....mysq| >> 006030c0 6c 5f 64 61 74 61 62 61 73 65 73 32 05 80 70 00 |l_databases2..p.| >> 006030d0 1c 00 12 02 4f 70 65 6e 50 72 69 6e 74 69 6e 67 |....OpenPrinting| >> 006030e0 2d 53 70 6c 69 58 00 00 01 40 64 00 10 00 07 02 |-SpliX...@d.....| >> >> For /dev/sda1, the one I cannot mount, I cannot find text. But I had >> two virtual machines in this partition and maybe no other files. >> # hexdump -C /dev/mapper/crypt1 | less >> 003a6000 a6 83 00 00 a6 83 01 00 a6 83 02 00 a6 83 03 00 |???...???...???...???...| >> 003a6010 a6 83 04 00 a6 83 0c 00 a6 83 0d 00 a6 83 18 00 |???...???...???...???...| >> 003a6020 a6 83 28 00 a6 83 3e 00 a6 83 79 00 00 00 00 00 |???.(.???.>.???.y.....| >> 003a6030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| >> > > Ok, for all three, this is not a LUKS problem, LUKS header and > at least the keyslots you used are intact. Decrypting anything > but data encrypted with the same key results in random data, i.e. > equally distributed, no patterns. We have clear patterns in all > three, so they get decrypted with the right keys. > > I suspect that OpenBSD wrote stuff somewhere in the encrypted > partitions. > > The further steps are now as you would do on non-encrypted partitions, > but on the /dev/mapper/<somthing> containers. I am sorry, but > I cannot really help here, this never has happened to me so far. > Best guess is to look into what e2fsck and maybe other ext2 recovery > tools can do for you. > > There is also the possibility that the small partitions do create > problems. To check that, use dd to copy the decrypted devices to > files (right size or a bit lather than the original partition), > losetup them and try to mount. Come to think of it, that > would probably also be easiest for anything else from here onwards, > as keeping the decryption layer is not necessary. > > Arno > > > > >> >> Luis >> >> >> >> >> 2012/1/14 Arno Wagner <arno@wagner.name>: >> >> > Hi Luis, >> >> > >> >> > first thing is to check that the LUKS headers are still there: >> >> > >> >> > ??cryptsetup isLuks <device> >> >> > >> >> > If that succeeds, you can still manually map the LUKS containers >> >> > and mount the filesystems inside (best only as "ro", i.e. >> >> > read-only) to get your data off. ??LUKS and the filesystems >> >> > actually do not care about the partitioning (well, the >> >> > filesystems care about it but only on creation). Your >> >> > partitioning is shot to hell though, so after you rescue your >> >> > data, you should at the very least remove sda6/7/8 and recreate >> >> > them (with fsidk or cfsisk). ??This may or may not repair the damage. >> >> > To be on the safe side, I would recommend you to with the whole >> >> > installation and recreate it from backup. >> >> > >> >> > If the isLuks test fails, then there are several options, >> >> > making an image before running testdisk was definitely the >> >> > right thing to do. One option will be to seach the LUKS >> >> > headers and map them with offset (no partitions needed >> >> > for that). >> >> > >> >> > Arno >> >> > >> >> > >> >> > On Sat, Jan 14, 2012 at 08:40:19PM +0000, Luis P. Mendes wrote: >> >> >> Hi, >> >> >> >> >> >> Maybe you can help me on this. >> >> >> >> >> >> My problem started when I booted my laptop with an OpenBSD CD that I >> >> >> was trying to install to a SD card. OpenBSD installer didn't detect my >> >> >> SD card, but went to partition my disk (/dev/sda). >> >> >> I didnt' confirm any change to the partition table of my disk but the >> >> >> installer changed the partition table of /dev/sda and I lost the >> >> >> configuration. >> >> >> As I didn't have a backup for the MBR of /dev/sda, I used testdisk >> >> >> http://www.cgsecurity.org/ and recovered the structure of the disk. >> >> >> >> >> >> Right now, fdisk reports: >> >> >> # fdisk -l /dev/sda >> >> >> >> >> >> Disk /dev/sda: 320.1 GB, 320072933376 bytes >> >> >> 255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors >> >> >> Units = sectors of 1 * 512 = 512 bytes >> >> >> Sector size (logical/physical): 512 bytes / 512 bytes >> >> >> I/O size (minimum/optimal): 512 bytes / 512 bytes >> >> >> Disk identifier: 0x4483617d >> >> >> >> >> >> Device Boot Start End Blocks Id System >> >> >> /dev/sda1 63 16064 8001 83 Linux >> >> >> /dev/sda2 * 81915435 112631714 15358140 83 Linux >> >> >> /dev/sda3 112631715 259080254 73224270 f W95 Ext'd (LBA) >> >> >> /dev/sda5 112631778 115700129 1534176 82 Linux swap >> >> >> /dev/sda6 115700193 115716194 8001 83 Linux >> >> >> /dev/sda7 259064253 259080254 8001 83 Linux >> >> >> >> >> >> and cfdisk reports: >> >> >> cfdisk (util-linux 2.19) >> >> >> >> >> >> Disk Drive: /dev/sda >> >> >> Size: 320072933376 bytes, 320.0 GB >> >> >> Heads: 255 Sectors per Track: 63 Cylinders: 38913 >> >> >> >> >> >> Name Flags Part Type FS Type [Label] Size (MB) >> >> >> -------------------------------------------------------------------------- >> >> >> sda1 Primary crypto_LUKS 8.23 >> >> >> Primary Free Space 41932.48 >> >> >> sda2 Boot Primary ext3 15726.74 >> >> >> sda5 Logical Linux swap 1571.03 >> >> >> sda6 Logical crypto_LUKS 8.23 >> >> >> Logical Free Space 73394.18 >> >> >> sda7 Logical crypto_LUKS 8.23 >> >> >> Pri/Log Free Space 187423.85* >> >> >> >> >> >> >> >> >> I can boot the machine (/dev/sda2) but the encrypted partitions are >> >> >> not available: /home (/dev/sda6), /opt (/dev/sda7) and /mnt/cr1 >> >> >> (/dev/sda1). >> >> >> >> >> >> As you can see, for each of the three encrypted partitions, testdisk >> >> >> recovered the partition as having only circa 8MB and left the rest of >> >> >> the original partition as 'Free Space'. >> >> >> >> >> >> What can I do to have each one of these partitions consider all the >> >> >> 'Free Space" next to them as belonging to them? >> >> >> >> >> >> As a note, I did a 'dd' of the whole disk before using testdisk to a file. >> >> >> >> >> >> Luis >> >> >> _______________________________________________ >> >> >> dm-crypt mailing list >> >> >> dm-crypt@saout.de >> >> >> http://www.saout.de/mailman/listinfo/dm-crypt >> >> >> >> >> > >> >> > -- >> >> > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name >> >> > GnuPG: ??ID: 1E25338F ??FP: 0C30 5782 9D93 F785 E79C ??0296 797F 6B50 1E25 338F >> >> > ---- >> >> > 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@saout.de >> >> > http://www.saout.de/mailman/listinfo/dm-crypt >> >> _______________________________________________ >> >> dm-crypt mailing list >> >> dm-crypt@saout.de >> >> http://www.saout.de/mailman/listinfo/dm-crypt >> > >> > -- >> > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name >> > GnuPG: ??ID: 1E25338F ??FP: 0C30 5782 9D93 F785 E79C ??0296 797F 6B50 1E25 338F >> > ---- >> > 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@saout.de >> > http://www.saout.de/mailman/listinfo/dm-crypt >> _______________________________________________ >> dm-crypt mailing list >> dm-crypt@saout.de >> http://www.saout.de/mailman/listinfo/dm-crypt > > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name > GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F > ---- > 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@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dm-crypt] Problem recovering encrypted partitions 2012-01-14 21:17 ` Arno Wagner 2012-01-14 23:00 ` Luis P. Mendes @ 2012-01-15 14:13 ` Milan Broz 2012-01-15 14:23 ` Arno Wagner 1 sibling, 1 reply; 9+ messages in thread From: Milan Broz @ 2012-01-15 14:13 UTC (permalink / raw) To: dm-crypt On 01/14/2012 10:17 PM, Arno Wagner wrote: > first thing is to check that the LUKS headers are still there: > > cryptsetup isLuks<device> Just nitpicking - I would better suggest to use blkid -p <device> It will also detect crypto but also it will print if there is some other signature. You should see something like # blkid -p /dev/sda2 /dev/sda2: UUID="..." VERSION="1" TYPE="crypto_LUKS" USAGE="crypto" ... (-p means bypass cache, for old blkid just remove this switch if not supported) Milan ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dm-crypt] Problem recovering encrypted partitions 2012-01-15 14:13 ` Milan Broz @ 2012-01-15 14:23 ` Arno Wagner 0 siblings, 0 replies; 9+ messages in thread From: Arno Wagner @ 2012-01-15 14:23 UTC (permalink / raw) To: dm-crypt Indeed. Added in Wiki and SVN. Arno On Sun, Jan 15, 2012 at 03:13:06PM +0100, Milan Broz wrote: > On 01/14/2012 10:17 PM, Arno Wagner wrote: > > >first thing is to check that the LUKS headers are still there: > > > > cryptsetup isLuks<device> > > Just nitpicking - I would better suggest to use > > blkid -p <device> > > It will also detect crypto but also it will print if > there is some other signature. > > You should see something like > > # blkid -p /dev/sda2 > /dev/sda2: UUID="..." VERSION="1" TYPE="crypto_LUKS" USAGE="crypto" ... > > (-p means bypass cache, for old blkid just remove this switch > if not supported) > > Milan > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt > -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-01-15 14:23 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-01-14 20:40 [dm-crypt] Problem recovering encrypted partitions Luis P. Mendes 2012-01-14 21:17 ` Arno Wagner 2012-01-14 23:00 ` Luis P. Mendes 2012-01-14 23:15 ` Arno Wagner 2012-01-14 23:46 ` Luis P. Mendes 2012-01-15 1:03 ` Arno Wagner 2012-01-15 11:08 ` Luis P. Mendes 2012-01-15 14:13 ` Milan Broz 2012-01-15 14:23 ` Arno Wagner
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.