(Aircrack)Yet another WEP cracking tool for Linux - Page 17

joswr1ght · 06-26-2005

Quote:

Originally Posted by devine

Thanks! Also, the WPA cracking code is about 4 times faster than cowpatty on x86 hardware, thanks to a fine tuned SHA-1 MMX implementation.

Excellent job Christophe, but I'm not seeing the 4x CPU performance increase on WPA-PSK cracking:

Code:

$ time ../cowpatty/cowpatty -f test/password.lst -r test/wpa.cap -s test
cowpatty 2.0 - WPA-PSK dictionary attack. <jwright@hasborg.com>

Collected all necessary data to mount crack against passphrase.
Starting dictionary attack.  Please be patient.

The PSK is "biscotte".

170 passphrases tested in 2.57 seconds:  66.15 passphrases/second

real    0m2.572s
user    0m2.568s
sys     0m0.001s

And Aircrack 2.2beta1:

Code:

$ time ./aircrack -a 2 -e test -w test/password.lst -b 00:09:5b:91:53:5d test/wpa.cap -0 -q
KEY FOUND! [ biscotte ]

real    0m1.382s
user    0m0.003s
sys     0m0.002s

This is on a Pentium 4 2.8 GHz machine:

Code:

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 3
model name      : Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping        : 4
cpu MHz         : 2793.836
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl cid xtpr
bogomips        : 5521.40

I'm seeing a 2x performance increase (which is totally awesome!), not a 4x performance increase. Any thoughts on what is different in your test case?

Compiled Aircrack with just "make", no changes to Makefile.

Thanks,

-Josh

devine · 06-26-2005

Quote:

Originally Posted by joswr1ght

I'm seeing a 2x performance increase (which is totally awesome!), not a 4x performance increase. Any thoughts on what is different in your test case?

Hi Josh!

Here are the test results on my Pentium M 1.4 GHz; aircrack is compiled with make, and cowpatty 2.0 is compiled with -DOPENSSL. gcc version is 3.3.5 (Debian 1:3.3.5-8).

Code:

# time ./aircrack -w test/password.lst test/wpa.cap -e test -q
KEY FOUND! [ biscotte ]

real    0m1.650s
user    0m0.000s
sys     0m0.000s

Code:

# ../cowpatty/cowpatty -f test/password.lst -r test/wpa.cap -s test
cowpatty 2.0 - WPA-PSK dictionary attack. <jwright@hasborg.com>

Collected all necessary data to mount crack against passphrase.
Starting dictionary attack.  Please be patient.

The PSK is "biscotte".

168 passphrases tested in 3.95 seconds:  42.49 passphrases/second
Segmentation fault

Indeed, there's only a 2.39 performance increase! I stand corrected

-- Christophe

grcore · 06-26-2005

aireplay (in aircrack-2.2-beta1) gives me an error:

Make sure enhanced rtc device support is enabled in the kernel (module rtc, not genrtc) - also try 'echo 1024 >/proc/sys/dev/rtc/max-user-freq'.

I doublechecked my kernel config, and RTC is set to built in:

Code:

Subarchitecture Type (PC-compatible) --->
     Processor family (Pentium-4/Celeron(P4-based)/Pentium-4 M/Xeon) --->
[ ] Generic x86 support
[*] HPET Timer Support
[*] Provide RTC interrupt
[ ] Symmetric multi-processing support
[ ] Preemptible Kernel
[*] Local APIC support on uniprocessors
[*] IO-APIC support on uniprocessors
[*] Machine Check Exception

I tried changing the max-user-freq to 1024 (as specified, it was 64), but did not make any difference.

kernel is 2.6.11

g

devine · 06-26-2005

Quote:

Originally Posted by grcore

aireplay (in aircrack-2.2-beta1) gives me an error:

Make sure enhanced rtc device support is enabled in the kernel (module rtc, not genrtc) - also try 'echo 1024 >/proc/sys/dev/rtc/max-user-freq'.

Yes, that's a bug in the code. I forgot the resolution was supposed to be a multiple of 2. In aireplay.c, line 347, replace:

