It is not a good idea to remove origin timestamps!
It is not a good idea to use tools that remove timestamps!
It is not a good idea to use tools that replace the original timestamp by their own timestamp!
https://community.cisco.com/t5/wireless-...-p/3122477
https://ieeexplore.ieee.org/document/4251170
https://networkengineering.stackexchange...on-the-wlc
You can't rely on the replaycount alone. Disregarding the EAPOL time between EAPOL messages will lead to unrecoverable hashes, even if the replay count matches.
If you don't believe it. This is an exaggerated example:
Take a BEACON.
Take a M3 from the last year.
Take a M4 from this year.
zero the origin timestamps or replace them
merge this 3 packets to a capfile
and try to recover the PSK.
So, good luck!
Explanation:
For an authentication we have a time gap. The authentication is successful if all frames are transmitted within this gap.
Also we have time gaps between the request and answer or challenge and response.
If we are outside this gap, the NONCEs are renewed.
So, even if we have received EAPOL M2 replaycount (RC) 3 and EAPOL M3 RC 4 and the time gap is greater than the EAPOL timer, this message pair will not match! It is not possible to recover the PSKs from this message pair.
We distinguish several methods how an ACCESS POINT (AP) renew the values when the EAPOL timer has expired:
- leave RC increase ANONCE - great, nonce error corrections (NC) is working on it
- increase RC increase ANONCE - great, NC is working on it, too
- leave RC renew ANONCE - NC is not working.
- increase RC renew ANONCE - NC is not working.
NC is an amazing feature of hashcat - if you know about the "secrets" of EAPOL timers. Disregarding them will lead to unrecoverable PSKs and you will waste your GPU time.
Also do not transmit deauthentication or disassociation packets within an authentication sequence. That will cause the AP to destroy his EAPOL timer and to renew all NONCEs!
BTW:
hcxdumptool can do this, because it is able to request a new authentication sequence from an AP or to initiate a new authentication sequence for a CLIENT.
It is not a good idea to use tools that remove timestamps!
It is not a good idea to use tools that replace the original timestamp by their own timestamp!
https://community.cisco.com/t5/wireless-...-p/3122477
https://ieeexplore.ieee.org/document/4251170
https://networkengineering.stackexchange...on-the-wlc
You can't rely on the replaycount alone. Disregarding the EAPOL time between EAPOL messages will lead to unrecoverable hashes, even if the replay count matches.
If you don't believe it. This is an exaggerated example:
Take a BEACON.
Take a M3 from the last year.
Take a M4 from this year.
zero the origin timestamps or replace them
merge this 3 packets to a capfile
and try to recover the PSK.
So, good luck!
Explanation:
For an authentication we have a time gap. The authentication is successful if all frames are transmitted within this gap.
Also we have time gaps between the request and answer or challenge and response.
If we are outside this gap, the NONCEs are renewed.
So, even if we have received EAPOL M2 replaycount (RC) 3 and EAPOL M3 RC 4 and the time gap is greater than the EAPOL timer, this message pair will not match! It is not possible to recover the PSKs from this message pair.
We distinguish several methods how an ACCESS POINT (AP) renew the values when the EAPOL timer has expired:
- leave RC increase ANONCE - great, nonce error corrections (NC) is working on it
- increase RC increase ANONCE - great, NC is working on it, too
- leave RC renew ANONCE - NC is not working.
- increase RC renew ANONCE - NC is not working.
NC is an amazing feature of hashcat - if you know about the "secrets" of EAPOL timers. Disregarding them will lead to unrecoverable PSKs and you will waste your GPU time.
Also do not transmit deauthentication or disassociation packets within an authentication sequence. That will cause the AP to destroy his EAPOL timer and to renew all NONCEs!
BTW:
hcxdumptool can do this, because it is able to request a new authentication sequence from an AP or to initiate a new authentication sequence for a CLIENT.