undirected PROBEREQUEST frames

[ZerBea]

Sometimes there is a pre-shared-key (PSK) in an undirected PROBEREQUEST frame.
It is definitively not a good idea to filter these undirected PROBEREQUEST frames by BPF.

Example:
week_client.pcapng.zip

Steps to reproduce:

$ wget https://github.com/user-attachments/files/22580813/week_client.pcapng.zip
$ hcxpcapngtool -o test.22000 -R test.list week_client.pcapng
$ hashcat -m 22000 --nonce-error-corrections=4 test.22000 test.list
hashcat (v7.1.2-172-g3bb8ab8d5) starting
...
f6b32d9fc030aa42a250f1e93785bc2d:a0f3c1503e62:b0c090467cab:hascat:v+#gqu5g9pqnp%+7jbf%2uex+8hlo3ms
...
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 22000 (WPA-PBKDF2-PMKID+EAPOL)
Hash.Target......: test.22000
Time.Started.....: Sun Sep 28 09:08:44 2025 (0 secs)
Time.Estimated...: Sun Sep 28 09:08:44 2025 (0 secs)
Kernel.Feature...: Pure Kernel (password length 8-63 bytes)
Guess.Base.......: File (test.list)
Guess.Queue......: 1/1 (100.00%)
Speed.#01........:        5 H/s (0.57ms) @ Accel:9 Loops:16 Thr:512 Vec:1
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 1/1 (100.00%)
Rejected.........: 0/1 (0.00%)
Restore.Point....: 0/1 (0.00%)
Restore.Sub.#01..: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#01...: v+#gqu5g9pqnp%+7jbf%2uex+8hlo3ms -> v+#gqu5g9pqnp%+7jbf%2uex+8hlo3ms
Hardware.Mon.#01.: Temp: 31c Fan: 23% Util: 97% Core: 683MHz Mem:5005MHz Bus:16

Started: Sun Sep 28 09:08:42 2025
Stopped: Sun Sep 28 09:08:45 2025

Absolutely no GPU password cracker is able to recover such PSKs within a human lifetime unless they get help by hcxdumptool and hcxpcapngtool which have identified a weak client. If this undirected PROBEREQUEST frames have been filtered out by a strict BPF, this information get lost and hcxpcapngtool print an information:

Information: 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.

Another feature is hashcat's great nonce-error-corrections feature (NC).
To recover this PSK you need an NC value of at least 4. In this case it is also possible to run hashcat with its default value of 8.

$ hashcat -m 22000 --nonce-error-corrections=0 test.22000 test.list
...
Session..........: hashcat                                
Status...........: Exhausted
Hash.Mode........: 22000 (WPA-PBKDF2-PMKID+EAPOL)
Hash.Target......: test.22000
Time.Started.....: Sun Sep 28 09:37:44 2025 (0 secs)
Time.Estimated...: Sun Sep 28 09:37:44 2025 (0 secs)
Kernel.Feature...: Pure Kernel (password length 8-63 bytes)
Guess.Base.......: File (test.list)
Guess.Queue......: 1/1 (100.00%)
Speed.#01........:        5 H/s (0.52ms) @ Accel:9 Loops:16 Thr:512 Vec:1
Recovered........: 0/1 (0.00%) Digests (total), 0/1 (0.00%) Digests (new)
Progress.........: 1/1 (100.00%)
Rejected.........: 0/1 (0.00%)
Restore.Point....: 1/1 (100.00%)
Restore.Sub.#01..: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#01...: v+#gqu5g9pqnp%+7jbf%2uex+8hlo3ms -> v+#gqu5g9pqnp%+7jbf%2uex+8hlo3ms
Hardware.Mon.#01.: Temp: 29c Fan: 23% Util: 85% Core: 822MHz Mem:5005MHz Bus:16

Started: Sun Sep 28 09:37:43 2025
Stopped: Sun Sep 28 09:37:45 2025