firefighter99

i sent you a pm about it. the output is long, that"s why i thought it's better due pm. let me know what u think... it didnt work with my real key

topolb

selvanou: based on the output posted in the other thread, it seems to be based on the same general optimizations. Anyway without testing it myself, I cannot tell you for sure.

peekitty

You might like to ask for hardware donations, I think people would be willing to contribute to a project like this.

topolb

For those who haven't yet succeed cracked the wep key just 2 tips:

1) First you must know if you need --fcs or not. It depends on the chipset of the card that was used to capture the packets and the drivers used. To most simple way to know if you need --fcs or not is just trying both ways with --debug key.
Supose that your real key is 00:11:22:33:44:55:66:77:88:99:00:AA.BB:CC

Then just do this:
./weplab --debug 1 --debugkey 00:11:22:33:44:55:66:77:88:99:00:AA.BB:CC: -r ./pcap.log ./pcap.log
and this:
./weplab --debug 1 --debugkey 00:11:22:33:44:55:66:77:88:99:00:AA.BB:CC: --fcs -r ./pcap.log ./pcap.log

You will see KeyCracked in the right command.
Please note that you must not write the last byte of the key in --debugkey due to a programming error.
You can try decreasing the number of bytes in --debugkey and see if the key gets cracked finally.

2) Increase the default probability for candidate bytes selection (v0.0.2-alpha). By default 40% probability is used. In the output that weplabs gives you when using --debugkey, you will see the candidate keys selected for each keybyte, together with the probability of each one.
BYTE-SELECTED (PROBAB.), BYTE-SELECTED (PROBAB.)
You can check if your real keybytes are the first ones. If in one keybyte is the second one, and the probability of the first one is greater than 40% the second one (the real one in this example) will never be tested.
Thats why if your key does not get cracked with the default probability you can increase it to 70% (for example) with --perc 70
Of course if you are doing a real test and you dont know the real key you must use the try-error method. A good tip is trying first with the default one and then trying with 65%.
If you know the key and it is not cracked with 40% you can inspect the output given by --debugkey and see what was the keybyte that failed and calculate how much do you have to increase the default probability to crack the key.

Hope that this helps.

firefighter99

short question: why do we add the captured file twice as a parameter?

topolb

To help you to save disk space. The file parameter next to the -r is the one that has the weak packets. For this file only the bytes until the end of the IV (Initival Vector= first 4 bytes after de 80.11 header) must be present. So in order to save space you can use --caplen for the capture session, to just save a custom number of bytes for each packet.
The other file parameter is the one that has at least 10 wep data encrypted packets for key testing purposes. All the bytes of these packets must be logged, because the CRC is at the end of the payload and is needed for the key testing procedure.

But if you dont mind the diskspace you can just use --caplen 0, so all packet's bytes will be saved. Then you specify the packets twice for the FMS attack, one for the weak packets and another one for the verifications packets.

That's why in the example we put the file twice I thinks it is a good idea

kleptophobiac

No matter what combination of --prismheader, --fcs, and --perc xx.... I still haven't managed to crack my own wep.

I guess my network is über secure with FF:AA:FF:AA:FF

firefighter99

Oh so caplen x means it only captures x bit of the packet? I thought it means only capture packets smaller than x. that's interesting, but even if you cut it down to 80 there will be more than 10 packets that also include the crc, simply because some arp packets came along. what's the shortest caplen you can use? 24 (24bit of the IV)?

topolb

kleptophobiac: send me a pm. with all the output of the command
./weplab --debug 1 --debugkey FF:AA:FF:AA:FF: --prismheader -r ./pcap.log ./pcap.log

I guess that the problem you have is related to the format you have captured the packets. Could you leave an small (5 MB) pcap capture file somewhere (website, ftp or something) so I can download it and check that the hell is happening x)

firefighter99: that's right --caplen truncates all the packets to this size maximun. To calcule the minimun size to capture the IV you have to take into account also the 802.11 headers.

kleptophobiac

I don't have the big file available at the moment to run the command on... but here's the small file.

http://home.insightbb.com/~kleptophobiac/small.tar.bz2

topolb

Weplab 0.0.2 does not work for you because it seems to have a bug in --prismheader code.
I will try to release version 0.0.3 this night, with this (and other little bugs) fixed.

kleptophobiac

Yay!! I helped somebody find a bug!

firefighter99

used a Netgear MA401RA (prism 2/2.5), hostap drivers to collect data without --fcs.

My 128 Bit WEP was cracked after 1.7 million unique IV's, 1.2 GB Traffic within 1h 25min (802.11). Nice work

topolb

New alpha version 0.0.3 available in www.sourceforge.net/projects/weplab

It fixes problems with --prismheader, among other things (see Changelog)

Enjoy it

topolb

I'm sorry, I made an stupid mistake in release 0.0.3-alpha, so prismheader still does not work.

Version 0.0.4-alpha that fixes the error is available
I tested kleptophobiac's file with this new version and it works fine (finally!)