Yes, you are right.
The BPF is a nice and fast kernel feature to filter out unwanted packets. You can combine everything (MAC_AP, MAC_CLIENT, rx branch, tx branch). The best way to use BPFC is to protect APs and CLIENTs.
Example to protect AP and CLIENT in tx branch and rx branch:
001122334455 == AP
aabbccddeeff == CLIENT
run hcxdumptool -m to set monitor interface for tcpdump (tcmpdump need this to now how to generate BPFC)
create filtercode as follows:
Notice:
You will loose PSKs transmitted in plain, if you use attack filters due to MAC randomization of most of the CLIENTs. The PSK transmitted with MAC x used by the CLIENT will not match to the authentication with MAC z used by the CLIENT
Due to your attack filter z, x is filtered out!!!!
I dropped BPF support in old wlandump-ng, because it was very limited. But now BPFC is restricted to 65535 code blocks. That should be more than enough for every purpose. A good reason to re-add this feature.
-> But I am extracting the MACS for EAPOL and PMKID separately, so I don't think that shouldn't be an issue right?
that could be a problem if you feed hashcat with either EAPOL or PMKID
we can have two (or more - depend on count of the CLIENTs) valid but different PSKs for a combination of MAC and ESSID, if the essid is a common ESSID like "default", "home", "Home", ....
- one PSK belongs to the AP
- one PSK belongs to the CLIENT A
- one PSK belongs to the CLIENT B
- one PSK belongs to the CLIENT C
...
The PSKs will only match if the CLIENT belongs to the AP
This does not necessarily have to be the case.
The BPF is a nice and fast kernel feature to filter out unwanted packets. You can combine everything (MAC_AP, MAC_CLIENT, rx branch, tx branch). The best way to use BPFC is to protect APs and CLIENTs.
Example to protect AP and CLIENT in tx branch and rx branch:
001122334455 == AP
aabbccddeeff == CLIENT
run hcxdumptool -m to set monitor interface for tcpdump (tcmpdump need this to now how to generate BPFC)
create filtercode as follows:
Code:
$ tcpdump -i <interface> not wlan addr1 00:11:22:33:44:55 and not wlan addr2 00:11:22:33:44:55 and not wlan addr1 aa:bb:cc:dd:ee and not wlan addr2 aa:bb:cc:dd:ee -ddd > protect.bpf
Notice:
You will loose PSKs transmitted in plain, if you use attack filters due to MAC randomization of most of the CLIENTs. The PSK transmitted with MAC x used by the CLIENT will not match to the authentication with MAC z used by the CLIENT
Due to your attack filter z, x is filtered out!!!!
I dropped BPF support in old wlandump-ng, because it was very limited. But now BPFC is restricted to 65535 code blocks. That should be more than enough for every purpose. A good reason to re-add this feature.
-> But I am extracting the MACS for EAPOL and PMKID separately, so I don't think that shouldn't be an issue right?
that could be a problem if you feed hashcat with either EAPOL or PMKID
we can have two (or more - depend on count of the CLIENTs) valid but different PSKs for a combination of MAC and ESSID, if the essid is a common ESSID like "default", "home", "Home", ....
- one PSK belongs to the AP
- one PSK belongs to the CLIENT A
- one PSK belongs to the CLIENT B
- one PSK belongs to the CLIENT C
...
The PSKs will only match if the CLIENT belongs to the AP
This does not necessarily have to be the case.