bubaka

[root@localhost workspace]# weplab -r ./dmp1 --debug 1 --fcs ./dmp1
weplab - Wep Key Cracker Wep Key Cracker (v0.0.6-alpha).
Jose Ignacio Sanchez Martin - Topo[LB] <topolb@users.sourceforge.net>

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

Total valid packets read: 1470089
Total packets read: 1587364
10 packets selected.
Packet 0
---------------------------------------------
Frame Ctl: 0x0248
Key: 84:54:4f
Len including headers: 24
Len EXcluding headers (24 802.11, 4 IV+ID): -4
---------------------------------------------

Packet 1
---------------------------------------------
Frame Ctl: 0x0248
Key: 84:24:3b
Len including headers: 24
Len EXcluding headers (24 802.11, 4 IV+ID): -4
---------------------------------------------

Packet 2
---------------------------------------------
Frame Ctl: 0x0248
Key: 20:00:00
Len including headers: 24
Len EXcluding headers (24 802.11, 4 IV+ID): -4
---------------------------------------------

Packet 3
---------------------------------------------
Frame Ctl: 0x0248
Key: 20:00:00
Len including headers: 24
Len EXcluding headers (24 802.11, 4 IV+ID): -4
---------------------------------------------

Packet 4
---------------------------------------------
Frame Ctl: 0x0248
Key: 81:0d:90
Len including headers: 24
Len EXcluding headers (24 802.11, 4 IV+ID): -4
---------------------------------------------

Packet 5
---------------------------------------------
Frame Ctl: 0x1148
Key: 20:00:00
Len including headers: 24
Len EXcluding headers (24 802.11, 4 IV+ID): -4
---------------------------------------------

Packet 6
---------------------------------------------
Frame Ctl: 0x0248
Key: 58:2d:fb
Len including headers: 24
Len EXcluding headers (24 802.11, 4 IV+ID): -4
---------------------------------------------

Packet 7
---------------------------------------------
Frame Ctl: 0x0248
Key: 20:00:00
Len including headers: 24
Len EXcluding headers (24 802.11, 4 IV+ID): -4
---------------------------------------------

Packet 8
---------------------------------------------
Frame Ctl: 0x0248
Key: 20:00:00
Len including headers: 24
Len EXcluding headers (24 802.11, 4 IV+ID): -4
---------------------------------------------

Packet 9
---------------------------------------------
Frame Ctl: 0x4208
Key: c4:58:10
Len including headers: 136
Len EXcluding headers (24 802.11, 4 IV+ID): 108
---------------------------------------------

Opening packet file for loading all the IV

Total valid packets read: 1458206
Total packets read: 1587364
Total unique IV read: 1388880
1388880 Weak packets gathered:
Compressing IV table...
Total number of Weak packets for byte 0 is 13 (byte 1) and 16 (byte 2)
10(0), 1f(0), 37(0), 3b(0), 41(0), 46(0), 4f(0), 87(0), b0(0), b5(0), --> breath 10 (40% requested)


ENTER pressed and back to promt

[root@localhost workspace]#

chesh

I have an SMC2532W-B using hostap 0.0.4 (or whichever that version is that works right with Kismet). My .dump file is only about 9mb and my output looks a lot like Bubaka's. Actually, pretty much the same thing. I don't need the --prismheader option according to weplab's analysis of my .dump file and I've tried with and without --fcs.

sylvain

yes there is a problem as the output shows a negative length for headers !! sure it deals with the way weplab deals with the drivers you use. I guess the output is not the same according to drivers...

chesh

Any suggestions of how to get weplab to work in this situation?

chesh

sylvain

wait for future development .

topolb

Yes, there is a known bug in weplab with those data packets with empty data field. This bug was already reported and fixed for version 0.0.7
New version 0.0.7 is about to be released. I just need to verify and make some tests first.
You can download version 0.0.7 (develop) from the CVS on sourceforge. I guess that it will be released as a file .tar.gz on monday night (spanish time).

About the problem loading pcap files which size is more than 2GB, I haven't tested it myself. I would like someone to test one os these files with version 0.0.7 and tell me the results.

