No wifi card found

[xirotech]

My Phone is OnePlus7+Android 9.5.8+Nethunter

Perhaps this Android version is too new, so I have encountered a lot of strange problems (about aircrack-ng、wifite), but the difficult ones have been solved one by one.

hcxdumptool is the only problem left. I think this problem can only be solved by you. ;-)

airodump-ng works fine, but now hcxdumptool doesn't seem to recognize

[ZerBea]

The included driver doesn't support ioctl() system calls. It is reported also here https://forums.kali.org/showthread.php?44222-Gemini-monitoring-mode-question-amp-using-hcxdumptool&p=85992#post85992 and here https://github.com/ZerBea/hcxdumptool/issues/60 airodump-ng and iw are working, because they use NETLINK and the driver uses NETLINK, too. hcxdumptool doesn't use NETLINK and will not work using this driver The error message told you this: ioctl(SIGCGIWMODE) not supported by driver

You can try to stop wpa_supplicant because it interferes with hcxdumptool. But I don't think it will block the ioctl() system calls.

You can test if NETLINK is in use, running this command: iw --debug dev wlan1 set type monitor If you receive a message like this Debug: Sent Message: BEGIN NETLINK MESSAGE --------------------------- [NETLINK HEADER] 16 octets .nlmsg_len = 36 .type = 30 <0x1e> .flags = 5 <REQUEST,ACK> .seq = 1576446905 .port = 1434473441 [GENERIC NETLINK HEADER] 4 octets .cmd = 6 .version = 0 .unused = 0 [PAYLOAD] 16 octets 08 00 03 00 03 00 00 00 08 00 05 00 06 00 00 00 ................ END NETLINK MESSAGE ---------------------------

you're on a NETLINK interface.

[xirotech]

Thanks for your detailed reply, I will perform more tests to determine the problem

btw: I used the same wifi card to use hcxdumptool normally on another older (CM13) Android phone. I will see if the driver is different, thank you again

[ZerBea]

We can use iconfig to test that ioctl() calls are working. iwconfig doesn't use NETLINK. iwconfig wlan1 mode monitor if we get an error, we know that ioctl() calls are not supported by the driver.

[ZerBea]

USING NETLINK is no option for hcxdumptool, because: https://www.quora.com/What-are-the-differences-between-netlink-sockets-and-ioctl-calls https://config9.com/linux/ioctl-vs-netlink-vs-memmap-to-communicate-between-kernel-space-and-user-space/

[xirotech]

We can use iconfig to test that ioctl() calls are working. iwconfig doesn't use NETLINK. iwconfig wlan1 mode monitor if we get an error, we know that ioctl() calls are not supported by the driver.

Yes, as you would expect, iwconfig reports an error.

[ZerBea]

There must be a reason why the developer decided to use NETLINK instead of ioctl() calls. I'm running this driver (rt2800usb) on Arch Linux and it is working fine (out of the box). All ioctl() calls are supported. Maybe you can open an issue on Android Nethunter. There are similar issues mentioned here: https://forums.kali.org/archive/index.php/t-22989.html

[kimocoder]

@ZerBea We've got it. Thanks a lot, there are some issues as Android 9 & Android 10 is fairly new to the NetHunter project, as it was left behind for some time there's lots to catch up with :1st_place_medal:

[ZerBea]

Great, please keep me in the loop, because hcxdumptool can't give up ioctl() system calls. NETLINK is not an alternative to perform high speed attack vectors. NETLINK is designed to transport data (a stream, some mails, messenger traffic, nice pictures of lovely kittens, ...) but never to run attacks in a penetration environment.

[ZerBea]

By the way: Switching from iwconfig to iw doesn't make life easier. iw doesn't detect missing ioctl() system calls.

[kimocoder]

Hmm... I haven't really figured all that IOCTL, Netlink functions yet. This is what I see..

"iwconfig" is deprecated see https://dougvitale.wordpress.com/2011/12/21/deprecated-linux-networking-commands-and-their-replacements/

And I notice it struggles more and more, but! I also see developers is removing the IOCTL functions from their drivers, similar to our.

Think I need to spend some time learning more about those two.. IOCTL is also used for lots of functions. Read, read read

[ZerBea]

Yes correct, iwconfig is deprecated and replaced by iw and iw is working fine. I recommend iw and ip, too, to set monitor mode. Unfortunately NETLINK and it's messages isn't able to control a driver in that way, we need to run some attacks. Control: ioctl should be your first choice, unless there’s an overriding reason, due to its immediacy and reliable delivery. Data: For occasional data passing, ioctl should work fine. For bulk data, and especially if you’re look at asynchronous operation, NETLINK is preferred.

