kleptophobiac

Hooray! I'm going to try a difficult key sometime tonight or tomorrow.

topolb

It seems that weplab 0.0.4 is working fine so I'm thinking about changing the project state from alpha to beta.
For this first beta version I would like to include a README file with instructions of how to use weplab. I have wrote a draft but I guess I need some help with my english

I would really appreciate if some of you could take a look at it and check the vocabulary/grammar and perhaps rewrite some sentences to make it more clear.

Also if you want to add something to the README or have some suggestions about it, let me know.

The README file can be found in the CVS of the project (sourceforge), I can send you by email if you prefer.

Please let me know if someone is interesed in helping me.

Thank you

danielj

Is the weplab compatible with airsnort's log file?

I have run airsnort for about 24h now (not so long) on my office network and collected exact 2055 "intresting" packets. The thing is that it have not find any new intresting packets for about 12h now.

Is it just bad luck or just to litel time and traffic that I have not recived any more intresting packets?

I'am using a Prism2.5 mini-PCI card with hostap driver.

Edit: I puched the traffic some and it found some more. So it was only to little traffic. But my question is still if the log file is cobatible with weplab

topolb

Weplab is compatible with any packet log file in libpcap format. I don't know if airsnort logs packets in pcap format or not.

Anyway you can capture packets with weplab and if you can flood the network or the traffic is high, you wont need to wait 24 hours, just 30 minutes to capture 2M packets.

Weplab should break the key with the FMS attack in less than 2 hours.
You will find a draft of README file in http://weplab.sourceforge.net/files/README

If you still want to know if your airsnort captured packets can or not be used, just try

weplab -a --debug 1 ./pcaplog
weplab -a --prismheader --debug 1 ./pcaplog

Use the method explained in README to know if you need prismheader or fcs

danielj

I have tested the folowing commands

weplab -a --debug 1 ./myplogfile
weplab -a --debug 1 --prismheader ./myplogfile
weplab -a --debug 1 --prismheader --fcs ./myplogfile

and they all give me the same info. My guess is that I don't have the
prismheader and the "tail" on the log fil?

Setting the memmory to 0s
Opening packet file for reading sample encrypted packets

Total valid packets read: 1720369
Total packets read: 3442940
Total unique IV read: 1720369
Total truncated packets read: 0
Total non-data packets read: 1722571
Total FF checksum packets read: 0

topolb

Are you trying to break your own network? So you know the real WEP key? If your 64 bit key is for example AA:BB:CCD:EE do this:

./weplab -r ./pcap.log --debug 1 --debugkey AA:BB:CCD:EE ./pcap.log

and try also the same with --fcs, --prismheader or both

./weplab -r ./pcap.log --fcs --debug 1 --debugkey AA:BB:CCD:EE ./pcap.log
./weplab -r ./pcap.log --prismheader --debug 1 --debugkey AA:BB:CCD:EE ./pcap.log

./weplab -r ./pcap.log --fcs --prismheader --debug 1 --debugkey AA:BB:CCD:EE ./pcap.log

The one that gives you the message "Key correct!" is the one that has the right commands.
You can also use ethereal with your captured file and see with it if it has the prismheader.

danielj

Do you know any issue with large log files? I'am use a 1,1Gb log file

When I run
./weplab -r ./pcap.log --debug 1 ./pcap.log
it startet to do something but when I press enter for some info it just when to
the shell.

But now when I try it on my laptop at home with a much smaller log.. (28Mb)
I get some info when I press enter

Is there much in diffrent in time in the process if I have a small or big log file?

edit: I use Airsnort to make the pcap log file

topolb

Never had problems with long files. In fact libpcap is who manages the file so it shouldn't be any problem.
For weplab the point is not how large the file is, but how many encrypted data packets does it have. I have never tryied to run weplab -r with more than 3M packets (mainly because it is not neccesary so many packets to break the key).

Please, issue the 3 commands I gave you in my last post (using --debugkey with your real key), and post the results.
Dont forget to use the option --key 128 if your key is 128 bits long.

PD: new version of the README at http://weplab.sourceforge.net/files/README

f0urtyfive

He has posted 0.0.5 on his sourceforge page, for those interested this version now has multi-processor (which inherently gives us Hyper threading) support.

[edit] Oh, and by the way, on my Dual xeon it gives me about 408,000 C/s in brute force mode (total) [/edit]

topolb

selvanou: I cannot reply your p.m. because you have either disabled p.m. reception or something like that.
Please send me your card's captured logfile and I will make weplab understand it as far as it is in pcap format.

Thorn

He was banned after several warnings.

__________________
Thorn
"You guys'll be chalk outlines without me."

bubaka

it crashes by me if i use --prismheader together with -b -r options.
but works fine with -a option. File is 100% pcap compatioble.

topolb

bubaka: are you sure you need --prismheader?
Having a prism2 based wireless card does not mean you need it. It depends on the drivers you are using, and how the monitor mode is set up.

Try without it.

If you want to know if you really need it, use ethereal to check this file and see if it appears a prismheader in wep encrypted data packets.
If ethereal shows you the prism header and you get a segmentation fault in weplab, please send me by mail an small part of this file (no more than 5 MB) and I will take a look at the problem.

