grcore

Try with the -x option (to turn off bruteforce on the last 2 keybytes)

g

abx5

- With default option, it took more than an hour. (As I said earlier that it took like 7 hours. I wait till 8 hours but accidentally shut it down.)
- With the -x alone took more than 20 mins. (Didn't wait since I have to do sth.)
- with the -x -f 2 took 10:06 mins to find the key
- with the -f 2 took 8:05 mins to find the key.

It seems like the result is acceptable this time with Fudge factor set to 2. One thing I don't understand is I already tested it a few times with -f 2 and it always take more than an hour. But this time, with the same packet, same computer, same OS, I can crack it without any problem in 8 - 10 mins. That's strange though.


Thank you,

Rincebrain

Edit to note bug fixed:
Gentoo's automatic wireless config scripts are a pain in the arse, and were causing a chain.

Edit to subscribe and note that this is an awesome program, and thank everyone who contributed at all to it for working on it.

cybergibbons

I don't know if this is a bug with aireplay, madwifi, the hardware, or my head.

My understanding of the ARP reinjection attack is that the packet needs to stay the same, with regards to the encrypted ARP request, and the IV.

I am using aireplay 2.2 and madwifi-cvs-20050814 along with the respective patch.

The card is a D-Link DWL-G650 Hardware Revision C3, ("Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)" from lspci). I've seen reports than the C2 revision works fine with aireplay.

I perform a fake association, which repeats every 30 seconds as this appears to be necessary. This works fine:

aireplay -1 30 -e "My SSID" -a 00:09:4B:XX:XX:XX -h 0:1:2:3:4:5 ath0

I then perform an ARP-reinjection attack:

aireplay -3 -b 00:09:4B:XX:XX:XX -h 0:1:2:3:4:5 ath0

The "Read X packets" count then increases far faster than airodump or kismet report packets coming in. Once 1 ARP packet has been found, the "sent X packets" starts increasing rapidly, as does the "got X ARP requests". The ARP requests quickly hits 1024.

The IVs increase more rapidly in airodump now - but when I look into the file, these new IVs are simply the replayed ARP requests from 0:1:2:3:4:5. Each one of these has a different IV shown in ethereal.

It appears as if aireplay thinks these are new ARP requests, which is why the count increases to 1024 so quickly.

Is the hardware increasing the IVs, or is it a software bug?

Edit

I've now tried with unpatched madwifi-cvs-20050814, and the "Read x packets" increases far more slowly - at about the rate that kismet or airodump report the packets come in.

I also tried the latest madwifi-cvs-20050825 (unpatched, because there is no patch), and the packet count shoots up.

I also tried all of them using "sysctl -w dev.ath0.rawdev=1", and then using the ath0raw interface, but this appears exactly the same.

Edit 2

Appears to be an issue with having to use ath0raw with dev.ath0.rawdev_type=0 (not prism headers). I can now re-inject without IVs changing, and monitor at the same time. Problems with "malformed packets" - I think this is ethereal having issues with the CRC on the end.

devine

Looks like the driver and/or the card is somewhat re-encrypting the packets. Does "iwconfig ath0 key off" help ? Also, aireplay automatically enables rawdev_type=1. Try changing this to rawdev_type=0 in the aireplay.c source.

cybergibbons

Ok, I've played around some more. I checked that aireplay was changing the sysctls as expected, and it was. So using ath0 or ath0raw makes no difference.

With:

aireplay -2 -r arp1.cap ath0

And capturing using ethereal on ath0raw, the replayed packet (arp1.cap contains one packet only) is exactly as recorded, no change in sequence number or IV or anything.

However, with the -3 ARP reinjection, no matter what I use, I get the problem where the packet sent out has a different IV, and hence it gets recorded as a new ARP request.

Both use the same send_packet function, so it is either in the way that the h80211 variable is written, or in the way that the card is dealt with.

It looks as if the madwifi drivers themselves are partly to blame, as if dev.ath0.rawdev_type=1 is set, I get total rubbish in ethereal. I also seem to receive my own packets, whatever the case (not sure if this is supposed to happen or not). I'm also getting a lot of PHY errors showing in athstat - I will try to take a closer look tommorrow to isolate some of these issues.

cybergibbons

Ok, I've spent all day playing around with different drivers, hacked aireply, and so on. It's only really served to confuse me.

Several things:
*Something is up with madwifi because I get a lot of PHY errors caused by timing.
*I can connect to B and G networks fine, and they are fast and reliable, using any of the madwifi drivers (aircrack July, August and latest CVS). Can't really see any difference between onoe, sample and the other one.
* Depending on settings (ath0 or ath0raw, rawdev_type 0 or 1), I get different captures.
* Depending on the program I use, I get different captures.
* dev.ath0.rxfilter doesn't seem to change anything
* If I use my Orinoco (Hermes) for capture, it looks different again.
* Sometimes using -2 the IVs stay the same, sometimes they don't, I was too lazy to write stuff down, so I need to confirm what happens when.

It's all quite frustrating, I can't put my finger on the problem, and I know it's quite specific to me, so can't really expect people to do my work for me. And it's quite interesting learning about all this stuff anyway.

cybergibbons

Now I am physically hacking the outside of the d-link card off so that I can have both the orinoco and d-link in the laptop at the same time. Not sure if this will cause the front end of the receiving card to be overloaded, but it should make life a bit easier. It will certain look like I know what I'm doing.

If this is getting too verbose, or not really on the subject of bugs with aircrack, then a moderator can move these posts into a seperate thread.

Weifei

I don't mean to be rude why does this discussion (as cybergibbons has already stated) takes place in a thread about bugreports of an old beta-version (aircrack 2.2beta-x? Non-beta (latest is 2.2.23) versions are available for ages (?)

If this thread is intended for aircrack-bug-reports in general the subject should be changed (have the beta-x removed, please)

Cheers
Weifei

devine

Consider buying an usb rt2570 card, like the DWL-G122 or tthe WUSB54G. There are quite cheap, and work pretty well for monitor/injection (patching required).

No problem, I'm very interested to learn more about your madwifi problem (I couldn't reproduce it myself).

