topolb

Hi all,

A new tool, to analyze and crack WEP encryption (both 64 and 128 keys), has just been released. It implements the FMS attack but with some optimizations (h1kari ones) not present in wepcrack or airsnort. I guess some of you will find it quite useful

The name of the tool is weplab. You can find it in http://www.sourceforge.net/projects/weplab

Weplab is tested on GNU/Linux with latest version of libpcap. Please take a look at the scripts in the CVS to place your prism2 in monitor mode, so weplab is able to capture packets.

Please note that it is still in alpha stage, but stills it manages to product positive results with more than 1.5M normal (not necessary "classic" weak packets). For example my 64 bits keys gets cracked after 40 minutes with 2M packets and my 128 bits key falls with just 1M packets. I need some feedback to tune the cracking parameters.

King_Ice_Flash

Is there an online article of explaining how it works?

__________________
"Yeah," said a voice from under the table, "you go to pieces so fast people get hit by the shrapnel."

topolb

Not yet. First I would like to focus on finishing the tool and then I will write the documentation that will be included in the first beta version of the tool.
Anyway I have not reinvented the wheel. I have just implemented it as it was discussed it in lots of papers.

Weplab uses the FMS attack to both the first and the second byte of the payload. The main difference with other tools like wepcrack, is that weplab does not only focus on these little "classic" weak packets (A+3,FF,x), but also in any packet whose IV could reveal any probability on any keybyte.

kleptophobiac

Care to post an example of proper syntax? I'm a little confused by all the options.

topolb

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 (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

G8tK33per

Once you get things hammered out with respect to a good README let us know. If the big boss approves we can make it a sticky post in the *nix forums or possibly add it to the FAQ's under wireless tools.

__________________
"Butters, stop being such a pussy."

Sons of Confederate Veterans

kleptophobiac

Also, when you're done changing the way the command line works... maybe you should ask one of us to clean up the spelling/grammar before you make the release.

kleptophobiac

oookay... I'm having some trouble getting this to work.

According to iwconfig, wlan0 is in monitor mode on channel 1 (my AP). When I try to capture packets I get this error:

When I set up a ping flood using ath0, and captured using tethereal in libpcap mode, I got 1.82 million packets. When I did the file analysis it said there were a bunch of non-data packets and 0 uniq IV's and no truncated packets. That doesn't sound good.

EDIT:
Just for grins, I did a massive data transfer and got 75,000 packets and still they are "non-data".

peekitty

I don't believe an IMCP packet qualifies as a data packet, they're transmitted unencrypted.

kleptophobiac

Well, as I said, I did a massive file transfer later. Still no va.

Also, they are indeed encrypted.

topolb

ICMP are also encrypted, yes.
The error you have capturing packets with weplab is because of the DATA LINK type that libpcap detects in this interface is not the rigth one (for weplab). Have you enabled the interface with ifconfig wlan0 up? have you initialized it and set up in the rigth channel? What DATALINK type gives you tcpdump sniffing in this interface? what wireless chipset do you have?

About the other error analyzing the pcap file created by ethereal it can be produced because:
a) your card (chipset) is prepending some "header" in each packet. For example, in the case of prism2 card, depending on how have put your card in monitor mode, a special header in added before each packet. --prismheader should be used to inform weplab about that.
b) Sometimes the wireless card's driver does not set propertly the WEP flag bit on encrypted logged packets so weplab does not know that is was encrypted.

Could you please send me a 3 or 4MB file in pcap format with some logged encrypted packets? I would like to see what's wrong.

I will be pleased if you post or send me by email your suggestions about the command line syntax (I know it sucks) or any other feature of the problem.

A new version with some improvements will be released today (If the final tests go fine) in sourceforge.

Thank you very much for your tests and opinions.

peekitty

I'll do some testing later this evening to atone for my ignorance.

kleptophobiac

OK, you've got mail.

I sent it to your sf address.

kleptophobiac

seems to be working just fine after --prismheader was added....

Let's see how long it takes to crack a 64 bit key, FF:AA:FF:AA:FF

Anyway, it's taking 99.9% CPU and 9.9% mem right now.

topolb

I haven't received your email. Perhaps SF has some size limit for incoming emails...
I don't know how could you send me this file, could you hang it in some FTP or web server?

If --prismheader worked for you, is because you own a prism2 based wireless card. Rigth?

Could you paste here the result of analyzing the file with weplab?
It will be very usefull if you could also paste here the result of issue the following:
./weplab -r ./packetslogfile.log --debug 1 --debugkey FF:AA:FF:AA:FF: --key 64 --prismheader ./packetslogfile.log

Debukey will inform weplab about your real key so it will show the candidate key bytes for the real branch, skipping the others in order to give you inmediate results.
The output will tell you if the bytes of your real key are detected as candidate bytes. If so, then cracking the key without debugkey is matter of hours.

Anyway, a new version (0.0.2-alpha) has been released in sourceforge. The new version performs much better specially cracking 64 bit keys. I will be better if you could post the results using the new version.