Tutorial: How to crack WEP with no wireless clients

Introduction

There are many times when a wireless network has no wireless clients associated with it and there are no ARP requests coming from the wired side. This tutorial describes how to crack the WEP key when there are no wireless clients and there are no ARP requests coming from the wired side. Although this topic has been discussed many times over in the Forum, this tutorial is intended to address the topic in more detail and provide working examples.

It is recommended that you experiment with your home wireless access point to get familiar with these ideas and techniques. If you do not own a particular access point, please remember to get permission from the owner prior to playing with it.

Assumptions

First, this solution assumes:

You are using drivers patched for injection. Use the injection test to confirm your card can inject prior to proceeding.

You are physically close enough to send and receive access point packets. Remember that just because you can receive packets from the access point does not mean you may will be able to transmit packets to the AP. The wireless card strength is typically less then the AP strength. So you have to be physically close enough for your transmitted packets to reach and be received by the AP. You should confirm that you can communicate with the specific AP by following these instructions.

There are some data packets coming from the access point. Beacons and other management frame packets are totally useless for our purposes in this tutorial. A quick way to check is to run airodump-ng and see if there are any data packets counted for the access point. Having said that, if you have data captured from the access point from another session, then this can be used. This is an advanced topic and this tutorial does not provide detailed instructions for this case.

The access point uses WEP “open authentication”. It will not work if “shared key authentication” (SKA) is being used. With SKA, the only way to be successful with no clients present is if you captured the PRGA xor data with a airodump-ng handshake or an aireplay-ng attack previously. This is because you will need the PRGA xor file to do the fake authentication successfully.

You use the native MAC address of your wireless card for all the steps and do not change it. Do NOT use any other MAC address as the source for transmitting packets. Otherwise, some commands will not work correctly. See the Using Another Source MAC Address Section for instructions on dealing with using a different source MAC address.

You are using v0.9 of aircrack-ng. If you use a different version then some of the command options may have to be changed.

Ensure all of the above assumptions are true, otherwise the advice that follows will not work. In the examples below, you will need to change “ath0” to the interface name which is specific to your wireless card.

Equipment used

In this tutorial, here is what was used:

MAC address of PC running aircrack-ng suite: 00:09:5B:EC:EE:F2

BSSID (MAC address of access point): 00:14:6C:7E:40:80

ESSID (Wireless network name): teddy

Access point channel: 9

Wireless interface: ath0

You should gather the equivalent information for the network you will be working on. Then just change the values in the examples below to the specific network.

5 - Use packetforge-ng to create an arp packet using the PRGA obtain in the previous step

6 - Start airodump-ng on AP channel with filter for bssid to collect the new unique IVs

7 - Inject the arp packet created in step 5

8 - Run aircrack-ng to crack key using the IVs collected

Step 1 - Set the wireless card MAC address

To be honest, we will not be changing the wireless card MAC address.

This is a reminder to use your wireless card MAC address as the source MAC. I mention this explicitly as a reminder to use the actual MAC address from your card in “Step 3 - fake authentication” if you are replaying data from another session. Detailed instructions can be found in the FAQ: How do I change my card's MAC address ?.

Step 2 - Start the wireless interface in monitor mode on AP channel

Enter the following command to start the wireless card on channel 9 in monitor mode:

airmon-ng start wifi0 9

Note: In this command we use “wifi0” instead of our wireless interface of “ath0”. This is because the madwifi-ng drivers are being used. For other drivers, use the actual interface name.

