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/04/27 18:53] – updated to reflect v.8 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.02 February 12007 (Change log is at the end) \\+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 constuctive 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:
-  * You are using drivers patched for injection. You can sniff the packets with [[http://www.wireshark.org|Wireshark]] to confirm you are in fact injecting+  * You are using drivers patched for injection. Use the [[injection_test|injection test]] to confirm your card can inject prior to proceeding
-  * You have started the interface in monitor mode on the same channel as the access point. Run "iwconfig" and confirm that the interface you plan to use is in monitor mode, on the correct channel (frequency), correct speed, etc.  In monitor mode, the "Access Point" is your card MAC address. The output would look similar to this:+  * You have started the interface in monitor mode on the same channel as the access point. Run "iwconfig" and confirm that the interface you plan to use is in monitor mode, on the correct channel (frequency), correct speed, etc.  In monitor mode, the "Access Point" is your card MAC address. NOTE: Only madwifi-ng drivers display the card MAC in the AP field, other drivers do not do this.  The output would look similar to this:
  
   ath0      IEEE 802.11b  ESSID:""  Nickname:""   ath0      IEEE 802.11b  ESSID:""  Nickname:""
Line 29: Line 28:
  
   * 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 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 using v0.of aircrack-ng. If you use a different version then some of the command options may have to be changed.+  * 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.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.
  
-The lack of association with the access point is the single biggest reason why injection fails.  OK, lets look at the symptons so you confirm that this is happening.  Then we will look at possible solutions.+The lack of association with the access point is the single biggest reason why injection fails.  OK, lets look at the symptoms so you confirm that this is happening.  Then we will look at possible solutions.
  
 Here is your typical clue. Here is your typical clue.
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.
  
-If you want to select only the DeAuth packets with tcpdump then you can use: "tcpdump -n -e -s0 -vvv -i ath0 | grep DeAuth" You may need to tweak the phrase "DeAuth" to pick out the exact packets you want.+If you want to select only the DeAuth packets with tcpdump then you can use: "tcpdump -n -e -s0 -vvv -i ath0 | grep -i DeAuth" You may need to tweak the phrase "DeAuth" to pick out the exact packets you want.
  
 So now that you know the problem, how do you solve it? So now that you know the problem, how do you solve it?
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.+==== 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.
  
-  * 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 manufactuer. 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 valid wireless card manufacturer code when you make up MAC addresses. Otherwise your packets may be ignored.+This assumes that you have a wired or wireless client active.  To speed things up, simply ping non-existent IP on your LAN.
  
-Here is an example of what a failured authentication looks like: +==== Replay Previous ARP ==== 
-  8:28:02  Sending Authentication Request + 
-  18:28:02  Authentication successful +You can replay an ARP which was previously captured.  See this [[arp-request_reinjection#usage_example|section]] for an example.
-  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.+ 
 +==== Use "-p 0841" Technique ==== 
 + 
 +You can replay any data packet captured in real time.  See this [[interactive_packet_replay#other_examples|section]] for an example. 
 + 
 +This assumes that there is at least one data packet broadcast by the AP or a wireless client. 
 + 
 + 
 + 
 +==== Use "-p 0841" Technique with Previous Data ==== 
 + 
 +You can combine the "-p 0841" technique 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 168: Line 180:
 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]].
  
-  * 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". 
  
  
-===== Change Log ===== +===== Troubleshooting tips ===== 
-  * February 1/2006 v1.02: Corrected some typos + 
-  * January 28/2007 v1.01: Expand how to check if the card is in monitor mode+  * There will be occasions that even though it says you are associated and the keep alive packets are flowing nicely, the association breaksSo you might have to stop and rerun the command. 
-  * January 24/2007 v1.00: Initial Release+ 
 +  * 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]]. 
  
i_am_injecting_but_the_ivs_don_t_increase.txt · Last modified: 2018/03/11 20:14 by mister_x