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

[ciccio17]

i know, not a way to go on 5.4.xx and over kernels.

[ciccio17]

hi zerbea any progress on 2.4 ghz? i expanded the range, the patch applied, but the range is 1-14 with The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) patch

i'm not talking about hcxdumptool, the range of my phy is 1-14 with this patch.

[ZerBea]

You have to patch:
regulatory domain
common-init.c
regd.c
util.c
hw.h

[ciccio17]

hi zerbea, i'm back on the (1-14) + 0 -1 -2 channels, i'm not sure if you made it working on 2.4 ghz extended range.
but anyway the patches for me are totaly different, and i'm a common human, not an alien like you.Lol
so back : i see that my phy on 2.4 ghz is able to use channel -1 and -2 as mesh point and monitor and injection.
on 5.8 ghz my phy can do ap, station, until channel 179. and can do mesh point and monitor and injection until channel 184.
i just love hcxdumptool, thats why i'm so insistent.
so : my phy on 2.4 ghz is 2397-2484, hcxdumptool only see (1-14)
on 5.8 ghz hcxdumptool work until channel 175.
can we test this? for now?
anyway thanks for your help! you are a great one.

[ZerBea]

That depend on the 2.4GHz modification. if made correct, there are no negative channels. The expanded range is added as 14...33

Code:

+    CHAN2G(2312, 33), /* Channel -19 */
+    CHAN2G(2317, 32), /* Channel -18 */
+    CHAN2G(2322, 31), /* Channel -17 */
+    CHAN2G(2327, 30), /* Channel -16 */
+    CHAN2G(2332, 29), /* Channel -15 */
+    CHAN2G(2337, 28), /* Channel -14 */
+    CHAN2G(2342, 27), /* Channel -13 */
+    CHAN2G(2347, 26), /* Channel -12 */
+    CHAN2G(2352, 25), /* Channel -11 */
+    CHAN2G(2357, 24), /* Channel -10 */
+    CHAN2G(2362, 23), /* Channel -9 */
+    CHAN2G(2367, 22), /* Channel -8 */
+    CHAN2G(2372, 21), /* Channel -7 */
+    CHAN2G(2377, 20), /* Channel -6 */
+    CHAN2G(2382, 19), /* Channel -5 */
+    CHAN2G(2387, 18), /* Channel -4 */
+    CHAN2G(2392, 17), /* Channel -3 */
+    CHAN2G(2397, 16), /* Channel -2 */
+    CHAN2G(2402, 15), /* Channel -1 */
+    CHAN2G(2407, 14), /* Channel 0 */

This is only a comment:

Code:

/* Channel -3 */

If you are on 2397 it should be channel 17

Code:

CHAN2G(2392, 17)

No let's do a test to confirm expanded frequencies of the patch:
set monitor mode by hcxdumptool:

Code:

$ sudo hcxdumptool -m <interface>

Do not use iw - we don't want NETLINK stuff

open Wireshark and go to capture/options
select your interface
open the channel list
how much channels (channel . frequency) do you see?
please attach a screenshot of the opened channel list.

Please notice:
My committed changes only allow to set expanded channels, but it is possible that they don't show correct frequencies and channel numbers.
You must modify hcxdumptool, too. hcxdumptool's frequency range must match to your patched driver:
https://github.com/ZerBea/hcxdumptool/bl...ol.c#L6462

Code:

            else if((frequency >= 2407) && (frequency <= 2474)) testchannel = (frequency -2407)/5;
            else if((frequency >= 2481) && (frequency <= 2487)) testchannel = (frequency -2412)/5;
            else if((frequency >= 5150) && (frequency <= 5875)) testchannel = (frequency -5000)/5;

as mentioned here:
https://hashcat.net/forum/thread-6661-po...l#pid50509

If not modified, hcxdumptool will show you false frequencies and false channel numbers.

If the modification is working, please tell me the values (edge frequencies you used) and the output of hcxdumptool -C.

This one is is responsible to show the correct frequency for channel 14:
https://github.com/ZerBea/hcxdumptool/bl...ol.c#L6465

This one handle 2.4GHz frequencies:
https://github.com/ZerBea/hcxdumptool/bl...ol.c#L6464

This one handle 5GHz frequencies:
https://github.com/ZerBea/hcxdumptool/bl...ol.c#L6466

hcxdumptool's edge frequencies must(!) match to the edge frequencies of your driver!

[crappy.follower]

Hey,
Really enjoyed this tool and your work.
I have gone through the entire process of using hcxdumptools to capture wifi network data. 
I have converted the captured data using hcxpcapngtool.
I then use hashcat mode 22000 to start a dictionary attack.

I need to take a step back and ensure I have collected the appropriate data. 

I was wondering if there were any obvious ways to tell whether or not the captured data can be cracked? My concern is I have captured "synthetic hashes" (I read a post about this) which aren't actually capable of being cracked. For example, I have collected WPA 01 and WPA 02 data which has unknown MAC AP and Client data (hcxhashtool -i example.22000 --info=stdout).

When I enter the data into Hashcat, it starts the process, but not sure if its just making a bunch of sound and heat.

Is $ hcxhashtool -i example.22000 --info=stdout the indicator as to what hashes can be cracked? Despite many lines not having Mac AP and Client data?

[ZerBea]

Thanks. I'm glad to hear that the tools are working as expected.
hcxhashtool is designed to show an information about the content of the hash file. Unfortunately it is not able to detect whether a PSK can be recovered by hashcat or not.
But with the shown information you should be able to determine if it is useful to start a hashcat task on that hash or not. Also you can use this information to prepare/calculate the wordlist, mask or rule for this hash.
I give you some examples based on the output of hcxhastool --info=stdout

If the default PSK is based on the MAC_AP: search if there is an algo to calculate the default PSK for this MAC.
If yes, use the tools to calculate the exact PSK
https://github.com/routerkeygen
or the complete keyspace:
hcxpsktool

If the default PSK is based on the ESSID use
hcxpsktool
or
hcxeiutool -s option in combination with a rule (e.g. year) on hcxpcapngtool -EIU output

If the default PSK is requested and captured by hcxdumptool use hcxpcapngtool -EIU option and feed hashcat with this list.

Upload your captured dump file to wpa-sec to see if the PSK is inside of one of the default wordlists.
The results of wpa-sec are continuously used to improve hcxtools, e.g.:
https://github.com/ZerBea/hcxtools/pull/175
https://github.com/ZerBea/hcxtools/pull/172

Some words about the unknown MACs (AP and CLIENT):
To prevent tracking, nearly all CLIENTS running MAC randomization and hcxhashtool will show this MACs as unknown.
To prevent counter measures against us, hcxdumptool will randomize all MACs, too and hcxhashtool will show this MACs as unknown.

Also you should know that hcxdumptool/hcxtools are analysis tools. Therefore Atom added the new hash formats WPA-PBKDF2-PMKID+EAPOL (22000) and WPA-PMK-PMKID+EAPOL (22001) to hashcat. This allow huge analyses on mass data!
https://github.com/ZerBea/hcxtools/pulls...s%3Aclosed

[gentleforce]

That is another amazing feature.

$ hcxpcapngtool -o test.22000 -E wordlist test.pcap

$ hashcat -m 22000 test.22000 wordlist



hcxdumptool attack vector against weak client, converted to pcap by tshark, so that you can test it running other tools, too:

what's the rationale behind this?
how come the password gets broadcasted as SSID in a probe request?
is it a common user mistake (input in the wrong form)?

It's common to see brobe requests with SSIDs that really look like passwords, sometimes with multiple variations like "passwd123", "passwd 123", "Passwd123" but I cannot explain their origin.

My best guess is that confused users trying to connect to a hotspot might be typing the password when asked for ESSID, but it amazes me that it could be such a frequent mistake.

[ZerBea]

We can find PSKs in the clear in PROBEREQUEST and EAP-ID frames.
Your guess that confused users typing their PSK instead of the ESSID is correct. But we can find much more PSKs than this typo related ones. So it could be related to misconfigured/damaged config files and/or IoT devices.
Unfortunately we can't ask the user what he has done or take a look at his wpa_supplicant.conf.
So if someone has an idea why this happens, please let us know.

Running hcxdumptool 24/7, it is possible to recover the PSKs from 10% of the captured handshakes by this method.

Code:

$ sudo -i interface -o dump.pcapng --tot=1440 --bpfc=own.bpfc --disable_deauthentication --disable_ap_attacks --active_beacon -c 1,9,6,3,11 -t 3600

We choose 3 crowed channels and 2 less crowded channels for this attack.
We disable all AP attacks.
We stay a longer time on a channel to make sure every CLIENT will find us.
Please notice:
That depend on how much CLIENTs hcxdumptool attacked/received and on the attack mode:


A nice example is here (converted to old pcap, to allow old scool tools to read it, too) :
https://github.com/evilsocket/pwnagotchi...-598597214

BTW:
hcxpcapngtool will detect if this kind of frames is missing in a cap/pcap/pcapng file and print a warning:

Code:

summary capture file
--------------------
file name.................................: dump.cap
version (pcap/cap).......................: 2.4 (very basic format without any additional information)
timestamp minimum (GMT)..................: 19.01.2021 21:47:23
timestamp maximum (GMT)..................: 19.01.2021 23:08:33
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11 (105)
endianess (capture system)...............: little endian
packets inside...........................: 110524
BEACON (total)...........................: 1
ACTION (total)...........................: 4
PROBERESPONSE............................: 9
DEAUTHENTICATION (total).................: 32640
AUTHENTICATION (total)...................: 3
AUTHENTICATION (OPEN SYSTEM).............: 3
ASSOCIATIONREQUEST (total)...............: 2
ASSOCIATIONREQUEST (PSK).................: 2
WPA encrypted............................: 21324
EAPOL messages (total)...................: 4
EAPOL RSN messages.......................: 4
ESSID (total unique).....................: 1
EAPOLTIME gap (measured maximum usec)....: 10789
EAPOL ANONCE error corrections (NC)......: not detected
EAPOL M1 messages (total)................: 1
EAPOL M2 messages (total)................: 1
EAPOL M3 messages (total)................: 1
EAPOL M4 messages (total)................: 1
EAPOL pairs (total)......................: 2
EAPOL pairs (best).......................: 1
EAPOL M32E2 (authorized).................: 1

Information: no hashes written to hash files

Warning: out of sequence timestamps!
This dump file contains frames with out of sequence timestamps.
That is a bug of the capturing tool.

Warning: too many deauthentication/disassociation frames detected!
That can cause that an ACCESS POINT reset the EAPOL TIMER,
renew the ANONCE and set the PMKID to zero.
This could prevent to calculate a valid EAPOL MESSAGE PAIR
or to get a valid PMKID.

Warning: missing frames!
This dump file does not contain undirected proberequest frames.
An undirected proberequest may contain information about the PSK.
It always happens if the capture file was cleaned or
it could happen if filter options are used during capturing.
That makes it hard to recover the PSK.

Warning: missing frames!
This dump file does not contain enough EAPOL M1 frames.
It always happens if the capture file was cleaned or
it could happen if filter options are used during capturing.
That makes it impossible to calculate nonce-error-correction values.

[ciccio17]

i'm not sure about that but could be a bug in some version of wpa_supplicant?