Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5561B56D.4010504@gmail.com>
Date: Sun, 24 May 2015 13:26:37 +0200
From: Marek Wrzosek <marek.wrzosek@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Bleeding jumbo now defaults to UTF-8

W dniu 24.05.2015 o 06:17, Solar Designer pisze:
> On Fri, May 22, 2015 at 06:33:42PM +0200, magnum wrote:
>> On 2015-05-22 16:48, Marek Wrzosek wrote:
>>> That's a great news! What is the simplest way to "repair" all.lst from
>>> Openwall?
>>
>> I bet it's a mix of encodings so can't simply be converted.
> 
> Yes.  And maybe it should stay as a mix of encodings despite of magnum's
> change, because quite often multiple encodings may possibly have been
> used in target passwords.  I am worried that some lines are not valid
> UTF-8, though.  How do we ensure those are tested against the hashes
> verbatim, like core (non-jumbo) JtR would test them?  Will this just
> happen that way despite of the recent change of default in jumbo?
> 
> magnum, what do you suggest we do?  Simply assuming that e.g. md5crypt
> hashes are likely of UTF-8 plaintexts won't do.  Some of them might be,
> but some older ones might be iso-8859-1 or koi8-r or windows-1251 as
> well.  That's why current all.lst mixes all of these encodings together.
> 
> Alexander
> 
I understand why there are mixed encodings in all.lst and it should stay
that way but I don't think it's still possible to use this all.lst with
jumbo anymore, so maybe adding second "all.lst" list with only UTF-8
will do. The bad news is that in order to guess plaintext of hashes with
encoding different than UTF-8 using jumbo one will need to run jumbo
several times using different --target-encoding option. The good news is
that jumbo will display passwords correctly but unfortunately the
information about what encoding particular hash was using is gone (but
it's easy to guess, I think).
Changing defaults to UTF-8 also affects Incremental mode. Using
Incremental with Latin1 charset requires use of --target-encoding=cp1252
because otherwise passwords with Latin1 encoding will be written to
john.pot. Maybe jumbo should set target encoding automatically to cp1252
if Incremental with Latin1 is used.

Best Regards
-- 
Marek Wrzosek
marek.wrzosek@...il.com

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.