[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
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
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: