feature request: add NONCE ERROR CORRECTIONS to hcxpmktool #287
Comments
|
Interesting case, because I have no idea what's going on, yet. hcxpmktool confirmed the PSK hashcat confirmed the PSK john confirmed the PSK Same procedure with the new hash: hcxpmktool doesn't confirm the PSK hashcat confirm the PSK john doesn't confirm the PSK, too. To make sure that the hash line is correct (hcxpcapngtool bug?), could you add the dump file, please? |
|
I'll contact Atom (hashcat) to figure out, what went wrong. My suspect is the hash line calculated by hcxpcapngtool - but I'm not sure without analyzing the dump file. |
|
I got it! The difference between hashcat and hcxpmktool and hashcat is that hcxpcapngtool converted the MESSAGEPAIR to hashcat, but due to a packet loss, NONCEERROR CORRECTION is mandatory to recover th PSK. Neither hcxpmktool nor john doing NC, so both will not get the PSK. received ANONCE: 96c4775604afb7eaa46c9d91404e756f44ac5ca383a6345aacf2474d81a9a095 hcxpmktool confirmed the PSK (using the corrected ANONCE) john confirmed the PSK (using the corrected ANONCE) All tools (hashcat with NC), john (without NC), hcxpmktool (without NC) doing exactly what expected. I'll add a notice to help, that hcxpmktool not doing NC. I'll leave this open to remind me to check if it is possible to add NC on CPU to hcxpmktool, because it will slow down us. |
ZerBea
changed the title
|
I changed the head line, because it is more a feature request than a bug. Now I test if we can add at least NC = 8. The impact is huge, because it will slow us down by factor 32 (8 + 8 + 8 + 8), because we have to calculate the PTK 32 times and the MIC times instead of one time: |
ZerBea
changed the title
|
Adding NC will take awhile. The entire tools must be refactored. |
|
Do you still require the initial capture which generated this hash? |
|
No, that is not necessary, because I know what's going on: packet loss during capturing In detail: PSK can be only confirmed/recovered by a tool that does NONCE ERROR CORRECTIONS (like hashcat). explanation of the MESSAGEPAIR field: Which tool was used to capture the traffic? |
|
hcxdumptool was used to capture the traffic |
|
Thanks for the information. Conclusion: |
|
Confirmed. Works in wifite2 v2.7.0 also. password recovered with both "hashcat" and "cowPatty". |
|
Doing NC is a little bit tricky (on CPU), because we need several load balancers: Additional we need a good (fast) data base. All together == complete new design of hcxpmktool. |
|
Please ask bitmask |
|
As of today all hcxtools only detect if NC is possible and hcxdumptool give a suggestion about the value. This bitmask is explained in help: Hashcat evaluate this bits to handle NC exactly. Additional hcxpcapngtool give an advice: The value can be used with hashcat "--nonce-error-corrections=". |
|
BTW: |
|
To decrypt WPA it is mandatory to calculate a PTK that is exactly part of the same AUTHENTICATION sequence (session) as the 4way handshake. A matching MESSAGE PAIR that is exactly part of this AUTHENTICATION sequence (session) is mandatory too. In other words: BTW: and you get a warning: |
|
Some information about NC: |
|
@ZerBea e,g How to confirm compensation at a certain field position |
|
Take a look at this example: we know that on some LE routers the ANONCE increase (BE routers are different) Not all routers use this mechanism. Some increment the REPLAYCOUNTER, some of them increment the SEQUENCE NUMBER, some of the do a mix of all. hashcat will now calculate MESSAGE PAIRs with the following ANONCE SNONCE combinations to calculate the PTK (and later on the MC) by the formulas as explained here: At least, one of this combinations lead to a PTK that calculate the correct MIC of the M2. The same applies to M3 or combinations om M1 and M3, e.g.: A dump file contain one M1 MESSAGE, one M2 MESSAGE and one M3 MESSAGE NC can be controlled via hascat "nonce-error-corrections" option. |
|
|
|
The entire process: It is mandatory that the dump file is uncleaned! |
|
NONCE sequence calculation is NC=16 This need NC+14 Or NC-14 If set to NC=8, |
|
Correct, but that depend on the exact(!) timestamp of the M2. NC should be at least 16 NC should be at least 14 But in that case it should be greater due to a possible packet loss: |
|
By default hashcat takes the ANONCE of the hash line: |
|
Just to mention that: That applies to BE routers, too: |
Avoid this situation happening |
|
To avoid missing packets it is mandatory to use an active dumper. This dumper must be able to detect a packet loss and it must be able to request the missing packets. |
|
@ZerBea e.g |
|
@LLH-l that is absolutely correct and hashcat default is: |
|
@ZerBea 0_(1266).cap 0_(1751).cap They should be BE type or LE type |
|
I'll check it. |
|
I pushed and update. Please test. |
Only need In the hash mask identification is LE or BE type e.g,... use 0_(1751).cap is LE type 0_(2469).cap is LE type e.g |
|
For example, using hcxpcapngtool --all --nonce-error-corrections=1024 -o 0_(1266).cap 0_(2469).cap |
|
I'l check it, but this will take some time, because this is a real problem. |
If data packet cannot be confirmed to is LE or BE type If can in data packet confirmed it is LE type If can in data packet confirmed it is BE type NC default parameters by third-party tools themselves determined |
|
Problem at the moment is the detection of big NC values without a performance impact. |
|
Let me explain the problem: |
|
I think I have a solution: If ENDIANESS is detected: If MESSAGE PAIR is M2M3E3 remaining MESSAGE PAIRS, eg; Now you can filter the wanted MESSAGE PAIRs either by bash tools. e.g. get hash line(s) containing router ENDIANESS LE: or get hash line(s) EAPOL M2M3E3 or via hashcat directly: This is a solution without any performance impact. |
If I want know it belongs to LE or BE type |
|
bitmask: MESSAGE PAIR == 0x42 == 0b01000010 You can use galculator to calculate hex -> binary. |
|
Maybe I haven't mentioned this: |
Hmm...parameter is relatively large, goal is convert all message pairs I test hashcat NC |
|
hashcat default NC is +- 8 on BE and +-8 on LE In other words, NC is a mechanism to handle poor quality dump files, but goal should be (in every case) to record high quality dump files. A poor quality dump file always(!) requires manual analysis. No automatic, no matter how good, can restore lost packets. |
|
Thanks for reporting this. |
|
If a file packet is confirmed BE type, It should be like this |
|
That is not feasible. hcxdumptool calculate the MASSAGEPAIRs in chronological order At the time we got an M2 (05:06:50.080382000) we got only one M1. The MP is 80 Also it is not feasible on hcxdumtool attacks in the case when hcxdumptool spoof the AP MAC, but use a different NONCE. Please notice, we are talking about a mechanism to handle crappy dump files. |
|
BTW: |
|
If want thoroughly optimize NC When NC+8 and -8, it should skip different authentication NONCE Although this is ideal, but it difficult achieve |
|
There is only one way to minimize performance impact from NC: You have this choices:
Absolutely no tool can make this decision for you. That require AI. Adding AI to hcxpcapngtool or to hashcat is far beyond the scope. For example: |
|
BTW: If you convert the example mentioned above: BTW; |
Seems can add fields in the format
If want achieve new NC performance, it should like this Okay, it really complicated. we discussion should over now |
I've encountered the following hash for which hashcat and hcxpmktool seem to disagree on what the correct PSK is.
WPA*02*c344678f5dffe6b2adb6e2bfbcf9a3d5*5a59ef3d5a0d*00082286fbfb*6950686f6e65202d204b4f5a*96c4775604afb7eaa46c9d91404e756f44ac5ca383a6345aacf2474d81a9a095*0103007502010a000000000000000000014647b5667f88fce5260ec391153c1dc0055c83b5226a3ff0dd6a09bcdc2f191c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020000*a0Running hashcat on this hash result in hashcat returining
12345678as the PSK for it, whilehcxpmktool -l <hash> -p 12345678is returning MIC not confirmed with a status return code of 2.Is this a hashcat bug?
The text was updated successfully, but these errors were encountered: