Bugreports for the Aircrack suite, version 2.2betaX - Page 3

grcore · 07-10-2005

I may have some trouble trying to repeat it, as what I am doing is running aircrack while airodump is running in background. By the time it segfaults, the cap file has changed.

I wonder if the problem may stem from running aircrack and airodump at the same time. I see the IV total increases as airodump runs.

If I can get a capfile that will repeat the fault, I will let you know.

g

kimbell · 07-10-2005

Maybe this will help.

Code:

(gdb) run
Starting program: /usr/local/bin/aircrack -a 1 -n 64 -c -f 3 -q -b 00:0D:72:40:88:09 beta5d.cap beta5g.cap
[Thread debugging using libthread_db enabled]
[New Thread -1208186592 (LWP 5258)]
[New Thread -1209455696 (LWP 5261)]
[New Thread -1217844304 (LWP 5262)]
[New Thread -1226499152 (LWP 5263)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208186592 (LWP 5258)]
0x0804aba7 in check_wep_key () at linux/aircrack.c:1121
1121            x1 = wep.ivbuf[xv + 3] ^ S[(S[i] + S[j]) & 0xFF];
(gdb) where
#0  0x0804aba7 in check_wep_key () at linux/aircrack.c:1121
#1  0x0804b47c in do_wep_crack (B=2) at linux/aircrack.c:1490
#2  0x0804b3f7 in do_wep_crack (B=1) at linux/aircrack.c:1497
#3  0x0804b3f7 in do_wep_crack (B=0) at linux/aircrack.c:1497
#4  0x0804decb in main (argc=13, argv=0xbffffa94) at linux/aircrack.c:2569
(gdb)

Also,

Code:

Program received signal SIGTERM, Terminated.
[Switching to Thread -1208186592 (LWP 5184)]
0xb7ebbb41 in kill () from /lib/tls/libc.so.6
(gdb) where
#0  0xb7ebbb41 in kill () from /lib/tls/libc.so.6
#1  0x0804d948 in main (argc=12, argv=0xbffffaa4) at linux/aircrack.c:2644
(gdb)

I do #make clean, #make all, #make install. Is this wrong or causing a problem?

devine · 07-11-2005

Thanks kimbell and grcore. When you run aircrack, do you only select one network, or are you trying to crack with IVs from multiple BSSID (using option -e) ?

grcore · 07-11-2005

Quote:

Originally Posted by devine

Thanks kimbell and grcore. When you run aircrack, do you only select one network, or are you trying to crack with IVs from multiple BSSID (using option -e) ?

I have been running aircrack with the BSSID of one AP.

(btw...any chance of modifying the deuath attack so it does not hit everything in range?).

thanks

g

devine · 07-11-2005

Quote:

Originally Posted by grcore

I have been running aircrack with the BSSID of one AP.

Thanks, I understand now where the bug comes from. Basically the reader thread will increase the IVs buffer when new IVs are available. But when there is no more room in the ivbuf, it calls realloc to enlarge the buffer. Problem is, the cracking thread also accesses ivbuf, so there is a race condition happening here. So I'll change to use separate IVs buffer.

Quote:

Originally Posted by grcore

(btw...any chance of modifying the deuath attack so it does not hit everything in range?).

Sure, I'll do this.

grcore · 07-11-2005

After further tests between aircrack brutforcing that last two keybytes, it seems for 128b keys there is an advantage. The key comes considerably earlier in the caputure. (with 5 out of 5 sessions). With 7 out of 7 sessions on 64b keys, both appeard to crack with about the same mount of IVs, but bruteforcing the last two keybytes made the process take longer....

I guess a lot of it depends on luck, and where the keybyte is wrong.

g

devine · 07-12-2005

Quote:

Originally Posted by grcore

After further tests between aircrack brutforcing that last two keybytes, it seems for 128b keys there is an advantage. The key comes considerably earlier in the caputure. (with 5 out of 5 sessions). With 7 out of 7 sessions on 64b keys, both appeard to crack with about the same mount of IVs, but bruteforcing the last two keybytes made the process take longer....

Yes, bruteforcing mostly increases the success rate on 128-bit WEP; it sometimes helps for 64-bit WEP, although it does indeed slow down the process a little.

Also, I released beta6, which fixes a couple of issues. Hopefully the segfault problem you've experienced should be resolved

I also added an auto-detection script (monitor.sh), please try it out.

kimbell · 07-12-2005

Quote:

Originally Posted by devine

I also added an auto-detection script (monitor.sh), please try it out.

Could you make it so that we can specify or choose which interface will be place into monitor mode?

Quote:

* aireplay: attack 0: target access point must be specified

Why not keep the original attack also?

grcore · 07-12-2005

Quote:

Originally Posted by devine

I also added an auto-detection script (monitor.sh), please try it out.

Using HostAP drivers on a smc2532w-b card, it detects wlan0, but cannot ID the card or driver....

Also, I cannot seem to send faster than x100 or so with a prism2 card under some circumstances, need to do some investigation...(not much has changed with this since earlier beta's in that respect)

On another note, i like the -1 fake assoc better now. Is there a way to end the association? (im sure resetting the card does the trick, just wondering if there was a better way.

lookin good!

g

devine · 07-13-2005

Quote:

Originally Posted by kimbell

Could you make it so that we can specify or choose which interface will be place into monitor mode? Why not keep the original attack also?

Sure. About attack 0, the original behaviour was a bit reckless and inefficient.

Quote:

Originally Posted by grcore

Using HostAP drivers on a smc2532w-b card, it detects wlan0, but cannot ID the card or driver....

What's the output of dmesg | grep "netdevice wlan0" ?

Quote:

Originally Posted by grcore

Also, I cannot seem to send faster than x100 or so with a prism2 card under some circumstances, need to do some investigation...(not much has changed with this since earlier beta's in that respect)

Sadly, I've been unable to reproduce this behaviour

Quote:

Originally Posted by grcore

On another note, i like the -1 fake assoc better now. Is there a way to end the association?

Well no.

grcore · 07-13-2005

Quote:

Originally Posted by devine

What's the output of [font=Courier]dmesg | grep "netdevice wlan0"[/font

Mysteriously, it's working now.

I also noticed that the the hostap driver installation removed a line I had added to modproble.conf to fix a bios issue with this laptop that caused cardbus cards
to fail. (options yenta_socket bios_override=1).

Just a question regarding the issue I am occasionally having with the -x option not working right. Any suggestions what to look for when it is happening?

Thanks for everything...

g

devine · 07-14-2005

Quote:

Originally Posted by grcore

Just a question regarding the issue I am occasionally having with the -x option not working right. Any suggestions what to look for when it is happening?

Which firmware are you using ? There seems to be a rate issue with the latest 1.8.4 & hostap, as reported by a few people; consider downgrading to 1.7.4.

tekn0 · 07-14-2005

The monitor.sh script it working great and beta6 is amazing with hostap.
So far i have only come across 1 bug and it's the
"open(/dev/rtc) failed: Device or resource busy" bug which i noticed
only happens when the classic attack is allready waiting for an arp.
Also on my end it does not appear that the "bug" effects anything.
I notice it when i am trying to fake auth which is awesome might i add hehe

but the auth still continues and end with the

face.

Also i was wondering if you might be able to re-add that 30 second fake auth option because some routers require a fake auth every 30 secs to produce iv's and some dont, i have been using a while loop atm but it would be cool to put a delay int there hehe. (EDIT: Sorry im a dumbass hehe i missed the delay option and found changing from "0" to "31" seems to work well

I noticed to that most AP's give up the arp after about 5 deauths to ither FF:FF:FF:FF:FF:FF or the AP's BSSID but i think it would be cool for scripting purposes to maybe also set a int var to allow how many deauth packets should be shot, so after 10 deauths it would quit. Just a though.

Your awesome and thanks again for your amazing work

grcore · 07-15-2005

beta7, prism2.5 card, 1.7.4 firmware

somethng is wrong with airodump in beta7, it does not see very many APs, and only captures a packet here and there. something is wrong. beta6 works great.

g

tekn0 · 07-15-2005

Kinda Strange And Only Happens Some Of The Time

VERSION=aircrack-2.2-beta6
SYSTEM=Slackware 1.0
ROUTER=2WIRE (Cant check the firmware)
CARD=NL-2511CD Plus EXT2
FIRMWARE=UPDATED FROM BETA TAR HEX FILES

I noticed this today when i was doing testing with hostap vs. wlan-ng.
It appears that when doing the classic arp-replay attack with wlan-ng, wlan-ng is able to inject the arp without needing to fake-accociate at all.
When i do the same attack with hostap, i need to fake-assocate every 25 seconds or the router will stop generating IV's.

Also i noticed and this is kinda wierd, is that when i do the attack with hostap and the fake-accoc every 25 seconds i am able to crack the 40bit key at around 50,000IVs (I have done this 2 times on a few routers). Then doing the same attack with wlan-ng and not fake-accoc at all i still have not been able to crack the key.

All in all it only happens some of the time but still worth mentioning:
wlan-ng injection seems much faster and some how needs no accocation, but i still have not been able to crack the key. (is it possiable a driver could produce bunk IVs?)
Hostap is a bit slower but seems much more reliable as it seems normal that i would have to fake-accoc every 30 secs or so. (plus cracking the key in 50k Ivs is nice)

My next test is to see how many IVs it will take to crack the 40bit key vi the wlan-ng method. Then try to figure out why this only happens some times.
I have a stong feeling its on my end and not the drivers or aircracks hehe

Thanks again and i hope this helps

07-14-2005	#43 (permalink)
tekn0 Registered Member Join Date: Jan 2005 Posts: 36	Awesome Job :) The monitor.sh script it working great and beta6 is amazing with hostap. So far i have only come across 1 bug and it's the "open(/dev/rtc) failed: Device or resource busy" bug which i noticed only happens when the classic attack is allready waiting for an arp. Also on my end it does not appear that the "bug" effects anything. I notice it when i am trying to fake auth which is awesome might i add hehe but the auth still continues and end with the face. Also i was wondering if you might be able to re-add that 30 second fake auth option because some routers require a fake auth every 30 secs to produce iv's and some dont, i have been using a while loop atm but it would be cool to put a delay int there hehe. (EDIT: Sorry im a dumbass hehe i missed the delay option and found changing from "0" to "31" seems to work well I noticed to that most AP's give up the arp after about 5 deauths to ither FF:FF:FF:FF:FF:FF or the AP's BSSID but i think it would be cool for scripting purposes to maybe also set a int var to allow how many deauth packets should be shot, so after 10 deauths it would quit. Just a though. Your awesome and thanks again for your amazing work Last edited by tekn0 : 07-14-2005 at 10:05 PM.

07-15-2005	#45 (permalink)
tekn0 Registered Member Join Date: Jan 2005 Posts: 36	Kinda Strange Issue Kinda Strange And Only Happens Some Of The Time VERSION=aircrack-2.2-beta6 SYSTEM=Slackware 1.0 ROUTER=2WIRE (Cant check the firmware) CARD=NL-2511CD Plus EXT2 FIRMWARE=UPDATED FROM BETA TAR HEX FILES I noticed this today when i was doing testing with hostap vs. wlan-ng. It appears that when doing the classic arp-replay attack with wlan-ng, wlan-ng is able to inject the arp without needing to fake-accociate at all. When i do the same attack with hostap, i need to fake-assocate every 25 seconds or the router will stop generating IV's. Also i noticed and this is kinda wierd, is that when i do the attack with hostap and the fake-accoc every 25 seconds i am able to crack the 40bit key at around 50,000IVs (I have done this 2 times on a few routers). Then doing the same attack with wlan-ng and not fake-accoc at all i still have not been able to crack the key. All in all it only happens some of the time but still worth mentioning: wlan-ng injection seems much faster and some how needs no accocation, but i still have not been able to crack the key. (is it possiable a driver could produce bunk IVs?) Hostap is a bit slower but seems much more reliable as it seems normal that i would have to fake-accoc every 30 secs or so. (plus cracking the key in 50k Ivs is nice) My next test is to see how many IVs it will take to crack the 40bit key vi the wlan-ng method. Then try to figure out why this only happens some times. I have a stong feeling its on my end and not the drivers or aircracks hehe Thanks again and i hope this helps Last edited by tekn0 : 07-15-2005 at 11:55 PM.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

07-10-2005	#31 (permalink)
grcore Member at large Join Date: Aug 2004 Posts: 121	I may have some trouble trying to repeat it, as what I am doing is running aircrack while airodump is running in background. By the time it segfaults, the cap file has changed. I wonder if the problem may stem from running aircrack and airodump at the same time. I see the IV total increases as airodump runs. If I can get a capfile that will repeat the fault, I will let you know. g

07-11-2005	#33 (permalink)
devine Emergence Join Date: Jul 2004 Location: Paris Posts: 389	Thanks kimbell and grcore. When you run aircrack, do you only select one network, or are you trying to crack with IVs from multiple BSSID (using option -e) ?

07-11-2005	#36 (permalink)
grcore Member at large Join Date: Aug 2004 Posts: 121	After further tests between aircrack brutforcing that last two keybytes, it seems for 128b keys there is an advantage. The key comes considerably earlier in the caputure. (with 5 out of 5 sessions). With 7 out of 7 sessions on 64b keys, both appeard to crack with about the same mount of IVs, but bruteforcing the last two keybytes made the process take longer.... I guess a lot of it depends on luck, and where the keybyte is wrong. g

07-15-2005	#44 (permalink)
grcore Member at large Join Date: Aug 2004 Posts: 121	beta7, prism2.5 card, 1.7.4 firmware somethng is wrong with airodump in beta7, it does not see very many APs, and only captures a packet here and there. something is wrong. beta6 works great. g