2012/1/14 Arno Wagner <arno@xxxxxxxxxxx>:
> 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@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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
