New hccapx format explained
#41
(03-09-2017, 07:10 PM)abdou99 Wrote:
(03-09-2017, 06:50 PM)TheFool Wrote:
(02-16-2017, 08:28 PM)c4p0ne Wrote: 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
Reply
#42
Information 
(03-09-2017, 07:17 PM)TheFool Wrote:
(03-09-2017, 07:10 PM)abdou99 Wrote:
(03-09-2017, 06:50 PM)TheFool Wrote:
(02-16-2017, 08:28 PM)c4p0ne Wrote: 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.
Reply
#43
(03-09-2017, 09:48 PM)c4p0ne Wrote: [
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.

Thanks for the info!

I am a newbie/fool so I don't understand everything you posted..  What I did was take the raw .cap file and run it through the cap2hccapx converter, then sent hashcat to work on it. (Which took 1 second, because of my single-word wordlist).  But.. no luck... "hashcat exhausted."

So.. it failed.

Then.. I took the same .cap file and converted it with aircrack-ng, and ran it through an older version of hashcat.. Boom, it cracked.

So how were you able to get 3/6 cracked on a single hccapx when I got no results at all? :/
Reply
#44
I didn't take any special action. Just reporting my results with the provided ap.cap/ap.hccapx, which are that the .cap contains at least 3 crackable handshakes. I don't know why your .hccapx file is not producing those results. Could be a range of reasons.
Reply
#45
For short readers: Everything is fine here. For all others, here's our analysis:

The Handshake in the cap has the following entries:

M1 and M2 from the first handshake
M1, M2, M3 and M4 from the second handshake.

The evil about this is that the ReplayCounter was always set to 4. That is kind of a bad behavior from the AP, but hashcat can deal with it. So it created the following hanshakes:

M1 + M2 of the first handshake
M1 + M2 of the second handshake
M2 + M3 of the second handshake.

Those are fine, and they all have been cracked with hashcat. There's also

M1 of the first and M2 of the second handshake.

The cap2hccapx tool exported it correctly, because the AP marked both with ReplayCounter 4, which caused by the deauth attack spam. So it's not possible to crack this, but that's the price to pay in general. We export more handshakes than required just to make sure that there's at least one that is cracking. It doesn't cost us any performance to check 4 or 1, because the calculation is done after the PBKDF2.
Reply
#46
(03-10-2017, 11:58 AM)atom Wrote: For short readers: Everything is fine here. For all others, here's our analysis:

The Handshake in the cap has the following entries:

M1 and M2 from the first handshake
M1, M2, M3 and M4 from the second handshake.

The evil about this is that the ReplayCounter was always set to 4. That is kind of a bad behavior from the AP, but hashcat can deal with it. So it created the following hanshakes:

M1 + M2 of the first handshake
M1 + M2 of the second handshake
M2 + M3 of the second handshake.

Those are fine, and they all have been cracked with hashcat. There's also

M1 of the first and M2 of the second handshake.

The cap2hccapx tool exported it correctly, because the AP marked both with ReplayCounter 4, which caused by the deauth attack spam. So it's not possible to crack this, but that's the price to pay in general. We export more handshakes than required just to make sure that there's at least one that is cracking. It doesn't cost us any performance to check 4 or 1, because the calculation is done after the PBKDF2.

Thanks for the info, atom.

My newbie question still remains, however. How come I was able to crack it as a .hccap but not as a .hccapx?

.hccap was generated by aircrack-ng
.hccapx was generated with the cap2hccapx.exe tool (Windows)

Also.. what do you mean by "Those are fine, and they all have been cracked with hashcat." I just got "hashcat exhausted"....
Reply
#47
That's some local problem on your side then. Works for everyone else. Read this: https://hashcat.net/wiki/doku.php?id=fre...hould_i_do and follow it 100% as it is written there, especially when you have to manually do something.
Reply
#48
Links to HCCAP and HCCAPX formats definition are incorrect. Correct ones are:
HCCAP format
HCCAPX format
Reply