hcxtools - solution for capturing wlan traffic and conversion to hashcat formats

[mugenma]

This information is only available in an original(!) and uncleaned(!) dump file (cap/pcap/pcapng format).
A single BEACON and a single M1 (with PMKID) or a single message pair (M1M2,  M2M3, M3M4 not zeroed SNONCE, M1M4 not zeroed SNONCE) is is far from enough to retrieve all this information!
Due to my analysis of dump files submitted to wpa-sec, I noticed many dump files which doesn't contain important frames. Either this frames are not stored by the dump tool or they have been removed/cleaned by the submitter. That will make it hard to recover the PSK.
tshark is a very good tool, to retrieve all information on the command line. If you prefer a GUI, you can use Wireshark.

Hash formats 1680x and 250x (hccapx) only contain pure information, required to recover the PSK.

BTW:
And example, what you're missing on a cleaned dump file or a dump file which doesn't contain this frames is here:
https://hashcat.net/forum/thread-6661-po...l#pid47500

1680x and 250x will be deprecated as soon as release of hashcat 6.0.0
Successor is the new hashline/hashmode 22000, which will give you full advantage of reuse of PBKDF2 over PMKID and EAPOL.

Thank you very much for in-depth reply. This is really helpful.
I knew about tshark and wireshark. I was hoping that there was simpler way
Thanks again !!!

[ZerBea]

tshark can do this really good:
$ tshark -r test.pcapng.cap -T fields -e wps.device_name -e wps.serial_number
or (inclusive transmitter address and ESSID):
$ tshark -r test.pcapng.cap -T fields -e wlan.ta -e wlan.ssid -e wps.device_name -e wps.serial_number

You can save them via stdout and validate them via bash commands with hcxhastool output.

[wakawaka]

updated to latest (after not updating 6 months or so) and I notice that when running latest hcxdumptool
- there is no more status line at the bottom which states how many handshakes have been captured anymore
- less items (status updates) on display than before ?
am running hcxdumptool with --enable_status=15, should this be changed to something else ?

anyway Zerbea, thanks for all your work in updating and adding new features to this tool.

[ZerBea]

We are using a bitmask:

Code:

--enable_status=<digit>            : enable real-time display (waterfall)
                                     some messages ​​are shown only once at the first occurrence
                                     bitmask:
                                       0: no status (default)
                                       1: EAPOL
                                       2: PROBE REQUEST/PROBE RESPONSE
                                       4: AUTHENTICATON
                                       8: ASSOCIATION/REASSOCIATION
                                      16: BEACON
                                      32: GPS (once a minute)
                                      64: internal status
                                     128: run as server
                                     256: run as client

To retrieve the status add 64!

[WPA_Catcher]

Hi ZerBea

Just thought I would let you know I am still watching your progress on GitHub as you tweak your code!

I am slowly working through the questions I have myself and look forward to the day hcx-anything replaces pretty much all other wifi tools.

Great work and thank you for sharing.

[ZerBea]

I'll do my very best.

BTW:
Feedback appreciated regarding this commit:
https://github.com/ZerBea/hcxdumptool/co...2d48e02cc5

Target: AP with activated Management Frame Protection (MFP) and (if possible) deactivated PMKID caching and connected CLIENT(s)
$ hcxdumptool -i interface --enable_status=63 --reactive_beacon -c working_channel_of_AP

expected result:
12:16:18 6 xxxxxxxxxxxx <-> xxxxxxxxxxxx REASSOCIATION (NETWORKNAME)
12:16:18 6 xxxxxxxxxxxx <-> xxxxxxxxxxxx MP:M1M2 RC:x EAPOLTIME:xxxxx (NETWORKNAME)
12:16:18 6 xxxxxxxxxxxx <-> xxxxxxxxxxxx MP:M2M3 RC:x EAPOLTIME:xxxxx (NETWORKNAME)

or
12:16:18 6 xxxxxxxxxxxx <-> xxxxxxxxxxxx REASSOCIATION (NETWORKNAME)
12:16:18 6 xxxxxxxxxxxx <-> xxxxxxxxxxxx MP:M1M2 RC:xxxxx EAPOLTIME:xxxxx (NETWORKNAME)

or
12:16:18 6 xxxxxxxxxxxx <-> xxxxxxxxxxxx REASSOCIATION (NETWORKNAME)
12:16:18 6 xxxxxxxxxxxx <-> xxxxxxxxxxxx MP:M1M2 RC:xxxxxx EAPOLTIME:xxxxx (NETWORKNAME)
12:16:18 6 xxxxxxxxxxxx <-> xxxxxxxxxxxx MP:M2M3 RC:x EAPOLTIME:xxxxx (NETWORKNAME)

or any combination of this message pairs.

