Hi winxp5421.
No, automatically it is not possible (an automatic often fails). The only way to prevent this behavior is "manual intervention". By using the corresponding switches for your operation area and scenario, wlandump-ng does what you want.
Use wlanresponse in fast moving operations.
To have a quick reaction time the capture/authentication engine is client oriented (all other cracking tools are accesspoint oriented). In a worst case scenario, you can have at least 3 different mac_ap for one real network:
If we received a beacon 'Land Of sweets', both tools use this mac_ap.
If the client transmits undirected probes, both tools generates a ranom mac_ap on 'Land Of sweets'
If the client transmits directed probes, both tools use this mac_ap on 'Land Of sweets'
So it is possible that you have every loop leave a different constellation of mac_ap - mac_sta - ESSID.
If a client asks for an M1 key, both tools must answer immediately without checking older entries in a buffer.
ap <- client: associationrequest
ap -> client: acknowledge (client knows that the ap received his packets and needs some time to calculate the answer)
(at this point, we must be faster than than the ap and answer in the gap between ap ack and ap M1)
ap -> client: M1
(at this point, we have the last chance to answer)
ap <- client: acknowledge (ap knows that the client received his packets and needs some time to calculate the answer)
ap <- client: M2
ap -> client: acknowledge (client knows that the ap received his packets and needs some time to calculate the answer)
ap -> client: M3
ap <- client: acknowledge (ap knows that the client received his packets and needs some time to calculate the answer)
ap <- client: M4
For us (wd) it is not neccessary to receive the ap!!!
ap <- client: associationrequest
wd -> client: acknowledge (client knows that the ap received his packets and needs some time to calculate the answer)
wd -> client: M1
wd <- client: acknowledge (ap knows that the client received his packets and needs some time to calculate the answer)
wd <- client: M2
ap <- client: acknowledge (ap knows that the client received his packets and needs some time to calculate the answer)
ap <- client: M4
In this case we have a 100% valid, authenticated and verified 4-way handshake exchange!
If you read the status display you'll see that captured handshakes are not a direct result of deauthentications/disassociations (if you use high values in -d and -D). The stupid clients follows us to establish a connection (an ugly weakpoint in the implementation of the 802.11 protocol on the clients).
And for us, ..... well, it's much faster to answer them everytime they asks, than to check if we allready answered them.
Some words about the noise: In this case, neither a client, nor an ap is able to detect us.
We are only detectable if we transmit to much deauthentications/disassociations!
Keep in mind: hcxtools are designed to provide only one function each tool
- wlandump-ng/wlanresponse -> capture traffic
- wlancapinfo and wlanhcxinfo -> analysis
- wlancap2hcx -> convert to hccapx
- wlanhcx2ssid -> select what you want for output
they are also designed to retrieve mass data for analyse purpose (we found some real sad weakpoints in 802.11)
Conclusion:
To reduce noise, you must set the corresponding option (use less deauthentications/disassociations options -d -D, set option -r to reset the deauthentication-/disassociation counter, use option -F Berkeley Packet Filter).
To identify the handshake you want to crack, you must analyse either the cap file or the hccapx file (or filter by cascading wlanhcx2ssid).
Then you can strip the handshakes you want to crack.
Cheers
Mike
No, automatically it is not possible (an automatic often fails). The only way to prevent this behavior is "manual intervention". By using the corresponding switches for your operation area and scenario, wlandump-ng does what you want.
Use wlanresponse in fast moving operations.
To have a quick reaction time the capture/authentication engine is client oriented (all other cracking tools are accesspoint oriented). In a worst case scenario, you can have at least 3 different mac_ap for one real network:
If we received a beacon 'Land Of sweets', both tools use this mac_ap.
If the client transmits undirected probes, both tools generates a ranom mac_ap on 'Land Of sweets'
If the client transmits directed probes, both tools use this mac_ap on 'Land Of sweets'
So it is possible that you have every loop leave a different constellation of mac_ap - mac_sta - ESSID.
If a client asks for an M1 key, both tools must answer immediately without checking older entries in a buffer.
ap <- client: associationrequest
ap -> client: acknowledge (client knows that the ap received his packets and needs some time to calculate the answer)
(at this point, we must be faster than than the ap and answer in the gap between ap ack and ap M1)
ap -> client: M1
(at this point, we have the last chance to answer)
ap <- client: acknowledge (ap knows that the client received his packets and needs some time to calculate the answer)
ap <- client: M2
ap -> client: acknowledge (client knows that the ap received his packets and needs some time to calculate the answer)
ap -> client: M3
ap <- client: acknowledge (ap knows that the client received his packets and needs some time to calculate the answer)
ap <- client: M4
For us (wd) it is not neccessary to receive the ap!!!
ap <- client: associationrequest
wd -> client: acknowledge (client knows that the ap received his packets and needs some time to calculate the answer)
wd -> client: M1
wd <- client: acknowledge (ap knows that the client received his packets and needs some time to calculate the answer)
wd <- client: M2
ap <- client: acknowledge (ap knows that the client received his packets and needs some time to calculate the answer)
ap <- client: M4
In this case we have a 100% valid, authenticated and verified 4-way handshake exchange!
If you read the status display you'll see that captured handshakes are not a direct result of deauthentications/disassociations (if you use high values in -d and -D). The stupid clients follows us to establish a connection (an ugly weakpoint in the implementation of the 802.11 protocol on the clients).
And for us, ..... well, it's much faster to answer them everytime they asks, than to check if we allready answered them.
Some words about the noise: In this case, neither a client, nor an ap is able to detect us.
We are only detectable if we transmit to much deauthentications/disassociations!
Keep in mind: hcxtools are designed to provide only one function each tool
- wlandump-ng/wlanresponse -> capture traffic
- wlancapinfo and wlanhcxinfo -> analysis
- wlancap2hcx -> convert to hccapx
- wlanhcx2ssid -> select what you want for output
they are also designed to retrieve mass data for analyse purpose (we found some real sad weakpoints in 802.11)
Conclusion:
To reduce noise, you must set the corresponding option (use less deauthentications/disassociations options -d -D, set option -r to reset the deauthentication-/disassociation counter, use option -F Berkeley Packet Filter).
To identify the handshake you want to crack, you must analyse either the cap file or the hccapx file (or filter by cascading wlanhcx2ssid).
Then you can strip the handshakes you want to crack.
Cheers
Mike