hccapx file with more handshakes - exhausted
Hello friends, I have captured wifi handshake using "wifite2". When I convert CAP file to HCCAPX file (hcxtools), it consist of several saved handshakes (some may be wrong, but I'm sure that at least 1 is correct and crackable).

- When I use hashcat (hashcat-5.1.0+1412) on this "multi" HCCAPX file result is always "EXHAUSTED".
- When I split to 7 HCCAPX files and go 1 by 1, I get result on 1 of them with correct key.

What I'm doing wrong? Sad

p.s.: I tested second "multi" HCCAPX file with same behavior (split = cracked, multi = exhausted)
Use a more reliable software such as hcxdumptool which is better integrated with hashcat. You don't even need to acquire handshakes necessarily anymore. Unless Wifite is cleaning the caps, then that's the only potential issue.

If you're able to crack a single handshake, there is no difference having multiple handshakes in a single file, the only thing that will change is the time to crack.

Without seeing your hashcat command & log there's not much else we can help you with. Post something like this.

hashcat64.exe -1 ?d?H -2 01  -m 2500 -a 3 -w 4 capture.hccapx 2511?d?1?2?1?d?d?d?d
hashcat (v5.1.0) starting...

* Device #1: WARNING! Kernel exec timeout is not disabled.
             This may cause "CL_OUT_OF_RESOURCES" or related errors.
             To disable the timeout, see: https://hashcat.net/q/timeoutpatch
* Device #3: Intel's OpenCL runtime (GPU only) is currently broken.
             We are waiting for updated OpenCL drivers from Intel.
             You can use --force to override, but do not report related errors.
OpenCL Platform #1: NVIDIA Corporation
* Device #1: GeForce GTX 1070, 2048/8192 MB allocatable, 15MCU

OpenCL Platform #2: Intel(R) Corporation
* Device #2: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, skipped.
* Device #3: Intel(R) HD Graphics 4000, skipped.

Hashes: 6 digests; 6 unique digests, 6 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Applicable optimizers:
* Zero-Byte
* Brute-Force
* Slow-Hash-SIMD-LOOP

Minimum password length supported by kernel: 8
Maximum password length supported by kernel: 63

Watchdog: Temperature abort trigger set to 90c

INFO: Removed 3 hashes found in potfile.

[s]tatus [p]ause [b]ypass [c]heckpoint [q]uit =>

Session..........: hashcat
Status...........: Running
Hash.Type........: WPA-EAPOL-PBKDF2
Hash.Target......: capture.hccapx
Time.Started.....: Mon Nov 04 19:23:38 2019 (2 secs)
Time.Estimated...: Mon Nov 04 19:31:18 2019 (7 mins, 38 secs)
Guess.Mask.......: 2511?d?1?2?1?d?d?d?d [12]
Guess.Charset....: -1 ?d?H, -2 01, -3 Undefined, -4 Undefined
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:   334.7 kH/s (361.72ms) @ Accel:512 Loops:256 Thr:256 Vec:1
Recovered........: 3/6 (50.00%) Digests, 3/6 (50.00%) Salts
Progress.........: 0/307200000 (0.00%)
Rejected.........: 0/0 (0.00%)
Restore.Point....: 0/51200000 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:1280-1536
Candidates.#1....: 251123123456 -> 25116E0E3712
Hardware.Mon.#1..: Temp: 40c Fan: 25% Util:100% Core:2050MHz Mem:4104MHz Bus:16

[s]tatus [p]ause [b]ypass [c]heckpoint [q]uit =>

We need to see if you're actually attacking 7 different handshakes by checking the recovered line.
Recovered........: 3/6 (50.00%) Digests, 3/6 (50.00%) Salts
There is work in progress on wifite2:

as well as on aircrack-ng:

and of course on hcxpcaptool and hcxdumptool, too.
Guys, there is enough information for me in your answers. I will check "Digests" and "Salts" info Wink I know that capturing PMKID is enough so not need to capture 4-way HS. It really seams, that Wifite2 is not cleaning "incomplete" 4-way handshakes.

Thanks for your work!

best regards