Comfast CF-953AX (MT7921u): Problems with pentesting / wardriving (wifite2, aircrack-ng, etc.) #327
Comments
baltic-tea
changed the title
|
Hi @baltic-tea Let me throw a few ideas out:
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 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.
The script I mentioned above will also put the interface into monitor mode.
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. |
|
Hi, @morrownr
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
[!] ExitingAlso tried to run 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 |
|
After kill |
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 |
|
Everything works fine now (wifite keeps giving error messages, but the scanning works correctly). I'll be testing the capturing handshake again. UPD: |
|
Actual situation
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. |
How are you scanning for APs? I'll do some testing here and see what I come up with. |
I only running wifite2 2.7.0 (bundled in Kali Linux) |
|
I did some testing. Adapter with a mt7921au chipset. Alfa AXML. Interestingly, I was able to change txpower using my script. I then opened another terminal and... Test injection Scan Set the channel of your choice Test 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 |
|
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. |
For example: |
|
In my case --------------------------------
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
|
### 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%
|
|
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. |
|
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. |
|
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. |
CF-953AX does't work with an active USB cable (5 m) |
|
See the following post: 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. |
Subject links:
OS: Kali Linux 2023.3 [Kernel 6.3.0, Xfce 4.18.4]
Downloaded and installed these MediaTek drivers as advised here by @morrownr:
Problems
The device sometimes stops working (detecting APs) – need to re-plug it in USB port.
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
Failedstatus. 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 thewifitegets 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
Output:
Kernel message buffer on device re-plug.
Output ("-" is errors, "+" is drivers):
Network information
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:onStatistics in managed mode (wavemon)
Connected to your own WiFi router in the same room.
Screenshot of wavemon output
Kill the conflict processes (NetworkManager.service)
sudo airmon-ng check killOutput:
Killing these processes: PID Name 1231 wpa_supplicantSwitch to monitor control mode
Output:
Check monitor control mode
First step.
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:onSecond step.
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 dBmRegion and power configuration
Note
These actions probably do not affect the real power of WiFi-adapters.
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 getOutput:
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
txpowervalue of Comfast CF-953AX. It is always 3.00 dBm. Tried it:I think the visible value of the force is not true.
Check hcxdumptool
Tool version: hcxdumptool 6.3.1 (C) 2023 ZeroBeat
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)
The text was updated successfully, but these errors were encountered: