You are confusing options regarding attacks against APs and attacks against CLIENTs.
Please also notice that the ESSID list is not(!) a filter list.
We're doing filtering by MACs only using two different kinds of soft coded filter lists: MAC AP filtering and MAC CLIENT filtering.
As an alternative, you can use BPF code to filter whatever you want.
Filtering by ESSID is too slow, because many frames do not contain an ESSID. Doing this we need an additional list holding all(!) received MACs and the assigned ESSID (MAC_AP: MAC_CLIENT:ESSID). Due to MAC randomization this list will grow up very fast and it will take a long time to find the matching combination. We have to do this search on every(!) received frame! As a result, our response is too slow and the target disregard us.
"As far as I understand these two examples are not WILDCARD requests. It seems to me that they are targeted towards a particular ESSID (<ESSID_NOTINLIST> and <OTHERESSID_NOTINLIST>), so I don't understand why hcxdumptool is "creating" these fake APs from all probe requests in the area and responding to obtain the M1M2 challenge when I only want it to create and respond to the ones I specified in the essidlist."
Correct, this are not wildcard requests, but they are addressed to a bradcast MAC: fffffffffff
We can't use a broadcast MAC to respond and have to create a new MAC on every new ESSID. If we don't to this, we end up in an ESSID/MAC mismatch (same MAC on different ESSIDs).
This example
MAC_AP 112233445566 : ESSID "home"
MAC_AP 112233445566 : ESSID "my_network"
MAC_AP 112233445566 : ESSID "Obi WLAN Kenobi"
will end up in that mismatch and we are not able to calculate a PTK.
Please remember the 2 formulas (PTK and PMK). As a result of this mismatch, hashcat will fail to find the PSK..
To prevent that, we're doing this on broadcast requests (undirekted PROBEREQUEST):
HCX_MAC_000da7864fc5 : ESSID "home"
HCX_MAC_000da7864fc6 : ESSID "my_network"
HCX_MAC_000da7864fc7 : ESSID "Obi WLAN Kenobi""
You haven't set a target (CLIENT) filter list and hcxdumptool guess that you want to attack everything. If you don't want that behavior, set filterlist_client and filter mode 2:
You can choose 256 CLIENT targets:
By the way, hcxdumptool does not seem to be hosting the ESSIDs properly, because when I click join on my phone and input a random password it returns "Couldn't join the network" instead of "Password incorrect".
This is the default response code of hcxdumptool. We tell the CLIENT that he can't join our NETWORK and it should look for another NETWORK (usually his assigned NETWORK or the next entry in its wpa_supplicant.conf).
We are doing this, because we want to request an M2 of every entry of the CLIENTs wpa_supplicant.conf and not only for the first entry.
https://www.codegrepper.com/code-example...nf+example
BTW:
I know, that this stuff (zeored ESSID, wildcard ESSID, broadcast MAC, randomized MAC, PMK depending on ESSID and PSK, PTK depending on PMK and MACs and NONCEs, MIC depending on PTK, hashcat recovering the PSK depending on PMK and MIC, REPLAY COUNT, EAPOL TIMERs, time response behavior and the relationship/dependencies between all this conditions) is really hard core and it is very difficult to understand.
But hcxdumptool must take care about all of this dependencies and it must respond to a request just in time. Otherwise the target disregard/ignore it.
To ensure that (and I'm counting CPU cycles), hcxdumptool will respond to everything by default and store the packets to pcapng file. That is much faster than doing several filter options on the fly (except BPF code, because this is done inside kernel space, before the packet reach hcxdumptool).
Please notice:
It takes several CPU cycles until the packet find its way from the antenna through the device (firmware) and through the driver (kernel) until it reached hcxdumptool.
Once it reached the user space, hcxdumptool must handle the radiotap header and detect the kind of the frame before it decide how to respond to it and to create a response packet). All this have a price tag, counted in CPU cycles. If the response packet is created, it has to go the way back (driver -> device firmware -> antenna). All this must happen before the packet response timeout is reached.
Once we did it, hcxpcapngtool and hcxhashtool will have all the time needed to offline filter by MAC, ESSID, MESSAGE PAIR, PMKID, EAPOL, VENDOR, or whatever).
All converted and filtered hashes are valid and hashcat is able to recover the PSK.
Please also notice that the ESSID list is not(!) a filter list.
We're doing filtering by MACs only using two different kinds of soft coded filter lists: MAC AP filtering and MAC CLIENT filtering.
As an alternative, you can use BPF code to filter whatever you want.
Filtering by ESSID is too slow, because many frames do not contain an ESSID. Doing this we need an additional list holding all(!) received MACs and the assigned ESSID (MAC_AP: MAC_CLIENT:ESSID). Due to MAC randomization this list will grow up very fast and it will take a long time to find the matching combination. We have to do this search on every(!) received frame! As a result, our response is too slow and the target disregard us.
"As far as I understand these two examples are not WILDCARD requests. It seems to me that they are targeted towards a particular ESSID (<ESSID_NOTINLIST> and <OTHERESSID_NOTINLIST>), so I don't understand why hcxdumptool is "creating" these fake APs from all probe requests in the area and responding to obtain the M1M2 challenge when I only want it to create and respond to the ones I specified in the essidlist."
Correct, this are not wildcard requests, but they are addressed to a bradcast MAC: fffffffffff
We can't use a broadcast MAC to respond and have to create a new MAC on every new ESSID. If we don't to this, we end up in an ESSID/MAC mismatch (same MAC on different ESSIDs).
This example
MAC_AP 112233445566 : ESSID "home"
MAC_AP 112233445566 : ESSID "my_network"
MAC_AP 112233445566 : ESSID "Obi WLAN Kenobi"
will end up in that mismatch and we are not able to calculate a PTK.
Please remember the 2 formulas (PTK and PMK). As a result of this mismatch, hashcat will fail to find the PSK..
To prevent that, we're doing this on broadcast requests (undirekted PROBEREQUEST):
HCX_MAC_000da7864fc5 : ESSID "home"
HCX_MAC_000da7864fc6 : ESSID "my_network"
HCX_MAC_000da7864fc7 : ESSID "Obi WLAN Kenobi""
You haven't set a target (CLIENT) filter list and hcxdumptool guess that you want to attack everything. If you don't want that behavior, set filterlist_client and filter mode 2:
Code:
--filterlist_client=<file or MAC> : CLIENT MAC or MAC filter list
format: 112233445566, 11:22:33:44:55:66, 11-22-33-44-55-66 # comment
maximum entries 256
due to MAC randomization of the CLIENT, it does not always work!Code:
$ sudo hcxdumptool -i INTERFACE -c 1 --disable_ap_attacks --disable_deauthentication --essidlist=essidlist.txt --active_beacon --stop_client_m2_attacks=1000 --filterlist_client=attackmacclients.txt --filtermode=2 -o dump.pcapng --enable_status=31By the way, hcxdumptool does not seem to be hosting the ESSIDs properly, because when I click join on my phone and input a random password it returns "Couldn't join the network" instead of "Password incorrect".
This is the default response code of hcxdumptool. We tell the CLIENT that he can't join our NETWORK and it should look for another NETWORK (usually his assigned NETWORK or the next entry in its wpa_supplicant.conf).
We are doing this, because we want to request an M2 of every entry of the CLIENTs wpa_supplicant.conf and not only for the first entry.
https://www.codegrepper.com/code-example...nf+example
BTW:
I know, that this stuff (zeored ESSID, wildcard ESSID, broadcast MAC, randomized MAC, PMK depending on ESSID and PSK, PTK depending on PMK and MACs and NONCEs, MIC depending on PTK, hashcat recovering the PSK depending on PMK and MIC, REPLAY COUNT, EAPOL TIMERs, time response behavior and the relationship/dependencies between all this conditions) is really hard core and it is very difficult to understand.
But hcxdumptool must take care about all of this dependencies and it must respond to a request just in time. Otherwise the target disregard/ignore it.
To ensure that (and I'm counting CPU cycles), hcxdumptool will respond to everything by default and store the packets to pcapng file. That is much faster than doing several filter options on the fly (except BPF code, because this is done inside kernel space, before the packet reach hcxdumptool).
Please notice:
It takes several CPU cycles until the packet find its way from the antenna through the device (firmware) and through the driver (kernel) until it reached hcxdumptool.
Once it reached the user space, hcxdumptool must handle the radiotap header and detect the kind of the frame before it decide how to respond to it and to create a response packet). All this have a price tag, counted in CPU cycles. If the response packet is created, it has to go the way back (driver -> device firmware -> antenna). All this must happen before the packet response timeout is reached.
Once we did it, hcxpcapngtool and hcxhashtool will have all the time needed to offline filter by MAC, ESSID, MESSAGE PAIR, PMKID, EAPOL, VENDOR, or whatever).
All converted and filtered hashes are valid and hashcat is able to recover the PSK.