New tool to crack WEP keys under GNU/Linux

Postby kleptophobiac » Thu Jun 10, 2004 9:35 am

well... my battery ran out while running weplab previously, so I don't know how that turned out.

I'll give the new version a shot.
kleptophobiac
Mini Stumbler
 
Posts: 310
Joined: Sun Sep 01, 2002 8:32 am

Postby kleptophobiac » Thu Jun 10, 2004 10:05 am

I used "weplab --prismheader -r ~/packets.log --debug 1 -k 64 ~/packets.log"

OK, it's chugging now. Considering it is a simple key, FF:AA:FF:AA:FF, and that it is only 64 bit with a bunch of weak keys... how long should it take?

It's doing ~100,000 c/s and 400 b/s. What exactly does this mean?

Also, there are some interface changes that I would make - including the command line input. I'll write up a doc about how I would do it sometime soon. :)

Let's see how this goes.
kleptophobiac
Mini Stumbler
 
Posts: 310
Joined: Sun Sep 01, 2002 8:32 am

Postby topolb » Thu Jun 10, 2004 12:11 pm

Issue this command and post here the results please.

./weplab -r ./packets.log --debug 1 --debugkey FF:AA:FF:AA:FF: --key 64 --prismheader ./packets.log

I will tell you if all went ok. 400 b/s is too much. I think that maybe your logged packets are not in the right format.
Also you may need to use --fcs (THIS IS IMPORTANT). Some drivers adds a tail called fcs to logged packets in monitor mode. If it is happening to you and you dont tell anything to weplab, weplab will be unable to test candidate keys.

c/s are the number of keys that are tested per second
b/s (branch per second) are the number of bytes that are calculated per second in the FMS attack.

You can press the ENTER key anytime during the crack to get statistics of the work done. You will see what is the current key that is being tested.
topolb
Mini Stumbler
 
Posts: 67
Joined: Tue Jun 08, 2004 2:51 am

Postby kleptophobiac » Thu Jun 10, 2004 12:32 pm

I know about enter... I've been using it for a while

I plugged in my laptop and it jumped to 118,300 and 465.

Key not found. Aww.
kleptophobiac
Mini Stumbler
 
Posts: 310
Joined: Sun Sep 01, 2002 8:32 am

Postby f0urtyfive » Thu Jun 10, 2004 5:17 pm

trying it out on a few different pieces of equipment, for a straight out brute force (using ethereal capture, 9 packets encrypted)... Funny thing, my dual Xeon 2.4 ghz server (Im not sure cache size), runs it SLOWER, then my 1.3 ghz Pentium M laptop (1M cache I htink).

Server:
15327215 keys tested
71289 c/s
Key: ee:df:e9:00:00

Laptop:
33059158 keys tested
79469 c/s
Key: 55:71:f8:01:00
f0urtyfive
 
Posts: 68
Joined: Sun May 04, 2003 5:39 pm

Postby kleptophobiac » Thu Jun 10, 2004 7:39 pm

I wonder why mine isn't able to get a key...?

I tried it with two files, captured with "tethereal -i wlan0 -F libpcap -w ~/packets.log"

:confused:
kleptophobiac
Mini Stumbler
 
Posts: 310
Joined: Sun Sep 01, 2002 8:32 am

Postby firefighter99 » Thu Jun 10, 2004 10:07 pm

weired and my 1.3 ghz Pentium M seems to be slow huh?

I collected data with:

$ weplab -c -i wlan0 --caplen 150 ./pcap.log

Analyse says:

Total valid packets read: 3333952
Total packets read: 3333952
Total unique IV read: 3333952
Total truncated packets read: 2114595
Total non-data packets read: 0
Total FF checksum packets read: 0

Cracking the 128bit key:

$ weplab -r pcap.log --debug 1 --key 128 pcap.log

9 hours later (I stopped the process) it says:

3490695 keys tested
24611 branch taken
106 c/s
0 b/s
........

didnt crack the key yet. why is my c/s compared to the others so slow? 1,3 Ghz Pentium M / 512 MB DDR Ram.

btw: I tried the MA401RA Netgear before and couldnt get the tool running (same error as above). Did the capturing with my Senao SL-2511CD Plus

thanks
firefighter99
Mini Stumbler
 
Posts: 17
Joined: Sat Apr 17, 2004 2:24 pm

Postby topolb » Thu Jun 10, 2004 11:25 pm

f0urtyfive: perhaps the configure script haven't detected fine your xeon processor and you haven't compiled with the proper gcc optimizations. Check it. I tried to detect the gcc version and processor type in configure, and apply the best optimizations in each case.

firefighter99: not slow. The c/s in heuristic attack (FMS) has nothing to do with c/s in bruteforce mode.

All of you:
1) Please use --debug 1 --debugkey (put your key finishing in ':') . It will show you statistics about the number of weak keys per byte (of the real key branch). Paste here in the forum the lines that will appear. These lines tells you the number of weak packets and the candidate keys. If all went ok, you should see your real key bytes the first or second ones.

2) Sometimes the card adds an special 4 bytes tail. You should use --fcs to tell weplab about that. Otherwise weplab will take these 4 bytes as the packet's CRC instead of the real CRC, so the real WEP key will not test fine agains the packet. If you can see your real key bytes with --debugkey but still weplab doesnt find it, just try with --fcs

3) Please tell me which card do you have, which drivers, and what did you do to put it into monitor mode so weplab is able to capture packets. I'm doing the README and FAQ for next releases, and this information will be very helpfull for me.

Thank you very much for your tests.
topolb
Mini Stumbler
 
Posts: 67
Joined: Tue Jun 08, 2004 2:51 am

Postby selvanou » Fri Jun 11, 2004 12:36 am

Two questions :
- Is the tool you developed related to this post : http://www.netstumbler.org/showthread.php?t=9524
- can it work with a cisco aironet card ?
thank you
selvanou
 

Postby topolb » Fri Jun 11, 2004 1:06 am

The FMS attack is the vulnerability used by airsnort and wepcrack. However these tools didn't implemented the attack fine.
Instead of consider all the set of weak packets, they just use an small subset. That's why they detect so few weak packets.

The first tool that implemented the FMS attack with the entire weak packets set, was dwepcrack by h1kari. H1kari wrote a paper describing the problem with wepcrack and airsnort and suggested some optimizations over the standar FMS attack algorithm. He wrote dwepcrack (only for *BSD) that had some of these optimizations, but not all of them.

Weplab should work with any wireless card that supports monitor mode. The problem is that I just have a prism2 based card so I don't know if other card's drivers adds some special header or tail to the packets, or sniffs over another DATALINK. I'll do my best to make weplab work with any card with to your feedback :)
topolb
Mini Stumbler
 
Posts: 67
Joined: Tue Jun 08, 2004 2:51 am

Postby firefighter99 » Fri Jun 11, 2004 1:19 am

thanks for the answer! As you can see I collected many packets (over 3 million, ~2gb of data), but even after 9 hours of cpu "thinking" the wep key wasnt cracked. How many more packets do i need you crack my wlan with your tool?

nice work btw :)
firefighter99
Mini Stumbler
 
Posts: 17
Joined: Sat Apr 17, 2004 2:24 pm

Postby selvanou » Fri Jun 11, 2004 1:39 am

topolb wrote:The FMS attack is the vulnerability used by airsnort and wepcrack. However these tools didn't implemented the attack fine.
Instead of consider all the set of weak packets, they just use an small subset. That's why they detect so few weak packets.

The first tool that implemented the FMS attack with the entire weak packets set, was dwepcrack by h1kari. H1kari wrote a paper describing the problem with wepcrack and airsnort and suggested some optimizations over the standar FMS attack algorithm. He wrote dwepcrack (only for *BSD) that had some of these optimizations, but not all of them.

Weplab should work with any wireless card that supports monitor mode. The problem is that I just have a prism2 based card so I don't know if other card's drivers adds some special header or tail to the packets, or sniffs over another DATALINK. I'll do my best to make weplab work with any card with to your feedback :)


So I think your tool is the same one that the one described in the other post...maybe he can be intereresting to compare both

I can send you some log files if you need it ? btw when I will have the time I will test your tool
selvanou
 

Postby topolb » Fri Jun 11, 2004 1:42 am

3 millions is enough of course.
try with --fcs

also post here what messages you get if you use --debug 1 --debugkey AA:BB:CC:DD:EE:

change AA:BB:CC:... with your REAL key (I guess you are trying with your own wireless lan, so you know the real key) and finish with ':'. Post here the lines you get, and we will see why the key does not get cracked ;)
topolb
Mini Stumbler
 
Posts: 67
Joined: Tue Jun 08, 2004 2:51 am

Postby topolb » Fri Jun 11, 2004 2:07 am

selvanou:

What do you mean with "the other tool"? You mean "Experimental weak iv finder v0.2"?

As far as I know this tool is not released to the public. Free software is better than propietary software because among other things lots of people have tested and made contributions to the project. From my point of view if this tool exists but it is not public, is like if it does not exist.

Weplab is GPL and can be downloaded from http://www.sourceforge.net/projects/weplab
topolb
Mini Stumbler
 
Posts: 67
Joined: Tue Jun 08, 2004 2:51 am

Postby selvanou » Fri Jun 11, 2004 2:09 am

yes I know it is not released yet but I think it is based on the same optimizations. Am I right ?
selvanou
 

PreviousNext

Return to Unix/Linux

Who is online

Users browsing this forum: No registered users and 3 guests

cron