hashcat Forum
Hcxtools Freezes Mid Operation - Printable Version

+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Misc (https://hashcat.net/forum/forum-15.html)
+--- Forum: User Contributions (https://hashcat.net/forum/forum-25.html)
+--- Thread: Hcxtools Freezes Mid Operation (/thread-10484.html)

Hcxtools Freezes Mid Operation - Rocuronium - 11-27-2021

For some reason when I run hcxdump it takes several minutes to start and will pick up 3 or 4 out of probably 20 nearby networks which Wifite can find as can any Aircrack-ng commands. I'm even using four of the Alfa 9dbi antennas on my Alfa AC1900. Not only that but it takes almost fifteen minutes in between networks as opposed to seconds or a few minutes between each. If I manually kill "Networkadapter.services" it will not even run saying "Network Is Down". If I use airmon-ng check kill or manually kill the wpa_supplicant it makes no difference in results. Aircrack-ng applications, Besside, and Wifite all detect networks with no issue. Here's what my terminal looks like and after a half hour no new networks have popped up. I'm running The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) in a Virtual Box.


Code:
┌──(roc㉿Rocuronium)-[~]
└─$ sudo airmon-ng check kill
[sudo] password for roc:

Killing these processes:

    PID Name
  1245 wpa_supplicant

                                                                                                                                                                                       
┌──(roc㉿Rocuronium)-[~]
└─$ sudo hcxdumptool -i wlan0 -o GalleriaMall.pcapng --enable_status=1
initialization of hcxdumptool 6.2.4-62-gafc9e51...

start capturing (stop with ctrl+c)
NMEA 0183 SENTENCE........: N/A
INTERFACE NAME............: wlan0
INTERFACE PROTOCOL........: unassociated
INTERFACE TX POWER........: 0 dBm (lowest value reported by the device)
INTERFACE HARDWARE MAC....: 00c0caaedd33 (not used for the attack)
INTERFACE VIRTUAL MAC.....: 00c0caaedd33 (not used for the attack)
DRIVER....................: rtl8814au
DRIVER VERSION............: 5.14.0-kali4-amd64
DRIVER FIRMWARE VERSION...:
openSSL version...........: 1.1
ERRORMAX..................: 100 errors
BPF code blocks...........: 0
FILTERLIST ACCESS POINT...: 0 entries
FILTERLIST CLIENT.........: 0 entries
FILTERMODE................: unused
WEAK CANDIDATE............: 12345678
ESSID list................: 0 entries
ACCESS POINT (ROGUE)......: 000dc2377263 (BROADCAST HIDDEN used for the attack)
ACCESS POINT (ROGUE)......: 000dc2377264 (BROADCAST OPEN used for the attack)
ACCESS POINT (ROGUE)......: 000dc2377265 (used for the attack and incremented on every new client)
CLIENT (ROGUE)............: c022507c6834
EAPOLTIMEOUT..............: 20000 usec
EAPOLEAPTIMEOUT...........: 2500000 usec
REPLAYCOUNT...............: 62528
ANONCE....................: 3a4e60aa2d7d064b41aa98bf4eccf0633be0e78ecff43c3ef4cb0229588971f4
SNONCE....................: bf353673c46030e8b44e989a4cb8faaa329b8b158b55c07de98e0b517549ecac

13:23:59 2447/8  c022507c6834 bc99115d4233 N60 wifi [PMKIDROGUE:6a91c174352638c5a5385746b527db61 KDV:2]
13:24:19 2452/9  8cc6816c337e 980d678e2bea n60B [PMKID:69ed33987e137136f7700a8949ab859c KDV:2]
13:24:19 2452/9  8cc6816c337e 980d678e2bea n60B [EAPOL:M1M2 EAPOLTIME:4617 RC:0 KDV:2]
13:24:19 2452/9  8cc6816c337e 980d678e2bea n60B [EAPOL:M2M3 EAPOLTIME:48 RC:1 KDV:2]
13:24:19 2452/9  8cc6816c337e 980d678e2bea n60B [EAPOL:M3M4ZEROED EAPOLTIME:19 RC:1 KDV:2]
13:40:45 5222/44  7c5079402987 44a56edf0f02 Hillarys_Email_Server_5G [EAPOL:M1M2 EAPOLTIME:4 RC:1 KDV:2]
13:40:45 5222/44  7c5079402987 44a56edf0f02 Hillarys_Email_Server_5G [EAPOL:M2M3 EAPOLTIME:4406 RC:2 KDV:2]
13:40:45 5222/44  7c5079402987 44a56edf0f02 Hillarys_Email_Server_5G [EAPOL:M3M4ZEROED EAPOLTIME:27 RC:2 KDV:2]
13:40:52 5224/44  7c5079402987 44a56edf0f02 Hillarys_Email_Server_5G [EAPOL:M1M2 EAPOLTIME:31 RC:1 KDV:2]
13:40:52 5224/44  7c5079402987 44a56edf0f02 Hillarys_Email_Server_5G [EAPOL:M2M3 EAPOLTIME:68 RC:2 KDV:2]
13:40:52 5224/44  7c5079402987 44a56edf0f02 Hillarys_Email_Server_5G [EAPOL:M3M4ZEROED EAPOLTIME:43 RC:2 KDV:2]


RE: Hcxtools Freezes Mid Operation - ZerBea - 11-28-2021

That behavior is easy to explain. On option --enable_status=1 hcxdumptool will show only PMKIDs and EAPOL messages from connected CLIENTs. All other messages are suppressed.
If you would like to monitor more traffic (e.g. connection attempts), you must enable this by --enable_status=31

If you choose --enable_status=95 you will get an additional alive message every minute
Code:
10:21:00 2447/8   ERROR:1 INCOMING:1090 AGE:1 OUTGOING:432 PMKIDROGUE:1 PMKID:0 M1M2ROGUE:0 M1M2:0 M2M3:0 M3M4:0 M3M4ZEROED:0 GPS:0
Every ERROR value < 10 is ok. Mostly this are radiotap errors during init of the device.

If you would like to attack CLIENTs, too I recommend to activate beaconing by --active_beacon

The init process on some devices will take some time. Especially on dual or triple band devices, because hcxdumptool request all available frequencies from the device. The more frequencies, the longer the init time.


BTW:
You should know that you're running a driver (rtl8814au) that depend on NETLINK and hcxdumptool doesn't work well on this drivers.
Please take a look at the beginning of your status and you'll see that some information is not present or wrong:
INTERFACE PROTOCOL........: unassociated
INTERFACE TX POWER........: 0 dBm (lowest value reported by the device)
Looks like the interface isn't fully initialized.
Instead of reporting the NETWORK protocol the driver reported the association state which is unusual. Also it doesn't report the tx power.

compared to drivers without NETLINK dependency:
INTERFACE PROTOCOL........: IEEE 802.11
INTERFACE TX POWER........: 20 dBm (lowest value reported by the device)
DRIVER....................: rt2800usb

or
INTERFACE PROTOCOL........: IEEE 802.11
INTERFACE TX POWER........: 20 dBm (lowest value reported by the device)
DRIVER....................: mt7601u

The reason, why I don't use NETLINK stuff is explained here:
https://github.com/ZerBea/hcxdumptool/pull/176#issuecomment-858375892

A workaround could be to to activate monitor mode for the device by ip:
Code:
$ sudo ip link set dev wlan0 down
$ sudo iw dev wlan0 set type monitor
$ sudo ip link set dev wlan0 up
Assuming the interface is successfully initialized (by NETLINK commands), start hcxdumptool, that will skip some checks, now:
Code:
interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls

Please check the status. Is INTERFACE PROTOCOL and INTERFACE POWER correct shown, after setting monitor mode by iw (running NETLINK API)?

Please notice:
It is important to set monitor mode on the phy device and not to add a virtual interface.