User Tools

Site Tools


i_am_injecting_but_the_ivs_don_t_increase

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
i_am_injecting_but_the_ivs_don_t_increase [2007/08/21 01:24] – added -i (case insensitive) in grep examples darkaudaxi_am_injecting_but_the_ivs_don_t_increase [2018/03/11 20:14] (current) – Removed link to trac mister_x
Line 1: Line 1:
 ====== Tutorial: I am injecting but the IVs don't increase! ====== ====== Tutorial: I am injecting but the IVs don't increase! ======
-Version: 1.07 August 202007\\+Version: 1.09 September 102009\\
 By: darkAudax By: darkAudax
 +
  
 ===== Introduction ===== ===== Introduction =====
-A frequent problem that problem that comes up is that packets are being injected but the IVs don't increase. This tutorial provides guidance on determining the root cause of the problem and how to fix it.+A frequent problem that comes up is that packets are being injected but the IVs don't increase. This tutorial provides guidance on determining the root cause of the problem and how to fix it.
  
 Experiment with your home wireless access point to get familiar with these ideas and techniques. If you do not own a   particular access point, please remember to get permission from the owner prior to playing with it. Experiment with your home wireless access point to get familiar with these ideas and techniques. If you do not own a   particular access point, please remember to get permission from the owner prior to playing with it.
