[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3839f932ecfe001c41738ae27041c998@smtp.hushmail.com>
Date: Wed, 14 Sep 2016 22:29:23 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: Error: wordlist contains NULL bytes - aborting
On 2016-09-14 21:51, Patrick Proniewski wrote:
> On 14 sept. 2016, at 21:37, Frank Dittrich wrote:
>
>> "cracking" SHA1 hashes of random garbage bytes are hardly a use case
>> john should support, IMHO.
>>
>> Is there any system which really accepts random bytes including line
>> feeds and null bytes in passwords?
>> How do you enter such passwords as a user? And even if you can, should
>> you ever do this?
>>
>> How would you know (as a user who didn't audit the system in use) that
>> the system will not silently convert your
>>
>> "pass\0word" into pass?
>
>
> There are use case for this kind of exotic passwords: internal passwords, service accounts, etc. If you have coded the application you can make it support this kind of oddities.
There's no problem at all writing a cracker that can handle null bytes.
Hashcat does, but JtR doesn't. The legacy core code doesn't, the pot
file format doesn't, and so on. "Fixing" that would be a HUGE task for a
next-to-none benefit, it just wont happen. There could be some
performance benefits of using "pascal strings" though, passing lengths
between functions instead of repeatedly doing strlen().
I'd like to point out there is one "exception" though: UTF-16 passwords
that have null *bytes* as part of their 16-bit *characters* (eg. the
upper half of ISO-8859-1) obviously work just fine. That's because all
internal handling as well as the pot file entry will be using a codepage
or UTF-8 encoding.
BTW technically we could cheat and add support for null bytes by
allowing MUTF-8 (see https://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8)
throughout core with VERY little changes (shared code), which would make
it work just fine right up to each format's set_key() function. But then
we'd need to add a little decoding to each format that we want able to
use it. This could be implemented if there would be popular demand for
it - but I really doubt many people would need it.
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.
