Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Oct 2014 00:19:41 +0400
From: Aleksey Cherepanov <>
Subject: Re: [RFC] Johnny further development proposal

Hi Shinnok,

I am sorry for so late reply.

On Wed, Oct 08, 2014 at 09:58:27AM +0300, Shinnok wrote:
> My current plan for Johnny as promised. I should probably add this to some
> Wiki page, not sure if I still have access there.

I guess that your credentials for the wiki should work. Otherwise you
could make new easily.

> Comma's added where I
> really need suggestions/feedback from you guys.
> Immediate tasks:
> 1. Upgrade to Qt 5

Debian stable does not have qt5 yet. Could Johnny be compatible with
both qt4 and qt5?

> 2. Fix any outstanding bugs or crashes (crash on exit while john is running,
> pause not working, etc..)
> 4. Support for OS X and distribution package (DMG package, should probably
> include JtR)
> 5. Ui improvements (hide progress bar when not needed, better sidebar
> navigation, proper layout constraints so that UI elements look nice, e.g.
> the button's in the Settings page are a mile long, etc..)
> 6. Windows support and distribution package either:
>   a) .msi if it makes sense, will have to include JtR since I don't think
> there is one for it
>   b) just .zip package would do
> 7. Make proper .deb package for Linux with CONTROL file that specifies:
>   a) ARCH
>   b) Qt dep
>   c) JtR dep
>   d) app description
>   Maybe Kali have done that properly for their package so we could use that
> as a reference.

I made .deb and .rpm files for 6 most popular distributions in 2012.

Packages are on the wiki.

It is my fault that CONTROL/spec files are not there (and not in
repo). Though I've used one binary for all packages (so .rpm was not
built from "sources") due to incompatibility between qt 4.8 and qt

> 8. The progressbar doesn't really say much currently. Percentage of cracked
> password could just as well be shown as numbers.

I just did

git clone
cd johnny

loaded some file with hashes and it shows something like:

0% (0/2657: 0 cracked, 2657 left) []

Though it is not a status line from john, it is internal statistics
over full set of hashes loaded into johnny.

> Maybe we should switch the
> progress bar to showing either:
>     a) how much till cracking completion (if JtR can estimate that, per
> cracking mode type would be fine too)
>     b) ??

I'd show how much of the hashes were loaded and are under attack now
(maybe cracked, left from them too).

Current jumbo shows guesses per second too.

> 9. Manual plain-text probing for individual hashes
> 10. Hash type suggestion/guessing for individual hashes
> 11. Critical JtR integrations

What do you mean by #11?

> Things for later:
> 1. Further JtR integration (need suggestions)
> 2. JtR pro integration

Mmm, "pro"? Do you mean jumbo? (Though jumbo is not "pro")

> Things for way later:
> 3. Support multiple cracking sessions, not sure if this can be done now by
> just running multiple Johnny apps. The best option would be multiple tabs,
> but if multiple apps would work just as fine I'd be contempt with just that
> for now.
> 4. Remote cracking sessions, most people that are going to do heavy usage of
> JtR like a "pro" are not going to crack on the everyday machine where they
> run Johnny too, but on remote always on headless power beasts, so a cool
> feature would be for Johnny to be able to tap(securely) on such remote
> sessions from a remote PC. This needs to be researched and discussed on the
> lists before anything can be done. What I think the easiest option would be
> to be able to use ssh pipes to either direct JtR ttys or some log file(no
> interactivity for this option). Separate watcher daemon is another more
> complex alternative.
> 5. Translation support?
> 6. Dictionary editing and generation based on interactive rule sets?
> 7. Post-cracking statistics regarding the frequency of passwords, characters
> and lengths, would be nice. Provided in the statistics pane.


> Goals to keep in mind for the future:
> 1. Maintain default operating system UI looks, until otherwise needed.
> 2. Simplicity over complexity.
> 3. The UI needs to give people reasons to use it, otherwise they'll just
> skip it.

#3 is interesting. I don't use Johnny myself. I am not sure about
goals of Johnny. Should it be easy and limited? Or should it be all in
tool that does not hide complexity of cracking? Or should we just make
john easier (things like batch mode aka default behaviour) and easy
gui? Of course, Johnny should make things easier. But what should be
made easy earlier?

When could next release occur in your opinion? What features should be


Aleksey Cherepanov

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.