Here you have a preliminary draft that will be included in the README file on next alpha release.
Please excuse my poor english.
USAGE.
Weplab has lot of options that could be a bit confused to new users. The purpose of all these options is not only allow the user to "tune" the cracking process, but also help the user to analyze and understand the cracking process. After all weplab is an educational tool
Following there is a brief summary of all the options.
--debug <debug_level> : gives more more information of the current cracking process
-v : nothing at the moment
-y : dictionary based attack. Not implemented yet.
-b : bruteforce cracking. Tests all possible keys.
-r <file>: FMS statistical attack. The main purpose of this tool. <file> is the pcap format file where the packets that will be used for the FMS attack, are stored.
-c : Capture packets from interface. Does not crack anything, it just captures unique IV packets and logs them in a file
-i <interface>: Uses <interface> por capturing packets with -c. Mandatory option if -c is used.
-a : Analyzes specific file and gathers some statistics about the packets that are stored.
-k <size>: Uses this key size in bits. Default 64. Possible values: 64, 128
--caplen <size>: captures maximun <size> per packets. Only applies when using -c (capture mode).
--fcs: Sometimes your wireless card appends a "tail" to all captured packets in monitor mode. This "tail" is called fcs. By default weplab does not expect to see this tail. If you know it is pressent in captures packets, you have to specify it to weplab with --fcs.
--keyid <id>: when cracking 64 bits keys. You must specify which of the four possible keys do you want to crack. Default: 0
--prismheader: Sometimes prism2 wireless cards append a special "header" to all captured packets in monitor mode. This "header" is called prismheader. By default weplab does not expect to see it. If you know it is pressent in captures packets, you have to specify it to weplab with --prismheader.
--ascii : If you are using bruteforce (-b) to crack the key, you can reduce the search to ascii bytes. By specifing --ascii each key byte can be in the range 0 - 0x3F.
--allowdups: deprecated. Not used in this version.
--deep: I think I will remove this option in next version. At the moment it uses more bruteforce in the FMS cracking method.
--debugkey <key>: VERY IMPORTANT OPTION if you want to test the tool. If you already know the key or at least part of it, you can specify this part here so weplab will not try to guess these already known bytes. Key must be in the form AA:BB:CC: (always ending with ':').
-h : shows help
-V : shows current version of weplab.
EXAMPLES OF USE.
Example 1. Cracking using FMS attack
You want to test the tool so you collect 1.5M packets from your own wireless LAN. You just want to know if weplab would be able to crack it.
You can use first --debugkey. If you are using a 128 bits key the right sintax would be
./weplab -r ./packets.log --debugkey 01:02:03:04:05:06:07:08:09:10:11:12:13: --debug 1 --key 128 ./packets.log
You should see the statistics and guesses for each byte of the key so you can see the viability of the attack. At the end you should see "key succesfully cracked". If you do not see such message, perhaps your captured packets have the FCS tail so it will be neccesary to issue --fcs
./weplab -r ./packets.log --debugkey 01:02:03:04:05:06:07:08:09:10:11:12:13: --fcs --debug 1 --key 128 ./packets.log
Now can try with just a part of the key in debugkey. If the FMS is possible with these packets, weplab should be able to crack the key using just these bytes.
./weplab -r ./packets.log --debugkey 01:02:03:04:05:06: --fcs --debug 1 --key 128 ./packets.log
If it works you can try reducing the debugkey more. At the end you can try with no debugkey at all, as if it were a real attack.
You can push ENTER key in any moment to get statistics of the work done.
Example 2. Cracking using bruteforce
To crack a 64 bits key using normal bruteforce just issue the following command.
./weplab --debug 1 --key 64 ./packets.log
If you suspect that the key may be in plain ascii, do this:
./weplab --debug 1 --key 64 --ascii ./packets.log
You can push ENTER key in any moment to get statistics of the work done.
Example 3. Capturing packets.
In order tu capture packets you have to put your wireless card in monitor mode in the rigth channel. The way to do this depends on your specific card. For prism2 cards there are 2 scripts in the CVS (
http://www.sourceforge.net/projects/weplab).
Be carefull to configure monitor mode to ignore WEP bit.
Once you have your card in monitor mode, you can capture packets using tcpdump or weplab -c -i <interface>
./weplab -c -i wlan0 --debug 1 --caplen 150 ./packets.log
You can push ENTER key in any moment to get statistics of the work done.
Example 4. Analyze an existing pcap file.
Weplab can also analyze a pcap file to the some statistics. Use -a for this purpose. --prismheader --fcs can also be used.
./weplab -a --debug 1 ./pcap.log