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