I removed the option mac_ap to set a default MAC_AP instead of a randomized one, because it was counterproductive.
It doesn't work if the CLIENT transmit directed PROBEREQUESTs.
It can cause ESSID mismatches if another ESSID using the same MAC is on air.
".. it responds to EVERY client authentication from EVERY AP, not just the ones setup by hcxdumptool itself."
That always happens if the CLIENT set a WILDCARD ESSID or a zeroed ESSID in his PROBEREQUESTs. In that case we must respond to the AUTHENTICATION REQUEST and the ASSOCIATIONREQUEST of the CLIENT the get the ESSID and some other information). And if we respond, not only the ESSID.
BTW:
hcxdumptool doing the same as a modern CLIENT (use WILDCARD ESSID and MAC randomization), when attacking an AP:
Using WILDCARD or zeroed ESSIDs and MAC randomization is a very effective way (used by default on modern devices) to prevent tracking. Unfortunately it also prevent to filter an unwanted CLIENT.
Authentication procedure:
Step 1
BC <- CLIENT : undirected PROBEREQUEST (ESSID not mandatory) BC_MAC = ffffffffffff
or
AP <- CLIENT : directed PROBEREQUEST (ESSID not mandatory)
AP -> CLIENT : PROBEREPSONSE (ESSID not mandatory - information about all possible AKM and CYPHER suites)
Step 2
AP <- CLIENT : AUTHENTICATION (no ESSID - request AUTHENTICATION system))
AP -> CLIENT : AUTHENTICATION (no ESSID - set AUTHENTICATION system)
Step 3
AP <- CLIENT : ASSOCIATIONREQUEST (ESSID mandatory, request AKM and CYPHER suite)
Step 4
AP -> CLIENT : ASSOCIATIONRESPONSE (no ESSID, set AKM and CYPHER suite that will be used )
AP -> CLIENT : M1 (challenge - unencrypted WPA information) must be transmitted immediately after the ASSOCIATIONRESPONSE
AP <- CLIENT : M2 (challenge - unencrypted WPA information)
Step 5
AP -> CLIENT : M3 (authorization - encrypted WPA information)
AP <- CLIENT : M4 (authorization - usually zeroed SNONCE)
In every case hcxdumptool must do step 1, step 2 and step 3 to get an accurate information on ESSID and AKM and CYPHER suite.
It will not do step 4, if the CLIENT MAC is in the filter list (option filterlist_client & --filtermode=2). Unfortunately, this kind of filtering only works if the CLIENT doesn't randomize its MAC.
It will not do step 5 (because we do not have the correct PSK).
Please note:
To avoid that the CLIENT spam a channel by his requests, we must respond to stop that behavior!
At the moment, I (and many companies that provide tracking tools) found no way to identify and protect a MAC randomized CLIENT.
https://www.techrepublic.com/article/how...ndroid-10/
BTW:
stop_client_m2_attacks= 2 and the user doesn't notice that the device transmit the M2 to hcxdumptool
It doesn't work if the CLIENT transmit directed PROBEREQUESTs.
It can cause ESSID mismatches if another ESSID using the same MAC is on air.
".. it responds to EVERY client authentication from EVERY AP, not just the ones setup by hcxdumptool itself."
That always happens if the CLIENT set a WILDCARD ESSID or a zeroed ESSID in his PROBEREQUESTs. In that case we must respond to the AUTHENTICATION REQUEST and the ASSOCIATIONREQUEST of the CLIENT the get the ESSID and some other information). And if we respond, not only the ESSID.
BTW:
hcxdumptool doing the same as a modern CLIENT (use WILDCARD ESSID and MAC randomization), when attacking an AP:
Code:
ACCESS POINT (ROGUE)......: 10b71301efb2 (BROADCAST WILDCARD used for the attack)Using WILDCARD or zeroed ESSIDs and MAC randomization is a very effective way (used by default on modern devices) to prevent tracking. Unfortunately it also prevent to filter an unwanted CLIENT.
Authentication procedure:
Step 1
BC <- CLIENT : undirected PROBEREQUEST (ESSID not mandatory) BC_MAC = ffffffffffff
or
AP <- CLIENT : directed PROBEREQUEST (ESSID not mandatory)
AP -> CLIENT : PROBEREPSONSE (ESSID not mandatory - information about all possible AKM and CYPHER suites)
Step 2
AP <- CLIENT : AUTHENTICATION (no ESSID - request AUTHENTICATION system))
AP -> CLIENT : AUTHENTICATION (no ESSID - set AUTHENTICATION system)
Step 3
AP <- CLIENT : ASSOCIATIONREQUEST (ESSID mandatory, request AKM and CYPHER suite)
Step 4
AP -> CLIENT : ASSOCIATIONRESPONSE (no ESSID, set AKM and CYPHER suite that will be used )
AP -> CLIENT : M1 (challenge - unencrypted WPA information) must be transmitted immediately after the ASSOCIATIONRESPONSE
AP <- CLIENT : M2 (challenge - unencrypted WPA information)
Step 5
AP -> CLIENT : M3 (authorization - encrypted WPA information)
AP <- CLIENT : M4 (authorization - usually zeroed SNONCE)
In every case hcxdumptool must do step 1, step 2 and step 3 to get an accurate information on ESSID and AKM and CYPHER suite.
It will not do step 4, if the CLIENT MAC is in the filter list (option filterlist_client & --filtermode=2). Unfortunately, this kind of filtering only works if the CLIENT doesn't randomize its MAC.
It will not do step 5 (because we do not have the correct PSK).
Please note:
To avoid that the CLIENT spam a channel by his requests, we must respond to stop that behavior!
At the moment, I (and many companies that provide tracking tools) found no way to identify and protect a MAC randomized CLIENT.
https://www.techrepublic.com/article/how...ndroid-10/
BTW:
stop_client_m2_attacks= 2 and the user doesn't notice that the device transmit the M2 to hcxdumptool