Re: Problem recovering encrypted partitions

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

 



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@xxxxxxxxxxx>:
> > 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@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
> > ----
> > 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
> _______________________________________________
> 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
----
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


[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