Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Failure to capture full WPA handshake

  1. #1
    Just burned his ISO
    Join Date
    Jul 2008
    Posts
    5

    Default Failure to capture full WPA handshake

    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

  2. #2
    Developer
    Join Date
    Mar 2007
    Posts
    6,124

    Default

    At least some of our complete n00bs can read the rules and not double post.

  3. #3
    Just burned his ISO
    Join Date
    Jul 2008
    Posts
    5

    Default

    Lol yeah, sorry about that man That 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*

  4. #4
    Senior Member
    Join Date
    Apr 2008
    Posts
    2,008

    Default

    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.

  5. #5
    Just burned his ISO
    Join Date
    Jul 2008
    Posts
    5

    Default

    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?

  6. #6
    Member m1cha3l's Avatar
    Join Date
    May 2008
    Posts
    208

    Default

    have you also made sure you are capturing on the correct band? using the -b option in airodump?

  7. #7
    Just burned his ISO
    Join Date
    Jul 2008
    Posts
    5

    Default

    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.

  8. #8
    Senior Member
    Join Date
    Apr 2008
    Posts
    2,008

    Default

    Quote Originally Posted by havok_ View Post
    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?
    Any discussion related to intercepting/injecting/accessing an AP you do not have the right to access is prohibited on this forum, and the rule will, and is on a daily basis, enforced by the moderators.
    -Monkeys are like nature's humans.

  9. #9
    Just burned his ISO
    Join Date
    Jul 2008
    Posts
    5

    Default

    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.

  10. #10
    Member m1cha3l's Avatar
    Join Date
    May 2008
    Posts
    208

    Default

    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

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •