Joan the Helper for John the Ripper

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

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: http://www.openwall.com/lists/john-users/2011/08/09/3

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

• Comfortable and not confusing user interface design
• Collaborative attack development and decision making
• Easy attack and decision review
• Advanced statistics to help in decision making
• Easy deployment
• Transparent distribution
• Easy cluster building
• Support in search for password patterns
• Support for rule auto generation

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

• server part with user interface (ui, probably web ui) for attacks tracking,

communication and statistics calculation,

• client scripts around John the Ripper for tracking,
• and variable amount of client scripts to help in different ways in

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.

• To research different synchronization mechanisms (rsync, git, other), to

try to create wrapper

• To find and compare different premade solutions for collaboration and

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

• To consider what statistics are important, to experiment with them
• For unexpected research

Result of bonding period is a draft implementation.

• To develop part of wrapper around john to send attack description

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).

• To develop part of the wrapper to send progress information

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.

• To attach synchronization mechanism to the wrapper

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.

• To adopt premade solution for collaboration and to develop part of server/

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.

• To develop server part to receive and show attack's description and

progress

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

• To develop server part to show advanced statistics

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

• To pack client side into a bundle for easy deployment

Result: easy to install package, maybe live cd.

• To develop simple distribution system to involve all hardware at least

suboptimal

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

• To test everything well: while simple testing and debugging will be done

with development this testing should make proposed software really robust

• To fix bugs and problems revealed during testing

• adoption of existing tools (like fstrcmp) to search patterns
• scripts for initial testing of speed on client side
• autobuilding tool to take most from the hardware
• packaging of server side
• extensive documentation