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