Code:

    if( ioctl( fd_rtc, RTC_IRQP_SET, 1000 ) < 0 )

With

Code:

    if( ioctl( fd_rtc, RTC_IRQP_SET, 1024 ) < 0 )

And it should work.

grcore · 06-26-2005

Quote:

Originally Posted by devine

Yes, that's a bug in the code. I forgot the resolution was supposed to be a multiple of 2. In aireplay.c, line 347, replace:

Code:

    if( ioctl( fd_rtc, RTC_IRQP_SET, 1000 ) < 0 )

With

Code:

    if( ioctl( fd_rtc, RTC_IRQP_SET, 1024 ) < 0 )

That did the trick.

I notice some strangeness with airodump though. First, the sample syntax it displays is inaccurate, which is not a big deal but confusing. Second, I see the AP list is separated into two sections. On top is what I imagine is the channel hopping list, and the capture list below (I think, not sure). Anyway when running the chopchop attack, I get a shitload* of bssid's in the capture list, which come from the arp transmits.

I have not checked out the WPA stuff yet.

g

devine · 06-26-2005

Quote:

Originally Posted by grcore

I notice some strangeness with airodump though. First, the sample syntax it displays is inaccurate, which is not a big deal but confusing.

Right, fixed that.

Quote:

Originally Posted by grcore

Second, I see the AP list is separated into two sections. On top is what I imagine is the channel hopping list, and the capture list below (I think, not sure). Anyway when running the chopchop attack, I get a shitload* of bssid's in the capture list, which come from the arp transmits.

The first list is the detected access points, the second list is the detected wireless clients. When running chopchop in non-authenticated mode, it will generate a bunch of forged station MACs, thus flooding airodump. I'll implement a workaround for this.

In other news, I released aircrack-2.2-beta2. Most notably, it features fake open-system authentication in Monitor mode (see the README for more details).

_metro_ · 06-27-2005

Quote:

Originally Posted by devine

By the way, I've left a couple of easter eggs in the aircrack source code

This weekend i note the l33t colors!
So matrix...

alex_ng · 06-27-2005

Quote:

Originally Posted by devine

As of now, I haven't started hacking the Win32 code. I'm rather focusing on fully automating the attacks in aireplay, especially the ARP replay attack. The basic idea is, for each captured ARP request, to resend it and check if it generates some IVs - if not, try another ARP request, etc.

hi devine, i have a question regarding ARP replay method. If a particular model of AP is susceptible to ARP replay I assumed all replayed ARP requests would work, provided the spoofed MAC is still associated. However when I put this to the test, it is as you say, only certain ARP requests will elicit a response from the network. Could you explain why? I use the following filter in ethereal to find ARP frames during the initial traffic analysis:

Code:

wlan.wep.iv&&wlan.addr==ff:ff:ff:ff:ff:ff&&frame.pkt_len==68

Thank you for your incredible work on this tool.

devine · 06-28-2005

Quote:

Originally Posted by alex_ng

hi devine, i have a question regarding ARP replay method. If a particular model of AP is susceptible to ARP replay I assumed all replayed ARP requests would work, provided the spoofed MAC is still associated. However when I put this to the test, it is as you say, only certain ARP requests will elicit a response from the network. Could you explain why?

