hashcat Forum

Full Version: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
The whole filter stuff was refactored:
Now we have filtermode (0, 1, 2) in combination with filterlist_ap (ACCESS POINTs) and filterlist_client (CLIENTs).
That is much faster than filtering ACCESS POINTs and CLIENTs running the same list.

Additional, we have a new and very fast Berkeley Packet Filter as alternative. I suggest to use this in case of protection of ACCESS POINTs and CLIENTs. Usage of Berkeley Packet Filter Code is explained in help menu and here:
https://biot.com/capstats/bpf.html
and here:
https://www.tcpdump.org/manpages/pcap-filter.7.html
and here:
https://www.tcpdump.org/manpages/tcpdump.1.html

To answer your question:
filtering command to receive transmission of ap & client
create Berkeley Packet Filter Code
$ tcpdump -i <interface> wlan addr1 11:22:33:44:55:66 or wlan addr2 11:22:33:44:55:66 -ddd > attack.bpf
than run hcxdumptool --bpfc=attack.bpf
Notice:
It is mandatory to add every ACCESS POINT and every CLIENT here (each for addr1 and addr2)!
can hcxdumptool decloak and capture handshakes from hidden ssid ?
hcxdumptool try to attack the ACCESS POINT (AP) by transmitting several requests and capture the whole traffic. That depend on the options, you selected.
If the AP respond to the requests, we retrieve the ESSID and the PMKID (if the AP support PMKID caching). The same applies, if we receive CLIENTs belonging to this AP. In that case, we will receive a M2 and/or M4 from the CLIENT (handshake).
In every other case we will not receive the ESSID and the received PMKIDs and/or EAPOL messages are useless, because hcxdumptool doesn't transmit random generated ESSIDs in the hope that one ESSID match.
Hello there,
the first post in this thread mentions that the AWUS036NHA is still in work.
Are there any news to it?
That depend on the wireless driver (must support full monitor mode, full packet injection and ioctl() system calls).
At last the Atheros driver (ath9k) was completely broken:
https://bugzilla.kernel.org/show_bug.cgi?id=208251
https://bugzilla.kernel.org/show_bug.cgi?id=208579
https://bugzilla.kernel.org/show_bug.cgi?id=208577
Additional there a some more issues:
https://bugzilla.kernel.org/show_bug.cgi?id=207397
https://bugzilla.kernel.org/show_bug.cgi?id=208111
the list is long...

Regarding this issues I can't recommend a device that uses this chipset and wireless driver in combination with hcxdumptool.
Additional I can't recommend high (output) power devices. A low power device and a good antenna is the better choice, because the HF signal is amplified in both directions (rx and tx).
My favorite chipset is MediaTek mt76 series. The driver is well maintained and working out of the box on kernel >= 5.4. The chipset is very sensitive.
https://github.com/openwrt/mt76
https://github.com/nbd168/wireless

Please notice:
It is important that the wireless driver support monitor mode!
It is important that the wireless driver support full packet injection!
It is important that the wireless driver support ioctl() system calls (not NETLINK messages)!
When all this conditions are met, hcxdumptool will work.

You can compare "hcxdumptool and wireless drivers" to "hashcat and GPU drivers".
Missing drivers or running deprecated drivers will cause both tools not to work.
Hm okay. Thanks for your quick reply though.
Guess I have to buy another adapter.
Here you will get some good additional information:
https://www.siliceo.es/en/classification...ibilities/
https://www.siliceo.es/en/the-four-types...gnal-wifi/

I strongly recommend to only buy adapters with a chipset that is supported by native kernel module (inclusive monitor mode and full packet injection).
Otherwise (third party driver) you will run into a dependency hell on next kernel update.
To get information about driver, monitor mode and packet injection capabilities, read more here:
https://wikidevi.wi-cat.ru/Main_Page

To get information about the progress regarding wireless kernel drivers, read more here (Linux Wireless Mailing List):
https://patchwork.kernel.org/project/lin...less/list/

If a kernel driver doesn't support monitor mode or full packet injection, you can make a feature request here:
https://bugzilla.kernel.org/
hi zerbea, hope all is well, long time now. i use your tools from the first you have done to the last, and on every linux kernel, always with ath9k radios, and i never, never had any problem. also hcxdumptool is fenomenal on owt and ath9k.
i have it running on kernel 4.4.xx, 4.14.xx, 4.19.xx, and now on kernel 5.4.xx and ath9k, never a problem.
Nice to hear that.
Unfortunately driver was broken on other kernel versions for a few months:
https://bugzilla.kernel.org/show_bug.cgi?id=208579
https://bugzilla.kernel.org/show_bug.cgi?id=208577
but that should be fixed, now.

BTW:
Latest git head of hcxtools/hcxdumptool received some nice improvements.
Additional I started to remove deprecated 2500/16800 tools because hashcat -m 22000 is working fine.
hi zerbea, hope all is well, i want ask you something about hcxdumptool. my question is:
it's possible to use other wifi channels , or this need a rewrite of the code? i can do that with airodump, but i'm not able to do that on hcxdumptool. thanks!
basically it's possible to set frequency?