For this test, it is important that the CLIENT is connected before hcxdumtool starts. Only then MFP is active.
If it isn't possible to deactivate PMKID caching, it is very likely that hcxdumptool got a PMKID before MFP is active and stops the attack. In that case please retry it.
Requesting a PMKID is much faster than retrieving a full 4-way handshake.

Read more about MFP (PMF) here:
https://en.wikipedia.org/wiki/IEEE_802.11w-2009

[WPA_Catcher]

I'll do my very best.

BTW:
Feedback appreciated regarding this commit: 
https://github.com/ZerBea/hcxdumptool/co...2d48e02cc5

I am impressed with the new vector, you are really pushing forward on all possibilities.

The more I learn about this subject the more I realise I am not qualified to have any opinion!

However I think the first option looks OK to me.

hcx- is just getting better and better!

[wakawaka]

am using RT3070 & RT3072 adapters with latest update

Code:

PHY    Interface      Driver          Chipset
phy0    wlan0          rt2800usb      Ralink Technology, Corp. RT2870/RT3070
phy1    wlan1          rt2800usb      Ralink Technology, Corp. RT3072

but get lots of these errors

Code:

INFO ERROR:0 INCOMING:581 OUTGOING:358 PMKID:0 MP:0 GPS:0 RINGBUFFER:13
INFO ERROR:0 INCOMING:1776 OUTGOING:1182 PMKID:21 MP:0 GPS:0 RINGBUFFER:15
INFO ERROR:0 INCOMING:3281 OUTGOING:1997 PMKID:21 MP:1 GPS:0 RINGBUFFER:16
INFO ERROR:0 INCOMING:4387 OUTGOING:2719 PMKID:21 MP:1 GPS:0 RINGBUFFER:17
INFO ERROR:0 INCOMING:5831 OUTGOING:3445 PMKID:21 MP:1 GPS:0 RINGBUFFER:17

is this normal? have another RT8812AU adapter that I  have not tried as it sometimes have driver issues
am still able to capture pmkid/handshakes

Code:

summary capture file:                         
---------------------
file name........................: dump1.cap
file type........................: pcapng 1.0
file hardware information........: x86_64
capture device vendor information: 000f02
file os information..............: Linux 5.4.8
file application information.....: hcxdumptool 6.0.1 (no custom options)
network type.....................: DLT_IEEE802_11_RADIO (127)
endianness.......................: little endian
read errors......................: flawless
minimum time stamp...............: (GMT)
maximum time stamp...............: (GMT)
packets inside...................: 142
skipped damaged packets..........: 1
packets with GPS data............: 0
packets with FCS.................: 0
beacons (total)..................: 17
beacons (WPS info inside)........: 5
probe requests...................: 3
probe responses..................: 12
association responses............: 4
authentications (OPEN SYSTEM)....: 5
authentications (BROADCOM).......: 1
EAPOL packets (total)............: 101
EAPOL packets (WPA2).............: 101
PMKIDs (not zeroed - total)......: 1
PMKIDs (WPA2)....................: 21
PMKIDs from access points........: 1
best handshakes (total)..........: 1 (ap-less: 0)
best PMKIDs (total)..............: 1

[ZerBea]

There are no(!) errors:
INFO ERROR:0 INCOMING:5831 OUTGOING:3445 PMKID:21 MP:1 GPS:0 RINGBUFFER:17

INFO ERROR:0 that means no device ERROR
INCOMING:5831 received packets
OUTGOING:3445 transmitted packets
PMKID:21 received total PMKIDs (not unique)
GPS:0 no GPS frames retrieved
MP:1 one hadhsake
RINGBUFFER: 17 APs in use

skipped damaged packets..........: 1
we possible miss the interface statistic block at the end of the cap file.

RT8812AU and RTL8188EU are under maintenance and there are many issues. Christian (kimocoder) doing a great job here:
https://github.com/aircrack-ng/rtl8812au/issues
https://github.com/aircrack-ng/rtl8188eus/issues
Unfortunately he is a little bit busy.

Unfortunately both drivers require iw (running NETLINK) to set monitor mode.
hcxdumptool use ioctl() and AF_PACKET instead of adding another dependency to the attack vector. That is much, much faster than a virtual NETLINK interface!

BTW:
hcxpcaptool is deprecated. Please use hcxpcapngtool!

[ciccio17]

hi zerbea, i'm back, long time now, hope everythink is ok for you. i have some question.
is the bug with ath9k-htc resolved? also is this problem the same on ath9k non usb card, i use hcxdumptool on openwrt in general? also i'm still on version 5 of your tools, and still on stable hashcat 5.1.
so should i stay on this old tools or just use the new one with my hardware and hashcat 5.1 version?
also is usable the tool on linux kernel 5.4.x?
i used your last git on kernel 4.19 and is totaly a different tool for me,
thank you for you work.