Dutch

Occasional "Write buffer full." error, and exiting of aireplay during arp replay attack.
Atheros based 802.11b/g card, using MadWiFi drivers pulled from CVS 06292005, and patched with the MadWiFi patch from the first aireplay 2.2 beta.

Restarting aireplay sometimes works, sometimes give the same error.

When it works, it works well, giving me appr. 23000 unique IV's Page Ranking. minute.
Managed to detect my test AP's 128 bit wep key within 10 minutes (including fake authentication, chopchop'ing packet , generating an arp packet with arpforge, reinjecting and collecting 203394 unique IV's), when using fudge factor 4 for aircrack.
Admittedly a very easy key used on the test setup (00:00:00:00:00:00:00:00:00:00:00:00:00), but just shows that WEP, even 128bit, as a security measure is FUBAR...

Dutch

__________________
All your answers are belong to Google. SEARCH DAMMIT!
Warning. Warning.
Low C8H10N4O2 level detected. Operator halted....

devine

Thanks! This can be fixed quite easily I think, by calling usleep and retrying. I hope to release the next beta in a couple of days

Yup. People are starting to use WPA, a good thing indeed -- even WPA1 which has no current flaws if the passphrase is robust enough.

grcore

I noticed while trying the fake authentication, that other APs respond (other than the one you are attempting the association with) and these packets are picked up by aireplay and arps sent out.

devine

Yes, I've noticed that too. I've added a check in attack 3, so that aireplay filters packets on the BSSID: the option -b will be mandatory.

scope

Hi!

2 things I noticed:

1.
Grabbed a packet, faked authentication, tried to chopchop the packet.
chopchop and aireplay -4 work, but the keystream differs.
arpforged the chopchop keystream and injected it, produces ivs.
The arpforged packet from the aireplay keystream does not work. Actually that keystream is far smaller than the one chopchop produces.
(tested with pcmcia Netgear ma401ra, prism2_cs on newest auditor).

I´d be glad if the aireplay -4 worked, because I could use my prismgt for chopping then
I saved all the packets and keystreams for further reference, well, can produce new ones too, if needed

2.
Fake authentication works great on most aps I tested. But I got several ones where it didn´t work. Suprisingly I could associate to the ap by hand (iwconfig eth essid xxxx enc restricted... and so on...).

If I use aireplay-chop in combination with fake authentication it keeps saying it got an deauth packet from the ap and stops, though chopchop does the job in that situation.

hope that helps a bit,
thx,

scope

devine

Ok. Could you send me the two keystreams ? And also the original packet and the WEP key if possible.

Yes, that is a known problem that lies within injection in monitor mode. Basically aireplay can't send ACK frames fast enough, the max. delay is 0.3 ms which is really short. Most APs will let the association work even if they don't receive the ACKs, but others don't.

Could you also send me the decrypted packet and the keystream generated by chopchop in this situation ?

Thanks!

-- Christophe

devine

Had a look at your files. It appeared you used the aireplay keystream and mistakingly named the resulting arp request "arp-chopchop". Similarly, you named the arp forged with the chopchop keystream "arp-aireplay".

The "arp-aireplay" forged packet (created from the chopchop keystream) didn't worked, because the keystream format used by chopchop is different from the keystream format used by attack 4 in aireplay. Hence the different sizes. But if we look closer at the keystreams, they are identical:

As of now, one cannot use the chopchop xor mask (keystream) with arpforge.

EDIT: some people reported that chopping with prism54 sometimes hangs; I'm looking into it.

Dutch

Huh ? That's what I have been doing, when generating my arp packet for reinjecting with aireplay -3.
Worked fine with beta 3, and generated 49K IV's a minute, when injecting with the -x param set to 800.

Dutch

__________________
All your answers are belong to Google. SEARCH DAMMIT!
Warning. Warning.
Low C8H10N4O2 level detected. Operator halted....

devine

Ah, perhaps I haven't made myself clear enough. arpforge is not compatible with the original "chopchop-0.1" as released by KoreK last year.

scope

