morrownr / USB-WiFi

USB WiFi Adapter Information for Linux
2.39k stars 161 forks source link

Comfast CF-953AX (MT7921u): Problems with pentesting / wardriving (wifite2, aircrack-ng, etc.) #327

Open baltic-tea opened 8 months ago

baltic-tea commented 8 months ago

Subject links:

Downloaded and installed these MediaTek drivers as advised here by @morrownr:

Problems

  1. The device sometimes stops working (detecting APs) – need to re-plug it in USB port.

  2. CF-953AX in monitor control mode works correctly, but any attempt to capture handshakes by wifite2 on any WiFi point (with WPS or not) is very slow and always ends up with Failed status. When cracking WPS I only get fails and a large amount of timeouts (sometimes over 1500). This is true when wardriving any AP with any wifite call options. Often the wifite gets stuck at some stage, for example, when sending a PIN codes; all kinds of attacks are ineffective.

[!NOTE] When powered by USB 2.0, the adapter (in about 15-20 seconds) finds more than 140 APs. When powered by USB 3.0, it finds ~20-30 APs 🤔

INFO

USB information

lsusb usb

Output:

Bus 004 Device 002: ID 3574:6211 MediaTek Inc. Wireless_Device

Kernel message buffer on device re-plug.

dmesg --decode --time-format iso | grep -e 'usb' -e 'mt7921u'

Output ("-" is errors, "+" is drivers):

kern :info : 2023-11-03T03:18:38 usb 3-12: USB disconnect, device number 4
- kern :err  : 2023-11-03T03:18:40 mt7921u 3-12:1.0: timed out waiting for pending tx
kern :info : 2023-11-03T03:18:43 usb 3-12: new high-speed USB device number 5 using xhci_hcd
kern :info : 2023-11-03T03:18:43 usb 3-12: New USB device found, idVendor=3574, idProduct=6211, bcdDevice=1.00
kern :info : 2023-11-03T03:18:43 usb 3-12: New USB device strings: Mfr=2, Product=3, SerialNumber=4
kern :info : 2023-11-03T03:18:43 usb 3-12: Product: Wireless_Device
kern :info : 2023-11-03T03:18:43 usb 3-12: Manufacturer: MediaTek Inc.
kern :info : 2023-11-03T03:18:43 usb 3-12: SerialNumber: 000000000
+ kern :info : 2023-11-03T03:18:43 mt7921u 3-12:1.0: firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7961_1.bin
kern :info : 2023-11-03T03:18:43 usb 3-12: reset high-speed USB device number 5 using xhci_hcd
+ kern :info : 2023-11-03T03:18:43 mt7921u 3-12:1.0: firmware: direct-loading firmware mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
kern :info : 2023-11-03T03:18:43 3-12:1.0: HW/SW Version: 0x8a108a10, Build Time: 20230526130917a
+ kern :info : 2023-11-03T03:18:44 mt7921u 3-12:1.0: firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7961_1.bin
kern :info : 2023-11-03T03:18:44 mt7921u 3-12:1.0: WM Firmware Version: ____010000, Build Time: 20230526130958

Network information

iwconfig

Output:

lo        no wireless extensions.

eth0      no wireless extensions.

wlan0     IEEE 802.11  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=3 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on

Statistics in managed mode (wavemon)

Connected to your own WiFi router in the same room.