In the response above, you can see that ath0 is in monitor mode, on the 2.452GHz frequency which is channel 9 and the Access Point shows the MAC address of your wireless card. So everything is good. It is important to confirm all this information prior to proceeding, otherwise the following steps will not work properly. (Note: If you are using a driver other than madwifi, then the Access Point field will be either invisible or show something other than your card's MAC address. This is normal.)

For such interfaces, use the interface name after “monitor mode enabled on” (here “mon0”) for further commands, rather than your card's actual interface.

Step 3 - Use aireplay-ng to do a fake authentication with the access point

This is a very important step.

In order for an access point to accept a packet, the source MAC address must already be associated. If the source MAC address you are injecting is not associated then the AP ignores the packet and sends out a “DeAuthentication” packet. In this state, no new IVs are created because the AP is ignoring all the injected packets.

The lack of association with the access point is the single biggest reason why injection fails.

Notice the “Got a deauthentication packet” and the continuous retries above. Do not proceed to the next step until you have the fake authentication running correctly.

Troubleshooting Tips

Some access points are configured to only allow selected MAC addresses to associate and connect. If this is the case, you will not be able to successfully do fake authentication unless you know one of the MAC addresses on the allowed list. See the MAC access control troubleshooting tip here.

If at any time you wish to confirm you are properly associated is to use tcpdump and look at the packets. Start another session and…

Notice that the access point (00:14:6c:7e:40:80) is telling the source (00:09:5B:EC:EE:F2) you are not associated. Meaning, the AP will not process or accept the injected packets.

If you want to select only the DeAuth packets with tcpdump then you can use: “tcpdump -n -e -s0 -vvv -i ath0 | grep -i DeAuth”. You may need to tweak the phrase “DeAuth” to pick out the exact packets you want.

The objective of the chopchop and fragmentation attacks is to obtain a PRGA (pseudo random generation algorithm) file. This PRGA is not the WEP key and cannot be used to decrypt packets. However, it can be used to create new packets for injection. The creation of new packets will be covered later in the tutorial.

Either chopchop or fragmentation attacks can be to obtain the PRGA bit file. The result is the same so use whichever one works for you. The pros and cons of each attack are described on the aircrack-ng page.

We will cover the fragmentation technique first. Start another console session and run:

aireplay-ng -5 -b 00:14:6C:7E:40:80 -h 00:09:5B:EC:EE:F2 ath0

Where:

-5 means the fragmentation attack

-b 00:14:6C:7E:40:80 is the access point MAC address

-h 00:09:5B:EC:EE:F2 is the MAC address of our card and must match the MAC used in the fake authentication

Success! The file “replay_dec-0201-191706.xor” above can then be used in the next step to generate an arp packet.

Helpful Tips

Be sure the packet is 68 or more bytes otherwise you may not have enough PRGA data to subsequently generate a packet. The PRGA captured has to equal or greater then the packet length we want to generate.

At home, to generate some packets to force chopchop to start, ping a nonexistent IP on your network using a wired client. This forces an arp to be broadcast and this will show up in chopchop to be used.

If something happens part way through chopchop, you can reuse the source packet by entering “aireplay-ng -4 ath0 -h 00:09:5B:EC:EE:F2 -r replay_src-0201-191639.cap”. The replay source file is noted when chopchop starts.

Taking the previous tip further, if you have a capture file from another session, you can use it as input “aireplay-ng -4 ath0 -h 00:09:5B:EC:EE:F2 -r capture-from-some-other-time.cap”

Troubleshooting Tips

If the first packet you select does not work, then try a few others. Sometimes it takes more then one try to be successful with either attack.

The chopchop attack will not be successful on some access points. If this happens, move onto the fragmentation attack. And vice versa.

Make sure you are properly associated. To check this, follow the tcpdump instructions in step 2.

Step 5 - Use packetforge-ng to create an arp packet

In the previous step, we obtained PRGA. It does not matter which attack generated the PRGA, both are equal. This PRGA is stored in the files ending with “xor”. We can then use this PRGA to generate a packet for injection. We will be generating an arp packet for injection. The objective is to have the access point rebroadcast the injected arp packet. When it rebroadcasts it, a new IV is obtained. All these new IVs will ultimately be used to crack the WEP key.

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.

You will notice that only one access point is being display since we included an airodump-ng filter to limit the capture to a single BSSID. Also notice that the station packets are roughly equal to the BSSID data packets. This means injection is working well. Also notice the data rate of 336 packets per second which is also an indicator that the injection is working well. This is a pretty “ideal” injection scenario.

Troubleshooting Tips

If the BSSID data packets are not increasing, make sure you are still associated with the access point. To do this, follow the tcpdump instructions in step 2.

Step 8 - Run aircrack-ng to obtain the WEP key

Start another console session and enter:

aircrack-ng -b 00:14:6C:7E:40:80 capture*.cap

Where:

capture*.cap selects all dump files starting with “capture” and ending in “cap”.

-b 00:14:6C:7E:40:80 selects the one access point we are interested in

You can run this while generating packets. In a short time, the WEP key will be calculated and presented. Using the PTW method, 40-bit WEP can be cracked with as few as 20,000 data packets and 104-bit WEP with 40,000 data packets. As a reminder, the requirement is that you capture the full packet with airodump-ng. Meaning, do not use the “--ivs” option.

Troubleshooting Tips:

Sometimes you need to try various techniques to crack the WEP key. Try ”-n“ to set various key lengths. Use ”-f“ and try various fudge factors. Use ”-k“ and try disabling various korek methods.

Alternate Solution

There is a neat trick which simplifies cracking WEP with no clients. Essentially it takes any packet broadcast by the access point and converts it to a broadcast packet such that the access point generates a new IV.

OK, at this point you are asking why didn't you show me this technique right at the start? The reason is that this technique rebroadcasts whatever size packet you receive. So if you receive a 1000 byte packet you then rebroadcast 1000 bytes. This potentially slows down the packets per second rate considerably. However, on the good news side, it is simple and easy to use. You might also get lucky and receive a very small packet for rebroadcasting. In this case, the performance is comparable to the solution described above.

The same assumptions apply and you must also do a successful fake authentication first.

Using Another Source MAC Address

The base tutorial assumes you are using the native MAC address of your wireless device as the source MAC. If this is not the case, then you need to change the process used. Since this is an advanced topic, I will provide the general guidelines and not the specific detail.

Preferably, you should change the native MAC address of your wireless device to the MAC you will be spoofing. This could the MAC of a client already associated with the AP or one that you make up. See this FAQ entry regarding how to change the MAC address of your card.