Unfortunately we need "control" to perform attacks. In other words, if that feature is removed, the developer can remove monitor mode, too. Unfortunately, I noticed that Realtek is going in this direction (NETLINK prefered, no monitor mode and packet injection in staging driver).

[ZerBea]

BTW I share this opinion: https://stackoverflow.com/questions/40529308/linux-driver-ioctl-or-sysfs/41258845#41258845

[kimocoder]

Well this actually happened.. I've added monitor / frame injection to branch v5.2.20(.2) on rtl8812au, on the release after (v5.3.4), Realtek actually added frame injection themselves, BUT.. they have hidden it pretty good, cause I can't really find it. It's become unstable with time, so I have to diff and look around between v5.2.20 and v5.3.4 to find where they hidden it. Totally weird, as I can't maintain it properly..

[ZerBea]

I have a 8188 device (my 8811 isn't working in combination with the 8812au driver) and try to find out, what's going on inside the driver, if hashcat 6.0.0 and hcxtools 6.0.0 released. New hashmode 22000 has priority (Atom pushed a hashcat update, yesterday), because it will save much GPU time. From now on we pay the price (PBKDF2) once and get the results (PMKID and EAPOL) twice (on same ESSIDs). Firsts tests are very impressive.

[kimocoder]

8188 is working fine, they didn't add it there, and that's much more stable, faster/reliable. injection at 88XXau is sluggish, but working atm, even though I only did the v5.3.9 branch, not the two others yet

[ZerBea]

BTW: I have a 8821AE PCIe device and monitor mode is working like a charm. All ioctl() system calls are accepted by the driver.

[ZerBea]

8188: $ sudo hcxdumptool -i wlp39s0f3u3u1u2 --check_driver initialization... starting driver test... failed to set monitor mode, ioctl(SIOCSIWMODE) not supported by driver: Operation not permitted

now running iw and create a NETLINK interface: Interface wlp39s0f3u3u1u2 ifindex 8 wdev 0x200000001 addr 50:3e:aa:d5:e0:35 type monitor wiphy 2 txpower 13.00 dBm

$ sudo hcxdumptool -i wlp39s0f3u3u1u2 --check_driver initialization... starting driver test... interface is already in monitor mode driver tests passed... all required ioctl() system calls are supported by driver

terminating... Now the driver is working. Unfortunately, the only way to set monitor mode is doing this via NETLINK

Once, if we did that we can set monitor mode by ioctl() calls, too: Interface wlp39s0f3u3u1u2 ifindex 8 wdev 0x200000001 addr 50:3e:aa:d5:e0:35 type managed wiphy 2 txpower 13.00 dBm

$ sudo hcxdumptool -i wlp39s0f3u3u1u2 --check_driver initialization... starting driver test... driver tests passed... all required ioctl() system calls are supported by driver

terminating...

In other words: After device is plugged in, we must use NETLINK to set monitor mode - otherwise the driver doesn't initialize the hardware properly. There is something missing if we try to do initialization by ioctl() calls only.

[kimocoder]

Take a look at this...

root@kali:~/Desktop/rtl8812au# grep -or "ioctl" | wc -l
2086
root@kali:~/Desktop/rtl8812au# grep -or "NL80211" | wc -l
537

I need to learn about these two, according to the internet the NETLINK should be used over ioctl() calls, like this guys explains at https://www.quora.com/What-are-the-differences-between-netlink-sockets-and-ioctl-calls

[ZerBea]

Correct. Unfortunately the ioctl() part is skipped during first init. Running NETLINK first, the driver doing an init as expected. Running ioctl() first, the interface remaining partly uninitialized. In that case we never reach this part: https://github.com/aircrack-ng/rtl8812au/blob/v5.6.4.2/os_dep/linux/ioctl_linux.c#L1390 because we run into several fails between here: https://github.com/aircrack-ng/rtl8812au/blob/v5.6.4.2/os_dep/linux/ioctl_linux.c#L1363 and here https://github.com/aircrack-ng/rtl8812au/blob/v5.6.4.2/os_dep/linux/ioctl_linux.c#L1388 Mostly the fail ocured here: https://github.com/aircrack-ng/rtl8812au/blob/v5.6.4.2/os_dep/linux/ioctl_linux.c#L1371 and here https://github.com/aircrack-ng/rtl8812au/blob/v5.6.4.2/os_dep/linux/ioctl_linux.c#L1376 because the struct wasn't filled properly, because the init failed.