Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control.
If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

Router Charts

Click for Router Charts

Router Ranker

Click for Router Ranker

NAS Charts

Click for NAS Charts

NAS Ranker

Click for NAS Ranker

More Tools

Click for More Tools

Wireless How To

Step 4 - Generate Traffic for Capture

Now that we have our target WEP-protected AP, we need to capture enough IVs with airodump for aircrack-ng to work with. The airodump-ng #Data column tells you how many IVs have been captured and the #/s column reports the per-second capture rate.

If you look back at Figure 4, you can see we captured only 246 IVs at a rate so low that it didn't even register in terms of IVs/second, in the 9 minutes that the program was running before we took the screen shot. Considering that we need at least 20,000 IVs to crack WEP 64, we definitely need to speed things up!

How many IVs do I need?

The number you need depends on WEP key length, cracking techniques used, and just plain luck (or more precisely, the laws of probability).

The aircrack-ng FAQ says a WEP 64 key usually needs at least 300,000 IVs, while a WEP 128 key needs more than 1,500,000(!).

Fortunately, the PTW technique in aircrack-ng 0.9 significantly lowers the number of required IVs to around 20,000 and 40,000 for 64 and 128 bit WEP keys respectively, but works with only with ARP packets captured in full (not --ivs) mode.

This is where aireplay-ng comes in. This program is used to generate traffic for capture through the use of various frame injection techniques. We're going to use an ARP Request Replay Attack for our packet injection. Without packet injection it could take days to collect enough IVs!

A replay attack simply captures a valid packet generated by a target STA, spoofs the STA that it captured the packet from and replays the packet over and over again more frequently than normal. Since the traffic looks like it is coming from a valid client, it doesn't interfere with normal network operations and goes about its IV-generating duties quietly.

A perfect candidate for capture are Address Resolution Protocol (ARP) packets since they're small (68 Bytes long) and have a fixed and easily recognizable format. They're also the only type of packet that the faster PTW method works with.

NOTE!NOTE: The following procedures do not use the faster PTW method because it isn't included in the current BT2 distribution. See Appendix 1 if you want to use that method.

You first need to restart airodump-ng, but this time with the channel and BSSID (MAC address) of the target AP. Type the following into the shell window, substituting the channel number [AP channel] and AP MAC address [AP BSSID] that you previously obtained with the first airodump-ng run:

NOTE!NOTE: Some of the following commands have been broken into two lines to fit this page. Make sure you enter them in a single command.
airodump-ng --ivs --channel [AP channel]
      --bssid [AP BSSID] --write capturefile ath0

The captured packets will again be stored in a file in /root and be of the form capturefile_nn.ivs where nn is a two-digit number, i.e. capturefile_01.ivs. For our example, the command line looks like:

airodump-ng --ivs --channel 5 --bssid 00:06:25:B2:D4:19 
      --write capturefile ath0

Figure 5 shows the command result. Note that this time, we see only Channel 5, the single linksys AP and its client.

airodump-ng capturing from target AP
Click to enlarge image

Figure 5: airodump-ng capturing from target AP

Note that the #Data and #/s columns show a low capture rate, as expected. So let's speed things up with aireplay-ng. Open another shell window and type the following, substituting the information for your target WLAN for [AP BSSID] and [client MAC from airodump].

aireplay-ng --arpreplay -b [AP BSSID] 
      -h [client MAC from airodump] ath0

This starts the ARP replay on the target AP, spoofing the MAC address of the associated STA. For our example WLAN, the command line is:

aireplay-ng --arpreplay -b 00:06:25:B2:D4:19 
      -h 00:1A:70:7F:79:F2 ath0

Figure 6 shows aireplay-ng when it first starts up and it hasn't yet started replaying.

aireplay-ng just starting up, no replay yet
Click to enlarge image

Figure 6: aireplay-ng just starting up, no replay yet

The key indicator is the "sent 0 packets" in the last line. Note that ff your drivers or device don't support packet injection, then aireplay will do something like this:

aireplay with no packet injection
Click to enlarge image

Figure 7: aireplay with no packet injection

To check whether your drivers support injection, take a look in the aircrack-ng documentation here.

More Wireless

Wi-Fi System Tools
Check out our Wi-Fi System Charts, Ranker and Finder!

Support Us!

If you like what we do and want to thank us, just buy something on Amazon. We'll get a small commission on anything you buy. Thanks!

Over In The Forums

Hello, I recently moved into a new house and had the internet set up by Cox. I would like to extend wired internet to the upstairs rooms but don't wan...
RT AC68WFW Merlin 384.13I have a 4TB drive. I've partitioned it so the first partition is 500GB and the second partition is 3.5TB. The labels for each...
I'm running 384.13 on an 86U. On enabling the Openvpn server I get the following message next to the Export OpenVPN Configuration File on the GUI."Ini...
I have a couple of RT-AC68Us (orig T-Mo CellSpots) which are running Merlin 384.13. Couple of months ago I OC'ed them to 1000,800. I now find that the...
Hi,I have an Asus AC-RT68R running Merlin FW 384.13 and I noticed a strange issue with a wired security camera I just installed. It is showing up in t...

Don't Miss These

  • 1
  • 2
  • 3