New attack on WPA/WPA2 using PMKID
(08-22-2018, 02:54 PM)undeath Wrote: No. Please review hashcat's attack modes and their usages.

Thanks. I'll take a look at what you suggest.
Pushed a small update hcxdumptool. From now on we parse SAE completely:

[10:10:20 - 005] c83a35000002 -> c83a35000001 [AUTHENTICATION, SAE COMMIT, STATUS 0, SEQUENCE 304]
[10:10:20 - 005] c83a35000001 -> c83a35000002 [AUTHENTICATION, SAE COMMIT, STATUS 0, SEQUENCE 337]
[10:10:20 - 005] c83a35000002 -> c83a35000001 [AUTHENTICATION, SAE CONFIRM, STATUS 0, SEQUENCE 305]
[10:10:20 - 005] c83a35000001 -> c83a35000002 [AUTHENTICATION, SAE CONFIRM, STATUS 0, SEQUENCE 338]
[10:10:20 - 005] c83a35000001 -> c83a35000002 [FOUND PMKID]
[10:10:20 - 005] c83a35000001 -> c83a35000002 [FOUND AUTHORIZED HANDSHAKE, EAPOL TIMEOUT 3741]

as you can see here:
[10:10:20 - 005] c83a35000001 -> c83a35000002 [FOUND PMKID]
We are not able to attack SAE yet...

SAE = Simultaneous authentication of equals
pre-shared password-based authentication with stronger security than WPA-PSK (as known as WPA3-Personal)

struct sae_commit_authentication_frame
 uint16_t    group_id;
 uint8_t    scalar[32];
 uint8_t    commit_element_x[32];
 uint8_t    commit_element_y[32];
} __attribute__((__packed__));

struct sae_confirm_authentication_frame
 uint16_t    send_confirm;
 uint8_t    confirm[32];
} __attribute__((__packed__));

read more about the status codes (reason codes) here:

read more about WPA3-Personal and WPA3-Enterprise here:
Is there a way to append or concatenate results from multiple hcxdumptool sessions?
Hello. I've noticed that --do_rcascan never shows AP's where SSID is hidden/not broadcast. I believe these AP's should be in range. Is there a fix or workaround for this?
Thank you
Hi dizcza.
Yes, there is a way. From the
Most output files will be appended to existing files (with the exception of .cap files).
You can/should cat all outputs from hcxpcaptool to build up your cracking envirnoment as here described:

cap files can be merged by wireshark tools, but I do not recommend this.
Hi sl0badob
That is correct. An access point is detected to be in our range, if he responds to our request using his ESSID. We are not able to associate to an access point without this information. As long as we didn't receive this information, the access point is not in our protocol layer 2 range for a successful authentication.
I do not plan to change this behavior, because I do not want to fight windmills.

from hostapd.conf:
# Send empty SSID in beacons and ignore probe request frames that do not
# specify full SSID, i.e., require stations to know SSID.
# default: disabled (0)
# 1 = send empty (length=0) SSID in beacon and ignore probe request for
# broadcast SSID
# 2 = clear SSID (ASCII 0), but keep the original length (this may be required
# with some clients that do not support empty SSID) and ignore probe
# requests for broadcast SSID

The access point is detected, if it responds to an authorized client who knows the ESSID.
this script read the last line of 16800.pot and show this info:

saludos Diego
Hi diegodieguex.
Nice improvement. Now we can retrieve the ESSID (in ASCII) and the VENDOR information from the hashline.
thank you ZerBea

I have the same result replacing line 21 simply by:
cat /tmp/PSK

saludos Diego


[23:42:51 - 001] 6872321b37b7 -> b065bddf493a [FOUND AUTHORIZED HANDSHAKE, EAPOL TIMEOUT 1712]
[23:42:54 - 001] 6872321b37b7 -> 3ca3080633f0 [FOUND AUTHORIZED HANDSHAKE, EAPOL TIMEOUT 1383]

FYI: I'm near my router

What can I do? Sad