WPA/ WPA2 crack not working

[sheerdil]

@TAPE: Fine i will post all the commands that I am following probably with screenshots soon. I have seen the links u have provided and truly saying doing exactly the same, but is always stuck on handshake or #Data step i.e. nothing happens after "airodump-ng -c 11 --bssid <<bssid>> -w capture mon0" only beacons keeps on increasing, the #Data doesn't increase or WPA handshake doesn't appear at all.

@strakar: actually i meant the "#Data". And the handshake that I mentioned happened during airodump-ng command is when I manually connect to my wifi i.e I provide the password and connected to my wifi for few seconds, due to which #Data increased and WPA handshake happened. After this I used aircrack-ng and I worked perfectly. Also have seen many videos.


One thing I want to bring in front. I thoroughly checked the site "www.aircrack-ng.org". There I came across that atheros 9k and 5k chipset is not supported and on some other page wireless adapter similar to mine were marked compatible. . Do I have to install driver patch or something more before aircrack.

Side note: Tested the injection test, every command worked fine [except the airserv-ng test( aireplay-ng -9 127.0.0.1:666), that too worked when "airserv-ng -d mon0" was running in background.]

Links: http://www.aircrack-ng.org/doku.php?...bility_drivers <<<ath9k mentioned compatible in linux section>>>
http://www.aircrack-ng.org/doku.php?...st_card_to_buy <<<<See---"Also, with ath5k comes ath9k, introduced for Atheros 802.11n capable chipsets. The ath5k and ath9k are not compatible as they have different designs." >>>

[sheerdil]

Screenshots of WPA commands I am using.
1. airmon-ng
2. airmon-ng start wlan0

Screenshot-1.jpg

3. airodump-ng mon0. In below image my ssid is shown.
Screenshot-2.jpg

4. Now used command airodump-ng -c <channel> -w <name> --bssid<my bssid> mon0
Screenshot-4.jpg

The last image shows 20 mins only, I have tested for hours but nothing happens,
also I have attached aireplay command image just for additional info

[TAPE]

The last image is too small, cannot see what you are doing.
Looks like it is an aireplay command, also mention what that is.

> Connect to network with 1 card
> Start monitoring that netowork with another card
> Force a handshake by disconnecting the 1st network

[Bl4cks4b3r]

Screenshots of WPA commands I am using.
1. airmon-ng
2. airmon-ng start wlan0

Screenshot-1.jpg

3. airodump-ng mon0. In below image my ssid is shown.
Screenshot-2.jpg

4. Now used command airodump-ng -c <channel> -w <name> --bssid<my bssid> mon0
Screenshot-4.jpg

The last image shows 20 mins only, I have tested for hours but nothing happens,
also I have attached aireplay command image just for additional info

For WPA after the airodump all you need to do is, aireplay-ng -0 2 -a (BSSID) mon0 -- that will get you your handshake.. (In theory you can replace 2 with 1, but sometimes one just wont cut it for some reason. This also means you can use 5, 10, 100, or 0 for infinite.)

[sheerdil]

@ Bl4cks4b3r:- already done this but handshakes didn't comes up.

The last image is too small, cannot see what you are doing.
Looks like it is an aireplay command, also mention what that is.

> Connect to network with 1 card
> Start monitoring that netowork with another card
> Force a handshake by disconnecting the 1st network

Actually I combined 2 images, sorry for that. 1st is airodump-ng -c <channel> -w <name> --bssid<my bssid> mon0 and 2nd image is of aireplay-ng -0 5 -a<bssid> -c<my hardware address> mon0
Screenshot-5.jpg

about the three steps you mentioned, is somewhat difficult as I have to invest in more money for that, but will definitely try.


No one said about the chipset thing, please someone see that also. That might be the problem.

[ternarybit]

Regardless of what some say, capturing handshakes is not always trivial. On very quiet networks, it may become quite a challenge. Send the aireplay-ng deauth command Bl4cks4b3r mentioned above; it will list the number of ACK packets received from the AP, and airodump-ng should capture those ACKs. If this happens, it just may be that you're attacking a very, very quiet network with no associated clients, and, well, you're out of luck.

Successfully capturing handshakes requires the attacker to be within range of both associating client *and* AP, to capture all 4 packets of the handshake properly. Again, in my experience this is not nearly as trivial as some guides make it seem like, at least for inactive networks. Good luck.