QSS Protocol for TP-Link Devices about reaver-wps

[GoogleCodeExporter]

I too have several TP-Link 1043 devices, and i don't have any issues cracking 
the wps/qss pincode.

Original comment by [email protected] on 31 Dec 2011 at 12:12

[GoogleCodeExporter]

Here there is another cap for a tl-wa901nd using the QSS utility.

This time I couldn't capture with reaver beacuse it gets stacked at this point:

Reaver v1.2 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner 
<[email protected]>

[+] Waiting for beacon from B0:48:7A:DB:6F:E7
[+] Switching mon0 to channel 9
[+] Associated with B0:48:7A:DB:6F:E7 (ESSID: TP-LINK_DB6FE7)

I tried with a 32 bits linux and with an ath5k with same results.


@stefanen

Are you using the latest firmware on your TP-Link 1043

Original comment by [email protected] on 31 Dec 2011 at 12:47

Attachments:

• tp_link_wa901nd_qss_utility_auth_windows.cap

[GoogleCodeExporter]

Succesfull auth using wpa_supplicant

Original comment by [email protected] on 31 Dec 2011 at 10:31

Attachments:

• tp_link_wr1043nd_qss_wpa_supplicant.cap

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I can see that the M2 packet of reaver is using:

Connection Type Flags: Unknown: 3 (0x03)

And the QSS utility and wpa_supplicant use :

Connection Type Flags: ESS (0x01)

Maybe is related to that? 

Original comment by [email protected] on 31 Dec 2011 at 10:37

[GoogleCodeExporter]

Reaver was updated to use connection type of 0x03 instead of 0x01 in some of 
the latest SVN check-ins, as this is what win7 sends (0x03 == ESS | IBSS).

Original comment by [email protected] on 31 Dec 2011 at 1:23

[GoogleCodeExporter]

Right after the M2 packet reaver is sending a M2D packet, shouldn't it wait for 
the M3 packet of the AP. 

Commenting wps_build_m2d in wps_registrar_get_msg(), reaver is able to send a 
M4 packet after the M3 packet of the AP, but then again reaver send some 
wsc_nack and the wps negotiation doesn't succeed.

Original comment by [email protected] on 31 Dec 2011 at 3:09

[GoogleCodeExporter]

I set the connection type to only use ESS. Also updated the code so that 
win7-specific options are only included in the M2 packet if --win7 is specified 
on the command line; run without --win7 and see if this changes anything for 
you.

FYI, based on the reaver pcap you provided, it looks like you may need to 
re-build reaver with 'make cleanall; ./configure; make'.

Original comment by [email protected] on 2 Jan 2012 at 3:32

• Changed state: Started

[GoogleCodeExporter]

No luck with this option.

I'm attaching the output and the cap files.

Thank you for your support

Original comment by [email protected] on 2 Jan 2012 at 4:22

Attachments:

• reaver_rev37.out
• tp_link_wr_1043nd_reaver_rev37.cap

[GoogleCodeExporter]

Well, After all it maybe driver related.

I've just tried with a usb dongle ZyDAS ZD1211 that uses the zd1211rw driver 
and it's worked great.

So to sum up:

Intel Centrino Ultimate-N 6300 (rev 35)---Iwlagn dirver---Kernel 3.1.6----Not 
Working
Atheros AR5001X+---ath5k driver---Kernel 3.1.6/ Kernel 2.6.34---Not Working
ZyDAS ZD1211---zd1211rw---Kernel 3.1.6---Working

So I'll stick to the usb dongle :) Thanks!!

Original comment by [email protected] on 2 Jan 2012 at 4:43

Attachments:

• rev37_zd1211rw_driver_single_pin_auth_with_windows7_option.cap
• rev37_zd1211rw_driver_normal_session.cap
• zd1211.out

[GoogleCodeExporter]

Hmm, interesting. I have not used the iwlagn or ath5k drivers myself, but I've 
had others tell me they worked for them. It may be specific to the actual card 
the drivers are talking to. 

Anyway, glad this fixed your issue as I have several TP-Links and Reaver works 
very well with all of them. I will add a "partially supported" section to the 
supported drivers wiki page and note that some of these drivers may or may not 
work depending on your card. Thanks!

Original comment by [email protected] on 2 Jan 2012 at 6:15

• Changed state: Fixed