sylvain

I think you are right..such a tool should be differentiated from chopchop ... I think it is better to include it with a tool as aireplay

devine

I've rewritten aireplay so as to use KoreK's awesome linux-wlan-ng patch. It works extremely well, and you only need one Prism2 card to perform the ARP replay attack now I'll let the user choose between 1. sniffing for an arp-request or 2. reusing a prga (from chopchop) to create an arbitrary arp-request.

I'll drop support for hostap, as the linux-wlan-ng driver provides a much cleaner interface to the hardware.

sylvain

awesome !! when will you totally drop support for hostap and keep linux-wlan-ng driver ?

devine

Will be merged in the next release. Also, while performing some tests with chopchop I found out an interesting property of the multicast destination address: if you send one of these packets over the air, the AP will re-encrypt it with a new IV (well, that's the behaviour of the Prism2 chipset in Master mode). The only requirement is that at least one station must be connected to the AP.

Any kind of packet will do, it doesn't even have to be an ARP packet or anything specific. This means it's only necessary to wait for a few seconds until one usable packet appears (even when there's very few traffic), and then traffic generation is extremely fast (~100k IVs in 10 minutes), thus you may crack a 104-bit WEP key in less than an hour, and a 40-bit WEP key in less than 15mn.

If anyone having a Prism2 card is interested in beta-testing the new version of aireplay, let me know - I'll send you the source & howto.

WaRRiorPro

Edited.

djben

the new aireplay -- definetally nice and got it to work in a snap.

Its too bad about hostap -- i actually got used to all of hostap's iwconfig commands (they were essentially the same as ones i use on my prismGT card using prism54 drivers)... now I've got to learn wlan-ng heh

sorbo

I have been playing with wep a while ago, but never finished my "research" so i never really published my results.

However a friend of mine brought to my attention that IV attacks are "resurrecting" [at least on this forum].

WEP attack developers may find my work useful, so ill just post it.

http://sorbo.darkircop.org

I encourage to try out the version 0.2 of the cracker [especially -w and -g options].

Have a read through the paper about the 13% stuff. It was new at the time... i do not know if it is new stuff now.
By new I mean... a correct implementation...
http://sorbo.darkircop.org/wlan/sorwep.txt

sylvain

really interesting..I think this attack is used by weplab and aircrack..Maybe topolb or devine can confirm

devine

Well honestly I don't really understand all those new WEP statistical attacks

sorbo

There are two main results in my work:
1) The 13% iv class
2) The "late resolve" cases.

I will illustrate #1:

Review from FMS:
================

X = S[1]
Y = S[X]
Z = S[ X + Y ]

Resolved cases where B is the key byte we are attacking:

X < B + 3
X + Y = B + 3


Assume we are attacking the first key byte [B = 0].

X, Y and Z are 3 distinct values... so 5% probability they all don't swap.

To get 13%, we need to have only 2 distinct values...
2 values must overlap!

13% probability:
================
X is fixed... always S[1].
Z is "fixed" too we always want it to point to S[3] [attacking first key byte].

The only way to get 2 distinct values is to have Y and Z point at the same
element. This means Y has to point at S[3] as well.

The only way to do that is having S[1] contain 3.
Thus, X = 3.
To get Z to point to 3, we have S[3 + Y]. So Y has to be 0. Y and Z point at the same place S[3], and need to contain the value 0.

Notice that this modifies the FMS equation to

X <= B + 3

Where X = B + 3 is the special case for 13% weak ivs.


Example:
========
run:
sorwep -k 68:9a:01:61:61:61:61:61 -d 3

it will debug the key 61:61:61:61:61 with IV 68:9a:01
concentrating on seed byte 3 [the first key byte].

This is the KSA state [after the swap]:
I=02 J=06 S[i]=06 S[J]=02 S[byte]=01 X=03 Y=01 X+Y=04 Z=04
I=03 J=68 S[i]=00 S[J]=01 S[byte]=00 X=03 Y=00 X+Y=03 Z=00
I=ff J=2a S[i]=f2 S[J]=04 S[byte]=00 X=03 Y=00 X+Y=03 Z=00

In normal conditions, we obviously know the state up to I=02... which is enough.
Notice the key setup at the end:
X=03 Z=Y=0
Just what we wanted.

However the first output byte of PRGA is:
Output of prga before xor 03

We would have expected the output to be 00!

Recall PRGA:
i = i + 1
j = j + S[i]
Swap(S[i], S[j])
Output z = S[S[i] + S[j]]

This means:
i = 1
j = 3
S[i] = S[1] = 3 [this is X]
S[j] = S[3] = 0 [this is Y... but also Z]