Basically, an ARP request asks the MAC address for a given destination IP (like 192.168.1.100). But if say, 192.168.1.100 is not online anymore it won't reply, so the ARP request won't generate any traffic. Thus, when creating an ARP request with arpforge you must take care that the destination IP responds (the source IP doesn't matter). Also, the source MAC must be of course associated with the access point.

jlmcp · 06-28-2005

Chris & All,

We just tried the Beta3 version of Air* Suite on Linux, and had mixed luck. The primary issue we are having is getting AiroDump to accurately identify an access point as using WEP or WPA encryption.

We have an access point configured with a standard 128-bit WEP key, but AiroDump fulctuates beteween reporting this as WEP or WPA. If you attempt to run AirCrack and a moment when it thinks the AP is using WPA, you get the "found 0 IV's..." message. If you happen to run AirCrack when it assumes that the AP is running WEP, it works as expected.

Kind of odd.

Just our experience, any hints?

Jake

devine · 06-28-2005

Quote:

Originally Posted by jlmcp

We just tried the Beta3 version of Air* Suite on Linux, and had mixed luck. The primary issue we are having is getting AiroDump to accurately identify an access point as using WEP or WPA encryption.

Which chipset are you using for capturing packets ?

-- Christophe

grcore · 06-28-2005

I have had some time to mess around with beta3. Seems the fastest I can send arps out (and get an equal number of replies) is about -x 100. Going any faster does not produce better results.

Older versions (as I remember) were quite a bit faster. Are there any tweaks to make it more efficient? (or is this in my head...)

g

PS.edit: I was able to get the fake authentication to work...very cool. In the readme, it shows -1 12345 for aireplay, what is the 12345 for?

kimbell · 06-28-2005

-1 12345 is just the ssid of the network the client is on I think.

grcore · 06-28-2005

Quote:

Originally Posted by kimbell

-1 12345 is just the ssid of the network the client is on I think.

yes, you are right...i figured that out just now...duh

devine · 06-29-2005

Quote:

Originally Posted by grcore

I have had some time to mess around with beta3. Seems the fastest I can send arps out (and get an equal number of replies) is about -x 100. Going any faster does not produce better results.

Hi grcore!

This is probably happening because you're using linux 2.4 and aireplay couldn't get RTC. As a workaround, it uses usleep(), which has a granularity of 10ms on 2.4 -- hence the limit of 100 packets per second.

06-26-2005	#243 (permalink)
grcore Member at large Join Date: Aug 2004 Posts: 121	RTC is enabled.... aireplay (in aircrack-2.2-beta1) gives me an error: Make sure enhanced rtc device support is enabled in the kernel (module rtc, not genrtc) - also try 'echo 1024 >/proc/sys/dev/rtc/max-user-freq'. I doublechecked my kernel config, and RTC is set to built in: Code: Subarchitecture Type (PC-compatible) ---> Processor family (Pentium-4/Celeron(P4-based)/Pentium-4 M/Xeon) ---> [ ] Generic x86 support [] HPET Timer Support [] Provide RTC interrupt [ ] Symmetric multi-processing support [ ] Preemptible Kernel [] Local APIC support on uniprocessors [] IO-APIC support on uniprocessors [] Machine Check Exception I tried changing the max-user-freq to 1024 (as specified, it was 64), but did not make any difference. kernel is 2.6.11 g Last edited by grcore : 06-26-2005 at 02:17 PM.*

06-28-2005	#252 (permalink)
grcore Member at large Join Date: Aug 2004 Posts: 121	I have had some time to mess around with beta3. Seems the fastest I can send arps out (and get an equal number of replies) is about -x 100. Going any faster does not produce better results. Older versions (as I remember) were quite a bit faster. Are there any tweaks to make it more efficient? (or is this in my head...) g PS.edit: I was able to get the fake authentication to work...very cool. In the readme, it shows -1 12345 for aireplay, what is the 12345 for? Last edited by grcore : 06-28-2005 at 06:49 PM.

06-28-2005	#253 (permalink)
kimbell Registered Member Join Date: Jan 2005 Posts: 38	-1 12345 is just the ssid of the network the client is on I think. __________________

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

06-28-2005	#250 (permalink)
jlmcp Registered Member Join Date: Jul 2002 Posts: 17	Chris & All, We just tried the Beta3 version of Air* Suite on Linux, and had mixed luck. The primary issue we are having is getting AiroDump to accurately identify an access point as using WEP or WPA encryption. We have an access point configured with a standard 128-bit WEP key, but AiroDump fulctuates beteween reporting this as WEP or WPA. If you attempt to run AirCrack and a moment when it thinks the AP is using WPA, you get the "found 0 IV's..." message. If you happen to run AirCrack when it assumes that the AP is running WEP, it works as expected. Kind of odd. Just our experience, any hints? Jake