1weplab(1) General Commands Manual weplab(1)
2
6 weplab - Wireless WEP encryption security analyzer
7
9 weplab {-a | -r | -b | -y | -c} [options] {pcap file}
10
12 weplab is a tool to review the security of WEP encryption in wireless
13 networks from an educational point of view. Several attacks are avail‐
14 able (including advanced statistical attacks) so it can be measured the
15 efectiveness and minimun requirements of each one.
16 On the other hand, weplab can also be saw as an advanced Wireless WEP
18 encryption cracker that aims to support a big variety of attacks. At
19 the moment the attacks supported are dictionary based, bruteforce and
20 several kind of statistical based.
21
23 -a, --analyze
24 Analyzes specific file and gathers some statistics about the
25 packets that are stored per detected wlan network.
26 -c, --capture
28 Uses a wlan interface to capture wep encrypted data packets.
29 Those captured packets will be logged into a file in pcap format
30 and can be used later to crack the key.
31 -b, --bruteforce
33 Launches a bruteforce attack to break the key. That means that
34 weplab will test all possible keys in order to find the right
35 one.
36 Please, that this can take lot of time depending on the key size
38 and your processor speed. Refer to Bruteforce method above in
39 this document for futher information.
40 If no BSSID was specified, those packets who belong to the same
42 network as the first one, will be used for the crack.
43 -r, --heuristics
45 Launches an statistical attack to break the key. This is the
46 fastest method to crack the key if you own enough packets. As an
47 example a 64-bit key can be broken from 100.000 packets, and a
48 128-bit key from 300.000 packets, within 1-2 hours. With enough
49 packets (lets say 900.000), the cracking time is matter of sec‐
50 onds.
51 Several statistical attacks will be used depending on the
53 selected stability level (3 by default). The processor time and
54 number of packets required, highly depends on the parameters
55 used to launch the attack.
56 This method is very advanced. You are fully encouraged to under‐
58 stand it reading its section on this document. Although it use
59 to work fine with default options and having, enough packets,
60 its better to understand how it works so you can tweak the pro‐
61 cedure using the apropiate parameters.
62 If no BSSID was specified, those packets who belong to the same
64 network as the first one, will be used for the crack.
65 -y, --dictionary
67 Launches a dictionary based attack to break the key.
68 Many WEP keys are derived from pass-phrases, entered by the net‐
70 work administrator. When, this happens and you do not have
71 enough packets to launch a statistical attack, it is better to
72 use a dictionary based cracking than a bruteforce aproach.
73 On dictionary attack, John the Ripper is used to generate the
75 words that weplab will use to derive the WEP key. So, John the
76 Ripper must be present and executed so its output is piped into
77 weplabs input. In the EXAMPLES section you will find several
78 examples about that.
79 If no BSSID was specified, those packets who belong to the same
81 network as the first one, will be used for the crack.
82 -k, --key <key_length>
84 Specify the key length. It can be either 64 or 128-bit
85 This option is only usefull within a cracking method, so -y, -r
87 or -b must be used in conjuntion with it.
88 Default: 64 bits.
90 --keyid <key_id>
92 Specify the key id for 64-bit keys.
93 For 64-bit keys the WEP standard specifies four possible keys,
95 each one with a different keyid (0-3). Usually only keyid 0 is
96 used, but if you hit a network with more keyids you will need to
97 use this option to specify one of them, and launch a separate
98 cracking attack for each one.
99 Default: 0
101 --fcs Specify the presence of a 1 byte FCS tail on all logged packets
103 Depending on your driver and how did you set your card into mon‐
105 itor mode , it is possible than logged packets have an aditional
106 tail of 1 byte length.
107 Best way to find out if your card/drivers needs this, is trying
109 to break your own network. This way, as you already know the
110 key, if it does not get cracked without FCS, try with it.
111 This option is only usefull within a cracking method, so -y, -r
113 or -b must be used in conjuntion with it.
114 Default: fcs not present.
116 --prismheader
118 Specify the presence of an special header called PrismHeader on
119 all logged packets
120 Depending on your driver and how did you set your card into mon‐
122 itor mode , it is possible than logged packets have an aditional
123 header of 144 bytes length.
124 If you want to know if you need it or not, just analyze the file
126 with weplab. If prismheader is not necessary it will tell you.
127 If it is neccesary, you will see lot of bogus BSSIDs, and no
128 adversice about not using prismehader
129 Anyway, cracking your own WEP key is the best method to know if
131 you need it or not.
132 This option is only usefull within a cracking method, so -y, -r
134 or -b must be used in conjuntion with it. From weplab 0.1.2 you
135 will also need to specify it with -a in order weplab to show you
136 the right BSSIDs found.
137 Default: prismheader not present.
139 --bssid <bssid_in_hex>
141 Only use those packets that belongs to the selected BSSID.
142 BSSID must be in the form of AA:BB:CC:DD:EE:FF
144 If BSSID is not specified only those packets, that belong to the
146 same BSSID as the first one, will be used
147 Use -a with your file if you want to see all detected BSSIDs
149 This option is only usefull within a cracking method, so -y, -r
151 or -b must be used in conjuntion with it.
152 Default: none
154 --caplen <amount>
156 Specify the amount of bytes that will be logged for each pack‐
157 ets.
158 In order to launch an attack only a few number of packets (10)
160 must be fully logged. For the statistical attacks, only the
161 first bytes of other packets are needed.
162 In order to save diskspace when logging packets for the statis‐
164 tical attack, ony the begining of the packet should be logged
165 If you specify 0 here, the whole packet will be logged.
167 Please, notice that you will need to capture at least 10 packets
169 behind this amount (fully logged packets), as they will be
170 needed for testing candidate keys within the cracking process.
171 Default: 1500
173 -i <interface>
175 Specifies the wireless interface that will be used to capture
176 packets.
177 weplab does not set the interface into monitor mode, so you must
179 do it yourself before capturing packets. Read the above to learn
180 how to do it.
181 -m, --multiprocess <number>
183 Specifies the number of threads that will be launched to take
184 advantage of multiprocessors systems. If your microprocessor
185 supports hyperthreading please use the double of number of
186 microprocessors.
187 For example, use -m 4 if you own a dual P4 hyperthreading and -m
189 2 if you own a dual processor P-II machine.
190 At the moment this option does only work on bruteforce attack.
192 Default: 1
194 --ascii
196 When launching a bruteforce attack, it is faster to search only
197 ascii bytes if you are sure that the WEP key was generating from
198 a pass phrase using ascii direct-mapping.
199 This way, each key byte will only be tested in the range of
201 00-3F. As the key-space is smaller the attack is faster.
202 --perc <probability>
204 Specify the desired minimun probability for the statistical
205 attack. It means that at least enough candidate key bytes will
206 be tested to fit this probability.
207 In order to fully understand this option you are encouraged to
209 read carefully the "Statistical Attacks" caption, above in this
210 document.
211 Please note that the higher the minimun probability the slowest
213 the attack. For most cases 50% is fine. You can increase to 60
214 or 70% if you get the KEY NOT FOUND with 50, but never increase
215 it to 100% because you will be waiting for ever.
216 --stability <level>
218 Specify the predefined set of statistical attacks based on their
219 stability level. Not all the statistical attacks are stable
220 (works fine) your every key. Some of them are more unstable than
221 others. This options allows you to launch only those attacks
222 that meets the specified stability level.
223 Level can be from 1 to 5. The highest the more stable. I do not
225 recomment you to go for level 1 because it is too unstable to
226 give you any results. By default level 3 is used. It is a good
227 idea to change into level 2 if you have little unique IV and
228 cracking with level 3 failed.
229 In the Statistical Attack caption, you will find a detailed list
231 of the 17 attacks implemented with the stability level of each
232 one.
233 --attacks #attack1,#attack2,#attack2
235 This is the other way to select the statistical attacks that
236 will be launched, without using --stability parameter. Only
237 those attacks, whose number is selected here, will be used in
238 the statistical procedure.
239 The number of the attacks go from 1 to 17. Please, refer to the
241 Statistical Attacks section for further information.
242 --debugkey <key>
244 if you want to test how a set of statistical attacks works with
245 a known WEP key, then this parameter will give you the oportu‐
246 nity to get the final result without going trhow all the possi‐
247 ble branches.
248 Using this option you tell weplab about the WEP key used to
250 encrypt the packets. Only the real branch will be followed and
251 you will get the candidate list for each key byte.
252 -V Outputs version information and exists.
254 -h Displays command line parameters help.
256
258 weplab does not need any special installation. It runs in userlevel and
259 only requires the libpcap libraries (>=0.8) to be present. For most
260 functions weplab can be executed by any user, however for packet cap‐
261 ture functionality it must be executed by root.
262 if you are installing it from source code distribution, the configure
264 script should be able to detect your proccessor type to optimize the
265 code specifically for your platform.
266 At least 128 MB of free RAM memmory are required to run FMS statistical
268 attack in weplab, 64 MB of free ram for capturing packets, and nothing
269 special for the other features.
270 Weplab is reported to work fine under GNU/Linux for intel, GNU/Linux
272 for PPC and MacOSX.
273 Windows version cannot capture packets due to the lack of a opensource
275 method to do it, but its other features works fine. Please read Windows
276 Platform section under Capture Packets caption for futher information
277 about how to deal with this issue under Windows.
278
280 First you will need to capture 802.11b encrypted packets to crack the
281 wep key. The way weplab cracks the key is using passive attacks to an
282 already captured packet set.
283 To capture encrypted packets in a wireless network, your wireless card
285 must be put in monitor mode. The way monitor mode is set is highly
286 dependant on which card do you own, and which drivers are you using.
287 Explaining how to set monitor mode in your card is beyond the scope of
289 this document, and sometimes involves patching the kernel or "hacking"
290 the drivers. As an example, the following steps should be done in order
291 to set monitor mode on a prism2 based card using wlan-ng drivers.
292 Initialization of the card.
294 prism2 and wlan-ng
295 wlanctl-ng wlan0 lnxreq_ifstate ifstate=enable
297 wlanctl-ng wlan0 lnxreq_autojoin ssid=any authtype=opensystem
299 orinoco : nothing special
301 Enable the interface (wlan0 in the example, just change to eth0 if
303 using orinoco)
304 ifconfig wlan0 up
305 Setting monitor mode on desired channel (6 in the example).
307 prism2 and wlan-ng
308 wlanctl-ng wlan0 lnxreq_wlansniff channel=06 keepwepflags=false
310 prismheader=false enable=true (I dont know why, but sometimes
311 this step must be taken twice :) )
312 orinoco and iwpriv
314 iwpriv eth0 monitor 2 6
316 There are a few things that must be done regardless of the card and
318 drivers used.
319 1. The wireless card placed in monitor mode should accept encrypted
321 packets and mark them as encrypted. In the example above, that's the
322 purpose of the option keepwepflags=false in third step.
323 2. The interface must be enabled (up)
325 3. If your card is appending prism header or fcs "tail" to the packets,
327 weplab needs to be told about it (with --fcs or --prismheader). Deter‐
328 mining if this is necessary for your hardware will be explained later.
329 Now, to capture encrypted packets you can either use weplab, tcpdump,
331 or a similar sniffer that logs packets in pcap format.
332 To do it with weplab, just use -c. Interface must be specified with -i
334 weplab --debug 1 -c -i wlan0 ./packets.log
336 There is no need to log the entire packet, just the 802.11 header and
338 the IV, but to verify possible canditate keys the whole packet
339 encrypted payload must be present. That's why you must specify two
340 files in weplab when using FMS attack. One file must have just 10 pack‐
341 ets with the whole payload, and the other file contains weak packets
342 that don't need to have payload logged.
343 So, in order to save disk space it is a good idea to log a few packets
345 for key verification on one file, and then just log the first bytes of
346 all other possible packets, to be used as possible weak packet for FMS
347 attack.
348 You can specify maximun captured bytes per packet with --caplen bytes
350 weplab -c -i wlan0 --debug 1 ./verification_packets.logweplab -c -i
352 wlan0 --debug 1 --caplen 100 ./weak_packets.log
353 Alternately, if your disk space is not so critical and you don't mind
355 wasting a few extra seconds on loading the file later, these two steps
356 can be joined into one.
357 weplab -c -i wlan0 --debug 1 --caplen 150 ./packets.log
359 Then this file can be used both for verification and weak packets.
361
363 Before trying to crack the key using the already captured packets, it
364 is a good idea to verify the file just to ensure that the packets were
365 logged fine, and there are enough to perform the desired attack.
366 weplab --debug 1 -a ./packets.log
368 You can try with --prismheader or --fcs, or both.
370 weplab --debug 1 -a --fcs ./packets.logweplab --debug 1 -a --prism‐
372 header --fcs ./packets.log
373 As explained above, prismheader is an special header that some cards
375 and drivers add to all captured packets, and fcs is an special tail
376 added to the captured packets by some drivers. You can determine if
377 your card/drivers needs --fcs or --prismheaders by using the FMS attack
378 together with --debugkey and a set of encrypted packets captured by
379 your card where the wep key is known. This is explained later in the
380 FMS attack section.
381
383 At the moment weplab supports 2 main cracking methods: bruteforce and
384 FMS statistical attack. Before selecting the cracking method, the key‐
385 size should be specified. By default the keysize is 64. To crack a
386 128-bit key, you must specify --key 128
387
389 Bruteforce cracking means testing all possible keys to find the right
390 one. That means that each key byte can take values from 0 to 255. So a
391 quick calculus will reveal that for a 64 bits key the total combina‐
392 tions are 2^40, so at 100.000 c/s cracking the key will take you
393 4100061318 seconds maximun. 127 days working fulltime.
394 With a 128-bit key the total combinations possible are 2^104, so at
396 100.000 c/s the total maximun amount of time will be
397 6520836420927105974 YEARS!! I guess you will never try to launch a
398 bruteforce attack to a 128-bit key. Anyway, weplab gives you the pos‐
399 sibility to do it ;)
400 You will need at least 10 full wep encrypted data captured packets in
402 order to launch a bruteforce attack avoiding false positives.
403
405 Guess what ? Users often use simple words as their WEP key. The dictio‐
406 nnary cracking mode gives you the ability to check if the WEP key isn't
407 a so-simple-to-guess word. Using this mode in addition to John-the-Rip‐
408 per could produce some usefull results.
409 Weplab reads the dictionnary words from STDIN, so if you want statis‐
411 tics, you want be able to press SPACE. However, you'll have statistics
412 printed on STDOUT every 10 seconds.
413 Dictionary cracking can use two different modes :
415 By default the classical algorithm (MD5 for 128 bits keys or one of 4
417 keys for 40 bits keys) it is used. This mode is widely used on Access
418 Points to generate keys from a passphrase.
419 Alternatively you can select Word to key with the "--attack 2" option
421 if you want weplab to use plaintext keys with NULL bytes appended (if
422 needed) at the end of each word to fit the WEP key size. This second
423 mode is used on my system when I configure the WEP key using "iwconfig
424 eth0 s:silly".
425
427 Wireless networks WEP encryption is based on RC4 algorithm. RC4 has
428 some weaknesses as Fluhrer, Mantin and Shamir described in 2001 with
429 the paper "Weaknesses in the Key Scheduling Algorithm of RC4". The spe‐
430 cific implementation of the RC4 algorithm in WEP makes possible its
431 practical use. The initials of the authors gave it the name of FMS sta‐
432 tistical cryptoanalysis.
433 In order to make this attack possible for breaking the encryption of
435 wireless networks, lots of specific data wep encrypted packets, called
436 weak packets, must be gathered. Soon after the paper was published, two
437 tools appeared that implemented the FMS attack, but the set of weak
438 packets that these tools use is just asmall subset of the total possi‐
439 ble weak packets. As a result, the attack was not as practical to
440 launch as it should be.
441 In February 2002, h1kari released the paper "Practical Exploitation of
443 RC4 Weaknesses in WEP Environments". This describes the problem with
444 the set of weak packets used by existing tools and suggest several
445 optimization in the attack like attacking other bytes besides the first
446 one. H1kari created a tool called dwepcrack that implements a part of
447 these optimizations, and runs under *BSD. Weplab uses FMS attack sup‐
448 porting the whole set of weak packets for attacking both the first and
449 the second byte of the encrypted payload. Also some bruteforce and
450 smart probabilistic based decisions are implemented within the FMS
451 attack to make it more powerful, especially when you dont have enough
452 packets to launch a straight-forward attack.
453 But apart from that, the main purpose of weplab is to be an educational
455 tool to help users understand the existing weaknesses in WEP and how
456 can the be used to break the encryption key. Several command line
457 parameters are implemented with this purpose.
458 Also, if you plan to test weplab cracking capacity with your own wire‐
460 less lan, you can use --debugkey. By using this option you tell weplab
461 what your WEP key is (or at least a part of it), so weplab will skip
462 all other branches when searching candidate key bytes in FMS attack.
463
465 New statistical attacks published on Netstumbler forum by Korek. These
466 new attacks make possible to crack the key with even less than 500k.
467 Many thanks to Korek for this information. All the credit goes to you.
469
471 Example 1. Cracking using FMS attack
472 You want to test the tool so you collect 1.5M packets from your own
474 wireless LAN. You just want to know if weplab would be able to crack
475 it. You can use first --debugkey. If you are using a 128-bit key the
476 right sintax would be:
477 weplab -r./packets.log --debugkey
479 01:02:03:04:05:06:07:08:09:10:11:12:13 --debug 1 --key 128 ./pack‐
480 ets.log
481 You should see the statistics and guesses for each byte of the key so
483 you can see the viability of the attack. At the end you should see "key
484 succesfully cracked". If you do not see such message, perhaps your cap‐
485 tured packets have the FCS tail so it will be neccesary to issue --fcs
486 weplab -r./packets.log --debugkey
488 01:02:03:04:05:06:07:08:09:10:11:12:13 --fcs --debug 1 --key 128
489 ./packets.log
490 Now can try with just a part of the key in debugkey. If the FMS is pos‐
492 sible with these packets, weplab should be able to crack the key using
493 just these bytes.
494 weplab -r./packets.log --debugkey 01:02:03:04:05:06 --fcs --debug 1
496 --key 128 ./packets.log
497 If it works you can try reducing the debugkey more. At the end you can
499 try with no debugkey at all, as if it were a real attack.
500 You can push ENTER key in any moment to get statistics of the work
502 done.
503 Example 2. Cracking using bruteforce
505 To crack a 64-bit key using normal bruteforce just issue the following
507 command.
508 weplab --debug 1 --key 64 ./packets.log
510 If you suspect that the key may be in plain ascii, do this:
512 weplab --debug 1 --key 64 --ascii ./packets.log
514 You can push ENTER key at any moment to get statistics of the work
516 done.
517 Example 3. Capturing packets.
519 In order to capture packets you have to put your wireless card in moni‐
521 tor mode in the right channel. Be carefull to configure monitor mode
522 to ignore WEP bit. Once you have your card in monitor mode, you can
523 capture packets using tcpdump or weplab -c -i interface
524 weplab -c -i wlan0 --debug 1 --caplen 150 ./packets.log
526 You can push ENTER key at any moment to get statistics of the work
528 done.
529 Example 4. Analyze an existing pcap file.
531 Weplab can also analyze a pcap file to the some statistics. Use -a for
533 this purpose. --prismheader --fcs can also be used.
534 weplab -a --debug 1 ./pcap.log
536 Example 5. Cracking a 64 WEP key using a dictionnary file with John the
538 Ripper
539 john -w:/path/to/my/big/dictionnaryfile -rules -stdout | weplab -y -d 1
541 --key 64 capt.dump
542
544 This man page is correct for version 0.1.3 of weplab
545
547 weplab was created by Jose Ignacio Sanchez - Topo[LB].
548 However other people have made contributions to the project. In the
550 AUTHORS file within the distribution package, you will find them.
551 Any new contribution in form of documentation translation, new feature
553 development, bug fixing, and so on, will be welcome
554 weplab(1)