Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 May 2017 23:27:15 +0200
From: magnum <>
Subject: Re: Max characters for password candidates (NTLM) and

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:
> 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.


Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.