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

[Arno Wagner <arno@wagner.name>]

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