Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 11 Feb 2018 19:56:58 -0500
From: Matt Weir <>
Subject: Re: Reading salt that contain semicolum

Hi Jeroen,
   This is a pretty common problem, and unfortunately until you run
across it it's hard to find the solution, so I'm glad you asked :) The
solution is in the John the Ripper documents in the DYNAMIC file. I'm
going to quote the relevant part:

Salts can contain some problematic characters. Some of these would be
characters such as: : \r \n \ NULL, etc. The : (colon) char is used
by JtR as a field separator. If it exists in the salt, it will split
the salt into multiple fields (i.e. wrong). A carriage return or line
feed, will cause the line to split, and JtR to not read it right.
NULL bytes are a problem in any C file, using normal 'string' functions.
The \ char, is used as a quoting char within dynamic, and can cause issues.
One other recently found issue, is if the salt ends in ' ' or '\t' (space
or tab), then if the dyna hash is placed on a line by itself (i.e. without
a user: prepended), then jtr will trim the whitespace off. This is a known
issue, and this is just a bad side effect of a known wanted behavior where
the raw hash files are cleaned up during processing.
DUE to all of these problems, dynamic has been expanded to take this as
the salt: $dyanamic_#$base_16_hash$HEX$hex_bytes_of_salt. In this
format, if the salt was 1234, then $HEX$31323334 would be the equivalent
value. This allows salts such as $\x0:\r\nBadSalt to actually be encoded.
This salt CAN be used, if you use the representation:
There is an application in ./run which can 'help' This is ./run/raw2dyna
This process will convert files in the format of hashCsalt (c can be any char),
into the proper $dynamic_#$hash$salt It can also handle saltChash (if
salt is a fixed size). It also properly handle the problematic characters,
and uses the $HEX$hex_salt method, if there are bad characters in the salt.

Good luck, and I hope this helps!


On Sun, Feb 11, 2018 at 3:11 PM, Jeroen <> wrote:
> Jeroen wrote:
>>Some hashing algorithms use salts that might - and do in some cases - contain
>>semicolums. John seems to do some magic, effectively skipping the hash.
>>bofh@...:~$ echo
>>'0123456789abcdef0123456789abcdef$123456789012345678901234567890' > /tmp/hash
>>bofh@...:~$ /opt/JohnTheRipper/run/john --format=dynamic_2006 /tmp/hash Using
>>default input encoding: UTF-8 Loaded 1 password hash (dynamic_2006
>>[md5(md5($p).$s) (PW > 55 bytes)
>>256/256 AVX2 8x3])
>>Warning: no OpenMP support for this hash type, consider --fork=8 Press 'q' or
>>Ctrl-C to abort, almost any other key for status 0g 0:00:00:03  3/3 0g/s
>>383538p/s 383538c/s 383538C/s bilbark..107969 Session aborted bofh@...:~$ echo
>>'0123456789abcdef0123456789abcdef$1234567890:2345678901234567890' > /tmp/hash
>>bofh@...:~$ /opt/JohnTheRipper/run/john --format=dynamic_2006 /tmp/hash Using
>>default input encoding: UTF-8 No password hashes loaded (see FAQ) bofh@...:~$
>>Is there a workaround? HEX$ encoding the salt doesn't seem to be successful.
> To prevent misunderstandings: the salt can contain any ASCII 7-bit character. In large sets all ASCII printable characters are present. So --field-separator-char doesn't work without introducing issues with for salts. Using a field separator of an 8 bit value that is not used in the salts, e.g. 0x80, results in a 'trying to use an invalid field separator char: € (must be single byte character)'.
> Thanks,
> Jeroen

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