New hccapx format explained

[c4p0ne]

Also, I have a test AP here whose password is known. cap2hccapx extracts dosens of handshakes from my .cap files off that AP. Yet the known password isn't being cracked. I'm assuming 100% of all of those handshakes are bad. But I'm having trouble understanding how it's grabbing handshakes when the only machine connected to the AP is not re-authenticating (i'm not running any de-auth attacks, just casually sniffing).

I think there is a problem with this new tool... 

Testing my own AP, I captured the handshake (using aircrack) and used a wordlist with 1 word (because I know the password).

Older version of hashcat, aircrack-ng to convert to .hccap -- success!

Hashcat 3.4, using the SAME .cap and converting it to .hccapx with cap2hccapx -- FAIL - hashcat exhausted.

.... confused.

Please upload that .cap file let me test it

http://www.bithop.net/AP.cap

The AP's password is: Password4

Here are my results with "AP.cap":

Wireless Password Auditor (Elcomsoft) > Detects 2 handshakes:

1 (valid) = FAILED
2 (no data) = FAILED

Wireless Password Recovery (Passcape) > Detects 2 handshakes:

1 (invalid) = CRACKED
2 (unknown) = CRACKED

cap2hccapx converter > Detects 6 handshakes:
hashcat results:

1 (P0) = CRACKED
2 (P0) = CRACKED
3 (P0) = FAILED
4 (P0) = CRACKED
5 (P2) = FAILED
6 (P2) = CRACKED

In this experiment with AP.cap, I have also discovered something new & weird. When running an attack on a SINGLE .hccapx file with all 6 handshakes, the result is 3 out of 6 get cracked. However, when manually separating the 6 handshakes each into its own individual .hccapx file and attacking them one-by-one, *4* out of 6 get cracked.