recovering forgotten password

Having searched through the archives and read the FAQ list, I know this isn't going to be easy, but I have to give it a try anyway. Yes, I'm yet another guy who forgot his LUKS password. And I encrypted both the system and data LVs (when I first installed CentOS/Linux). After a couple days trying out various passphrases (going through my three chances and then having to shut down and restart the machine to get another three chances) and not succeeding, I removed the drive and put it into a drive enclosure, then attached it (via USB) to an older but working system. Now I can read only the /boot partition of that drive....

Now, when I run cryptsetup, it won't let me specify the device name:

# cryptsetup status luks-3[...]683a /dev/sda3
/dev/mapper/luks-3[...]683a does not exist.

I also tried for device /dev/sda ... still no go.

Or is there a better way to input my passphrase guesses...?

tnx.

Good. Forst step done right.

Huh? What kind of command is that supposed to be? You have to 1. luksOpen and 2. mount. There is no autoMagic after the removal from the original system.

To verify the LUKS header, use something like
cryptsetup luksDump /dev/sda3

To try a password, use somethin like
cryptsetup luksOpen /dev/sda3

If you need enough tries to automatize this, you can read the passphrase from file (or stdin) with something like this
cryptsetup --key-file=<some file> luksOpen /dev/sda3

For this, make sure to not have a trailing newline in the file.

Arno

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
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 

On Wed, Aug 17, 2011 at 09:35:13PM +0200, Arno Wagner wrote:
[...]

Needs a device of course, so
cryptsetup luksOpen /dev/sda3 e1
for /dev/mapper/e1

Same as above:
cryptsetup --key-file=<some file> luksOpen /dev/sda3 e1

and with reading from stdin

   cryptsetup --key-file="-" luksOpen /dev/loop0 e1 

Arno

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
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 

Over the weekend I read a bunch more documentation, got a spare drive connected, and on it created an encrypted partition containing a Linux LVMed filesystem (ext3 if it matters... same as the on the disk I'm trying to get back). I did all this to test and refine a script I created so I can input possible/likely passphrases and see which of them might work. My script works fine on the one encrypted partition I created on the test disk. I have a concern though.

When booting the disk I'm locked out of, it would prompt me twice... because, as explained above, the partition contained two encrypted logical volumes... so I was prompted for passphrases for each. In fact, if I failed to input the correct passphrase for the first LV, I'd still be prompted for the passphrase for the second LV. When I do "cryptsetup isLuks /dev/sda5" the error code (0) tells me I've got an encrypted device... but just one. Using luksDump likewise shows just one instance of something (?) encrypted.

Why is this, when I know there to be *two* encrypted LVs on that partition/device?

Most importantly, when I run

echo -n "$PASS PHRASE" |/sbin/cryptsetup luksOpen /dev/sdb5 name1

is cryptsetup going to be talking to one or the other encrypted LVs...? and if so, which one?

Thanks^128,
ken

/dev/sdb5 doesn't look like a logical volume. Are you sure you activated the volume groups before.

I don't have a clue what your setup is, but it might just be that you need to run

vgchange -ay <vgname>

which would make your two lvs appear in /dev/mapper/<vg>-<lv> or something like that.

Regards,

Yves-Alexis

Yves, thanks for replying.

This setup worked fine for years without changing anything on it. I'm fairly certain that there are two logical volumes on /dev/sda5, both encrypted. As said, when I booted the system up, I was prompted for two passphrases (one for each filesystem).

Does this tell us anything?

# cryptsetup luksDump /dev/sda5
LUKS header information for /dev/sda5

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
Payload offset: 1032
MK bits:        128
MK digest:      a6 74 e6 0d 12 60 aa ae 29 fc 19 74 7c b2 8f 88 23 fd 52 75
MK salt:        b2 5d f0 62 f8 f0 3c b9 de 5a a5 a8 75 31 91 71
                7a 72 2c 4d e0 a5 38 b2 eb 46 ae ec 1c 47 2b 39
MK iterations:  10
UUID:           074c3369-bd66-4afa-97ad-973769aeb208

Key Slot 0: ENABLED
Iterations: 104644
Salt: 0e bf a9 bf eb 10 b6 02 52 5c f4 08 fc
02 b4 2a

                                85 f6 eb 16 fc ac 59 a9 1f b5 93 9c 6b

c3 11 b2
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

I have to admit that I don't know how it was set up either. It was all part of an install routine (started after booting an install DVD) which I ran two years ago. The install routine didn't explain how the filesystem encryption was being set up. I probably just clicked on a couple checkboxes to encrypt the two filesystems/LVs/(?).

On the other hand, if I do a "vgdisplay /dev/sda5", I get a series of lines saying "Input/output error" along with the locations of those errors, ending with the statement 'Volume group "sda5" not found'.

I'd think that if vgdisplay can't locate the volume group, then vgchange isn't going to function properly. And, as said in an earlier post, the PV/VG/LV/LUKS configuration all booted and mounted just fine. It's just that I recently forgot the two passphrases needed to mount the two LVs.

In addition, this happens if I try to mount /dev/sda5:

# mount /dev/sda5 /mnt/sda5
mount: unknown filesystem type 'crypt_LUKS'

There is another partition which I can mount, /dev/sda3, which ultimately (if I knew the passphrases so everything would be properly mounted) is mounted on /boot. As such it contains kernels, system maps, etc., and of course /boot/grub/menu.lst; this last lists an entry (one of the items which appears in the grub boot menu):

title CentOS (2.6.18-238.12.1.el5)

        root (hd0,2)
        kernel /vmlinuz-2.6.18-238.12.1.el5 ro
root=/dev/mapper/luks-3d723b4f-0184-438d-9cb9-9ebff16e683a rhgb quiet
        initrd /initrd-2.6.18-238.12.1.el5.img

(The line beginning "kernel" wraps... everything through "quiet" is on one line.) Could this be the "/dev/mapper/<vg>-<lv>" you referred to?

My uneducated guess (newbie + 5 days) is that /dev/sda5 is a LUKS container, inside of which are the two logical volumes (each of which is separately encrypted) and that something in the /boot partition (/dev/sda3, which I can mount) says to read /dev/sda5-- *how* to read it, or what to read it with, I don't know.

No. vgdisplay does not take physical path as argument, this command must fail. (but io errors indicate something more serious - what exactly it says?)

Whatever, seems you are doing several mistakes, lets try this:

/dev/sda5 is LUKS device for sure, you have to first activate:

1) cryptsetup luksOpen /dev/sda5 sda5_crypt

does it work and device is properly unlocked? If so, then

2) please paste output of: "blkid /dev/mapper/sda5_crypt"

I guess it will be LVM PV. If so then run

3) vgscan ; vgchange -a y

4) paste here output of "blkid /dev/mapper/*"

Maybe you can add also "blkid /dev/sd*" so we can be sure what's type of partitions you have there - the grub entry you mentioned does not match the device on /dev/sda5.

(I would say paste here output of "lsblk -f" but this command is not yet in CentOS5.)

Thanks,
Milan

You're right... vgdisplay takes the VG name as its arg.

# cryptsetup luksOpen /dev/sda5 sda5_crypt
Enter LUKS passphrase for /dev/sda5:
Enter LUKS passphrase for /dev/sda5:
Enter LUKS passphrase for /dev/sda5:
Command failed: No key available with this passphrase.

I tried three different passphrases. None worked. This is the original problem. If I knew the passphrase-- even just for the data partition-- I'd be done... the whole problem would be solved for me.

Since I don't know the passphrase for the command above, I can't do any of the rest of these commands.

Thanks, Milan.

Please provide the results of blkid /dev/sd* (and vgscan too).

Regards,

Yves-Alexis

# blkid /dev/sda5
/dev/sda5: UUID="074c3369-bd66-4afa-97ad-973769aeb208" TYPE="crypt_LUKS"
root@agnes:~/bin # blkid /dev/sda*
/dev/sda1: SEC_TYPE="msdos" LABEL="DellUtility" UUID="07D4-0612" TYPE="vfat"
/dev/sda2: TYPE="ntfs"
/dev/sda3: LABEL="/boot" UUID="3043a9bc-cee8-4e8f-8f96-5725ad0a5db1"
SEC_TYPE="ext2" TYPE="ext3"
/dev/sda5: UUID="074c3369-bd66-4afa-97ad-973769aeb208" TYPE="crypt_LUKS"