-  
-I would like to acknowledge and thank the [[http://trac.aircrack-ng.org|Aircrack-ng team]] for producing such a great robust tool.  
-Please send me any constructive feedback, positive or negative. Additional troubleshooting ideas and tips are especially welcome. 
  
 +Please send any constructive feedback, positive or negative. Additional troubleshooting ideas and tips are especially welcome.
  
-===== Solution =====+===== Assumptions =====
  
 First, this solution assumes: First, this solution assumes:
Line 30: Line 29:
   * You have started airodump-ng on the same channel as the access point.  IE with the "-c <channel number" option.   * You have started airodump-ng on the same channel as the access point.  IE with the "-c <channel number" option.
   * You are physically close enough to send and receive access point packets.  Remember that just because you can receive packets from the access point does not mean you may will be able to transmit packets to the AP.  The wireless card strength is typically less then the AP strength.  So you have to be physically close enough for your transmitted packets to reach and be received by the AP.  You should confirm that you can communicate with the specific AP by following [[injection_test#hidden_or_specific_ssid|these instructions]].   * You are physically close enough to send and receive access point packets.  Remember that just because you can receive packets from the access point does not mean you may will be able to transmit packets to the AP.  The wireless card strength is typically less then the AP strength.  So you have to be physically close enough for your transmitted packets to reach and be received by the AP.  You should confirm that you can communicate with the specific AP by following [[injection_test#hidden_or_specific_ssid|these instructions]].
 +  * The injection techniques used in this tutorial depend on having one or more data packets.  If there are zero data packets coming from the AP or a client, then it is impossible to crack the WEP key.  The exception is to reuse a previously captured data packet.  You must meet one or more of these data packet requirements to be successful.
   * You are using v0.9 of aircrack-ng. If you use a different version then some of the command options may have to be changed.   * You are using v0.9 of aircrack-ng. If you use a different version then some of the command options may have to be changed.
  
 Ensure all of the above assumptions are true, otherwise the advice that follows will not work.  In the examples below, you will need to change **ath0** to the interface name which is specific to your wireless card. Ensure all of the above assumptions are true, otherwise the advice that follows will not work.  In the examples below, you will need to change **ath0** to the interface name which is specific to your wireless card.
 +
 +
 +===== Solution =====
  
 In order for an access point to accept a packet, the source MAC address must already be associated.  If the source MAC address you are injecting is not associated then the AP ignores the packet and sends out a "DeAuthentication" packet.  In this state, no new IVs are created because the AP is ignoring all the injected packets. In order for an access point to accept a packet, the source MAC address must already be associated.  If the source MAC address you are injecting is not associated then the AP ignores the packet and sends out a "DeAuthentication" packet.  In this state, no new IVs are created because the AP is ignoring all the injected packets.
Line 60: Line 63:
  
   11:04:34.360700 314us BSSID:00:14:6c:7e:40:80 DA:00:0f:b5:46:11:19 SA:00:14:6c:7e:40:80 DeAuthentication: Class 3 frame received from nonassociated station   11:04:34.360700 314us BSSID:00:14:6c:7e:40:80 DA:00:0f:b5:46:11:19 SA:00:14:6c:7e:40:80 DeAuthentication: Class 3 frame received from nonassociated station
 +  
 +  
  
 Notice that the access point (00:14:6c:7e:40:80) is telling the source (00:0f:b5:46:11:19) you are not associated.  Meaning, the AP will not process or accept the injected packets. Notice that the access point (00:14:6c:7e:40:80) is telling the source (00:0f:b5:46:11:19) you are not associated.  Meaning, the AP will not process or accept the injected packets.
Line 100: Line 105:
   # and so on.   # and so on.
  
-At this point, you can start another session and try the packet injection.  With luck you are properly associated and the injected packets cause the IVs to increase.  Keep an eye on the fake authentication to ensure your remain associated.  Then use airodump-ng to capture the IVs and aircrack-ng to obtain the WEP key.+===== Injection Techniques =====
  
-===== Troubleshooting tips =====+Once you have successfully associated with the AP, try one or more of the following packet injection techniques techniques.  With luck, you are properly associated and the injected packets cause the IVs to increase.  Keep an eye on the fake authentication to ensure your remain associated.
  
-  * 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.+For all of these techniquesuse airodump-ng to capture the IVs and aircrack-ng to obtain the WEP key.
  
-  * 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 [[faq#how_do_i_change_my_card_s_mac_address|How do I change my card's MAC address?]]+==== ARP Request Replay ====
  
-  * 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.+Use the standard [[arp-request_reinjection|ARP request replay]] technique.
  
-To determine if MAC access control is in placeenter the following command:+This assumes that you have a wired or wireless client active.  To speed things upsimply ping a non-existent IP on your LAN.
  
-   tcpdump -n -vvv -s0 -e -i ath0 | grep -i -E "(RA:00:c0:ca:17:db:6a|Authentication|ssoc)"+==== Replay Previous ARP ====
  
-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.+You can replay an ARP which was previously captured.  See this [[arp-request_reinjection#usage_example|section]] for an example.
  
-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... 
  
-   tcpdump -n -e -vvv -r wep.open.system.authentication.cap+==== Use "-p 0841" Technique ====
  
-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 [[faq#how_do_i_change_my_card_s_mac_address|How do I change my card's MAC address?]]+You can replay any data packet captured in real time.  See this [[interactive_packet_replay#other_examples|section]] for an example.
  
-  * A normal MAC address looks like this: 00:09:5B:EC:EE:F2.  It is composed of six octets.  The first half (00:09:5B) of each MAC address is known as the Organizationally Unique Identifier (OUI).  Simply put, it is the card manufacturer. The second half (EC:EE:F2) is known as the extension identifier and is unique to each network card within the specific OUI. Many access points will ignore MAC addresses with invalid OUIs. So make sure you use valid OUI code code when you make up MAC addresses. Otherwise, your packets may be ignored by the Access Point.  The current list of OUIs may be found [[http://standards.ieee.org/regauth/oui/oui.txt|here]].+This assumes that there is at least one data packet broadcast by the AP or wireless client.
  
-Here is an example of what a failed authentication looks like: 
-  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 Request 
  
-Notice the "Got a deauthentication packetand the continuous retries above.+ 
 +==== Use "-p 0841" Technique with Previous Data ==== 
 + 
 +You can combine the "-p 0841technique with reading packets from a previous capture.  Simply use the technique from the previous section in combination with "-r <file name>". 
 + 
 +This assumes that you have a capture file containing one or more data packets. 
 + 
 + 
 +====  Replay Packets from a Wireless Client ====
  
 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. 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.
Line 179: Line 179:
  
 Although you can't see it, the above command started generating the IVs.  As usual, run [[airodump-ng]] and [[aircrack-ng]]. Although you can't see it, the above command started generating the IVs.  As usual, run [[airodump-ng]] and [[aircrack-ng]].
 +
 +
 +
 +===== 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 [[faq#how_do_i_change_my_card_s_mac_address|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:
 +
 +   tcpdump -n -vvv -s0 -e -i ath0 | grep -i -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...
 +
 +   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 [[faq#how_do_i_change_my_card_s_mac_address|How do I change my card's MAC address?]]
 +
 +  * A normal MAC address looks like this: 00:09:5B:EC:EE:F2.  It is composed of six octets.  The first half (00:09:5B) of each MAC address is known as the Organizationally Unique Identifier (OUI).  Simply put, it is the card manufacturer. The second half (EC:EE:F2) is known as the extension identifier and is unique to each network card within the specific OUI. Many access points will ignore MAC addresses with invalid OUIs. So make sure you use a valid OUI code code when you make up MAC addresses. Otherwise, your packets may be ignored by the Access Point.  The current list of OUIs may be found [[http://standards.ieee.org/regauth/oui/oui.txt|here]].
 +
 +Here is an example of what a failed authentication looks like:
 +  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 Request
 +
 +Notice the "Got a deauthentication packet" and the continuous retries above.
  
   * 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|How to crack WEP via a wireless client]].   * 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|How to crack WEP via a wireless client]].
  
  
i_am_injecting_but_the_ivs_don_t_increase.1187652299.txt.gz · Last modified: 2007/08/21 01:24 by darkaudax