Aireplay-ng

Aireplay-ng is used to inject frames.

The primary function is to generate traffic for the later use in aircrack-ng for cracking the WEP and WPA-PSK keys. There are different attacks which can cause deauthentications for the purpose of capturing WPA handshake data, fake authentications, Interactive packet replay, hand-crafted ARP request injection and ARP-request reinjection. With the packetforge-ng tool it's possible to create arbitrary frames.

Some drivers needs to be patched to be able to inject, don't forget to read Installing drivers.

It currently implements multiple different attacks:

• Attack 0: Deauthentication
• Attack 1: Fake authentication
• Attack 2: Interactive packet replay
• Attack 3: ARP request replay attack
• Attack 4: KoreK chopchop attack
• Attack 5: Fragmentation attack
• Attack 6: Cafe-latte attack
• Attack 7: Client-oriented fragmentation attack
• Attack 8: WPA Migration Mode
• Attack 9: Injection test

This section provides a general overview. Not all options apply to all attacks. See the details of the specific attack for the relevant details.

Usage:

 aireplay-ng <options> <replay interface>

For all the attacks except deauthentication and fake authentication, you may use the following filters to limit which packets will be presented to the particular attack. The most commonly used filter option is the “-b” to select a specific access point. For typical usage, the “-b” is the only one you use.

Filter options:

• -b bssid : MAC address, Access Point
• -d dmac : MAC address, Destination
• -s smac : MAC address, Source
• -m len : minimum packet length
• -n len : maximum packet length
• -u type : frame control, type field
• -v subt : frame control, subtype field
• -t tods : frame control, To DS bit
• -f fromds : frame control, From DS bit
• -w iswep : frame control, WEP bit

When replaying (injecting) packets, the following options apply. Keep in mind that not every option is relevant for every attack. The specific attack documentation provides examples of the relevant options.

Replay options:

• -x nbpps : number of packets per second
• -p fctrl : set frame control word (hex)
• -a bssid : set Access Point MAC address
• -c dmac : set Destination MAC address
• -h smac : set Source MAC address
• -e essid : For fakeauth attack or injection test, it sets target AP SSID. This is optional when the SSID is not hidden.
• -j : arpreplay attack : inject FromDS pkts
• -g value : change ring buffer size (default: 8)
• -k IP : set destination IP in fragments
• -l IP : set source IP in fragments
• -o npckts : number of packets per burst (-1)
• -q sec : seconds between keep-alives (-1)
• -y prga : keystream for shared key auth
• “-B” or “–bittest” : bit rate test (Applies only to test mode)
• “-D” :disables AP detection. Some modes will not proceed if the AP beacon is not heard. This disables this functionality.
• “-F” or “–fast” : chooses first matching packet. For test mode, it just checks basic injection and skips all other tests.
• “-R” disables /dev/rtc usage. Some systems experience lockups or other problems with RTC. This disables the usage.

