[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090121133152.GA6959@openwall.com>
Date: Wed, 21 Jan 2009 16:31:52 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: cracking dm-crypt
On Fri, Jan 16, 2009 at 04:11:15PM +0100, Stefan X wrote:
> I forgot my password of an encryption Linux partition (dm-crypt without
> LUKS) and would like to use JtR to crack it. I am new to JtR and am
> happy about some guiding by you experts.
>
> Because it is a partition I don't have any hash available which could be
> used easily with JtR. Thus I see two ways:
>
> 1) Extract a kind of hash from the partition; but I don't know how. Is
> there any kernel hacker who could give me input on how to do this?
When you're encrypting data, there's normally no hash of your passphrase
stored anywhere, although such a hash may be produced temporarily in
order to generate a fixed size encryption key out of your passphrase.
However, you obviously don't have to be in possession of this
intermediary hash in order to try candidate passphrases against your
encrypted partition. Instead, you may have a program attempt decryption
of a block of data with each candidate passphrase (generating the
intermediary hash and encryption key from that passphrase in the
process), then have it try to make sense of the decrypted data (e.g.,
see if it looks like a valid filesystem superblock or garbage).
I am not aware of anyone having implemented this as a JtR "format" yet,
although that is quite possible to do (indeed, a separate implementation
would be needed for every encrypted partition solution out there, etc.)
As it relates to having JtR crack encryption keys and analyze the
decrypted data (albeit in a trivial way), this concept can be seen
implemented in KRB5_fmt.c in the jumbo patch.
Alternatively, this can be implemented in a standalone program, and that
program may be fed the output of "john ... --stdout" via a pipe.
> 2) Instead I would need to try to mount the partition with each
> potential password. Unfortunately this would be quite slow.
Yes. That way, you don't limit the amount of data decrypted each time
to the necessary minimum, you have the kernel verify the decrypted data,
you incur overhead (syscalls, etc.), and you don't optimize the key
setup code for trying many candidate passphrases repeatedly. Indeed,
this will be slower than the approach I described above, but it might be
easier for you to implement.
> For my
> understanding the "external mode" of JtR is exactly for such purpose.
No, it has nothing to do with that. It is a way for you to "externally"
program JtR for trying specific kinds of candidate passwords.
> I could define a few commands to mount the partition and handle the
> result (success or failure).
You'll need to do this in your own program, perhaps written in some
scripting language such as Perl. If you like to have JtR generate the
candidate passwords for you, then you may feed the output of
"john ... --stdout" into your script.
> Unfortunately I did not found much information
> about such approach. Is there any more documentation about it than the
> official docs?
No. The "--stdout" option is documented. "External mode" is just not
it. I'm not sure how the documentation can be improved in this respect -
it would be unreasonable to list all things that "external mode" does not
do, just to state that it does not do those.
> Please let me know if my assumptions are correct and which advice you
> have for me.
Speaking of advice, unless you know/recall something about your
forgotten password or passphrase, or it was a weak one, you're most
likely out of luck cracking it. So you absolutely need to use whatever
knowledge you have in order to limit the search space and/or try more
likely guesses first.
Also, there's a small chance/risk of your passphrase or the encryption
key having been stored somewhere on your system - it could be on disk or
in your DRAM chips maybe. It is generally quite costly to check for
this as it requires time of someone experienced to do it.
Good luck!
Alexander
--
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