cybergibbons

I now also have a DWL-G122, which seems to work well. Slightly less sensitivity than the other cards, but 100% functional. That's 4 wireless adapters in one laptop now. Hopefully I can use experience with the USB adapter to find problems with the Atheros card.

I'll have a play with it and see what I can work out.

cybergibbons

Many apologies - this is my mistake - I think.

Aireplay was taking a packet, re-writing it with the destination address as broadcast, and FromDS=0, ToDS=1. This is expected. It was then sending out that packet, with that IV. This is also expected.

I then receive back the same packet - yet it has been re-encrypted. I thought that the AP would just re-broadcast the packet, as it has the source and destination address there. Maybe check that the WEP key is right, but not tamper with the packet. I thought the reason behind ARP re-injection was that you got the reponses with different IVs, not that the AP broadcast it with different IVs, otherwise re-injecting any packet with any valid source/address would cause IV increases.

So are these APs playing about with stuff they wouldn't? If so, and I think it is, is this not a serious vulnerability, as any replay will cause IV generation?

devine

It's a very serious vulnerability; with any AP that does re-encrypt the packet, you can generate IVs with just any WEP data packet by changing the type as 'ToDS', the source MAC as the fake client and the destination MAC as the broadcast address. That's why attack 3 sometimes goes up to 1024 ARPs very quickly, because the AP actually re-encrypts the ARP request we're sending. This would be called the "any data re-broadcast attack"; please see http://www.cr0.net:8040/code/network/aircrack/#q193 for more details and usage instructions for attack 2.

cybergibbons

How common would you say this is? It threw me at first, as it seemed like very odd behavior. I probably missed any ARP responses in the traffic, and hence thought something was going wrong.

Anyways, what is the point in decrypting the packet? These are very simple APs. Even acting as part of a DS, there is no need to decrypt and re-broadcast. I presume I should get onto the manufacturer for some firmware updates as well.

Nonetheless, there are no bugs in the aircrack suite that I can see. Thanks for the brilliant work. My understanding of drivers and 802.11 is much better now anyway.

k0b3_bryant

hi there, greeting to all, this is my first post in this forum.

cybergibbons, i hv a card (D-Link DWL-G650 rev c3) which is simliar with urs one (i think).i'd installed the madwifi-cvs driver for the card and everything works fine for me till now.But i'm having trouble whenever i wan to run the airodump with my card.

here is the problem that i encounter:

1)b4 running the airodump, the iwconfig shows the correct ESSID and it's connected to the access point in G mode.

2)after tat i change my card to B mode:

iwpriv ath0 mode 2 channel 6
ifconfig ath0 up

3)then i switch my card to monitor mode as requested by the aircrack documnetation:

iwconfig ath0 mode monitor
ifconfig ath0 up

and the problem happened here, when i 'ifconfig ath0', the H/W address appears to be invalid:

H/w add:00-13-40-9C-1B-4C-00-00-00-00

and also the 'iwconfig ath0' shows me tat the card is disconnected from my access point.

...
IEEE 802.11b
Mode:Monitor
ESSID:00:00:00:00:00:00
Bit rate:0 Mbps
...

4)Ok, after setup all the things, i started my airodump, n it's running, but it caputers the IV's data slowly without connecting to any station...????

since you r using the same card with me, so i need your advice to solve this problem and how u configure your card to make it works with airodump ...

i really appreciate for your help !!