This shows you the differences between two versions of the page.
john:joan [2012/05/01 23:07] aleksey fixed formatting, not yet right, but looks quite well |
john:joan [2012/05/15 17: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 | + | |
- | + |