Sorry for not have answered earlier. I have been on holiday all weekend.
I will do my best to solve all these problems

chesh

Well, I tried to compile the CVS, but since it is incomplete from your changes (I understand it's development), and I'm not familar with your coding, I can only say, that I am eagerly awaiting your release of 0.0.7 in order to try this out.

chesh

chesh

Well yay, I figured out my problem. It seems that I picked up like 4 different networks in my area with WEP when I was sniffing mine. I just noticed the option of --keyid. So, my new question is, how about implementing that if it fails on trying a network/key load, that it moves onto the next one in your .dump file if it exists, and if none exist, let the user know. Or when it starts, how many networks were found with weak packets, and which netowrk it is currently on. Ex.

Networks found = 20
Now loading packets from network 1 of 20 ...etc.

Also, in the configuration script you're calling upon aclocal-1.4 and one other with 1.4, should just call upon aclocal (without the 1.4) since most distros symlink their version of the program to just the straight name. Hrm, had something else, but I can't remember. Anyway, thanx for such a good program. I like how it works. Oh, yeah, are you going to add a HEX to ASCII conversion when the key is found to see what your program thinks it is? I've incremental cracked my WEP key with wepcrack and played with temp passwords and 64-bit WEP keys. I've had it guess the ASCII as something that was completely different then what my key actually was, but when I imputed it in, it actually allowed me to connect and decrypt my network. (And, no, this wasn't key 2 of 4 or something, this was just the regular old first HEX key). Anyway, just some ideas. Thanx topolb.

chesh

topolb

--keyid does not mean different networks, but the number of 64-bit key you are refering to. If you use 64-bit wep encryption, you can configure 4 keys in each wireless client. Normally people just configure 1 key, but I added this option just in case.

But you are right, it will be very usefull if weplab could detect different ESSIDs and allow you to select which one do you want to crack. I have it in the TODO list. I will implement it after summer.

Reconstructing the password that the user used to generate the key is not so easy. Usually the password is hashed (by MD5 for example) to generate the key. If you have the key (hash) and want to know which password was used to generate it, you have 2 options:
- Try different passwords, generate the hashes and compare them with the hash you have. This is exactly what John the Ripper and other cracking tools, do.
- Use rainbow tables. This is what some tools like rainbowcrack or cain&abel do. This requires lot of hard drive space and processing time to generate the tables.

So, retrieving the password from the hash is a "cracking problem" itself.

redbyte

How do i know if "the other side" use 64 or 128 key?

rd

devine

You can't know - best course of action is to run the cracking tool on two machines, one with a key size of 40 bits and the other one with a key size of 104 bit.

wiz561

Hi!

Does anybody know the usuage if you would like to use a tcpdump (from kismet) file? For some strange reason, Kismet works fine in capturing packets, but if I use something else (like weplab), it doesn't like my network monitor drivers.

I tried to use a kismet dump file, but it didn't get me very far.. :-(


Thanks for your help!

topolb

Hi!

Weplab should be able to sniff packets as long as you set manually your card into monitor mode.
Nevertheless you can capture packets with any software that uses pcap format (like kismet, ethereal, tcpdump...) and then use weplab to crack the key. The only point is that depending on how did you set the monitor mode, you may need --prismheader and/or --fcs.

Issue ./weplab --debug 1 -a ./myfilepcap.dump

It will tell you if you need --prismheader, but you still need to know if --fcs is needed.

Then try to crack with ./weplab --debug 1 -k 128 -r ./myfilepcap.dump ./myfilepcap.dump

Yes, you have to specify the file twice. One time for "control packets" to test candidate keys, and another time for needed packets for the statistical attack.

New version 0.0.8 is out, be sure to use this one. It includes new amazing optimizations (Korek's attacks).

devine

Way to go Just to let you know, there are a few other attacks you could also implement in attack.c, you can find them in chopper-0.1. BTW, thanks a lot for writing weplab; it got me interested in WEP cracking, and then I decided to write aircrack as a hobby during my free time.

sylvain

if we had to compare weplab and aircrack which one is the best ? aircrack with the attacks included in chopper ?