Moscrack 2.08b
Copyright 2011 Ryan Babchishin


1. Version info
2. Description
3. Supported software
4. Requirements
5. Installation
6. Usage
7. SSH and RSH modes
8. Aircrack-ng + Mosix?
9. Moscrack GUI
10. Hot config support
11. File access modes
12. Performance
13. Auto tuning mode
14. Moscrack monitoring tool 
15. Pyrit
16. Checkpoint and resume
17. Hang Detection
18. Dynamic node configuration
19. Node types
20. Plugins
31. API

1. Version info

This release contains a new plugin framework that allows Moscrack to be extended 
beyond it's original design. Currently there are only two plugins, Pyrit and 
Dehasher. I hope you are pleased. Please review release-notes.txt for details.

Further documentation, screenshots, downloads:

If you find any serious bugs please let me know as I don't want people to be 
disappointed. Since this release is beta, it means there could still be 
problems with it. You should check back for updates often as Moscrack is always 

SVN will always have the latest bug fixes and enahancements if you are looking 
for them.

SVN download:
svn co moscrack 

2. Description

Moscrack facilitates the use of a WPA cracker on a cluster. 
Currently it works with Mosix (clustering software), SSH, RSH and Pyrit. 
It works by reading a word list from STDIN or a file, breaking it into chunks 
and passing those chunks off to seperate processes that run in parallel. The 
parallel processes can then execute on different nodes in your cluster. All 
results are checked and recorded on your master node. Logging, 
error handling, etc... are all handled for you. Moscrack capable of running 
for long periods of time (days/weeks/months/etc...) reliably and without
risk of losing data or having to restart.

3. Supported software

See Requirements section below

4. Requirements

Master server:

Linux or possibly others
Mosix (optional)
zenity (GUI support)
Pyrit (optional)
rsh/rcp clients (optional)
scp client (optional)
Perl 5.8
Perl DateTime
Perl Math::Round
Perl Getopt::Lucid
Perl Acme::Tools
Perl Storable
Perl Term::ANSIColor
Perl File::Basename
Perl Sruct::Compare
Perl LWP::UserAgent
Perl HTTP::Request
Perl Net::SSH2
Perl Compress::Zlib
Perl Config::Std

End nodes:

Linux/Cygwin/FreeBSD/Solaris/MacOSX/iPhone all tested or Moscrack Live CD
One of Mosix, SSH v2 daemon, RSH daemon, Pyrit in serve mode
aircrack-ng v1.1 unless using Pyrit

5. Installation

This assumes you are using 'copy' file mode. If you want to know more
see "File access modes".

- Run ./install_modules to check for (and optionaly install) required Perl 
- Copy moscrack, mosctop, moscd, moscapid to anywhere you like, possibly in your 
  path like /usr/local/bin
