Download Latest Version Latest Version (167.6 kB) Get Updates
Name Modified Size InfoDownloads / Week
tools 2011-02-17
Moscrack_Live.txt 2013-06-05 1.9 kB
README 2013-06-05 19.5 kB
release-notes.txt 2013-06-05 10.5 kB
moscrack-2.08b.tar.gz 2013-06-05 167.6 kB
Moscrack_Live.i686-0.2beta.iso 2012-11-08 164.6 MB
Moscrack_Live.i686-0.2beta.img.bz2 2012-11-08 169.6 MB
moscrack-2.07b.tar.gz 2011-05-17 162.8 kB
dehasher-0.3b.tar.gz 2011-05-01 4.1 kB
dehasher-0.2a.tar.gz 2011-04-27 8.8 kB
dehasher-0.1a.tar.gz 2011-04-24 2.9 kB
moscrack-2.06b.tar.gz 2011-04-24 154.7 kB
moscrack.conf.FIXED-2.05b 2011-04-24 6.1 kB
moscrack-2.05b.tar.gz 2011-04-21 150.3 kB
Moscrack_Live.i686-0.1beta.iso 2011-04-10 153.1 MB
moscrack-2.04b.tar.gz 2011-04-03 135.3 kB
moscrack-2.03b.tar.gz 2011-03-29 133.6 kB
moscrack-2.02b.tar.gz 2011-03-14 337.9 kB
moscrack-2.01b.tar.gz 2011-03-03 127.2 kB
moscrack-2.0b.tar.gz 2011-02-19 114.7 kB
moscrack-1.01b.tar.gz 2011-02-15 99.4 kB
Totals: 21 Items   489.0 MB 41
Moscrack 2.08b Copyright 2011 Ryan Babchishin Contents: 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 improving. 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 modules - 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 <pcap file> -e <essid> -w <wordlist> 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. E.g. $ 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". Usage: 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: 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. Compression: 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 <yourfile> A file will be created called <yourfile>-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 improvement. Auto-Chunksize Settings: Moscrack has various methods of automatically determining the chunksize for you. These settings are documented in the sample moscrack.conf. Auto-Tuning: 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. Example: ./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 = <your status.dat>". 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. Usage: 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 <position> -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: 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 Example: 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. -Other 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 times.
Source: README, updated 2013-06-05