New tool to crack WEP keys under GNU/Linux - Page 2

kleptophobiac · 06-10-2004

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 · 06-10-2004

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.

topolb · 06-10-2004

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.

kleptophobiac · 06-10-2004

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.

f0urtyfive · 06-10-2004

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

kleptophobiac · 06-10-2004

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"

firefighter99 · 06-10-2004

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

topolb · 06-11-2004

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.

06-11-2004

Two questions :
- Is the tool you developed related to this post : I cracked my own WEP
- can it work with a cisco aironet card ?
thank you

topolb · 06-11-2004

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

firefighter99 · 06-11-2004

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

06-11-2004

Quote:

Originally Posted by topolb

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

topolb · 06-11-2004

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

also post here what messages you get if you use --debug 1 --debugkey AA:BB:CCD: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 · 06-11-2004

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 www.sourceforge.net/projects/weplab

06-11-2004

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

06-10-2004	#17 (permalink)
kleptophobiac Registered Member Join Date: Sep 2002 Posts: 310	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. Last edited by kleptophobiac : 06-10-2004 at 12:10 PM.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

06-10-2004	#16 (permalink)
kleptophobiac Registered Member Join Date: Sep 2002 Posts: 310	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.

06-10-2004	#18 (permalink)
topolb Registered Member Join Date: Jun 2004 Posts: 67	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.

06-10-2004	#19 (permalink)
kleptophobiac Registered Member Join Date: Sep 2002 Posts: 310	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.

06-10-2004	#20 (permalink)
f0urtyfive HAH! Join Date: May 2003 Posts: 68	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

06-10-2004	#21 (permalink)
kleptophobiac Registered Member Join Date: Sep 2002 Posts: 310	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"

06-10-2004	#22 (permalink)
firefighter99 Registered Member Join Date: Apr 2004 Posts: 17	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

06-11-2004	#23 (permalink)
topolb Registered Member Join Date: Jun 2004 Posts: 67	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.

06-11-2004	#24 (permalink)
selvanou Posts: n/a	Two questions : - Is the tool you developed related to this post : I cracked my own WEP - can it work with a cisco aironet card ? thank you

06-11-2004	#25 (permalink)
topolb Registered Member Join Date: Jun 2004 Posts: 67	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

06-11-2004	#26 (permalink)
firefighter99 Registered Member Join Date: Apr 2004 Posts: 17	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

06-11-2004	#28 (permalink)
topolb Registered Member Join Date: Jun 2004 Posts: 67	3 millions is enough of course. try with --fcs also post here what messages you get if you use --debug 1 --debugkey AA:BB:CCD: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

06-11-2004	#29 (permalink)
topolb Registered Member Join Date: Jun 2004 Posts: 67	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 www.sourceforge.net/projects/weplab

06-11-2004	#30 (permalink)
selvanou Posts: n/a	yes I know it is not released yet but I think it is based on the same optimizations. Am I right ?