Re: recovering forgotten passwords for 2 LVs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux