Results 1 to 4 of 4

Thread: ARPs and WEP doubts

  1. #1
    Just burned his ISO
    Join Date
    May 2007
    Posts
    6

    Default ARPs and WEP doubts

    Hello everyone,

    I was dumping with airodump on a locked channel, and started an arp replay with aireplay on another terminal.

    It picked one flying ARP packet and started playing it back. So on the airodump terminal I saw the data packets rising. Everything was going well, until the packets stopped coming on the airodump.

    I assume the router stopped responding to the replayed ARP packet. I still see the router's beacons, so it is still up. I stopped replaying that packet, and restarted aireplay after a while... Deauthed a client and another ARP was caught and started being replayed. But this time there are no packets coming on airodump. I assume the router isn't responding to the new ARP either, right?

    I also tried replaying some ARPs from files saved by aireplay. No success either.

    Why is that? Why doesn't the router respond to my little ARPs anymore?

    I tried to fakeauth without success. But I believe it is not necessary, since there is a real client generating ARPs. But it is weird that I did fakeauthed before successfully.

    Any thoughts?

    Thanks!

  2. #2
    Member Eristic's Avatar
    Join Date
    Aug 2006
    Posts
    188

    Default

    Quote Originally Posted by Sharper View Post
    Hello everyone,

    I was dumping with airodump on a locked channel, and started an arp replay with aireplay on another terminal.

    It picked one flying ARP packet and started playing it back. So on the airodump terminal I saw the data packets rising. Everything was going well, until the packets stopped coming on the airodump.

    I assume the router stopped responding to the replayed ARP packet. I still see the router's beacons, so it is still up. I stopped replaying that packet, and restarted aireplay after a while... Deauthed a client and another ARP was caught and started being replayed. But this time there are no packets coming on airodump. I assume the router isn't responding to the new ARP either, right?

    I also tried replaying some ARPs from files saved by aireplay. No success either.

    Why is that? Why doesn't the router respond to my little ARPs anymore?

    I tried to fakeauth without success. But I believe it is not necessary, since there is a real client generating ARPs. But it is weird that I did fakeauthed before successfully.

    Any thoughts?

    Thanks!
    First, you guys are so lazy its rediculous. That said...

    http://aircrack-ng.org/doku.php?id=i...don_t_increase

    Troubleshooting Tips:

    Troubleshooting tips
    There will be occasions that even though it says you are associated and the keep alive packets are flowing nicely, the association breaks. So you might have to stop and rerun the command.
    With some drivers, the wireless card MAC address must be the same as MAC address you are injecting. So if fake authentication is still not working then try changing the card MAC to the same one you are trying to authenticate with. A typical package to do this is macchanger. Search the forums or the internet for the details and other options. Changing the MAC address is beyond the scope of this tutorial. See How do I change my card's MAC address?

    Some access points are configured to only allow selected MAC access to associate and connect. If this is the case, you will not be able to successfully do fake authentication unless you know one of the MAC addresses on the allowed list. Thus ,the advantage of the next technique (interactive replay) is that it gets around this control.

    To determine if MAC access control is in place, enter the following command:
    Code:
     tcpdump -n -vvv -s0 -e -i ath0 | grep -E "(RA:00:c0:ca:17:db:6a|Authentication|ssoc)
    "You will have to change “00:c0:ca:17:db:6a” to the injection MAC address. It is case sensitive and typically lowercase. You may need to look at the tcpdump output without the grep filter to verify the case.

    When you are trying to do fake authentication, the exchange should look identical to the wep.open.system.authentication.cap file which comes with the aircrack-ng software. This file can be read into tcpdump as...

    Code:
    tcpdump -n -e -vvv -r wep.open.system.authentication.cap
    Basically you should see two authentication packets and then two association packets. If your real life capture does not contain all four packets and your fake authentication is failing then there is a MAC filter in place. In this case, you must use the MAC address of a client already associated with the AP. To do this, change the MAC address of your card to it. See How do I change my card's MAC address?

    A normal MAC address looks like this: 00:09:5B:EC:EE:F2. The first half (00:09:5B) of each MAC address is the manufacturer. The second half (EC:EE:F2) is unique to each network card. Many access points will ignore invalid MAC addresses. So make sure to use a valid wireless card manufacturer code when you make up MAC addresses. Otherwise your packets may be ignored.
    Here is an example of what a failed authentication looks like:
    Code:
    8:28:02  Sending Authentication Request
    18:28:02  Authentication successful
    18:28:02  Sending Association Request
    18:28:02  Association successful :-)
    18:28:02  Got a deauthentication packet!
    18:28:05  Sending Authentication Request
    18:28:05  Authentication successful
    18:28:05  Sending Association Request
    18:28:10  Sending Authentication Request
    18:28:10  Authentication successful
    18:28:10  Sending Association RequestNotice the “Got a deauthentication packet” and the continuous retries above.
    An alternate approach is to replay packets from a wireless client which is currently associated with the AP. This eliminates the need to use fake authentication since you be piggy backing on client MAC address which is already associated with the AP.

    Use the interactive replay attack instead. We are going to look for an arp packet coming from an already associated wireless client going to the access point. We know that this arp packet will be rebroadcast by the AP and generate an IV. ARP packets coming from a wireless client are normally 68 bytes long with a broadcast MAC address.

    So we construct a request which selects the packets we are looking for:
    Code:
    aireplay-ng -2 -a <bssid MAC address> -d FF:FF:FF:FF:FF:FF -m 68 -n 68 -t 1 -f 0 <interface>
    Where: -d FF:FF:FF:FF:FF:FF - broadcast - m 68 - minimum packet length of 68 - n 68 - maximum packet length of 68 - t 1 - packet is going to the access point - f 0 - packet is not coming from the access point

    This will display each packet captured for you to inspect before being used. Just ensure the packet you select is one of the wireless clients already associated with the access point.

    Here is an example:
    Code:
    aireplay-ng -2 -a 00:14:6C:7E:40:80 -d FF:FF:FF:FF:FF:FF -m 68 -n 68 -t 1 -f 0 ath0
    
    Read 202 packets...
    
          Size: 68, FromDS: 0, ToDS: 1 (WEP)
    
               BSSID  =  00:14:6C:7E:40:80
           Dest. MAC  =  FF:FF:FF:FF:FF:FF
          Source MAC  =  00:0F:B5:AB:CB:9D
    
          0x0000:  0841 d400 0014 6c7e 4080 000f b5ab cb9d  .A....l~@.......
          0x0010:  ffff ffff ffff a00f 010a dd00 a795 2871  ..............(q
          0x0020:  59e5 935b b75f bf9d 718b d5d7 919e 2d45  Y..[._..q.....-E
          0x0030:  a89b 22b3 2c70 b3c3 03b0 8481 5787 88ce  ..".,p......W...
          0x0040:  b199 6479                                ..dy
    
    Use this packet ? y
    
    Saving chosen packet in replay_src-0124-120102.cap
    You should also start airodump-ng to capture replies.Although you can’t see it, the above command started generating the IVs. As usual, run airodump-ng and aircrack-ng.
    Some access points have a setting to disable wireless client to wireless client communication (called at least on Linksys “AP isolation”). If this is enabled then all the techniques above will not work. The only approach is to use the techniques outlined in another one of my tutorials: How to crack WEP via a wireless client.

  3. #3
    Moderator theprez98's Avatar
    Join Date
    Jan 2010
    Location
    Maryland
    Posts
    2,533

    Default

    Quote Originally Posted by Eristic View Post
    First, you guys are so lazy its rediculous.
    QFT

    Google and the forum search function are their best friends, and they don't even know it. What's worse is when there are current, existing threads dealing with the same subject, and someone starts a new one asking the same thing. That doesn't even require searching!!!
    "\x74\x68\x65\x70\x72\x65\x7a\x39\x38";

  4. #4
    Just burned his ISO
    Join Date
    May 2007
    Posts
    6

    Default

    Eristic, thanks for the information.

    I already changed the wifi0 mac to the one I was spoofing.

    I don't know if you guys read it en passant or if I didn't express myself very well. What I was describing was what I believe was a strange behavior.

    Today I took another look at the situation... While monitoring with airodump (locked channel) I can see the AP sending beacons for a while (power level around 11), then it stops... Not a sign of life... Then after a minute or a few more it reappears... Stays for a while, the it's gone again.

    The AP is a Linksys 00:18:39...

    Could that be that the tx power of the AP was reduced? Or is there some economode that the AP enters when there is no client?

    Maybe my card has some unresolved psychological issues... It's an AR5212. I will try another one and see how it behaves.

    In the meantime, any thoughts are appreciated.

    Thanks again.

Posting Permissions

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