[dm-crypt] recovering forgotten password

[dm-crypt] recovering forgotten password

[ken]

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.

Re: [dm-crypt] recovering forgotten password

[Arno Wagner]

On Wed, Aug 17, 2011 at 01:44:44PM -0400, ken wrote:
> Having searched through the archives and read the FAQ list, I know this

Good. Forst step done right.

> 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.

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


> I also tried for device /dev/sda ... still no go.
> 
> 
> Or is there a better way to input my passphrase guesses...?
> 
> 
> tnx.
> 
> 
> 
> _______________________________________________
> 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
----
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 

Re: [dm-crypt] recovering forgotten password

[Arno Wagner]

On Wed, Aug 17, 2011 at 09:35:13PM +0200, Arno Wagner wrote:
[...]
> To try a password, use somethin like
>   cryptsetup luksOpen /dev/sda3

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


> 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

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: arno@wagner.name 
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 

Re: [dm-crypt] recovering forgotten passwords for 2 LVs

[ken]

On 08/17/2011 01:44 PM ken wrote:
> 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....

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

Re: [dm-crypt] recovering forgotten passwords for 2 LVs

[Yves-Alexis Perez]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On lun., 2011-08-22 at 10:48 -0400, ken wrote:
> 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? 

/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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [dm-crypt] recovering forgotten passwords for 2 LVs

[Arno Wagner]

On Mon, Aug 22, 2011 at 10:48:54AM -0400, ken wrote:
> 
> On 08/17/2011 01:44 PM ken wrote:
> > 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....
> 
> 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?

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: arno@wagner.name 
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 

Re: [dm-crypt] recovering forgotten passwords for 2 LVs

[ken]

On 08/22/2011 12:19 PM Yves-Alexis Perez wrote:
> On lun., 2011-08-22 at 10:48 -0400, ken wrote:
>> 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? 
> 
> /dev/sdb5 doesn't look like a logical volume. Are you sure you activated
> the volume groups before.

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 don't have a clue what your setup is, 

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/(?).


> but it might just be that you
> need to run
> 
> vgchange -ay <vgname>

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'


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

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.

Re: [dm-crypt] recovering forgotten passwords for 2 LVs

[Milan Broz]

On 08/23/2011 12:33 AM, ken wrote:
> 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

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

Re: [dm-crypt] recovering forgotten passwords for 2 LVs

[ken]

On 08/22/2011 06:53 PM Milan Broz wrote:
> On 08/23/2011 12:33 AM, ken wrote:
>> 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
> 
> No. vgdisplay does not take physical path as argument, this
> command must fail. (but io errors indicate something more
> serious - what exactly it says?)

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


> 
> 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

# 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.

> 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

Thanks, Milan.

Re: [dm-crypt] recovering forgotten passwords for 2 LVs

[Yves-Alexis Perez]

On lun., 2011-08-22 at 20:23 -0400, ken wrote:
> Since I don't know the passphrase for the command above, I can't do any
> of the rest of these commands.

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

Regards,
-- 
Yves-Alexis

Re: [dm-crypt] recovering forgotten passwords for 2 LVs

[ken]

On 08/23/2011 03:43 AM Yves-Alexis Perez wrote:
> On lun., 2011-08-22 at 20:23 -0400, ken wrote:
>> Since I don't know the passphrase for the command above, I can't do any
>> of the rest of these commands.
> 
> Please provide the results of blkid /dev/sd* (and vgscan too).
> 
> Regards,

# 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.)

Re: [dm-crypt] recovering forgotten passwords for 2 LVs

[ken]

On 08/22/2011 06:53 PM Milan Broz wrote:
> On 08/23/2011 12:33 AM, ken wrote:
>> 
> ....

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...


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

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


> 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.

# 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.


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

Is it in RH6/CentOS6?


Thanks, Milan

Re: [dm-crypt] recovering forgotten passwords for 2 LVs

[Arno Wagner]

On Mon, Aug 22, 2011 at 06:33:30PM -0400, ken wrote:
[...] 
> 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
[...]

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: arno@wagner.name 
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 

Re: [dm-crypt] recovering forgotten passwords for 2 LVs

[ken]

On 08/22/2011 01:16 PM Arno Wagner wrote:
> On Mon, Aug 22, 2011 at 10:48:54AM -0400, ken wrote:
>> On 08/17/2011 01:44 PM ken wrote:
>>> 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....
>> 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?
> 
> 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.

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?


> 
> 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.

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.

> 
> 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

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?

Re: [dm-crypt] recovering forgotten passwords for 2 LVs

[ken]

On 08/23/2011 08:57 AM Arno Wagner wrote:
> On Mon, Aug 22, 2011 at 06:33:30PM -0400, ken wrote:
> [...] 
>> 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
> [...]
> 
> 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

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

Re: [dm-crypt] recovering forgotten passwords for 2 LVs

[Arno Wagner]

On Tue, Aug 23, 2011 at 09:17:43AM -0400, ken wrote:
> On 08/22/2011 01:16 PM Arno Wagner wrote:
[...]
> >> is cryptsetup going to be talking to one or the other encrypted LVs...?
> >> and if so, which one?
> > 
> > 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.
> 
> 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?
> 
> 
> > 
> > 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.
> 
> 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.
> 
> > 
> > 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
> 
> Thanks, Arno.  Currently I have a script which basically does this:
> 
> echo -n "$PossiblePassphrase" |cryptsetup luksOpen /dev/sda5 name1

Looks like the best approach at this time.

> 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?

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: arno@wagner.name 
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