⚠️ Hacking should only ever be done with consent for pentesting (“ethical hacking”) and not for malicious purposes. Check your local laws before doing anything, I’m not responsible for your actions.
After looking for a potential upgrade to my Wi-Fi hacking dongle, I recently posted this onto my personal Signal “Sysadmin” group:
Just ordered a triband (2.4 – 6 GHz) Wi-Fi (6E) USB stick which should work with Linux’ drivers and support monitor mode and packet injection. I’ll let you know my findings once I got it and plugged it into Kali Linux.
Note: There is currently no USB Wi-Fi 7 that match this criteria, at least according to my findings.
There is however, PCIe Wi-Fi 7 cards that match the criteria.
The triband Wi-Fi 6E chipset on USB which supports monitor mode and packet injection is the mt7921au which is supported since Linux 5.18, with AP support added in 5.19 and P2P mode added in 6.4. The recommended kernel is 6.6 or later.
The TP-Link TXE50UH has the mt7921au chipset, so I ordered it for 40 EUR.
However, the device uses custom VID/DID, so it won’t show as mt7921au and won’t work plug and play. This can however be solved by writing a simple udev rule.
Native support will come in Linux 6.14 but writing an udev rule should be a good workaround until then.
I’ll have it on Tuesday and will test it out.
It’s now Tuesday, I got it, and it’s time to test it out. :D
On the USB stick’s sticker I can see it read “Archer TX50UH(EU) Ver:1.0″! That’s off by one letter… let’s continue anyway, maybe we’re lucky…
Plugging it into my M1 MacBook Air and attaching it to my Kali Linux (2024.4) VM (VMware Fusion) and running lsusb I can see this device:
ID 0bda:1a2b Realtek Semiconductor Corp. RTL8188GU 802.11n WLAN Adapter (Driver CDROM Mode)Now, Realtek sounds wrong, but keep in mind this device is designed for Windows and will first emulate a CDROM drive such that users can install the drivers straight from the stick. We don’t want the CDROM mode, and instead want to put it into the Wi-Fi card mode:
usb_modeswitch -KW -v 0bda -p 1a2bwhich will output:
Take all parameters from the command line
* usb_modeswitch: handle USB devices with multiple modes
* Version 2.6.1 (C) Josua Dietze 2017
* Based on libusb1/libusbx
! PLEASE REPORT NEW CONFIGURATIONS !
DefaultVendor= 0x0bda
DefaultProduct= 0x1a2b
StandardEject=1
Look for default devices ...
found USB ID 1d6b:0003
found USB ID 0bda:1a2b
vendor ID matched
product ID matched
found USB ID 0e0f:0002
found USB ID 0e0f:0002
found USB ID 0e0f:0006
found USB ID 0e0f:0003
found USB ID 1d6b:0002
found USB ID 1d6b:0002
Found devices in default mode (1)
Access device 007 on bus 001
Get the current device configuration ...
Current configuration number is 1
Use interface number 0
with class 8
Use endpoints 0x05 (out) and 0x84 (in)
USB description data (for identification)
-------------------------
Manufacturer: Realtek
Product: DISK
Serial No.: not provided
-------------------------
Sending standard EJECT sequence
Looking for active drivers ...
Set up interface 0
Use endpoint 0x05 for message sending ...
Trying to send message 1 to endpoint 0x05 ...
OK, message successfully sent
Read the response to message 1 (CSW) ...
Response successfully read (13 bytes), status 0
Trying to send message 2 to endpoint 0x05 ...
OK, message successfully sent
Read the response to message 2 (CSW) ...
Response reading failed (error -8)
Device is gone, skip any further commands
-> Run lsusb to note any changes. Bye!Uh oh, that failed. Well, we simply run usb_modeswitch again:
Take all parameters from the command line
* usb_modeswitch: handle USB devices with multiple modes
* Version 2.6.1 (C) Josua Dietze 2017
* Based on libusb1/libusbx
! PLEASE REPORT NEW CONFIGURATIONS !
DefaultVendor= 0x0bda
DefaultProduct= 0x1a2b
StandardEject=1
Look for default devices ...
found USB ID 1d6b:0003
found USB ID 0bda:1a2b
vendor ID matched
product ID matched
found USB ID 0e0f:0002
found USB ID 0e0f:0002
found USB ID 0e0f:0006
found USB ID 0e0f:0003
found USB ID 1d6b:0002
found USB ID 1d6b:0002
Found devices in default mode (1)
Access device 007 on bus 001
Get the current device configuration ...
Current configuration number is 1
Use interface number 0
with class 8
Use endpoints 0x05 (out) and 0x84 (in)
USB description data (for identification)
-------------------------
Manufacturer: Realtek
Product: DISK
Serial No.: not provided
-------------------------
Sending standard EJECT sequence
Looking for active drivers ...
Set up interface 0
Use endpoint 0x05 for message sending ...
Trying to send message 1 to endpoint 0x05 ...
OK, message successfully sent
Read the response to message 1 (CSW) ...
Response successfully read (13 bytes), status 0
Trying to send message 2 to endpoint 0x05 ...
Device seems to have vanished right after sending. Good.
Device is gone, skip any further commands
-> Run lsusb to note any changes. Bye!That worked! Now when we run lsusb again we can see:
35bc:0101 Realtek 802.11ax WLAN AdapterHmmm, still a Realtek Wi-Fi adapter… that’s… wrong.
We’re expecting a device with ID 35bc:0107 and instead we’re getting 35bc:0101… hm. Let’s run ip link and iwconfig… nothing. Let’s try lsmod and grep for mt and rt… nothing of relevance… Hm…
Let’s be naughty, and try something… let’s forcefully load the correct driver and force it upon this device. :D
modprobe mt7921uAnd we can see in dmesg:
usbcore: registered new interface driver mt7921uNow for the really naughty part:
echo 35bc 0101 > /sys/bus/usb/drivers/mt7921u/new_idAnd what does dmesg say?
usb 1-4.1: reset high-speed USB device number 8 using xhci_hcd
mt7921u 1-4.1:1.0: probe with driver mt7921u failed with error -22Seems we really got the wrong chipset here…
Hmmm, perhaps this really is just a Realtek Wi-Fi chipset… Ok, but can we get it to run as such, at least?
rmmod mt7921u mt7921_common mt792x_usb mt792x_lib mt76_usb mt76_connac_lib mt76Ok, we got rid of the wrong kernel modules, and dmesg confirms this:
usbcore: deregistering interface driver mt7921uNow, let’s see… lsusb doesn’t really reveal much other than that it’s a “Realtek 802.11ax WLAN Adapter” which is very generic. Time to Google. Aha!
Someone in a forum post stated that they contacted TP-Link and got this response from TP-Link “[…] TX50UH V1 is RTL8832CU […]”
Well, “RTL8832CU” is definitely more informative… let’s see… I can see a kernel module called rtl8xxxu… that’s the closest matching; Let’s try our luck…
modprobe rtl8xxxuAnd dmesg:
usbcore: registered new interface driver rtl8xxxuBut it seems this driver doesn’t offer any means to do echo 35bc 0101 > /sys/bus/usb/drivers/rtl8xxxu/... hm… let’s take a closer look at the driver:
modinfo rtl8xxxuWill output:
filename: /lib/modules/6.11.2-arm64/kernel/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.ko.xz
firmware: rtlwifi/rtl8192fufw.bin
firmware: rtlwifi/rtl8710bufw_UMC.bin
firmware: rtlwifi/rtl8710bufw_SMIC.bin
firmware: rtlwifi/rtl8188fufw.bin
firmware: rtlwifi/rtl8723bu_bt.bin
firmware: rtlwifi/rtl8723bu_nic.bin
firmware: rtlwifi/rtl8192eu_nic.bin
firmware: rtlwifi/rtl8192cufw_TMSC.bin
firmware: rtlwifi/rtl8192cufw_B.bin
firmware: rtlwifi/rtl8192cufw_A.bin
firmware: rtlwifi/rtl8188eufw.bin
firmware: rtlwifi/rtl8723aufw_B_NoBT.bin
firmware: rtlwifi/rtl8723aufw_B.bin
firmware: rtlwifi/rtl8723aufw_A.bin
license: GPL
description: RTL8XXXu USB mac80211 Wireless LAN Driver
author: Jes Sorensen <[email protected]>
[...]It doesn’t seem to mention any firmware files for this specific chipset… my guess is that this is the wrong driver.
Let’s check for packages:
apt search rtl8Hm, realtek-rtl88xxau-dkms does seem interesting. I mean, it’s an “a” instead of a “c” but my experience shows that sometimes one driver covers multiple similarly named chips.
But, nope! That just installs the realtek-rtl8814au-dkms which provides the kernel module rtl8821ae… not the right one…
*More Googling and asking girlfriend to Google along*
Ok, there’s this GitHub repo here that looks promising: https://github.com/morrownr/rtl8852cu-20240510
git clone https://github.com/morrownr/rtl8852cu-20240510
cd rtl8852cu-20240510
apt install linux-headers-6.11.2-arm64
./install-driver.shAfter successfully building and installing the driver we can optionally edit the driver options file at /etc/modprobe.d/8852cu.conf
We reboot and pray…
Oh! Ooooh! Blue blinking light on the Wi-Fi stick!
And what does ip link say? There’s wlan0! :D
But can we get into monitor mode?
airmon-ng check kill
airmon-ng start wlan0Output:
Killing these processes:
PID Name
1590 wpa_supplicant
PHY Interface Driver Chipset
phy0 wlan0 rtl8852cu Realtek 802.11ax WLAN Adapter
(monitor mode enabled)
ip link still only shows wlan0 despite “monitor mode enabled” hmmm…
airodump-ng wlan0 fails as well…
ioctl(SIOCSIWMODE) failed: Invalid argument
ioctl(SIOCSIWMODE) failed: Invalid argument
Error setting monitor mode on wlan0
Failed initializing wireless card(s): wlan0How about hcxdumptool -i wlan0? Nope:
Requesting physical interface capabilities. This may take some time.
Please be patient...
failed to arm interface
PACKET_STATISTICS failed
2 ERROR(s) during runtime
Possible reasons:
driver is broken
driver is busy (misconfigured system, other services access the INTERFACE)
0 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
Warning: too less packets received (monitor mode may not work as expected)
Possible reasons:
driver is broken (most likely)
no transmitter in range
frames are filtered out by BPF
0 SHB written to pcapng dumpfile
0 IDB written to pcapng dumpfile
0 ECB written to pcapng dumpfile
0 EPB written to pcapng dumpfileSo, we got Wi-Fi working but we can’t get into monitor mode. I also tried setting the country code (in the config file) and rebooting, because I know some Wi-Fi cards get sad if they don’t have a CC set, but it din’t change anything. I guess this driver and/or firmware just doesn’t do monitor mode. I spent an evening on this and am tired now, but I hope it was still an interesting read and that you could learn something on the way. Towards the end of the article I kept it more brief compared to the verbose beginning to not waste anyone else’s time.
The takeaway is: TX50UH is not TXE50UH and it won’t have the desired chipset. It’s not a device suitable for hacking, and I don’t recommend it for general use on Linux, either.
I can’t find the supposed TP-Link TXE50UH anywhere (at least not in my market). I could import that model from the US, but I’m not in the mood to deal with international shipping and customs. If anyone knows where to get the TP-Link TXE50UH with the supposed mt7921au chipset or another USB stick with the mt7921au chipset in the EU/EFTA market, please let me know.
Ok, fuck it, I’ll order it from the US… let’s see, 70 USD… Fine. Let’s check out… Oof. With shipping and customs we’re now at a little over 100 USD (pretty much close to 100 EUR). I can reduce this to 95 USD with slow shipping, but still not worth it. If anyone wants to donate a significant amount of the price to help me out, I’ll order the device and review it.
In any case, feel free donate at Ko-fi… As for this device here, looks like I’ll return it.
@sindastra hm.. you did try to turn it off and on but did you pry it open to check what's really in there? :D
Also… private Signal Sysadmin group? Curious now, very :)
I didn’t pry it open but since it doesn’t do the intended job, I better not do that so that I can return it. 😅
Also, curious? In what way? (:
@sindastra lemme join? FOMO is strong.
(And I don't really have any Signal groups so far beside fam :D)
@[email protected] I wasted an evening on this… :blobcat_daradara:
@[email protected] PS I offloaded the excerpt generation, I’m not sure I like it.
@[email protected] I changed “Upgrade your Wi-Fi hacking game on Linux!” to “I wasted an evening on this!”… I feel better about myself now. :starlight_happy: