Differences

This shows you the differences between two versions of the page.

Link to this comparison view

john:joan [2012/05/01 14:07]
aleksey fixed formatting, not yet right, but looks quite well
john:joan [2012/05/15 08:24] (current)
aleksey removed content because it is now located at mjohn page
Line 1: Line 1:
 ====== Joan the Helper for John the Ripper ====== ====== Joan the Helper for John the Ripper ======
  
- +Now it is renamed ​into [[mjohn]].
- +
-===== Description ===== +
-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. +
- +
-===== Proposal/​Timeline ===== +
- +
- +
-==== 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: 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. +
- +
-==== Key Features ==== +
- +
-  * 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 +
- +
-==== Deliverables ==== +
- +
-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. +
- +
-==== Timeline ==== +
- +
-The following is my plan. Any point should take about 1 week of work. +
- +
-=== April 25 - May 23 (Before the official coding time): === +
- +
-  * 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. +
- +
-=== May 24 - June 23 === +
- +
-  * 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. +
- +
-=== June 24 - Jule 23 === +
- +
-  * 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. +
- +
-=== Jule 24 - August 7 === +
- +
-  * 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 +
- +
-== So there could be time for unexpected delays. Though I would like to spent it onto additional functionality (also 1 week per point): == +
- +
-  * 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 +
- +
john/joan.txt · Last modified: 2012/05/15 08:24 by aleksey
 
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate to DokuWiki Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki Powered by OpenVZ Powered by Openwall GNU/*/Linux