The attacks can obtain packets to replay from two sources. The first being a live flow of packets from your wireless card. The second being from a pcap file. Standard Pcap format (Packet CAPture, associated with the libpcap library http://www.tcpdump.org), is recognized by most commercial and open-source traffic capture and analysis tools. Reading from a file is an often overlooked feature of aireplay-ng. This allows you to read packets from other capture sessions. Keep in mind that various attacks generate pcap files for easy reuse.

Source options:

• iface : capture packets from this interface
• -r file : extract packets from this pcap file

This is how you specify which mode (attack) the program will operate in. Depending on the mode, not all options above are applicable.

Attack modes (Numbers can still be used):

• - -deauth count : deauthenticate 1 or all stations (-0)
• - -fakeauth delay : fake authentication with AP (-1)
• - -interactive : interactive frame selection (-2)
• - -arpreplay : standard ARP-request replay (-3)
• - -chopchop : decrypt/chopchop WEP packet (-4)
• - -fragment : generates valid keystream (-5)
• - -test : injection test (-9)

Here are the differences between the fragmentation and chopchop attacks

Pros:

• Typically obtains the full packet length of 1500 bytes xor. This means you can subsequently pretty well create any size of packet. Even in cases where less then 1500 bytes are collected, there is sufficient to create ARP requests.
• May work where chopchop does not.
• Is extremely fast. It yields the xor stream extremely quickly when successful.

Cons:

• Need more information to launch it - IE IP address info. Quite often this can be guessed. Better still, aireplay-ng assumes source and destination IPs of 255.255.255.255 if nothing is specified. This will work successfully on most if not all APs. So this is a very limited con.
• Setup to execute the attack is more subject to the device drivers. For example, Atheros does not generate the correct packets unless the wireless card is set to the mac address you are spoofing.
• You need to be physically closer to the access point because if any packets are lost then the attack fails.
• The attack will fail on access points which do not properly handle fragmented packets.

Pros:

• May work where fragmentation does not work.
• You don't need to know any IP information.

Cons:

• Cannot be used against every access point.
• The maximum xor bits is limited to the length of the packet you chopchop against. Although in theory you could obtain 1500 bytes of the xor stream, in practice, you rarely if ever see 1500 byte wireless packets.
• Much slower then the fragmentation attack

Optimizing injection speed is more art than science. First, try using the tools “as is”. You can try using the “-x” parameter to vary the injection speed. Surprisingly, lowering this value can sometimes increase your overall rate.

You can try playing with the transmission rate. IE “iwconfig wlan0 rate 11M”. Depending on the driver and how you started the card in monitor mode, it is typically 1 or 11MBit by default. If you are close enough set it up to a higher value, like 54M, this way you'll get more packets per second. If you are too far away and the packets don't travel that far, try to lowering it to (for example) 1M.

These items apply to all modes of aireplay-ng.

Ensure you are using the correct monitor mode interface. “iwconfig” will show the wireless interfaces and their state. For the mac80211 drivers, the monitor mode interface is typically “mon0”. For ieee80211 madwifi-ng drivers, it is typically “ath0”. For other drivers, the interface name may vary.

Make sure there are no other VAPs running. There can be issues when creating a new VAP in monitor mode and there was an existing VAP in managed mode.

You should first stop ath0 then start wifi0:

 airmon-ng stop ath0
 airmon-ng start wifi0

or

 wlanconfig ath0 destroy
 wlanconfig ath create wlandev wifi0 wlanmode monitor

You enter the command and the command appears to hang and there is no output.

This is typically caused by your wireless card being on a different channel then the access point. Another potential cause of this problem is when you are using an old version of firmware on prism2 chipset. Be sure you are running firmware 1.7.4 or above to resolve this. See Prism card for more details. Firmware upgrade instruction can be found here.

As well, if you have another instance of aireplay-ng running in background mode, this can cause the second to hang if the options conflict.

See this thread: Aireplay freezes when injecting

Or see this thread: Commenting out RTC

Also check the previous entries.

When using a broadcom chipset and related driver you get something similar to:

 write failed: Cannot allocate memory wi_write(): Illegal seek

This is due to a bug in the original bcm43xx patch. Use SuD's modified patch to fix this. Alternatively, you can try using the b43 driver instead of bcm43xx. (B43 requires aireplay-ng 1.0-beta2 or newer; 1.0 rc1 or svn is recommended.)

Symptoms: The injection works but very slowly, at around 30 packets per second (pps). Whenever you start injecting packets, you get the following or similar kernel message:

“rtc: lost some interrupts at 1024Hz”

This message is then repeated continuously. There are a couple of workarounds. The first workaround is to start another instance of aireplay, then injection would increase to around 300 pps. The second workaround is to:

 rmmod rtc
 modprobe genrtc

or if you have rtc-cmos enabled in your kernel:

 rmmod rtc
 modprobe rtc-cmos

There is no solution at this point in time, just the workarounds. See this forum thread.

Being too close to the AP can dramatically reduce the injection rate. This is caused by packet corruption and/or overloading the the AP. See this thread for an example of the impact of being too close to the AP.

This is caused by having two or more instances of aireplay-ng running at the same time. The program will still work but the timing will be less accurate.

After entering an aireplay-ng command similar to:

 aireplay-ng -1 0 -e horcer -a 00:50:18:4C:A5:02 -h 00:13:A7:12:3C:5B ath0

You get a message similar to:

 The interface MAC (06:13:F7:12:23:4A) doesn't match the specified MAC (-h).
      ifconfig ath1 hw ether 00:13:A7:12:3C:5B

This occurs when the source MAC address for injection (specified by -h) is different then your card MAC address. In the case above, the injection MAC of 00:13:A7:12:3C:5B does not match the card MAC of 06:13:F7:12:23:4A. In some cases, but not all, this will cause injection to fail. That is why it gives you this warning. So it is always recommended that your injection MAC match the card MAC address.

Detailed instructions on changing the card MAC address can be found in the FAQ: How do I change my card's MAC address ?.

Many aireplay-ng commands require knowing the SSID. You will sometimes see “<length: ?>” as the SSID on the airodump-ng display. This means the SSID is hidden. The “?” is normally the length of the SSID. For example, if the SSID was “test123” then it would show up as “<length: 7>” where 7 is the number of characters. When the length is 0 or 1, it means the AP does not reveal the actual length and the real length could be any value.

To obtain the hidden SSID there are a few options:

• Wait for a wireless client to associate with the AP. When this happens, airodump-ng will capture and display the SSID.
• Deauthenticate an existing wireless client to force it to associate again. The point above will apply.
• Use a tool like mdk3 to bruteforce the SSID.

See this FAQ entry

When you enter the command, the system freezes or a line is printed with “Waiting for beacon frame” or “No such BSSID available” and then no further activity occurs.

There are many possible root causes of this problem:

• The wireless card is set to a channel which is different from the AP. Solution: Use iwconfig and confirm the card is set to the same channel as the AP.
• The card is scanning channels. Solution: Start airodump-ng with the “-c” or “–channel” parameter and set it to the same channel as the AP.
• The ESSID is wrong. Solution: Enter the correct value. If if contains spaces or special characters then enclose it in quotes. For the complete details, see this FAQ entry.
• The BSSID is wrong. Solution: Enter the correct value.
• You are too far away from the AP and are not receiving any beacons. Solution: You can use tcpdump and/or airodump-ng to confirm you are in fact receiving beacons for the AP. If not, move closer.
• You are not receiving beacons for the AP: Solution: Use “tcpdump -n -vvv -e -s0 -i <interface name>” to confirm you are receiving beacons. Assuming you have dealt with with potential problems above, it could be the drivers or you have not put the card into monitor mode.

For all of the above, running airodump-ng and the related text file should provide all the information you require identify and correct the problem.

A typical example of this message is: “mon0 is on channel 1, but the AP uses channel 6”

This means something is causing your card to channel hop. Possible reasons is that failed to start airodump-ng locked to a single channel. airodump-ng needs to be started with “-c <channel-number>.

Another reason is that you have processes such as a network manager or wpa_supplicant channel hopping. You must kill off all these processes. See airmon-ng for details on checking what is running and how to kill the processes off.

Also make sure that:

• Most modes of aireplay-ng require that your MAC address be associated with the access point. The exception being client disassociation, injection test and fake authentication modes. You must either do a fake authentication to associate your MAC address with the access point or use the MAC address of a client already associated with the AP. Failure to do this means that the access point will not accept your packets. Look for deauthentication or disassociation messages during injection which indicates you are not associated with the access point. aireplay-ng will typically indicate this or it can be done using tcpdump: “tcpdump -n -e -s0 -vvv -i <interface name>”. You can filter it by piping it to grep with something like `tcpdump -n -e -s0 -vvv -i ath0 | grep -E “DeAuth|assoc”'.
• The wireless card driver is properly patched and installed. Use the injection test to confirm your card can inject.
• You are physically close enough to the access point. You can confirm that you can communicate with the specific AP by following these instructions.
• Another method to confirm that you can communicate with the AP is to ensure you receive ACK packets to each packet you transmit. In wireless communication, the receiver must acknowledge every packet received with an “ACK” packet. It is a mandatory part of the wireless communication protocol. By sniffing without filters on the wireless channel, you should see the “ACK” packets. Review a capture with wireshark or tcpdump. Alternatively you do this in real time with “tcpdump -n -vvv -e -s0 -i <wireless interface>”. Failure to receive any ACKs from the AP means it cannot hear you. Thus you are physically too far away.
• The wireless card is in monitor mode. Use “iwconfig” to confirm this.
• The card is configured on the same channel as the access point. Use “iwconfig” to confirm this.
• Make sure you are using a real MAC address. See discussion in setting MAC address).
• Some access points are programmed to only accept connections from specific MAC addresses. In this case you will need to obtain a valid MAC address by observation using airodump-ng and use that particular MAC address. Do not do a fake authentication for a specific MAC address if the client is active on the AP. MAC access control lists do not apply to deauthentication. See the MAC access control troubleshooting tip here.
• The BSSID and ESSID (-a / -e options) are correct.
• If Prism2, make sure the firmware was updated.
• Ensure your are running the current stable version. Some options are not available in older versions of the program. Also, the current stable version contains many bug fixes.
• It does not hurt to check the GitHub issues to see if your “problem” is actually a known bug in the current stable version. Many times the current development version has fixes to bugs within the current stable version.