Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 16 Jun 2015 11:34:04 +0200
From: Frank Dittrich <>
Subject: Johnny test feedback (was: Mathieu's weekly report #7)

Mathieu, Shinnok,

On 06/16/2015 05:38 AM, Mathieu Laprise wrote:
>  Accomplishments :
> 1) Since Shinnok and I changed a lot of code (and added threading) in
> Johnny since the beggining of GSOC, I wanted to take some time to deeply
> test normal use-cases of Johnny to prepare for our first summer release
> (planned around june 27th).

May be you should encourage others to test the latest github version, to
get some feedback prior to the release.

I did a
$ git clone
on a 64bit Fedora 22 system.

Latest johnny commit is c474084de8e521dd123750933334391cd3be5f48.

I installed qt5-qtwebkit-devel and built johnny (qmake-qt5; make -s).

I also collected all the test hashes into a sample file to test cracking:
$ ./john --list=format-tests |cut -f 3 | grep -n "^" > hashes

When I run ./johnny from the command line, I get a warning which is
probably harmless, but might confuse some users:
libpng warning: iCCP: known incorrect sRGB profile

I adjusted the settings, changing the path  of the John the Ripper
executable from /usr/bin/john to the latest bleeding-jumbo binary.

Then  I loaded the password hashes by clicking on the "Open Passwd File"
I must admit that I find the term "Passwd File" somewhat confusing
(because the file contains hashes, not passwords), but that term matches
john's usage output:

I like the "Formats" column, indicating that the hashes I collected into
the sample are indeed a mix of varying hash formats.

What I like less is that pressing the "Start Attack" icon just starts
john without any options, cracking just the descrypt hashes, ignoring
all the other hashes.
May be the user should be forced to pick a hash format. (After all, you
already know that there are many different formats in the file, you
don't need to parse ./john's stderr output...)

The user has to switch to the console log to see all the warnings.
The console log also shows that john immediately finds the passwords of
two users (5 and 5875; the same hashes, once for descrypt, once for
crypt, using an empty password).

I must admit that I noticed the "Open Last Session" icon only after
starting johnny several times.
That's why, resuming the work seemed to be rather complicated.
When I paused the attack, closed johnny, and restarted johnny, I would
have preferred johnny to load the previously loaded hashes, may be after
automatically parsing the .rec file of the default session.
Instead, I did re-load the hashes manually. I couldn't even pick from a
list of previously used files, but has to navigate through the file system.
Also, the "Resume Attack" icon was not active until I opened the same
"Passwd File" again.
Instead of automatically loading the hashes when restarting johnny, the
"Resume Attack" icon could be active of no password hashes are loaded,
and when pressing it, johnny could automatically load the password
hashes after parsing the .rec file of the default session.
I would prefer getting rid of the "Open Last Session" icon if johnny
would just do "the right thing". But please ask for input of other users.

There is no indication that the passwords of two users have been
cracked. The status bar is just showing "0%".
(After I restarted johnny several times, I noticed that it also prints
the number of guessed passwords, so may be I just didn't wait long
enough when I noticed that the number of cracked passwords was not
indicated on the status line.)

The fact that both "users" used empty passwords doesn't help to indicate
which hashes had been cracked.
May be you need to somehow indicate that the password has been found
even if the password is empty (or consists of a sequence of spaces).

I admit I didn't look at your release schedule, so I don't know what
kind of features you want to implement.
I just wanted to share what I think could cause trouble for users.
Feel free to ignore it or to address it after the first release.


Powered by blists - more mailing lists

Your e-mail address:

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