notice the swap!!!
the new state will be
S[1] = 0, S[3] = 3

z = S[0+3] = S[3] = 3

To calculate the key using the FMS method, simply assume Z is 0.


How to detect:
==============
The basic way of detecting all this is:
The output of PRGA is the seed byte we are attacking [for example 3].
And X = seed byte we are attacking.

Basically:
if(X == Z && Z == key_byte_we_are_attacking)

Remeber to use Z = 0 when calculating the key with the FMS method.


If anyone is interested, i can explain more of my results [too bad it was about a year ago so stuff isn't fresh in my mind ;D ].

KoreK

Sorry, mate, you are a bit late. Nice of you to share your code. I was wondering if you were ever going to come out.
Class 2, Class 3: Wrong? (I don't think you can reach 5% success with those two. Did you test them?). One simple reason is that there isn't a relation between (byte) and the data. If no condition links (byte) with the case, you can't deduce anything.
Class 4: A_s13
Class 5: A_w13_2
Class 6, 7: Those are left to the writer...

sorbo

A friend of mine just notified me about you today... that is why i posted. [i played with wep mainly in winter 2003, then i just got stuck doing other stuff so never continued].

The first thing i thought was that someone basically came out with an implementation of the 13% stuff and it seems so. I did not search your posts, but the one you linked definitely shows the result.

Class 2, you are right i never really figured that one out... it would always come out with a very low probability. Class 6,7 i do remember they had something weird.

I did test the classes vaguely while i was developing... I would do something like:
./sorwep -k 61:61:61:61:61 -w all -a all:2

and get something like:
Grandtotal results
Summary for output byte 0
Resolved/Candidate cases
Class 1(prob=0.050)=399/7884 5.061%
Class 2(prob=0.010)=178/16380 1.087%
Class 3(prob=0.050)=63/1206 5.224%
Class 4(prob=0.135)=164/1237 13.258%
Class 5(prob=0.135)=125/1243 10.056%
Class 6(prob=0.100)=381/1821 20.923%
Class 7(prob=0.135)=125/1187 10.531%

Can you give me a link to your tool, i am curious to see it. Does it handle class 1,3,4,5,6 ? possibly more ? And does it implement additional output bytes [as suggested by h1kari].

KoreK

chopper is posted in the aircrack thread: (Aircrack)Yet another WEP cracking tool for Linux
Anyway it's also been implemented in aircrack and weplab. Devine corrected at least one bug, and his tool, aircrack, uses (from what I read) a more stable version:
(Aircrack)Yet another WEP cracking tool for Linux
I posted a simple demo (just a few examples) in a mac thread as well: Need security pointers
The A_s13, A_w13_2 are attack names in chopper. There are 17 of them. The number of attacks is not that important, since the number of FMS-vulnerable IVs grows as the attack progresses. The problem is to balance the search for the key so that false positives are corrected. Results for chopper are
99% success for 256k random IV
over 75% success for 128k random IV
When IV's are distributed in a increasing little endian manner, chopper gets stuck on false positives and fails.
I'll have another look at "class 3" ivs. Your notations are quite hard to follow.

KoreK

From sorwep.txt and a bit of playing with it:

• class 2: Doesn't work. Conditions are S[1]=0,S[byte]=byte,S[0]=Y=output. Then if J is 0(=&Y), conditions are more likely to be met. But if J isn't, if the next J (byte+1) is 0, conditions are also more likely to be met and so on. The conditions are not sufficient to guess one of them, since they can guess all of them...
• class 3: That one is new to me. It's a weak 5% attack. It has stability problem (like most of the chopper weak attacks).
• class 4: chopper's A_s13.
• class 5: chopper's A_w13_2.
• class 6: chopper's A_w13_1.
• class 7: chopper's A_w13_3.

A note on this thread: I would like to keep it as technical as possible. So no lovefest please. No stoopid windows/my card/ignorant post either. Give your post some content, or you'll receive a nice PM from me. Ideally, it should be some contribution to wep cracking, or some intelligent bug report (and the thread won't have more than 3 pages). You can always PM me, if you have any doubt. Sorwep ended here after a short stay in the bin, because there has been a bit too much of wep threads lately. So keep it tidy.

For my part, next version of chopchop will be in a week or two. I'd like to wait for the release of the atheros injection patch, and in the meantime, I'll try to finish the wep paper I started. Hopefully this will be my next post here.

sknikam

Hi,
Can you post more information on how chopchop decrypts the packets. I am newbie to this field so a formal :-) document describing the method how you assume the last byte and the necessary corrections required for each assumption would be very helpful
Regards