[kismac] Re: weak IVs

  • From: Michael Rossberg <mick@xxxxxxxxxxxxxxxx>
  • To: kismac@xxxxxxxxxxxxx
  • Date: Mon, 12 Jul 2004 19:52:55 +0200

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?

well it does at least not hurt. it will help to recover a lot more of information, however you should take a look at console.log after starting a FMS attack. kismac will print out more detailed statistics...

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 ).

sounds like it

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.

this is nothing new. there are different pcap formats. one with and and one without prism headers. bsdtools uses the one with headers, while kismac uses the more common without this headers. actually you can put a #define USE_RAW_FRAMES in WaveScanner.mm and let KisMAC output prism headers...

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..

if the weather stays this freakin' rainy i wont have another chance to do anything else than programming KisMACng.

regarding brads packet injection strategy: it is in theory right what you have said. however only data packets are encrypted so probing wont help. also you have to reinject known packets, because you dont know the key, therefore you can safely use their MAC-addresses and a MAC-filter will not help.
The problem is that reinjecting packets wont give you new informations, unless you are injecting an ARP packet or a TCP ACK packet. These packets will generate responses, that will be encrypted with a new IV - and therefore give you new informations. Unfortunately this is not very easy. I got it to work a couple of times in a laboratory environment - that is what the reinjection menu does. But there are a couple of catches: for an example ARP packets are often padded and I did not find a way how to forecast the length of this packets.
If you guys want to do some real cutting-the-edge stuff, you might want to start up an ethereal and try to adjust the values in -(void)handleInjection:(WLFrame*) frame; (WaveScanner.mm).


Other related posts: