![]() |
Airsnort FAQ |
![]() |
Weak IV's are collected and sorted according to which key byte they help to expose. A weak IV can assist in exposing only one key byte. The Fluher et al attack states that a weak IV has about a five percent chance of exposing the corresponding key byte. When a sufficient number of weak IVs have been gathered for a particular key byte, statistical analysis will show a tendency towards a particular value for that key byte. Each of the 256 possible values for a given key byte are scored as to their probability of being the correct value. The crack process makes a key guess based on the highest ranking values in the statistical analysis phase. The number of guesses that airsnort will make for each key byte is governed by the 'breadth' parameter in the preferences section of airsnort. Remember that there is about a 95% chance that a weak IV will reveal nothing at all about a key byte. It may require only a few packets before a key byte is revealed, or it may require a very large number of packets, therefore some keys will crack quickly while others will crack slowly. In particular, I have seen cases where airsnort quickly hit on 12 of the 13 key bytes and took a very long time to zero in on the 13th. Try increasing the breadth parameters under the preferences menu to examine more key possibilities during the crack phase.
IV[2] approx #of weak IVs # of IVs 0x00-0x0C 3000 852K 0x0D-0xEE 3000 14.8M 0xEF-0xFF 3000 1.1MClearly you can be lucky or unlucky when collecting IVs depending on where your nic's IV counter's happen to be.
Promiscuous mode allows you to view all wireless packets on a network to which you have associated. The need to associate means that you must have some measn of authenticating yourself with an access point. In promiscuous mode, you will not see packets until you have associated. Not all wireless drivers support promiscuous mode.
echo 'Mode: r' > /proc/driver/aironet/eth1/Config echo 'Mode: y' > /proc/driver/aironet/eth1/ConfigSubstitute your device name as appropriate.
PF_PACKET also provides a means for packets to be passed to user programs. This mechanism is relied upon by libpcap and all of its clients. The fact that you can see packets provided via a NETLINK socket does not mean you get to run tcpdump, you need PF_PACKET sockets. Early Prism2 capture utilities read packets via the NETLINK interface and saved them in files compatible with programs like ethereal for after the fact viewing. With PF_PACKET capability you can use tcpdump and ethereal on live 802.11 capture sessions. My latest patch for Orinoco cards provides monitor mode packets via the PF_PACKET interface (again ported over from the wlan-ng guys. See the Orinoco info page for more details. A patch to enable PF_PACKET sockets for Prism2 monitor mode is available here.
Basically, we would be interested in having AirSnort ported to just about any platform, but we have neither the experience nor time currently to do it ourselves. Anyone who is interested in helping with a port is welcome to contact us, and we will help out in any way we can. Also, I really doubt the handspring will have AirSnort ported to it for a long time, but you never know.
To get an idea, assume that your business (it's not very big yet) has four employees, all using the same password. These employees surf the net pretty continuously throughout the day (they're not very good employees.) These employees will generate about a million packets a day. These employees will generate approximately a hundred and twenty interesting packets every day, so after sixteen days, the network will almost certainly be cracked.
However, this network is nowhere near being saturated. As networks approach saturation, the capture time approaches a single day. In some situations, different physical networks may use the same passwords. If this could be determined, this would usually linearly diminish the cracking time also.
We realize that some of our early numbers were much lower than this. The reason for this is simply that we were lucky in our initial tests, and we didn't actually calculate the average amount of time it would take. This can happen in the real world too, the best case and worst case are significantly different from the average case. All of the informal calculations performed here assume the average case. You should too.
Yes, AirSnort can be used as a cracking tool, but it can also be used to settle arguments over the safety of WEP. People with neither the inclination nor the ability to digest the papers about WEP's security can easily wrap their minds around a tool like WEP.
If it took us so little time to write AirSnort, it would take a determined adversary a similarly short amount of time to develop an attacking tool. The only sane assumption to make is that a malicious hacker would have developed a tool like this. The only thing AirSnort does is give the tool to system administrators and script kiddies.
While we are troubled by the fact that script kiddies can get their hands on this tool, we still figure that the benefits of full disclosure outweigh the risks. If you disagree, it's just an academic debate, since we cannot withdraw this program.