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

[ken <gebser@mousecar.com>]

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?