At least some of our complete n00bs can read the rules and not double post.![]()
Hi guys, i've just registered here and am posting in the Newbie Area because of the 3 day wait time but I wouldn't consider myself a complete noob on this topic.
Okay so first off i'm using the BackTrac 3.0 BETA version and it's great, thanks for all the great work
Now onto the problem....Basically i'm playing around with the WPA encryption on my AP at home but i've gotten kind of stuck at the crutial point of trying to capture the handshake. I've done what I feel has been a lot of research on the topic so i'll lay out what i've done so far...
These are the commands I run roughly (off the top of my head):
airmon-ng start wlan0 (put the card in monitor mode)
airdump-ng --channel X --bssid MACOFMYAP -w out wlan0 (capture packets from my AP)
aireplay-ng -0 1 -a MACOFMYAP -c MACOFCLIENTCONNECTED wlan0
As aireplay runs I notice there is packet loss between the client and the AP so it appears to be working as intended, and after a few seconds the data seems to send as normal. Airdump doesn't show that it has received a WPA handshake and checking the dump file with aircrack it shows 0 handshakes aswell.
I have analysed the capture file with wireshark and it seems to only recieve 2 EAPOL packets from the AP to the client but not the other way round..the counter stays at 1 but does not increment.
I've read around and this problem seems like it can be caused by the cards being in different modes so I tried setting the card rate with iwconfig to 1, 2, 5.5, 11, 36, 52 etc etc but none seemed to work. I read something about changing the "modulation" but havn't tried this as of yet...this post is getting long as but there is still more...I do have another computer that I could use other than my capturing computer and the laptop i'm using as the client for the AP which I could possible use to either inject/capture so that I don't have a single computer doing both but at the moment i'm having trouble getting wireshark to work in windows on this computer or to get backtrack to even boot on that computer........
Last thing is I have successfully run through a complete WEP crack with this computer so I can only assume that capturing and injecting is working as required, I have good reception from the AP and I don't think it's too close as to scramble packets either.
So just wondering if anyone may be able to shed some light on the situation and see where I might be going wrong, maybe once my 3 days is up this should be moved to the "pentesting" forum.
Okay think thats everything, cheers if you read this far![]()
At least some of our complete n00bs can read the rules and not double post.![]()
Lol yeah, sorry about that manThat page came up and dissapeared so fast then my net cut out for a minute so I thought my message wasn't sent.....doh *bangs head on monitor*
A pleasure to read such a well written post with all the steps as well as problems clearly stated.
Normally I would assume that the problem is that you are to far away from the client to be able to capture it’s side of the handshake, but as you state that you use only one machine, and two wireless cards I assume (?), to do both the capturing/injection and play the role of the actual client this can hardly be the case.
However, I found the part of your post describing the actual setup a bit confusing and in case I misinterpreted it and you do already use the laptop as the client you will most likely have to move it closer to your capturing computer to be able to intercept the client side of the handshake.
-Monkeys are like nature's humans.
Cheers man, it is infact two different computers and they are sufficiently close i'm pretty sure, i have done a bit of testing with distance and it doesn't seem to make a difference. I'm just hoping some one will have some miracle cure that i've missed...I read some where else that another thing to do is set your MAC to the MAC of the connected client and that still had problems so i'm a bit stumped.
One more thing...to help with my testing with some different hardware to what I have available what are the legalities surrounding purely the capture of the WPA handshake from an AP I don't own? I can see how it seems reasonably unethical but if I have no intention to actually apply any sort of crack to it and use the resulting key is it outside the rules of this forum to discuss the hypothetical capture of such a handshake?
have you also made sure you are capturing on the correct band? using the -b option in airodump?
Do you mean the channel or the filtered MAC address? Is the -b option the BSSID of the AP? If so then yeah i'm filtering just for that AP and also set airodump to just listen on one channel, i'm not sure if this guarantees that the card does actually sit just on one channel the whole time though or not...airodump reads "Channel 6" or whatever in the top left and doesn't change the whole time. Though after a while it sometimes comes up with a message on the right to the effect of something like "Static channel 10" which is definatly wrong...now that I think of it this might be the problem.
So how do I ensure my card is definatly on one channel only and doesn't switch?
Though this seems like it could be the solution I do seem to get the same results with the packets everytime I try which I don't think would be expected with channel hopping because it is pseudo-random it might pick up the 1st and 3rd parts of the handshake or whatever not always the 2 just from the AP.
Understood, yeah i've read quite a few threads where its happened so i'll steer well clear, cheers. Just thought it would be best to check the legality of that first.
no i mean the band not the bssid.
i have highlighted the relevent section
Code:bt ~ # airodump-ng Airodump-ng 1.0 rc1 r1083 - (C) 2006,2007,2008 Thomas d'Otreppe Original work: Christophe Devine http://www.aircrack-ng.org usage: airodump-ng <options> <interface>[,<interface>,...] Options: --ivs : Save only captured IVs --gpsd : Use GPSd --write <prefix> : Dump file prefix -w : same as --write --beacons : Record all beacons in dump file --update <secs> : Display update delay in seconds --showack : Prints ack/cts/rts statistics -h : Hides known stations for --showack -f <msecs> : Time in ms between hopping channels --berlin <secs> : Time before removing the AP/client from the screen when no more packets are received (Default: 120 seconds). -r <file> : Read packets from that file Filter options: --encrypt <suite> : Filter APs by cipher suite --netmask <netmask> : Filter APs by mask --bssid <bssid> : Filter APs by BSSID -a : Filter unassociated clients By default, airodump-ng hop on 2.4Ghz channels. You can make it capture on other/specific channel(s) by using: --channel <channels>: Capture on specific channels --band <abg> : Band on which airodump-ng should hop -C <frequencies> : Uses these frequencies in MHz to hop --cswitch <method> : Set channel switching method 0 : FIFO (default) 1 : Round Robin 2 : Hop on last -s : same as --cswitch --help : Displays this usage screen