[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fe28e11e3a6a7b7fb521e7c874756211@smtp.hushmail.com>
Date: Thu, 4 May 2017 23:27:15 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: Max characters for password candidates (NTLM) and
others
On 2017-05-04 23:00, Rob Fuller wrote:
> After checking
>
> ./john --list=format-details --format=nt
> NT 81
>
> (thx Solardiz)
>
> I tried cracking a known pass/hash combo:
>
> Password: Onceuponatimeinepisode5season2
> NTLM Hash: CB4D7AFFB476FD9B39A1447C1A66B564
>
> And it didn't work. Posted here:
> https://github.com/magnumripper/JohnTheRipper/issues/2529
>
> Anyone know what I might be doing wrong?
This is not really a bug, it's more of a quirk. The NT formats have a
max length of 27 *characters* (for performance reasons). That is true
even with Unicode characters, since the format uses UTF-16 internally.
The problem is that in order to get 27 Unicode characters we might need
(up to) 81 *bytes* of UTF-8 input, so in case you run
--input-encoding=utf8 (which is the default now), that is what we set.
Most of legacy john code can't tell the difference between bytes and
characters, and the result is what you see. We're pretty much stuck with
this problem.
The only way to solve all Unicode issues with all crackers (including
but not limited to JtR and hashcat) would be (I think) to re-write them
from scratch, and treating all strings as UTF-32 internally, almost
everywhere. When we're at it, I'd also use "pascal strings", that is,
store length first. That would come very handy in many situations and
speed things up. The end result would, I believe, not be significantly
slower than current code, only better. In some cases it'd be quite a lot
faster but in some cases we'd blow caches and get a regression.
magnum
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.
