 |
 |
 |
 |
 |
 |
 |
| WEP Key Recovery Help Documentation |
|
| |
|
||||||||||
|
|
|
 |
In WLANs with low network traffic levels, collecting a few hundred thousand unique packets necessary for key recovery (at least 400,000 for a 56-bit key) takes a long time. Using CommView for WiFi, one can induce a higher traffic level by sending encrypted ARP Request packets. The WLAN would then reply with ARP Response packets, thus generating additional traffic. While the original ARP Request packets being replayed cannot contribute to the pool of the packets needed for key recovery (they all have exactly the same contents, while key recovery requires unique packets), the ARP Response packets are different from each other, as a new Initialization Vector (IV) is used for every new packet. The following steps should be taken for desired traffic generation: Step 1 Since the WLAN traffic is encrypted, we can't see which of the captured packets are ARP Request packets. However, we can make a guess. An ARP Request packet is typically 68 bytes long (or 70 bytes long, if the WLAN is QoS-enabled), has the broadcast destination address, and has the ToDS flag set. Configure CommView for WiFi to capture such packets by creating a new capturing rule, as shown below: 
Step 2 ARP Request packets are usually sent immediately after the station performs the association. To force reassociation, use the Node Reassociation tool in CommView for WiFi (Tools => Node Reassociation): 
Capturing should be turned on prior to using this tool. Step 3 Following the reassociation, stations would normally send ARP Request packets. Because we created a rule that discards all packets except ARP Requests, CommView for WiFi would display only encrypted ARP Request packets. You may need to go back to Step 2 if you can't capture these packets and click Send Now multiple times. Once these packets are displayed as shown below, select Send Packet(s) => All to load these packets into Packet Generator: 
Step 4 Go back to the Rules tab (shown in Step 1) and disable the rule you created. This is very important, because if you don't do that, CommView for WiFi will filter out virtually all traffic, so no packets will be passed to WEPKR. Step 5 
|
||||||||
