User Tools

Site Tools


how_to_crack_wep_via_a_wireless_client

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
how_to_crack_wep_via_a_wireless_client [2007/01/28 19:06] – created mister_xhow_to_crack_wep_via_a_wireless_client [2018/03/11 20:17] (current) – Removed link to trac mister_x
Line 1: Line 1:
-====== Tutorial:  How to crack WEP via a wireless client ====== +====== Tutorial:  How to crack WEP via a wireless client ====== 
-Version: 1.10 January 222007 (Change log is at the end) \\ +Version: 1.17 September 112009 \\ 
-By: darkAudax+By: darkAudax \\ 
 +\\ 
 +File linked to this tutorial: [[http://download.aircrack-ng.org/wiki-files/other/arpcapture-01.cap|arpcapture-01.cap]] 
  
 ===== Introduction ===== ===== 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 from real working equipment, not theory.  Each was used in real life and successfully cracked the WEP keys.+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: 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:
Line 15: Line 18:
   * You are within range of a client but not the access point itself   * 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.+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.+Please send me any constructive feedback, positive or negative.
  
 ===== Solution ===== ===== Solution =====
 +
 +
 ====Assumptions used in this tutorial==== ====Assumptions used in this tutorial====
  
Line 27: Line 32:
   * You are physically close enough to the client to send packets to them and receive packets from them.   * 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 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.7.  This is very important since there is a bug in 0.6.2 aireplay-ng which switches -k and -l IP addresses. +  * 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==== ====Equipment used====
Line 44: Line 48:
 Operating System: Linux \\ Operating System: Linux \\
 MAC address: does not matter MAC address: does not matter
 +Wireless interface used: ath0
  
 ===Ethernet wired Workstation=== ===Ethernet wired Workstation===
-Operation System: Linux \\+Operating System: Linux \\
 MAC address: 00:40:F4:77:F0:9B MAC address: 00:40:F4:77:F0:9B
  
 ===Ethernet wired Workstation=== ===Ethernet wired Workstation===
-Operation System: Linux \\+Operating System: Linux \\
 MAC address: 00:0D:60:2E:CC:E1 MAC address: 00:0D:60:2E:CC:E1
  
 ===Wireless Workstation=== ===Wireless Workstation===
-Operation System: Linux \\+Operating System: Linux \\
 MAC address: 00:09:5B:EC:EE:F2 MAC address: 00:09:5B:EC:EE:F2
 +
 +
  
  
Line 73: Line 80:
 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. 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.+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: 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+   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.+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 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.+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: Characteristics of the incoming packet we want:
Line 87: Line 94:
   * Destination MAC: Broadcast (FF:FF:FF:FF:FF:FF)   * Destination MAC: Broadcast (FF:FF:FF:FF:FF:FF)
   * Source MAC: anything   * Source MAC: anything
-  * Packet length: 68 or 86 (68 is typical for arp packets originating from wireless clients.  86 is typical for arp requests from wired clients.)+  * 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: Characteristics of the outgoing packet we want:
Line 93: Line 100:
   * Destination MAC: the source MAC address from the incoming packet meaning the client is responding to it.   * Destination MAC: the source MAC address from the incoming packet meaning the client is responding to it.
   * Source MAC: MAC address of client   * 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 requests from wired clients.)+  * 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. In simple terms we are looking for an ARP request to the client and a subsequent reply.
  
 First try Wireshark display filter of: First try Wireshark display filter of:
-(wlan.bssid == 00:14:6c:7e:40:80 and (frame.pkt_len>=68 and frame.pkt_len<=86))+ 
 +   (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. 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.+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: 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))+ 
 +   (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. 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.
Line 111: Line 120:
 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. 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:+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. +  * 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. +  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. +  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. +  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. +  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 +  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.+  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.+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. 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.
Line 129: Line 138:
 Restart your packet capture if it not still going: Restart your packet capture if it not still going:
  
-  airodump-ng --channel 9 --bssid 00:14:6C:7E:40:80 --ivs -w aprcapture ath0+  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: Now use interactive replay in a second separate session:
  
   aireplay-ng -2 -r dsarprequests.cap ath0   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!+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=== ===Scenario Two - Interactively pulling packets from live communication===
  
-In this scenario we are going do the capture and injection in real time.+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: 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+  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: Now start a separate second session to interactively capture and replay packets:
Line 181: Line 192:
   Use this packet ?   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.+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 === === Scenario Three - Creating a packet from a chopchop replay attack ===
Line 187: Line 198:
 We first need to generate the xor file. This file gives us the ability to create new encrypted packets for injection. 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.+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". 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.+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: 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:
Line 283: Line 294:
 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. 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:+However, So if you are using 0.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   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
Line 308: Line 319:
 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. 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 +Decrypt the packet: 
-View the decrypted packet: tcpdump -n -r arpforge-dec.cap+ 
 +   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: It should be something like:
 +
   reading from file arpforge-dec.cap, link-type EN10MB (Ethernet)   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   16:44:53.673597 arp who-has 192.168.55.51 tell 192.168.55.109
Line 336: Line 354:
   * It does not support prism chipsets   * 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.   * 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 does work smoothly with ralink and realtek chipsets. +  * It sometimes does not work smoothly with ralink
-  * Keep an eye on the forms for more compatibility information.+  * 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: Here is the command to run:
Line 384: Line 404:
  
  
-=====Change Log ===== 
- 
-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 
how_to_crack_wep_via_a_wireless_client.1170007591.txt.gz · Last modified: 2007/01/28 19:06 (external edit)