i_am_injecting_but_the_ivs_don_t_increase
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
i_am_injecting_but_the_ivs_don_t_increase [2007/01/28 18:45] – cosmetic change mister_x | i_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.01 January 28, 2007 (Change log is at the end) \\ | + | Version: 1.09 September 10, 2009\\ |
By: darkAudax | By: darkAudax | ||
- | ==== Introduction ==== | + | |
- | A frequent | + | ===== Introduction |
+ | 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 | Experiment with your home wireless access point to get familiar with these ideas and techniques. If you do not own a | ||
- | |||
- | I would like to acknowledge and thank the [[http:// | ||
- | Please send me any constuctive feedback, positive or negative. Additional troubleshooting ideas and tips are especially welcome. | ||
- | ==== Solution | + | Please send any constructive feedback, positive or negative. Additional troubleshooting ideas and tips are especially welcome. |
+ | |||
+ | ===== Assumptions | ||
First, this solution assumes: | First, this solution assumes: | ||
- | * You are using drivers patched for injection. | + | * You are using drivers patched for injection. |
- | * You have started the interface in monitor mode on the same channel as the access point. Run " | + | * You have started the interface in monitor mode on the same channel as the access point. Run " |
ath0 IEEE 802.11b | ath0 IEEE 802.11b | ||
Line 27: | Line 28: | ||
* You have started airodump-ng on the same channel as the access point. | * You have started airodump-ng on the same channel as the access point. | ||
- | * You are physically close enough to send and receive access point packets. | + | * You are physically close enough to send and receive access point packets. |
- | * You are using v0.7 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. |
+ | * 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. | In order for an access point to accept a packet, the source MAC address must already be associated. | ||
- | The lack of association with the access point is the single biggest reason why injection fails. | + | The lack of association with the access point is the single biggest reason why injection fails. |
Here is your typical clue. | Here is your typical clue. | ||
Line 58: | Line 63: | ||
11: | 11: | ||
+ | | ||
+ | | ||
Notice that the access point (00: | Notice that the access point (00: | ||
- | If you want to select only the DeAuth packets with tcpdump then you can use: " | + | If you want to select only the DeAuth packets with tcpdump then you can use: " |
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 68: | Line 75: | ||
* Associate the source MAC address you will be using during injection with the access point. | * Associate the source MAC address you will be using during injection with the access point. | ||
* Replay packets from a wireless client which is currently associated with the AP. | * Replay packets from a wireless client which is currently associated with the AP. | ||
+ | \\ | ||
To associate with an access point, use fake authentication: | To associate with an access point, use fake authentication: | ||
Line 85: | Line 92: | ||
Where: | Where: | ||
- | 6000 - Reauthenticate very 6000 seconds. | + | * 6000 - Reauthenticate very 6000 seconds. |
- | -o 1 - Send only one set of packets at a time. Default is multiple and this confuses some APs. | + | |
- | -q 10 - Send keep alive packets every 10 seconds. | + | |
Success looks like: | Success looks like: | ||
Line 98: | Line 105: | ||
# and so on. | # and so on. | ||
- | At this point, you can start another session and try the packet injection. | + | ===== Injection Techniques ===== |
- | ==== Troubleshooting tips ==== | + | Once you have successfully associated with the AP, try one or more of the following packet injection techniques techniques. |
- | * 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 techniques, use airodump-ng to capture |
- | * 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. | + | ==== ARP Request Replay ==== |
- | * Some access points are configure to only allow selected MAC access to associate and connect. | + | Use the standard [[arp-request_reinjection|ARP request replay]] |
- | * A normal MAC address looks like this: 00: | + | This assumes that you have a wired or wireless client active. |
- | Here is an example of what a failured authentication looks like: | + | ==== Replay Previous ARP ==== |
- | 8: | + | |
- | 18: | + | |
- | 18: | + | |
- | 18: | + | |
- | 18: | + | |
- | 18: | + | |
- | 18: | + | |
- | 18: | + | |
- | 18: | + | |
- | 18: | + | |
- | 18: | + | |
- | Notice the "Got a deauthentication | + | You can replay an ARP which was previously captured. |
+ | |||
+ | |||
+ | ==== Use "-p 0841" Technique ==== | ||
+ | |||
+ | You can replay any data packet | ||
+ | |||
+ | 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 | ||
+ | |||
+ | 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 166: | 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" | ||
- | ==== Change Log ==== | + | ===== 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. | ||
+ | |||
+ | * Some access points are configured to only allow selected MAC access to associate and connect. | ||
+ | |||
+ | To determine if MAC access control is in place, enter the following command: | ||
+ | |||
+ | | ||
+ | |||
+ | You will have to change " | ||
+ | |||
+ | When you are trying to do fake authentication, | ||
+ | |||
+ | | ||
+ | |||
+ | Basically you should see two authentication packets and then two association packets. | ||
+ | |||
+ | * A normal MAC address looks like this: 00: | ||
+ | |||
+ | Here is an example of what a failed authentication looks like: | ||
+ | 8: | ||
+ | 18: | ||
+ | 18: | ||
+ | 18: | ||
+ | 18: | ||
+ | 18: | ||
+ | 18: | ||
+ | 18: | ||
+ | 18: | ||
+ | 18: | ||
+ | 18: | ||
+ | |||
+ | Notice the "Got a deauthentication packet" | ||
+ | |||
+ | * Some access points have a setting to disable wireless client to wireless client communication (called at least on Linksys "AP isolation" | ||
- | * January 28/2007 v1.01: Expand how to check if the card is in monitor mode. | ||
- | * January 24/2007 v1.00: Initial Release | ||
i_am_injecting_but_the_ivs_don_t_increase.txt · Last modified: 2018/03/11 20:14 by mister_x