Dreadnaught

I'm having a problem using weplab on a 128 bit key. I used a Dell TrueMobile 1150 to capture the packets with Kismet, and it looks to me that weplab is diverging away from the correct key. I used the same file and setup with a 64 bit key and it worked fine. Also, can you elaborate in the README about what the debug and debugkey are telling us in regards to the different bytes and what does the different values of breath mean.

The wep key is fe:ed:de:ad:be:ef:00:fe:ed:de:ad:be:ef

root@david:/var/log/kismet# weplab -r ./Kismet-Jun-22-2004-1.dump --debug 1 --debugkey fe:ed:de:ad:be:ef: --key 128 ./Kismet-Jun-22-2004-1.dump


Opening packet file for loading all the IV

Total valid packets read: 2221603
Total packets read: 2223075
Total unique IV read: 2133784
2133784 Weak packets gathered:
Compressing IV table...
Total number of Weak packets for byte 0 is 41 (byte 1) and 21 (byte 2)
e6(15), e7(12), 72(0), b3(0), 2a(0), 80(0), a0(0), 01(0), 03(0), 12(0), --> breath 10 (40% requested)

Total number of Weak packets for byte 1 is 42 (byte 1) and 63 (byte 2)
e0(15), 06(12), 17(0), 47(0), 87(0), b6(0), 21(0), 76(0), 89(0), 01(0), --> breath 10 (40% requested)

Total number of Weak packets for byte 2 is 8629 (byte 1) and 1 (byte 2)
de(95), 37(0), f3(0), b0(0), 28(0), 7e(0), 60(0), 73(0), e6(0), 09(0), --> breath 1 (40% requested)

Total number of Weak packets for byte 3 is 732 (byte 1) and 1 (byte 2)
a9(42), d1(24), 61(12), 45(3), 4b(3), 55(3), dd(3), f4(3), fc(3), 3c(2), --> breath 1 (40% requested)

Total number of Weak packets for byte 4 is 870 (byte 1) and 1 (byte 2)
be(49), 72(18), c7(7), 6c(4), 20(3), 3c(3), 6e(3), 4c(2), 51(2), 59(2), --> breath 1 (40% requested)

Total number of Weak packets for byte 5 is 648 (byte 1) and 1 (byte 2)
ef(30), 03(16), d3(14), fd(10), 0d(8), f4(5), 4b(4), 65(4), 05(3), 1c(3), --> breath 2 (40% requested)

Total number of Weak packets for byte 6 is 959 (byte 1) and 1 (byte 2)
00(32), ba(32), a1(11), f4(9), a6(4), b8(2), 06(1), 0c(1), 16(1), 39(1), --> breath 2 (40% requested)



512 keys tested
20 branch taken
13 c/s
0 b/s
Key: fe:ed:de:ad:be:ef:00:65:86:de:ad:be:ff
Key: 00:00:00:00:00:00:00:00:00:00:00:00:00
1st Byte current weaks :byte 0 (41),byte 1 (42),byte 2 (8629),byte 3 (732),byte 4 (870),byte 5 (648),byte 6 (959),byte 7 (940),byte 8 (979),byte 9 (960),byte 10 (1021),byte 11 (1071),byte 12 (0),
2st Byte current weaks :byte 0 (21),byte 1 (63),byte 2 (1),byte 3 (1),byte 4 (1),byte 5 (1),byte 6 (1),byte 7 (271),byte 8 (63),byte 9 (554),byte 10 (42),byte 11 (3),byte 12 (0),


3072 keys tested
41 branch taken
45 c/s
0 b/s
Key: fe:ed:de:ad:be:ef:ba:5e:8d:24:ad:3f:ff
Key: 00:00:00:00:00:00:00:00:00:00:00:00:00
1st Byte current weaks :byte 0 (41),byte 1 (42),byte 2 (8629),byte 3 (732),byte 4 (870),byte 5 (648),byte 6 (959),byte 7 (481),byte 8 (1139),byte 9 (1503),byte 10 (1831),byte 11 (7707),byte 12 (0),
2st Byte current weaks :byte 0 (21),byte 1 (63),byte 2 (1),byte 3 (1),byte 4 (1),byte 5 (1),byte 6 (1),byte 7 (308),byte 8 (23),byte 9 (274),byte 10 (66),byte 11 (515),byte 12 (0),
Key NOT found

topolb

Are you really sure your key is

fe:ed:de:ad:be:ef:00:fe:ed:de:ad:be:ef

and not

fe:ed:de:??:be:ef:00:fe:ed:de:ad:be:ef

As you can see from the weplab's debug output ?? is predicted as

a9 with 40% of suceed probability
d1 with 24%
61 with 12%

All logged data packets comes from the same ESSID? (AP)
You have captured 732 weak packets for this keybyte. I cannot believe weplab is not being able to derive the right keybyte.

Is your wireless card or the AP, or other card in the network firmware patched not to produce weak packets?

What size does this file has zipped? Could you hang it somewhere in a website so I can download it? I would like to see it myself.

About the README, you are right. I will include a detailed explanation of the debug output.