(Yeah, it's a dual-boot setup.)

Perhaps helpful to know cylinders and/or sectors of partitions...?

# fdisk -l /dev/sda ; fdisk -lu /dev/sda

Disk /dev/sda: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1           6       48163+  de  Dell Utility
/dev/sda2   *           7        2428    19454715    7  HPFS/NTFS
/dev/sda3            2429        2441      104422+  83  Linux
/dev/sda4            2442       38913   292961340    5  Extended
/dev/sda5            2442       38913   292961308+  8e  Linux LVM

Disk /dev/sda: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63       96389       48163+  de  Dell Utility
/dev/sda2   *       96390    39005819    19454715    7  HPFS/NTFS
/dev/sda3        39005820    39214664      104422+  83  Linux
/dev/sda4        39214665   625137344   292961340    5  Extended
/dev/sda5        39214728   625137344   292961308+  8e  Linux LVM

# vgscan
  Reading all physical volumes.  This may take a while...
  /dev/mapper/encpv1: read failed after 0 of 1024 at 1266089984:
Input/output error
  /dev/mapper/encpv1: read failed after 0 of 1024 at 1266155520:
Input/output error
  /dev/mapper/encpv1: read failed after 0 of 1024 at 0: Input/output error
  /dev/mapper/encpv1: read failed after 0 of 1024 at 4096: Input/output
error
  /dev/mapper/encpv1: read failed after 0 of 2048 at 0: Input/output error
  /dev/vg/lv1G: read failed after 0 of 4096 at 1262419968: Input/output
error
  /dev/vg/lv1G: read failed after 0 of 4096 at 1262477312: Input/output
error
  /dev/vg/lv1G: read failed after 0 of 4096 at 0: Input/output error
  /dev/vg/lv1G: read failed after 0 of 4096 at 4096: Input/output error
  Found volume group "VolGroup00" using metadata type lvm2

(Note: /dev/mapper/encpv1 and /dev/vg/lv1G refer to a physical volume and a logical volume respectively which I created on a test disk recently.)

Because "cryptsetup luksOpen ..." didn't work, I didn't think the rest of the commands you mentioned would work. But it seems they do, even when "cryptsetup luksOpen ..." fails. So...

# blkid /dev/mapper/*
/dev/mapper/VolGroup00-LogVol00:
UUID="aa98849e-f2fe-42b5-b28e-6df9230ebac8" TYPE="ext3"
/dev/mapper/VolGroup00-LogVol01: TYPE="swap"

# blkid /dev/sd*
/dev/sda1: SEC_TYPE="msdos" LABEL="DellUtility" UUID="07D4-0612" TYPE="vfat"
/dev/sda2: TYPE="ntfs"
/dev/sda3: LABEL="/boot" UUID="3043a9bc-cee8-4e8f-8f96-5725ad0a5db1"
SEC_TYPE="ext2" TYPE="ext3"
/dev/sda5: UUID="074c3369-bd66-4afa-97ad-973769aeb208" TYPE="crypt_LUKS"

Here's that grub menu entry again... in case someone no longer has that email:

title CentOS (2.6.18-238.12.1.el5)

        root (hd0,2)
        kernel /vmlinuz-2.6.18-238.12.1.el5 ro
root=/dev/mapper/luks-3d723b4f-0184-438d-9cb9-9ebff16e683a rhgb quiet
        initrd /initrd-2.6.18-238.12.1.el5.img

I can think of no reason for the mismatch. As said, all of this booted and ran fine until one evening when I put the system into hibernate; when I brought it back out of hibernate and was prompted for the two passphrases, I couldn't remember them. That was a week or so ago.

Is it in RH6/CentOS6?

Thanks, Milan

On Mon, Aug 22, 2011 at 06:33:30PM -0400, ken wrote:
[...]

[...]

It does. /dev/sda5 has a LUKS container at the start with one passphrase active. For password breaking attempts, it does not matter that there are some LVM mappings. I advise to just ignore any LVM stuff for the moment and to run your password guessing attempts against /dev/sda5.

You will possibly not get you data, but the password checking will be good, unless that thing was created using decrypt_derived or the like. I doubt that, as then you should have been asked only for one password.

Once you have the password recovered, you should be able to do a normal boot.

Arno

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
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 

Thanks! That's good news. I was specifically worried that my running "cryptsetup luksOpen /dev/sda5 name" might not be accessing what it should... and so that it would *never* succeed, even with the correct passphrase.

Once I determine the correct passphrase (big hopes... I've already tried a lot of them), I can take the drive out of the enclosure and install it back in its original machine. It should then boot properly. (This is Plan A anyway.) :)

Best regards to all,
ken

War is a failure of the imagination.
        --William Blake

With this command, cryptestup is going to look exactly at the start of /dev/sdb5 and nowhere else. If you want it to look anywhere else, you need to specify.

As I said before, any booting magic is with your distro and not cryptsetup. That means you have to recreate any such magic (as starting LVM, for example) in order for cryptsetup to work and you have to gve cryptesup the right partition, physical or remapped, possibly with offset if the distro "magic" does that if you actually want to open the LUKS container.

If you just want to find the paswort, you can go a simple way:
1. look for the physical location of the header(s)
2. copy it off to a loop-mounted file
3. try luksOpen on that.
This will not give you your data,
but will allow the testing of passwords, as cryptsetup does not care where the header is, just that it gets told where it is.

Header length and how to use a loop-mounted file with cryptestup are in the FAQ. The header has the magic string {'L', 'U', 'K', 'S', 0xBA, 0xBE } at the beginning. This should typically be right after a sector border. You can search for that, copy 2MiB off (just in case it is XTS) and try with that in said loopfile.

A very simple (but slow) way to find a LUKS header uses grep like this:

cat /dev/sdb | hd | grep "4c 55 4b 53 ba be"

This gives you the binary position of all LUKS headers with respect to the disk start.

To copy it off, you can use, e.g. dd_rescue as below, and assuming luksfile is a 100MB file described in FAQ item "How do I use LUKS with a loop-device?". Do not losetup or cryptsetup ist before adding the header! Do the losetuop afterwards and the cryptsetup then for the trial luskOpen.

  dd_rescue -s <offset found above, converted to decmal> \
            -S 0 -m 2M  /dev/sdb  luksfile

Don't do that with the original, it is far too easy to damage it by messing up the dd_rescue command and overwriting the headers insted of copying them. The rest should be fairly safe.

Arno

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
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 

And this is how I would hope it would operate. I just need to know where to tell cryptsetup to look. How do I find that out?

The term "boot" covers a lot, so you and I might be thinking of different things. I consider "booting" everything from when a system is powered on to when the init scripts are finished and the user is prompted for ID and password.

And perhaps I should have been clearer a few emails ago about encountering the problem and its context. Let me try again:

This disk which I'm locked out of boots fine until I'm asked for the passphrases. Because I don't know them, it can't boot any further. The boot process stops there. That is, when I turn the machine on, the (unencrypted) /boot partition is mounted and the boot partition is displayed. This is a dual-boot (actually multi-boot) system, so a boot menu is displayed from which I can select which system to boot. When Linux is selected, the root (/) filesystem needs to be mounted. But this is encrypted, so I'm prompted for a passphrase. I don't know it, so the booting of the system stops there. So I don't believe booting is in any way a part of the problem per se.

Moreover, because it was cumbersome to try possible passphrases (and because I couldn't use the non-booting system), I took out the drive, installed it in a hardware enclosure, and attached it to another Linux machine. In this hardware configuration booting is no longer an issue.
I simply need to access the encrypted partition and mount it. It
doesn't need to boot. Even though the partition contains system files, the entire filesystem can simply be mounted like a data drive. Indeed, this is what I have done with the (unencrypted) /boot partition. So for this reason too, the boot process cannot be said to be the source of the problem.

This procedure below sounds interesting. And, yes, all I want to do is determine what the passphrase it.

Thanks, Arno. Currently I have a script which basically does this:

echo -n "$PossiblePassphrase" |cryptsetup luksOpen /dev/sda5 name1

I don't understand, what benefit would be derived from creating a loopfile? Is there something wrong with using my "echo -n ..." command on the partition as it is on the original drive itself?

[...]

Looks like the best approach at this time.

No. Loopfile is just a proposal for when your LUKS header is not at the start of a partition. You could also specify an offset to LUKS. As it is, no need to go that way.

Arno

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
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