- Configure your system to start moscapid and optionally moscd on startup
- Copy moscrack.cgi to your web servers cgi-bin (doesn't need to be on Moscrack master)
- Edit moscrack.conf and copy to /etc/moscrack/moscrack.conf
- Copy plugins/ to /etc/moscrack/plugins/
- Create a working directory (home) for Moscrack. e.g. /opt/moscrack/
- Edit nodes.dat and add all of your nodes and type. The format is documented 
  in the file. Copy it to where you specified in the configuration file.
- Start moscapid (needed my mosctop and moscrack.cgi)
- Tune nodes.dat (mandatory). See "Auto tuning mode" and optionaly 
  "Performance" for details.
- If using ssh nodes, setup public-key authentication with each node
  e.g. ssh-copy-id user@node
- If using rsh nodes, configure .rhosts file on each node
- Install aircrack-ng on each node (or pyrit see "Plugins")
- Make sure you can access all nodes (of any type) without a password
- Launch "moscd" if using dynamic nodes (see "Dynamic node configuration")
- Run "moscrack" (see Usage section)
- In another terminal, optionally run "mosctop" to watch what's going on
- Access http://yourserver/cgi-bin/moscrack.cgi to view CGI status interface

6. Usage

You start it like this: ./moscrack -c  -e  -w 

If wordlist is a "-", moscrack reads from STDIN. This allows you to use things
like word list generators such as john or crunch.

Ex. using a word list 

moscrack -c ./MYSSID-01.cap -e MYSSID -w mywordlist.txt

Ex. using john the ripper to generate incremental wordlist by piping to STDIN
john -i:WPA -stdout |  moscrack -c ./MYSSID-01.cap -e MYSSID -w - 

7. SSH and RSH modes

You can configure nodes of type "ssh" or "rsh". All they need to communicate with 
Moscrack is an ssh/rsh daemon. These modes are actually pretty useful even if you run 
a Mosix cluster. I use it for my 32 bit systems as my master is 64 bit. 

SSH mode requires that you use public-key password-less authentication and the
same user name on every node.

RSH mode requires that you configure the nodes .rhosts file to allow connections
from Moscrack as the same user on every node.

8. Aircrack-ng + Mosix?

Aircrack-ng is super fast but it uses threads. Mosix doesn't work with threads. 
So I made the decision to keep using Mosix because it's so easy to use and just 
run aircrack-ng in "Native Mode" (mosrun -E). In this mode, processes behave 
like they were spawned with rsh/ssh or something. They cannot be migrated and 
they cannot access resources on the home node. 

9. Moscrack GUI

Moscrack contains an experimental GUI. It hasn't been used/tested very much as 
I don't care much about GUIs. 

To launch the GUI, cd to the moscrack share and run it. It is important that it 
runs relative to the share that moscrack and related files reside in. You must
still load wordlists, etc... from that share only as the other nodes need to 
access it all.


$ cd /haze
$ ./gui

10. Hot config support

Moscrack allows you to add/remove/modify nodes on the fly while it is running. 
Just edit nodes.dat to your liking and save it. You'll see Moscrack notice the 
change and pickup/remove the nodes as configured. Chunk size will be recalculated
and chunk files resized as needed.

Hot config will not load plugins. They must be loaded at startup.

11. File access modes

Moscrack has two different ways to share files with nodes. They are "shared" 
and "copy" modes. The default file mode is "copy". 

To change the file mode, set "fileMode" in the configuration file. You can also 
specify the --filemode argument on the command line.

Shared mode:
-Shared storage is required, like NFS, SMBFS, whatever
-Master and nodes all access the same files

The advantage of Shared mode is that it could be much faster depending on your 
setup (direct IO shared filesystem, GigE). It also doesn't have the lag that 
SSH/RSH have when logging in, etc... 

Copy mode: 
-Files are copied to each node for processing as needed and then cleaned up

The advantage of "copy" mode is that it may work better with slow links 
(Internet) and requires less configuration of the node. Copy mode uses scp for 
ssh nodes, rcp for RSH nodes and Mosix pipes/IO for Mosix nodes.

12. Performance


Mosix nodes are the fastest for local and fast networks, because of reduced 
latency, no encryption, no login, direct pipes, etc... i.e. Mosix was made for 
this kind of thing.


Moscrack uses compression for file transfers in copy file mode on ssh nodes. 
Mosix can use it's own compression if you configure it. Copy file mode is 
probably best for slower links. Shared file mode will not use any compression 
unless your file sharing protocol supports it.

Network IO:

One thing you can do to reduce network IO and file transfer time is to extract 
the WPA handshake from your capture file. This will reduce the size of this 
file significantly. For example, I have one that is 1.3MB, but when extracted 
the resulting handshake is only 2.5KB. This can make a big difference for ssh 
nodes with copy file mode as they recieve a copy this file with every chunk. 
1.3MB could waste a lot of bandwidth and time during the lifetime of a long 
cracking session.

You can use the included shrinkCapFile script to extract the handshake from 
your capture file. It depends on tshark, the text version of wireshark.

Usage: shrinkCapFile 

A file will be created called -handshake.cap in the current 
directory. Use that file with Moscrack instead of the original capture file.

Node Multiplier and Chunk Size:

In the nodes configuration file you can specify a speed in keys/sec for each node. 
This determines how many chunks a node will receive at a time for processing. 
The base chunk size is set in the configuration file. 

Moscrack uses an algorithm to determine how many chunks a node gets. Each node's
speed is compared against all others, the slowest node is used as a baseline for
a "node multiplier". The slowest node gets multiplier value of "1" and every other
node gets a value representing it's speed as a multiple of the slowest node.

e.g. Node A = 500 k/s, Node B = 1200 k/s, Node C = 650 k/s

-Node A is the slowest, set to multiplier "1" and used as baseline comparison
-Node B is 2x faster than Node A, set to multiplier "2"
-Node C is not 2x faster than Node A, set to multiplier "1"

Each node gets MULTIPLIER chunks at a time. 

e.g. Using same nodes as above

Base chunk size settings in conf file: chunkSize = 100000

Node A gets 100000 words at a time
Node B gets 200000 words at a time
Node C gets 100000 words at a time

The advantage of the varaible chunk size approach is that faster nodes will come 
back around the same time as slower nodes for new chunks if tuned properly. This 
prevents fast nodes from wasting time fetching small chunks and slower nodes 
from holding up processing by faster nodes.

Tuning the chunk size and setting node speeds can provide a significant performance 

Auto-Chunksize Settings:

Moscrack has various methods of automatically determining the chunksize for you. 
These settings are documented in the sample moscrack.conf.


Moscrack has a special mode for automatically determining you nodes processing
speed. See "Auto tuning mode" for details.

Node Prioritization:

Based on the node speed setting, the fastest node free/available is always chosen 
to process a chunk. e.g. node1 has a speed of 1200 and node2 has a speed of 822
and both are free, node1 will be used first. When the time comes to process
another chunk, the list of available nodes is prioritized again. All nodes
will still be used, just starting from fastest to slowest.

13. Auto tuning mode

Moscrack can automatically determine your nodes processing speed using your 
nodes configuration file. To do this, pass the command line argument --tune.


./moscrack --tune -c tune.cap -w tune.words -e test 

You can specify specific nodes instead of doing the whole file:

./moscrack --tune -c tune.cap -w tune.words -e test -n -n

In the above example, tune.cap and tune.words are files in tuning/ 
sub-directory of Moscrack. They are intended for this purpose. The essid for 
tune.cap is 'test'. tune.words is 2000 lines and does not contain the key.
This ensures the whole word list is processed. You can use your own files,
but these are provided to make your life easier.

Upon completion, Moscrack will print out your nodes configuration with included
node speeds. It will also write this information to nodes.dat.tuned which you can 
rename and use as your nodes.dat.

How it works:

It works by reading nodes.dat and loading your configuration. It then executes 
aircrack-ng on each of your nodes using a small word list and capture file that 
does not contain the key. The whole word list will be processed and aircrack-ng 
will tell Moscrack how fast the machine was able to test the words. This 
measurement (keys/sec) is recorded per node. 

14. Moscrack monitoring tool

There are two tools 

Terminal application mosctop:

Moscrack includes a separate tool for monitoring it's activity. It displays
data in a fashion similar to Un*x "top", thus the name "mosctop".

Mosctop works by reading "status.dat", which is created and updated often
by Moscrack while it is running. It uses the data from the file to 
display the following things per node: name, last result, status, failure
count, throttle time left, PID of current process handling this node, chunk
file. It also displays the computation rate in words/sec and the amount of
data processed as a percentage.

To use mosctop, cd to the working directory for moscrack (where status.dat
is) and run it.

CGI inteface moscrack.cgi:

There is a CGI script that does basicaly what mosctop does, but a little
nicer looking. Just copy moscrack.cgi to your web servers CGI directory
and edit it, setting the value "my $statusFile = ".
the file status.dat is generated by Moscrack and will reside in your
Moscrack working directory.

15. Pyrit

Pyrit is an open-source WPA cracker that has the ability to process data
in parallel on multiple nodes (like Moscrack) as well as use CUDA and 
OpenCL drivers to offload processing onto graphics cores. If you have 
any high end graphics cards, it is worth trying it.

Moscrack can use a local Pyrit client to process data and can use any resources
that Pyrit has to offer, such as other Pyrit nodes that it is configured
to use and graphics cores. Therefore there are no "pyrit" nodes, rather a
single entry in the nodes.dat file identifying that pyrit should be used.
Nodes of any other type can still be used along side Pyrit.

Pyrit support has been moved to a plugin. See "Plugins" for details.

16. Checkpoint and resume

Moscrack writes data regarding it's progress in the wordlist to a file called 
"position.dat". If Moscrack is interrupted, that data can be used to resume
processing where it left off.


To have Moscrack determine your last processed line in the wordlist, run the 
following command in the Moscrack working directory. It will give you a line
number and a word. This is the last line/word that Moscrack completed
processing. Before resuming it is recommended that you backup this file
in case something goes wrong and it is overwritten.

moscrack --position
To resume, use the line number provided by --position and run this command:

moscrack --resume  -P CAPTURE -w WORDLIST -e ESSID 

It's up to you to make sure you specify the same word list and capture file, etc...
to be processed. Moscrack will skip ahead and start processing at the position
you specified. Resume works with STDIN as well.

17. Hang detection

Moscrack has detect if a PID/node is hung (not responding or finishing). The feature is 
documented in the included moscrack.conf file. 

One note about hang detection is that it assumes your nodes are always the same speed.
So if your nodes are shared (doing other CPU intensive things) or are somehow going
to change speeds (slow down) e.g. Virtual machines, amazon EC2, variable clock speeds, then
hang detection could cause problems for you.

18. Dynamic node configuration

Moscrack is packaged with client and server daemons that allow for automatic configuration 
and discovery of nodes. As long as the Moscrack server and nodes are running these
daemons, they will always be ready to work together even between IP address changes,
reboots, configuration changes, etc...

There is also a live CD available that runs SUSE Linux and auto-starts the Moscrack Client
daemon. All you need to do it boot a machine with it and it becomes a dynamic Moscrack node
with no changes or server configuration necessary.

Full documentation is in README.daemon
The Moscrack Live CD is available at htt://

19. Node types

Moscrack supports a number of connectivity methods for executing commands. When you define
a node in the nodes.dat configuration file, you must select one of these.

Node types available:

local 	- execute a command locally
	- perform no status check 
	- copy no files
ssh   	- execute a command over SSH using the Net::SSH2 Perl module
	- perform a TCP status check to specified port
	- copy files to node with scp command line utility if needed
rsh	- execute a command over rsh using the rsh command line tool specified in moscrack.conf
	- perform a TCP status check to specified port
	- copy files to node with rcp command line utility if needed
mosix	- execute a command with mosrun, the Mosix cluster launching tool	
	- perform a status check with "mosrun -$node status" 
	- copy files by piping through mosrun command

Example node.dat entry:


Plugins can be used instead of the standard node types to extend functionality. They still must 
be passed a standard node type, whether they use all of it's features or not. Plugins can choose
to behave differently based on what node type is passed to them.

The format for the type field in nodes.dat for a plugin is: pluginName/type


20. Plugins

Plugins are seperate pieces of code that Moscrack can load at startup. Moscrack will only attempt
to load plugins if the --plugin argument is specified. See --help for details.

Two basic types of plugins:

-Node definition
This plugin type will define a new node type. See "Node Types" above for details.

This plugin type does not define a new node type, however it alters Moscracks behaviour in some
other way.

Plugins by default are located in /etc/moscrack/plugins/. Any file in that directory with the
extension .def will be loaded on startup.

Using plugins:
Plugins may require command line arguments, configuration settings, etc... you should view their
documentation for full details. The --list argument will provide a list of plugins available
and their help facility if one is provided. 

Prioritizing plugins:
If one plugin is dependant on another, you can load them in sequence by renaming the plugin. 
Prefix the filename with a number such as 001, 002, etc... to have them load in that order.
e.g. 001dehasher.def, 002dehasher-addon.def

Disabling plugins:
Remove .def from the end. e.g. dehasher.def.disabled

Creating your own plugins:
The framework for plugins is not 100% stable, but it should not change much. I'll try only to 
add to it in the future. The module "dehasher.def" is fully commented and is intended to be
used to document the plugin framework. Please use it as a template/example for your own
plugins. If you develop a nice plugin and want to share it, send it to me and I will publish it
with Moscrack.

Plugins bundled with Moscrack:
- pyrit.def: Enables the use of Pyrit to crack WPA keys, can be combined with default methods
- dehasher.def: Enable the use of dehasher to dehash various hashes, disables other node types

Plugin documentation:
There is a plugins/pluginname.def.README for each plugin.

21. API

Moscrack has an API that is a work in progress. Only a few things are supported. The API access 
is provided by "moscapid" which must run in the background on your Moscrack master server.

Currently the API allows mosctop and moscrack.cgi to gather information remotely, or without
directly accessing the status.dat from Moscrack. moscrack.cgi is also able to stop Moscrack and
should eventually be able to launch it.

If you run mosctop or moscrack.cgi on a system other than the Moscrack master, copy
/etc/moscrack/moscrack.conf to that system as it will be needed. Configure the moscapid
section as necessary.

moscapid should now be considered a dependancy of Moscracks tools and be kept running at all