Wesside-ng is an auto-magic tool which incorporates a number of techniques to seamlessly obtain a WEP key in minutes. It first identifies a network, then proceeds to associate with it, obtain PRGA (pseudo random generation algorithm) xor data, determine the network IP scheme, reinject ARP requests and finally determine the WEP key. All this is done without your intervention.
The original wesside tool was written by Andrea Bittau and was a proof-of-concept program to accompany two published papers. The two papers are “The Fragmentation Attack in Practice” by Andrea Bittau and “The Final Nail in WEP's Coffin” by Andrea Bittau, Mark Handley and Josua Lockey. See the the links page for these papers and more. The papers referenced provide excellent background information if you would like to understand the underlying methodologies. The concepts for the fragment attack currently incorporated in aircrack-ng came from these papers.
For you trivia buffs, who knows where the program name “wesside” came from? As it turns out, it comes from tupac the rapper (2Pac / Tupac Shakur).
Wesside-ng has been updated to reflect advances in determining the WEP key. Here are the steps which wesside-ng takes:
So you may be asking “What is the linear keystream expansion technique?”. The foundation is the fact that packets like an encrypted ARP request can easily be identified combined with the fact that the start of it has known plain text. So the program first obtains the PRGA from known plain text portion of the ARP request. Then it creates a new ARP request packet broken into two fragments. The first fragment is one more byte then the know PRGA and the PRGA is guessed for the extra byte. These guesses are sent and the program listens to see which one is replayed by the AP. The replayed packet has the correct PRGA and this value was included in the destination multicast address. Now that we know the correct PRGA, one more byte can be decrypted in the original ARP request. This process is repeated until the sending IP in the original ARP request is decrypted. It takes a maximum of 256 guesses to determine the correct PRGA for a particular byte and on average only 128 guesses.
There are a few known limitations:
Please remember that this is still basically a proof-of-concept tool so you can expect to find bugs. Plus you will find features that don't quite work as expected. Consider using easside-ng as an alternative or a companion program. Easside-ng is considered relatively stable software.
Usage: wesside-ng <opts> -i <wireless interface name>
When you run wesside-ng, it creates three files automatically in the current directory:
It is very important to delete these files prior to starting the program when you change target access point.
Be sure to use airmon-ng to put your card into monitor mode.
Then you enter:
wesside-ng -i wlan0
Where:
The program responds:
[13:51:32] Using mac 00:C0:CA:17:DB:6A [13:51:32] Looking for a victim... [13:51:32] Found SSID(teddy) BSS=(00:14:6C:7E:40:80) chan=9 [13:51:32] Authenticated [13:51:32] Associated (ID=5) [13:51:37] Got ARP request from (00:D0:CF:03:34:8C) [13:51:37] Datalen 54 Known clear 22 [13:51:37] Got 22 bytes of prga IV=(0e:4e:02) PRGA=A5 DC C3 AF 43 34 17 0D 0D 7E 2A C1 44 8A DA 51 A4 DF BB C6 4F 3C [13:51:37] Got 102 bytes of prga IV=(0f:4e:02) PRGA=17 03 74 98 9F CC FB AA A1 B3 5B 00 53 EC 8F C3 BB F7 56 21 09 95 12 70 24 8C C0 16 40 9F A8 BD BA C4 CC 18 04 A1 41 47 B3 22 8B D2 42 DC 71 54 CE AD FE D0 C3 15 7E EB D1 E2 BB 69 7F 11 8A 99 40 FC 75 EC 12 BF 3B C8 2A 32 88 8A DC E8 35 7C EE DA A3 E3 6B 0C 45 21 DC BD 23 59 28 85 24 49 18 49 1C 24 6D E2 [13:51:37] Got 342 bytes of prga IV=(10:4e:02) PRGA=5C EC 18 24 F3 21 B2 74 2A 86 97 C7 4C 22 EC 42 00 3A C6 07 0C 02 AA D6 B6 D8 FF B1 16 F8 40 31 B7 95 3B F8 1B BD 94 8B 3B 7A 98 DE C6 72 FD F8 A5 FC E7 81 A0 9E 01 76 44 57 C4 EB AE D7 AB EB 2F 40 C8 E5 5F EF 13 DB F4 F7 F2 91 D9 36 77 C1 F0 9C E4 8C BA F9 50 C0 B0 E7 23 75 85 41 82 54 F5 22 3C A9 45 0C 1F AE DA 3B F7 AA 41 30 23 63 97 B1 42 4C A8 0E C0 5A 7E A2 58 C2 02 B8 7F DB C7 CC 66 4D 86 53 30 E0 A0 81 52 13 14 08 5F 45 C5 AC 21 C3 90 86 A1 8D 45 CC 7C A2 F2 95 34 EF 38 59 FA 21 0F CC 63 81 05 26 8D B8 84 A1 D3 DF 5D E0 CA 23 52 85 4F 61 5B E3 83 4B 2A 10 0A 14 94 FA 90 D4 FC 3F 7B CD A9 C3 E3 4D B7 99 BD 21 D4 FC DB 60 0C 92 8D 76 87 EF F7 45 C6 D7 0B 96 A4 18 41 63 48 79 E0 4E 3A 9F 1B 8D 17 F5 B0 FE 30 F3 27 55 E1 EA 8A 60 FA 9E CB CE D9 1D EE 94 20 20 EB 58 F8 55 38 4F C9 E7 53 55 94 6C 6A 6D F0 D5 4E DB 78 D6 52 A3 34 68 2C 8B 7A EA C8 DA 3B D9 CB 4C 65 E6 CE B8 EE CD 58 DD C1 C8 F8 08 1B 27 EC 74 7E AD A0 0E 1E 85 79 F4 C0 54 D9 99 51 CA 96 02 73 93 33 6F E6 D5 F1 55 81 2B AA C4 3A B2 0A C6 04 FE [13:51:39] Guessing PRGA 8e (IP byte=230) [13:51:39] Got clear-text byte: 192 [13:51:40] Guessing PRGA be (IP byte=198) [13:51:40] Got clear-text byte: 168 [13:51:40] Guessing PRGA 8d (IP byte=47) [13:51:40] Got clear-text byte: 1 [13:51:40] Guessing PRGA 12 (IP byte=240) [13:51:40] Got clear-text byte: 200 [13:51:40] Got IP=(192.168.1.200) [13:51:40] My IP=(192.168.1.123) [13:51:40] Sending arp request for: 192.168.1.200 [13:51:40] Got arp reply from (00:D0:CF:03:34:8C) [13:52:25] WEP=000009991 (next crack at 10000) IV=60:62:02 (rate=115) [13:52:36] WEP=000012839 (next crack at 20000) IV=21:68:02 (rate=204) [13:52:25] Starting crack PID=2413 [13:52:27] WEP=000010324 (next crack at 20000) IV=0d:63:02 (rate=183) [13:54:03] Starting crack PID=2415 [13:53:28] WEP=000023769 (next crack at 30000) IV=79:32:00 (rate=252) [13:53:11] Starting crack PID=2414 [13:53:13] WEP=000020320 (next crack at 30000) IV=7d:2b:00 (rate=158) [13:54:21] WEP=000034005 (next crack at 40000) IV=53:47:00 (rate=244) [328385:55:08] Tested 5/70000 keys KB depth byte(vote) 0 0/ 1 01( 206) 3B( 198) 5F( 190) 77( 188) 3D( 187) D2( 187) 60( 186) 6F( 186) A1( 185) 48( 184) 1 0/ 1 23( 232) 82( 190) BF( 187) 4E( 184) 0D( 183) 90( 181) B9( 181) 08( 180) 1A( 180) 8A( 180) 2 0/ 1 45( 200) F0( 186) 52( 184) AE( 184) 75( 183) 48( 181) A1( 180) 71( 179) DE( 179) 21( 178) 3 0/ 1 67( 221) AE( 202) B2( 193) 14( 191) 51( 184) 6D( 184) 64( 183) 65( 183) 5B( 182) 17( 181) 4 0/ 5 89( 182) DB( 182) 74( 181) C2( 181) CC( 181) 64( 180) CD( 180) 5F( 179) A6( 179) 1A( 178) Key: 01:23:45:67:89 [13:54:51] WEP=000040387 (next crack at 50000) IV=0d:a0:02 (rate=180) [13:55:08] WEP=000043621 (next crack at 50000) IV=da:5a:00 (rate=136) [13:55:08] Stopping crack PID=2416 [13:55:08] KEY=(01:23:45:67:89) Owned in 3.60 minutes [13:55:08] Dying...
Some cards/drivers do not properly report ACKs. The “-k” option allows ACKs to be ignored and forces wesside-ng to retransmit the packets the number of times specified. It will therefore automatically retransmit X times. That is, -k 1 will transmit once and assume the packet gets there. -k 2 will retransmit twice, and so on. Note: The higher the -k value, the slower transmission rate will be due to the many retransmits.
Some specific cases:
In general, you can experiment with different values to determine if it resolves the problem. There is no right or wrong value.
Make sure your card is in monitor mode.
Make sure your card can inject by testing it with the aireplay-ng injection test. Also specifically ensure you can communicate with the AP in question.
Make sure your card supports the fragmentation attack. Again, this can be confirmed with the aireplay-ng injection test.
Make sure to delete wep.cap, prga.log and key.log files if you are changing access points or if you want to restart cleanly. In general, if you have problems, it is a good idea to delete them.
There are a few known limitations:
You get an error similar to the following while running the program:
[18:23:49] ERROR Max retransmits for (30 bytes): B0 00 FF 7F 00 1A 70 51 B0 70 00 0E 2E C5 81 D3 00 1A 70 51 B0 70 00 00 00 00 01 00 00 00
This can be caused if the AP does not acknowledge the the packets you are sending. Try getting closer to the AP.
Another reason is that the internal state machine of wesside-ng is confused. This typically happens when there are other wireless packets picked up and the state machine does not properly interpret them. Remember, this is still proof-of-concept code and not completely stable. Just try rerunning wesside-ng.
If you are using the RT73 chipset, try adding the “-k 1” option. The driver for this chipset does not properly report ACKs. Using the “-k 1” option gets around this.
There are a variety of known bugs which are outlined below. Additionally, the state engine is known to be broken and this leads to unpredictable results.