How to use Airodump-ng
Contents
Setup
Set monitor mode:
wconfig wlan0 mode monitor
Start airmon-ng service:
airmon-ng start wlan0
Start Scan:
airodump-ng wlan0
Sniffing IVs
Because of the channel hopping you won't capture all packets from your target net. So we want to listen just on one channel and additionally write all data to disk to be able to use it for cracking:
airodump-ng -c 11 --bssid 00:01:02:03:04:05 -w dump wlan0
With the -c parameter you tune to a channel and the parameter after -w is the prefix to the network dumps written to disk. The “--bssid” combined with the AP MAC address limits the capture to the one AP. The “--bssid” option is only available on new versions of airodump-ng.
Before being able to crack WEP you'll usually need between 40 000 and 85 000 different Initialization Vectors (IVs). Every data packet contains an IV. IVs can be re-used, so the number of different IVs is usually a bit lower than the number of data packets captured.
So you'll have to wait and capture 40K to 85K of data packets (IVs). If the network is not busy it will take a very long time. Often you can speed it up a lot by using an active attack (=packet replay). See the next chapter.
Cracking
If you've got enough IVs captured in one or more file, you can try to crack the WEP key:
aircrack-ng -b 00:01:02:03:04:05 dump-01.cap
The MAC after the -b option is the BSSID of the target and dump-01.cap the file containing the captured packets. You can use multiple files, just add all their names or you can use a wildcard such as dump*.cap.
For more information about aircrack-ng parameters, description of the output and usage see the manual.
The number of IVs you need to crack a key is not fixed. This is because some IVs are weaker and leak more information about the key than others. Usually these weak IVs are randomly mixed in between the stronger ones. So if you are lucky, you can crack a key with only 20 000 IVs. But often this it not enough and aircrack-ng will run a long time (up to a week or even longer with a high fudge factor) and then tell you the key could not be cracked. If you have more IVs cracking can be done a lot faster and is usually done in a few minutes, or even seconds. Experience shows that 40 000 to 85 000 IVs is usually enough for cracking.
There are some more advanced APs out there that use an algorithm to filter out weak IVs. The result is either that you can't get more than “n” different IVs from the AP or that you'll need millions (like 5 to 7 million) to crack the key. Search in the Forum, there are some threads about cases like this and what to do.
Active attacks Injection support
Most devices don't support injection - at least not without patched drivers. Some only support certain attacks. Take a look at the compatibility page, column aireplay. Sometimes this table is not up-to-date, so if you see a “NO” for your driver there don't give up yet, but look at the driver homepage, the driver mailing list or our Forum. If you were able to successfully replay using a driver which is not listed as supported, don't hesitate to update the compatibility page table and add a link to a short howto. (To do this, request a wiki account on IRC.)
The first step is to make sure packet injection really works with your card and driver. The easiest way to test it is the injection test attack. Make sure to perform this test prior to proceeding. Your card must be able to successfully inject in order to perform the following steps.
You'll need the BSSID (AP MAC) and ESSID (network name) of an AP that does not do MAC filtering (e.g. your own) and must be in range of the AP.
Try to connect to your AP using aireplay-ng:
aireplay-ng --fakeauth 0 -e "your network ESSID" -a 00:01:02:03:04:05 wlan0
The value after -a is the BSSID of your AP.
If injection works you should see something like this:
12:14:06 Sending Authentication Request 12:14:06 Authentication successful 12:14:06 Sending Association Request 12:14:07 Association successful :-)
ARP replay
Now that we know that packet injection works, we can do something to massively speed up capturing IVs: ARP-request reinjection
The idea
ARP works (simplified) by broadcasting a query for an IP and the device that has this IP sends back an answer. Because WEP does not protect against replay, you can sniff a packet, send it out again and again and it is still valid. So you just have to capture and replay an ARP-request targeted at the AP to create lots of traffic (and sniff IVs).
The lazy way
First open a window with an airodump-ng sniffing for traffic (see above). aireplay-ng and airodump-ng can run together. Wait for a client to show up on the target network. Then start the attack:
aireplay-ng --arpreplay -b 00:01:02:03:04:05 -h 00:04:05:06:07:08 rausb0 -b specifies the target BSSID, -h the MAC of the connected client.
Now you have to wait for an ARP packet to arrive. Usually you'll have to wait for a few minutes (or look at the next chapter).
If you were successful, you'll see something like this:
Saving ARP requests in replay_arp-0627-121526.cap You must also start airodump to capture replies. Read 2493 packets (got 1 ARP requests), sent 1305 packets...
If you have to stop replaying, you don't have to wait for the next ARP packet to show up, but you can re-use the previously captured packet(s) with the -r <filename> option.
When using the arp injection technique, you can use the PTW method to crack the WEP key. This dramatically reduces the number of data packets you need and also the time needed. You must capture the full packet in airodump-ng, meaning do not use the “--ivs” option when starting it. For aircrack-ng, use “aircrack -z <file name>”. (PTW is the default attack in 1.0-rc1.)
If the number of data packets received by airodump-ng sometimes stops increasing you maybe have to reduce the replay-rate. You do this with the -x <packets per second> option. I usually start out with 50 and reduce until packets are received continuously again. Better positioning of your antenna usually also helps.
The aggressive way
Most operating systems clear the ARP cache on disconnection. If they want to send the next packet after reconnection (or just use DHCP), they have to send out ARP requests. So the idea is to disconnect a client and force it to reconnect to capture an ARP-request. A side-effect is that you can sniff the ESSID and possibly a keystream during reconnection too. This comes in handy if the ESSID of your target is hidden, or if it uses shared-key authentication.
Keep your airodump-ng and aireplay-ng running. Open another window and run a deauthentication attack:
aireplay-ng --deauth 5 -a 00:01:02:03:04:05 -c 00:04:05:06:07:08 rausb0
-a is the BSSID of the AP, -c the MAC of the targeted client.
Wait a few seconds and your arp replay should start running.
Most clients try to reconnect automatically. But the risk that someone recognizes this attack or at least attention is drawn to the stuff happening on the WLAN is higher than with other attacks.
Further tools and information