Ok. Tried it again, it worked. Sorry, really confused the different files, versions and stuff.

Thanks!

However the second issue persists:

ap, no client associated.

Two terminals on my desktop:

1. terminal:

aireplay -1 try2hackme -a apmac -h clmac eth2

clmac is the mac of a client usually connected.

aireplay says:

16:28:57 Sending Authentication Request
16:28:57 Authentication successful
16:28:57 Sending Association Request
16:28:57 Association successful

this is repeated every 30 seconds.

2. terminal:

aireplay -4 -a apmac -h clmac -r chop eth2

Will run for a while, successful guessing bytes, then break with:
"Failure: Got a deauth from..." (aireplay.c, line 1905 to 1912)

I noticed that this happens exactly when the other terminal sends a request sequence.
So if aireplay got lucky, guessing all the bytes beetween the 30 seconds auth interval, everything works.
Maybe the two aireplay instances disturb each other?

What does actually work is the following:
Start fake auth, let it auth and associate, immediately stop it again (so it can´t send another request after 30s). Then start aireplay.
My AP keeps thinking for a while that the station is connected, enough time for aireplay to decrypt the packet.

Well, if I associate by hand, aireplay -4 works, too.

I uncommented the above error message, then recompiled aireplay.c.
Now, when terminal 1 does another fake auth terminal 2 breaks with the next error: "Failure: the access point does not properly discard..." (aireplay.c line 1922 to 1928).
If I uncomment this, too, something weird happens:

aireplay -4 stops guessing bytes when terminal 1 send an auth, but will continue to guess for 2 seconds on every auth send after that.
So it kinda reversed now, aireplay guesses only when an auth is send.
This will take a lot of time, but is successful.
Not the way it should be used

The packet I tried to decrypt was just a simple ping to the ap from inside of the network.

Hope this helps,

scope

devine

Will run for a while, successful guessing bytes, then break with:
"Failure: Got a deauth from..." (aireplay.c, line 1905 to 1912)

Ok, I've added a workaround in beta4. Please try it out.

Thanks,

-- Christophe

King_Ice_Flash

No, thank you!

__________________
"Yeah," said a voice from under the table, "you go to pieces so fast people get hit by the shrapnel."

2marshall8

I have the mac address of the ap and the client but get the errors below when running this command. Does my nic have to have the same mac address as the client that is associated? It's in monitor mode so I didn't think so. I'm running this version of auditor: "auditor-150405-04.iso". For the attack I am using a Senao 2511 ext-2 using the prism2 wlan drivers. I recently upgraded the firmware on the Senao to 1.8.4 The AP is a Cisco 350 w/11.07 firmware. The client that is associated is using a Belkin 11mbps Wireless Nic. I'm running the command:

The output says this:
It will keep going. that is just the beginning part. I can provide more if you need it. It does say it's "buggy" so I think this reply fits her just fine

On another note I have tried the aireplay arp/replay option and had success but was only bringing in around 1000 IV's every 7-8 seconds. This is quite low for what I have seen. The best I've done with my Senao is 1000 iv's every 3 seconds. that is about 20000 a minute. If you can give me some tips on this as well that would be great.

I appreciate any help you can provide. thanks

grcore

I noticed that the -3 "classic" attack now requires an associated client MAC (-h), I would not think that this is necessary, rather it should be optional.

It seems the -1 fake association does not work an many APs, and with some it reports successful association but no ARPs are generated.

With the -0 "deauth" function, it would be nice to be able to specify a single AP or BSSID to focus on.

It also appears that I can generate IVs twice as fast witn an Atheros card as opposed to a Prism2.5 card. I may try recompiling the Prism source + patch to see if something in there might be the problem. (there does not appear to be any changes to the driver/patch though).

nice work though!

g

devine

That message is totally benign.

Code 13 means, "Responding station does not support the specified authentication algorithm". The target AP probably requires shared-key authentication.

Make sure you have RTC support. Also, beta5 (to be released shortly) will have support for injection in monitor mode on hostap, perhaps it'll fix your rate problem.