hccapx file with more handshakes - exhausted
#1
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)
Reply
#2
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.

Code:
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
Reply
#3
There is work in progress on wifite2:
https://github.com/kimocoder/wifite2/issues/1

as well as on aircrack-ng:
https://github.com/aircrack-ng/aircrack-ng/issues/2079
https://github.com/aircrack-ng/aircrack-ng/issues/2067
https://github.com/aircrack-ng/aircrack-ng/issues/1958

and of course on hcxpcaptool and hcxdumptool, too.
Reply
#4
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

Postak
Reply