Table of Contents

MJohn - collaboration tool for John the Ripper

MJohn stands for Multi-/Massive-/Mega-/Meta- John the Ripper.

(At the beginning it was known as automation equipped working place of a hash cracker and as Joan the Helper for John the Ripper.)


MJohn is a set of helpers for John the Ripper to support collaborative audits. It is not yet implemented. Below you will find proposal for the task with timeline for summer. Currently as proposed by Aleksey Cherepanov.


Problem description

While John the Ripper is the major password security auditing tool it could be significantly improved adding worlflow oriented features. There are common patterns of JtR use. There is a lot of them and they are quite high level and small but could be combined to improve effectiveness of attacks. So they are not in JtR itself but exist on the lists in some form (script or just description).

So I propose to collect such patterns, workflows, to improve them and to make consistent environment for their use. (I partially proposed something similar as a part of JtR: GUI project but it was rejected to keep GUI simple and to provide non-GUI users with the same features set.)

CrackMeIfYouCan 2011 was a hard contest that showed me that there are some problems in mass cracking workflow. That problems are not limited just to that contest, they are in real life too. That's why I would like to develop a tool that helps to avoid that problems.

There are different kinds of victory requirements: high personal skills of members, easy collaboration, easy distribution, big rough hardware power, fast cracking software, good workflow to make cracking intelligent.

All of these factors could be improved by software and/or preparation. For instance, high personal skills needed to write john rules could be lowered using helper software with tips, ability to try new rules easily, rules auto creation or assistance based on examples. Easy collaboration could be achieved using special software with social features like collaborative attack editing, voting for attacks to be used, easy reviewing. And so on.

I would like to emphasize social (wiki-like) features to improve collaboration and transparent fully automated distribution. Also I would like to see helper scripts for attack development there.

I have developed some scripts to help in password patterns search and quality measurement after the contest. Announce:

I think such tool should be interesting any auditing company bigger than one man with one computer.

Key Features


I would like to offer system for collaborative hash auditing consisting of following parts:

communication and statistics calculation,

development of attacks (being lucky they will include helpers for pattern search).

All will be connected as shown below.

        user- wrapper - john
            \ |
other users -server

or with distribution

        user- wrapper - john on remote machine or machines
            \ |
other users -server

So user uses wrapper to call john. Before attack wrapper synchronizes user's setup with the server: downloads input files for that attack and uploads current john.pot. Then wrapper uploads information about attack including keys, configuration file, wordlist (for wordlist mode) and so on. Then wrapper starts john and periodically sends progress and speed info to the server, also it sends cracked passwords. All information is stored on the server and available through its ui. Through server's ui users talk, discuss attacks and coordinate right near description of attack.


The following is my plan. Any point should take about 1 week of work.

April 25 - May 20 (Before the official coding time):

try to create wrapper

decide how our system should look like, to try to build server part

Result of bonding period is a draft implementation.

May 21 - June 20

Result: wrapper that is a transparent proxy around john, so when user calls it behaves like normal john but under the hood it takes cmd line arguments, configuration file and send it to the server (in the future, at this point it calls dummy function to send).

Result: timer in wrapper that collects progress information on every tick and sends it to the server (again dummy). Here approaches are similar to progress collection in Johnny: it is not finished there but discussed.

Result: preamble in wrapper that synchronizes files with server. It could be done as of it is about files. So there is a file structure on the server where hashes, john.pot are laid, preamble upload updates and download only interesting updates (there could be too much) before every command.

ui specific for attacks

Result: simple web ui like blog or forum or bug tracker where there are entries, comments on them, some kind of chat.

June 21 - Jule 20


Result: when wrapper sends attack information it is reflected in web ui: relative entry is marked or added.

Result: separate part of web ui that shows statistics about entries like overlap of attacks, their effectiveness.

Result: easy to install package, maybe live cd.


Result: addition to wrapper that dispatches john remotely (over ssh) so wrapper becomes a central server for user's cluster.

Jule 21 - August 5

with development this testing should make proposed software really robust

So there could be time for unexpected delays. Though I would like to spent it onto additional functionality (also 1 week per point):