-
Notifications
You must be signed in to change notification settings - Fork 392
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
About using - o some questions #320
Comments
@ZerBea |
There is another question
|
I suppose we're talking about the automatic mode of hcxdumptool Criteria that a MESSAGEPAIR will be converted in this mode is the time gap between two EAPOL MESSAGES.
The lowest time gap is 3577000. This MESSAGEPAIR will be converted in automatic mode:
If you don't accept this behavior it is mandatory to run hcxdumptool with option --all and filter authorized MESSAGEPAIRs by hcxhashtool:
I will not change the automatic mode, because: About m1m2m4: Just to mention that:
|
Summary:
Definitely not in automatic mode because that need an additional stage that will slow down the entire conversion process.
Not for analysis purpose (e.g. get a password history, typos by user, weak points by system, detect an attack where the attacker types several passwords to get access to the NETWORK).
This problem is solved by hcxpcapngtool/hcxhastool combination. Problem is your workflow. |
Yes we are discussing automatic mode
e.g_3 If Packets 89261 and 89264 conversion were selected based on time priority because ignored the more reliable m1m2m4 triple metadata package 186360-->186363-->186368 What I mean is, before preparing to convert m1m2E2, within the specified time interval, to detect whether there is still m3 or m4 message present.. If m3 or m4 exists, priority should be given, |
We can't use that M4, because its SNONCE is zeroed. If you got a warning by hcxpcapngtool you should use --all, because the source is crappy. |
|
An example on a crappy dump file with heavy packet loss.
Which MESSAGEPAIR is more reliable and should be converted by the automatic? |
Of course, choosing data packets with continuous m1m2m4 messages is more reliable
|
Test environment: TEST ACCESS POINT (WPA2 easy PSK) TEST DUMP device (passive dumper) close to the border of the AP TRANSMIT range (so that we have a packet loss). Now make up your own mind:
When hashcat finished, check which EAPOL MIC was taken to recover the PSK (compare MIC of hashcat out file with dump of tshark). |
Can be seen that 12345678 is not correct password M1m2m4 is likely authorized password
|
For sure, 12345678 is the correct password, because I added this to the configuration of the TEST AP. The example dump file is really crappy and hcxpcapngtool throws several warnings. At least we have three(!) authentication sequences:
second third
Due to missing frames (packet loss) there is only one authentication sequence (first) from which we can calculate a valid MESSAGE PAIR. If you use --all option you'll notice that hashcat got the PSK (12345678) only from the first MESSAGEPAIR. Now the lesson learned: Due to REUSE of PBKDF2, the speed impact is low.
versus
You may have noticed hashcat failed to recover the MESSGAEPAIR of the third AUTHENTICATION sequence due to missing frames. I'll say that it is not a good idea to run hcxpcapngtool, hcxhashtool or hashcat with default options on crapy dump files. |
Maybe I haven't explained it in detail yet. I'm not going to customize this tools to make them work on:
And I don't add functions (in favor of other tools) that slow hcxdumtool/hcxtools down. If you don't follow the recommendations you'll run into serious problems. |
Ok, Not be discussed temporarily |
I mistakenly thought that is clear. Everything that is not inside the dump file (e.g. missing frames) is gone for ever(!) and absolutely nothing can bring it back. The most important parts of such a penetration testing system (not the CPU, not the GPU):
In this case (and only in this case) you can expect good results, even on a small GPU, e,g, like mine:
The philosophy should always be: |
A good example for this is here: |
Adding more or less complex code to the conversion tool will only fight the symptoms (and make the entire process slow). |
@ZerBea Hello
Some questions about using hcxpcapngtool - o
e,g_1
5095.zip
When m1m3 NONCE same
m1m2E2 equivalent m2m3E2
So, Should convert m2m3E2
Not convert m1m2E2
But it mistakenly chose to convert m1m2E2
In this case, it is impossible restore the authorized password !
e.g_2
2907.zip
When m1m3 NONCE is different
Priority should be given to selecting conversion authorization m2m3E2
If the m1m2E2 situation is converted, it will waste GPU time
Ultimately, will result in failure recover the correct password
The text was updated successfully, but these errors were encountered: