And when i write "I generated only some 8000.." I of course mean
On 12. jul 2004, at 16:28, Lasse Jespersen wrote:
Thanks for this information.. I already saw weplab, but I havent used it yet. I understand you generated a lot of traffic to get this many packets? I generated only some 8000 in about 24 hours. At that rate, it would take me 6 months, and I dont have any means of generating traffic on the network.
On 12. jul 2004, at 16:16, Erik Winkler wrote:
There is a new WEP testing tool under development called weplab (http://sourceforge.net/projects/weplab) that implements the FMS attack as well. I had to tweek it a bit to get it to work under MacOS X, but it does work. You need about 1.5 to 2 million IVs (that means lots and lots of encrypted data packets) to even have a 50-50 chance of cracking a 128-bit WEP key.
If Kismac is using the same FMS principles, you will need the same amount of traffic. The 8000 IVs isn't enough in this case. You have to wait until the number reaches 1,500,000. On my own access point, it takes about 3 hours of me generating traffic to get this many IVs. If you don't have a busy AP, figure it could take 24 to 48 hours. I haven't tested it on Kismac yet, so give it a try.
With regards to Kismet, I am running it under Yellowdog Linux 3.0.1 on a G4 powerbook and I have found it very useful for isolating a single AP. By adding filter_tracker=BSSID(00:11:22:33:44:55) to the kismet.conf file, where 00:11:22:33:44:55 is the BSSID of interest, I have been able to focus my WEP testing to specific APs. My kismet dumps were easily imported into Kismac 0.12a. Kismet is also nice because you can capture multiple .dump files and use the mergecap command combine them into a single file. This way you don't have to capture packets for continuously for 24 hours.
On Jul 12, 2004, at 9:17 AM, Lasse Jespersen wrote:
The question that begs to be asked is then: Has this new feature worked in your tests? Or is it theoretical? If it HAS worked, how long do you reckon I would have to pick up traffic from a given wlan to be able to crack it?
At some point in the process, Ill want to try an attack on the dump, and doing THAT -stops- the sniffing process, forcing me to restart it later if I want to continue my attack -- obviously if the first attack was unsuccessful.
I'd use pcapmerge ( pcapmerge.sf.net afair ) to merge the different pcapdumps, but thus far I havent used it. I assume it will be able to merge dump1 with dump2 with dump3 et cetera, is this correct? ( it's a perlscript so it would work with no problems in osx ).
I tried using the kismac pcapdumps with dwepcrack ( the newest ( yet old ) release of bsd-airtools ), but receieved some errors about dwepcrack being unable to read these dumps.. Thought this might be of interest to you.
May I be so bold as to inquire when you'll continue working - if only a little - on the greatest stumbler of all time? I hate dstumbler and kismet with a passion..
Thanks if you do, thanks if you dont..
On 11. jul 2004, at 18:44, Michael Rossberg wrote:
using kismac 0.12a i joyfully collected some 8000 weak IVs from a nearby network. however this was insufficient to crack wep. when i imported the pcap dump into 0.11b, i had 1 weak IV in total... I can provide this dump if it will help fix what appears to be a bug.
this is actually a feature. i outlined it briefly in a mail in may. the idea is the following. there are a number of ivs, which are always weak. this is what airsnort usually collects and what was told in the FMS paper. however there are ivs which can be weak, depending on the chosen key. this is an additional vulnerability which was discovered by h1kari <http://www.dachb0den.com/projects/bsd-airtools/wepexp.txt>. kismac will keep this packets too, and do the selection of weak or not later on. hope this helps