Screenshot of wavemon output ![CF-953AX_wavemon](https://github.com/morrownr/USB-WiFi/assets/97766478/a14a53a7-9772-4a62-beb2-2eedf45caf09)

Kill the conflict processes (NetworkManager.service)

sudo airmon-ng check kill

Output:

Killing these processes:

    PID Name
   1231 wpa_supplicant

Switch to monitor control mode

sudo airmon-ng start wlan0

Output:

PHY Interface   Driver      Chipset

phy0    wlan0       mt7921u     MediaTek Inc. Wireless_Device
        (mac80211 monitor mode vif enabled for [phy0]wlan0 on [phy0]wlan0mon)
        (mac80211 station mode vif disabled for [phy0]wlan0)

Check monitor control mode

First step.

iwconfig

Output:

lo        no wireless extensions.

eth0      no wireless extensions.

wlan0mon  IEEE 802.11  Mode:Monitor  Frequency:2.457 GHz  Tx-Power=3 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on

Second step.

iw dev

Output:

phy#0
    Interface wlan0mon
        ifindex 4
        wdev 0x2
        addr e0:e1:a9:38:96:1b
        type monitor
        channel 10 (2457 MHz), width: 20 MHz (no HT), center1: 2457 MHz
        txpower 3.00 dBm

Region and power configuration

[!NOTE] These actions probably do not affect the real power of WiFi-adapters.

sudo iw reg get

Output:

global
country 00: DFS-UNSET
        (2402 - 2472 @ 40), (6, 20), (N/A)
        (2457 - 2482 @ 20), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN
        (2474 - 2494 @ 20), (6, 20), (N/A), NO-OFDM, PASSIVE-SCAN
        (5170 - 5250 @ 80), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN
        (5250 - 5330 @ 80), (6, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN
        (5490 - 5730 @ 160), (6, 20), (0 ms), DFS, PASSIVE-SCAN
        (5735 - 5835 @ 80), (6, 20), (N/A), PASSIVE-SCAN
        (57240 - 63720 @ 2160), (N/A, 0), (N/A)

Changing region to BZ (Belize) works correctly.

sudo iw reg set BZ
sudo iw reg get

Output:

global
country BZ: DFS-UNSET
        (2400 - 2494 @ 40), (N/A, 36), (N/A)
        (5735 - 5835 @ 80), (N/A, 30), (N/A)

[!WARNING] I couldn't change the txpower value of Comfast CF-953AX. It is always 3.00 dBm. Tried it:

iw [options] dev <devname> set txpower <auto|fixed|limit> [<tx power in mBm>]

I think the visible value of the force is not true.


Check hcxdumptool

Tool version: hcxdumptool 6.3.1 (C) 2023 ZeroBeat

hcxdumptool -i wlan0

Output:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  0   3 e0e1a938961b e0e1a938961b * wlan0            mt7921u (NETLINK)

available frequencies: frequency [channel] tx-power of Regulatory Domain: 00

  2412 [  1] 20.0 dBm     2417 [  2] 20.0 dBm     2422 [  3] 20.0 dBm     2427 [  4] 20.0 dBm
  2432 [  5] 20.0 dBm     2437 [  6] 20.0 dBm     2442 [  7] 20.0 dBm     2447 [  8] 20.0 dBm
  2452 [  9] 20.0 dBm     2457 [ 10] 20.0 dBm     2462 [ 11] 20.0 dBm     2467 [ 12] 20.0 dBm
  2472 [ 13] 20.0 dBm     2484 [ 14] 20.0 dBm     5180 [ 36] 20.0 dBm     5200 [ 40] 20.0 dBm
  5220 [ 44] 20.0 dBm     5240 [ 48] 20.0 dBm     5260 [ 52] 20.0 dBm     5280 [ 56] 20.0 dBm
  5300 [ 60] 20.0 dBm     5320 [ 64] 20.0 dBm     5500 [100] 20.0 dBm     5520 [104] 20.0 dBm
  5540 [108] 20.0 dBm     5560 [112] 20.0 dBm     5580 [116] 20.0 dBm     5600 [120] 20.0 dBm
  5620 [124] 20.0 dBm     5640 [128] 20.0 dBm     5660 [132] 20.0 dBm     5680 [136] 20.0 dBm
  5700 [140] 20.0 dBm     5720 [144] 20.0 dBm     5745 [149] 20.0 dBm     5765 [153] 20.0 dBm
  5785 [157] 20.0 dBm     5805 [161] 20.0 dBm     5825 [165] 20.0 dBm     5845 [169] disabled
  5865 [173] disabled     5955 [  1] disabled     5975 [  5] disabled     5995 [  9] disabled
  6015 [ 13] disabled     6035 [ 17] disabled     6055 [ 21] disabled     6075 [ 25] disabled
  6095 [ 29] disabled     6115 [ 33] disabled     6135 [ 37] disabled     6155 [ 41] disabled
  6175 [ 45] disabled     6195 [ 49] disabled     6215 [ 53] disabled     6235 [ 57] disabled
  6255 [ 61] disabled     6275 [ 65] disabled     6295 [ 69] disabled     6315 [ 73] disabled
  6335 [ 77] disabled     6355 [ 81] disabled     6375 [ 85] disabled     6395 [ 89] disabled
  6415 [ 93] disabled     6435 [ 97] disabled     6455 [101] disabled     6475 [105] disabled
  6495 [109] disabled     6515 [113] disabled     6535 [117] disabled     6555 [121] disabled
  6575 [125] disabled     6595 [129] disabled     6615 [133] disabled     6635 [137] disabled
  6655 [141] disabled     6675 [145] disabled     6695 [149] disabled     6715 [153] disabled
  6735 [157] disabled     6755 [161] disabled     6775 [165] disabled     6795 [169] disabled
  6815 [173] disabled     6835 [177] disabled     6855 [181] disabled     6875 [185] disabled
  6895 [189] disabled     6915 [193] disabled     6935 [197] disabled     6955 [201] disabled
  6975 [205] disabled     6995 [209] disabled     7015 [213] disabled     7035 [217] disabled
  7055 [221] disabled     7075 [225] disabled     7095 [229] disabled     7115 [233] disabled

scan frequencies: frequency [channel] of Regulatory Domain: 00

  2412 [  1]      2437 [  6]      2462 [ 11]
Screenshot of hcxdumptool scan loop (empty) ![hcxdumptool -i result](https://github.com/morrownr/USB-WiFi/assets/97766478/6a351b18-13f6-4656-90bd-f260f2c16693)
morrownr commented 8 months ago

Hi @baltic-tea

Let me throw a few ideas out:

sudo airmon-ng check kill

Over the last few years I have noticed that using airmon-ng check kill is often less than effective. In fact, I wrote a script to replace it. My script does not kill, it pauses threads that may cause problems. The issues with killing is that some of the problematic processes are programmed these days to detect when they are going down and they start a new process effectively defeating any attempt to kill. Pausing the processes does not seem to trigger a new process.

Go to the Main Menu:

https://github.com/morrownr/USB-WiFi

Menu item 10 is what you want.

I couldn't change the txpower value of Comfast CF-953AX. It is always 3.00 dBm.

I have not seen a new adapter come on the market for a long time where we could set txpower.

3 dBm does not appear to be what we think it should be but consider it cosmetic as the actually results tell us it can't be 3 dBm.

sudo airmon-ng start wlan0

The script I mentioned above will also put the interface into monitor mode.

Downloaded and installed these MediaTek drivers as advised...

Those are the firmware files. The driver comes with the kernel. You only need to install the firmware files if the maintainer of the distros has not installed them or if they are an old version.

See if you can make some progress with the info above.

baltic-tea commented 7 months ago

Hi, @morrownr

Go to the Main Menu:

morrownr/USB-WiFi

Menu item 10 is what you want.

I run your scripts but am getting a wifite error:

sudo wifite

   .               .
 .´  ·  .     .  ·  `.  wifite2 2.7.0
 :  :  :  (¯)  :  :  :  a wireless auditor by derv82
 `.  ·  ` /¯\ ´  ·  .´  maintained by kimocoder
   `     /¯¯¯\     ´    https://github.com/kimocoder/wifite2

 [!] Conflicting processes: NetworkManager (PID 1106), wpa_supplicant (PID 2625)
 [!] If you have problems: kill -9 PID or re-run wifite with --kill

 [+] Using wlan0mon already in monitor mode

 [+] Scanning. Found 0 target(s), 0 client(s). Ctrl+C when ready
 [!] Error: No targets found. You may need to wait longer, or you may have issues with your wifi card

 [!] Exiting

Also tried to run stop-procs.sh in the background - no effect:

sudo ./stop-procs.sh wlan0mon &

Kernel output (after re-plugging adapter):

kern  :info  : 2023-11-03T14:50:27 usb 3-12: reset high-speed USB device number 5 using xhci_hcd
kern  :info  : 2023-11-03T14:50:27 mt7921u 3-12:1.0: firmware: direct-loading firmware mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
kern  :info  : 2023-11-03T14:50:27 mt7921u 3-12:1.0: HW/SW Version: 0x8a108a10, Build Time: 20230526130917a
kern  :info  : 2023-11-03T14:50:27 mt7921u 3-12:1.0: firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7961_1.bin
kern  :info  : 2023-11-03T14:50:27 mt7921u 3-12:1.0: WM Firmware Version: ____010000, Build Time: 20230526130958
kern  :info  : 2023-11-03T14:51:22 mt7921u 3-12:1.0 wlan0mon: renamed from wlan0
kern  :info  : 2023-11-03T14:51:30 mt7921u 3-12:1.0 wlan0mon: entered promiscuous mode
kern  :info  : 2023-11-03T14:51:30 mt7921u 3-12:1.0 wlan0mon: entered allmulticast mod
baltic-tea commented 7 months ago

After kill NetworkManager (PID 1106) the scanning started working... and then stopped again after rerun wifite.

morrownr commented 7 months ago

I run your scripts but am getting a wifite error:

I would not trust the output of wifite in this case because my start-mon.sh and stop-procs.sh scripts do not kill the processes so unless wifite is programmed to understand what is being done, it will simple say that the procs are running and there is a problem.

To do a proper test, run start-mon.sh and once you are in monitor mode, run the app you wish to run and see if it gives the results you are looking for. If not, post the steps necessary for me to reproduce the result and I will take a look.

Keep in mind, start-mon.sh does everything that stop-procs.sh does with the exception that it does not take the interface into monitor mode. After reading the docs again, I probably need to make that clear. I always run start-mon.sh because if I am stopping the processes, it is for monitor mode.

Keep in mind that there are some advantages to stopping the procs instead of killing them. There is no need to reboot to get things going again as start-mon.sh will simple release the procs to run again at the end of the script. It also allows a managed mode connection to stay connected so if you want to be connected to the internet with one interface and run monitor mode in another, it works.

Cheers

baltic-tea commented 7 months ago

Everything works fine now (wifite keeps giving error messages, but the scanning works correctly). I'll be testing the capturing handshake again.

UPD: This problem https://github.com/morrownr/USB-WiFi/issues/327#issuecomment-1792300434 occurs more frequently when connected to the motherboard's USB port. I'm confused.

baltic-tea commented 7 months ago

Actual situation

  1. After running only sudo ./Monitor_Mode/start-mon.sh wlan0: the adapter stops scanning APs. if it actually finds the APs:

    • slow scanning and little number of APs received (versus default wifite's script that switch adapter to monitor mode);
    • WPS status of every AP is "no" – it is not true;
    • all attacks ended with this error: Error: Target did not appear after 60 seconds, stopping;
  2. After running only sudo wifite (wifite using airmon-ng - reference code): the adapter start scanning APs (fast) and I was even able to crack a few WPS-encrypted APs, but - in this case - only one type of attack is effective – Pixie-Dust. Other types of attacks go on too long (usually triggers a timeout error) and have no effect.

P.S. in the 2nd scenario CF-953AX often - after a failed cracking try, I think - stops detecting APs and only re-plugging could fix it (switched to default managed mode after unplugging) - error message as hear.

morrownr commented 7 months ago

script stops scanning APs

How are you scanning for APs?

I'll do some testing here and see what I come up with.

baltic-tea commented 7 months ago

script stops scanning APs

How are you scanning for APs?

I'll do some testing here and see what I come up with.

I only running sudo wifite or sudo wifite --reaver --wps

wifite2 2.7.0 (bundled in Kali Linux)

morrownr commented 7 months ago

I did some testing.

Adapter with a mt7921au chipset. Alfa AXML. Distro: LMDE 6 (Debian 12)

sudo ./start-mon.sh <wlan0>
--------------------------------
    start-mon.sh 20230305
 --------------------------------
    WiFi Interface:
             wlxxxxxxxxx
 --------------------------------
    name  -  wlxxxxxxxxx
    type  -  monitor
    state -  DORMANT
    addr  -  00:c0:ca:aa:e8:ba
    chan  -  11 (2462 MHz), width: 20 MHz (no HT), center1: 2462 MHz
    txpw  -  18.00 dBm
 --------------------------------

 DORMANT = up but inactive.

 Ready for Monitor Mode use.

 You can place this terminal in
 the background while you run any
 applications you wish to run.

 Press any key to exit... 

Interestingly, I was able to change txpower using my script.

I then opened another terminal and...

Test injection

Scan

sudo airodump-ng <wlan0> --band ag

Set the channel of your choice

sudo iw dev <wlan0> set channel <channel> [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz]

Test

sudo aireplay-ng --test <wlan0>

Scanning was very fast and smooth. Changing channels was smooth. Injection was fast and smooth.

I suspect the problem is wifite. If you want me to test it, provide a link where I can get a deb.

Cheers

morrownr commented 7 months ago

FYI: I forgot to mention that I tested channels 11 and 44 so as to test 2.4 and 5 Ghz. Both tests were smooth and fast.

baltic-tea commented 7 months ago

If you want me to test it, provide a link where I can get a deb.

For example: https://packages.debian.org/sid/all/wifite/download https://debian.pkgs.org/sid/debian-main-amd64/wifite_2.7.0-1_all.deb.html

baltic-tea commented 7 months ago

In my case state value change from DOWN to UNKNOWN, not DORMANT, after that UP

 --------------------------------
    start-mon.sh 20230305
 --------------------------------
    WiFi Interface:
             wlan0
 --------------------------------
    name  -  wlan0mon
    type  -  monitor
    state -  UNKNOWN
    addr  -  9a:42:78:bc:xx:xx
    chan  -  6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz
    txpw  -  3.00 dBm
 --------------------------------

 DORMANT = up but inactive.

 Ready for Monitor Mode use.

I tried run airodump-ng independently of wifite in 1 and 2 scenarios that i described here. For 2 scenario I run wifite and immediately stop it to only change the mode. Got a similar situation (wifite is mostly python wrapper for some libs like aircrack-ng, I think):

  • slow scanning and little number of APs received (versus default wifite's script that switch adapter to monitor mode);
baltic-tea commented 7 months ago

### After your script

▶ sudo aireplay-ng --test wlan0mon

08:41:19  Trying broadcast probe requests...
08:41:21  No Answer...
08:41:21  Found 0 APs

▶ sudo aireplay-ng --test wlan0mon

08:41:24  Trying broadcast probe requests...
08:41:24  Injection is working!
08:41:26  Found 2 APs

08:41:26  Trying directed probe requests...
08:41:26  28:D1:27:E9:xx:xx - channel: 6 - 'A'
08:41:30  Ping (min/avg/max): 5.856ms/10.636ms/13.378ms Power: -75.00
08:41:30   8/30:  26%

08:41:30  50:FF:20:7E:xx:xx - channel: 6 - 'B'
08:41:35  Ping (min/avg/max): 1.444ms/7.372ms/11.797ms Power: -73.00
08:41:35   5/30:  16%

### After wifite

▶ sudo aireplay-ng --test wlan0mon
08:42:34  Trying broadcast probe requests...
08:42:34  Injection is working!
08:42:35  Found 13 APs

08:42:35  Trying directed probe requests...
08:42:35  28:6C:07:98:xx:xx - channel: 11 - 'X'
08:42:36  Ping (min/avg/max): 0.132ms/1.228ms/10.120ms Power: -55.86
08:42:36  28/30:  93%

08:42:36  B0:BE:76:A8:xx:xx - channel: 11 - 'Y'
08:42:38  Ping (min/avg/max): 0.088ms/2.607ms/8.735ms Power: -58.38
08:42:38  21/30:  70%

08:42:38  B0:A7:B9:40:xx:xx - channel: 11 - 'Z'
08:42:38  Ping (min/avg/max): 0.082ms/1.003ms/12.185ms Power: -71.41
08:42:38  29/30:  96%

08:42:38  B4:B0:24:18:xx:xx - channel: 11 - 'Y'
08:42:41  Ping (min/avg/max): 0.093ms/1.341ms/11.975ms Power: -76.71
08:42:41  14/30:  46%

08:42:41  08:C6:B3:DA:xx:xx - channel: 11 - 'O'
08:42:46  Ping (min/avg/max): 0.011ms/0.193ms/0.638ms Power: -78.00
08:42:46   5/30:  16%

08:42:46  68:FF:7B:64:xx:xx - channel: 11 - 'H'
08:42:52  Ping (min/avg/max): 0.011ms/0.587ms/1.163ms Power: -74.00
08:42:52   2/30:   6%

08:42:52  00:EB:D8:11:xx:xx - channel: 11 - 'F'
08:42:58  Ping (min/avg/max): 0.992ms/0.992ms/0.992ms Power: -78.00
08:42:58   1/30:   3%

08:42:58  B0:95:75:76:xx:xx - channel: 11 - 'S'
08:43:04   0/30:   0%

08:43:04  3C:84:6A:4A:xx:xx - channel: 11 - 'Z'
08:43:07  Ping (min/avg/max): 0.127ms/8.759ms/62.872ms Power: -75.29
08:43:07  14/30:  46%

08:43:07  50:D4:F7:D9:xx:xx - channel: 11 - 'L'
08:43:08  Ping (min/avg/max): 0.082ms/1.587ms/10.170ms Power: -70.83
08:43:08  23/30:  76%

08:43:08  CC:32:E5:96:xx:xx - channel: 11 - 'T'
08:43:14   0/30:   0%

08:43:14  E4:18:6B:01:xx:xx - channel: 11 - 'K'
08:43:20   0/30:   0%

08:43:20  38:6B:1C:9F:xx:xx - channel: 11 - 'R'
08:43:26  Ping (min/avg/max): 0.011ms/0.105ms/0.152ms Power: -78.33
08:43:26   3/30:  10%
morrownr commented 7 months ago

I will do additional testing on my script as I have time. My to-do list is long and it appears you have an acceptable solution.

baltic-tea commented 7 months ago

I have ordered an active USB cable and will be testing the CF-953AX with it. I will also try to do all this on Windows 11.

kasinjsh commented 7 months ago

I have Fenvi AX1800 (same chipset) that I'm passively testing for a while as WiFi penetration hardware combined whit arm SBC board for field work. Reason why I bought this WiFi adopter was because my existing WiFi adopter, Alpha AWUS036ACM, quite often hanged. As recommended here and overall on internet Mediatek chipsets should have the best support, so I bought Mediatek based again, but looks like there is instability issues on arm arch, again. Quickest way to hang these adopters is whit airodump-ng, sometimes it runs for tens of minutes, maybe hour of two, but usually hangs quite quickly, both adopters. I have tested on Allwinner, Rockchip based SBCs, also Raspberry Pi whit various kernels, usb2 or 3 makes no difference, also usb extensions overall work on both, but no difference. Both adopters work fine on x86, tested Fenvi on weekend whit default kali linux (6.3.0 kernel), run for more than 8h over night, no issues, also tried updating firmware to latest version on SBCs - nothing, it still hangs. Kismet works better, as it can be fine for hours, but can hang. I have not seen any log messages what happens, board just gets unresponsive (might try serial connection). I could not test on latest kernel version, as I am no guru on kernel compiling and use what armbian and others are providing. Arbian have latest kernel 6.6.0 on Rockchip soc, but there is issues whit usb ports, they flap. SBCs kernel versions overall are around 6.1, tested arm64 and armhf.

baltic-tea commented 7 months ago

I have ordered an active USB cable and will be testing the CF-953AX with it. I will also try to do all this on Windows 11.

CF-953AX does't work with an active USB cable (5 m)

morrownr commented 7 months ago

@baltic-tea

See the following post:

https://github.com/openwrt/mt76/issues/839

That post is by @zerbea . That location is the downstream OpenWRT repo for mt76. Zerbea knows far more about monitor mode than I do and we were talking. We both think it is time to try to get some eyes on the issues in monitor mode.