--filterlist_ap does not filter

[dizcza]

Hi, I experience an issue with limiting capturing (and what is more important, sending deauth and flooding the network) to only one particular AP.

I saved 1 AP mac that I got from --do_racscan into a file like this

$ cat ap-mac
112233445566

Of course, I put a different mac address. I tried with a breaking line at the end and without. The AP is on channel 1. Then I run your tool like this

sudo hcxdumptool -i wlx983f9f511fd0 --filterlist_ap=ap-mac -c1  -o capture.pcapng

and it immediately shows me

FILTERLIST ACCESS POINT...: 1 entries
FILTERLIST CLIENT.........: 0 entries
FILTERMODE................: unused

But it seems that the tool ignores the --filterlist_ap option because it captures the packets from other APs that are not specified in the ap-mac file list. I take the info by running hcxhashtool --info=stdout followed by hcxpcapngtool.

I've run --check_driver and --check_injection tests with success.

Am I doing something wrong?

[ZerBea]

You have forgotten the (mandatory) filter mode: FILTERMODE................: unused

From the help menu:

-filterlist_ap=<file>             : ACCESS POINT MAC filter list
                                     format: 112233445566, 11:22:33:44:55:66, 11-22-33-44-55-66 # comment
                                     maximum entries 256
                                     run first --do_rcascan to retrieve information about the target
--filterlist_client=<file>         : CLIENT 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!
--filtermode=<digit>               : mode for filter list
                                     mandatory in combination with --filterlist_ap and/or --filterlist_client
                                     0: ignore filter list (default)
                                     1: use filter list as protection list
                                        do not interact with ACCESS POINTs and CLIENTs from this list
                                     2: use filter list as target list
                                        only interact with ACCESS POINTs and CLIENTs from this list
                                        not recommended, because some useful frames could be filtered out

so you have to add --filtermode=2

Please notice: Filterlist and filtermode are working in the transmit branch. In every case hcxdumptool is working as a passive dumper and will capture the whole traffic. We must do that, due to MAC randomization of the CLIENTs.

If you don't want this behavior, you must use the Berkeley Packet Filter:

--bpfc=<file>                      : input Berkeley Packet Filter (BPF) code
                                     steps to create a BPF (it only has to be done once):
                                      set hcxdumptool monitormode
                                       $ hcxumptool -m <interface>
                                      create BPF to protect a MAC
                                       $ tcpdump -i <interface> not wlan addr1 11:22:33:44:55:66 and not wlan addr2 11:22:33:44:55:66 -ddd > protect.bpf
                                       recommended to protect own devices
                                      or create BPF to attack a MAC
                                       $ tcpdump -i <interface> wlan addr1 11:22:33:44:55:66 or wlan addr2 11:22:33:44:55:66 -ddd > attack.bpf
                                       not recommended, because important pre-authentication frames will be lost due to MAC randomization of the CLIENTs
                                      use the BPF code
                                       $ hcxumptool -i <interface> --bpfc=attack.bpf ...

Please notice: In case of running BPFC as attack filter, you will loose frames from CLIENTs, running MAC randomization.

[dizcza]

Dear me! You're right, I overlooked that. The bpfc mode is something new to me, but I found your post with the description links, I'll take a look shortly.

Thank you.

[ZerBea]

The BPF is very powerful and extreme fast, because it is running inside the kernel space. The packets are filtered out, before they reach hcxdumptool. That means that running BPFC is more strict, than running filterlist in combination with filtermode. I use BPFC to protect own CLIENTs and own APs. Packets from them and to them are filtered completely.

[dizcza]

I'm probably doing something wrong, but I keep beeing disconnected even though I added MAC into protect.bpf like so:

$ hcxdumptool -m wlan0
$ tcpdump -i wlan0 not wlan addr1 <AP-MAC> and not wlan addr2 <sta1> and not wlan addr3 <sta2> and not wlan addr4 <sta3>  -ddd > protect.bpf
$ hcxdumptool -i wlan0 --bpfc=protect.bpf

initialization...
interface is already in monitor mode

start capturing (stop with ctrl+c)
NMEA 0183 SENTENCE........: N/A
INTERFACE NAME............: wlan0
DRIVER....................: rt2800usb
DRIVER VERSION............: 4.15.0-106-generic
DRIVER FIRMWARE VERSION...: 0.36
ERRORMAX..................: 100 errors
BPF code blocks...........: 40
FILTERLIST ACCESS POINT...: 0 entries
FILTERLIST CLIENT.........: 0 entries
FILTERMODE................: unused
WEAK CANDIDATE............: 12345678
ESSID list................: 0 entries
EAPOLTIMEOUT..............: 20000 usec
REPLAYCOUNT...............: 63393

My sta3 (another device within the same WLAN, a laptop) keeps getting deauth.

[ZerBea]

The source of the filtercode is not correct. You mus add AP to wlan addr1 and wlan addr2. The same applies to the client. Example 1: we protect AP and 3 CLIENTs.

tcpdump -i <interface>
not wlan addr1 <AP> and not wlan addr2 <AP> and 
not wlan addr1 <sta1> and not wlan addr2 <sta1> and
not wlan addr1 <sta2> and not wlan addr2 <sta2> and
not wlan addr1 <sta3> and not wlan addr2 <sta3> -ddd > own.bpfc

Example 2: we protect 2 APs and 2 CLIENTs (regardless to which of the 2 APs they belong).

tcpdump -i <interface>
not wlan addr1 <AP1> and not wlan addr2 <AP1> and 
not wlan addr1 <AP2> and not wlan addr2 <AP2> and 
not wlan addr1 <sta1> and not wlan addr2 <sta1> and
not wlan addr1 <sta2> and not wlan addr2 <sta2> -ddd > own.bpfc

explanation: addr1 = to address addr2 = from address addr3 = additional address addr4 = additional address https://www.oreilly.com/library/view/80211-wireless-networks/0596100523/ch04.html http://80211notes.blogspot.com/2013/09/understanding-address-fields-in-80211.html

BTW: we don't attack addr3 (used in data frames) - you don't need it in your bpf code addr4 is used within mesh networks - you don't need it in your bpf code

Please notice: If the CLIENT run MAC randomization, hcxdumptool will respond (proberesponse) to his proberequests. We can't prevent that as long as the CLIENT doesn't use is origin MAC. If the CLIENT use is origin MAC (e.g. in the following authentication procedure), he is protected by the Berkeley Packet Filter.

[dizcza]

I see, I misunderstood the logic of addrX (I thought it's just enumeration). Now I got it. Thanks!

[ZerBea]

No problem, you're welcome. The BPF is very powerful. You can filter addresses as well as types of frames in a very fast way.

[ZerBea]

BTW: Your kernel (4.15.0-106-generic) is outdated. https://www.kernel.org/

[dizcza]

Agh, after 3 years I still run into the same problem.

So I have an external USB wifi adapter A1 (Alfa something) connected to my PC and I'd like to avoid getting disconnected while running hcxdumptool on an OrangePI 3 with another USB Alfa adapter A2 put into the unmanaged mode.

On my PC I ran

sudo tcpdump -i A1 not wlan addr1 <..> and not wlan addr2 <..> -ddd >> protect.bpf

and got

tcpdump: 'addr1' and 'address1' are only supported on 802.11 with 802.11 headers

Soon I realized that I need to switch the interface to the monitor mode (after I read the help of hcxdumptool carefully).

I was thinking of the --bpfc_from_22000 or similar flag to be added into your tool to automatically create protect rules from either .22000 or raw .pcapng files with AP and STA handshakes already captured. Since one handshake is enough for any AP to be processed with tools like hashcat, such an option will facilitate the use of BPFC rules creation. The interface to create the rules for is already passed as an argument to the hcxdumptool. So creating a protect rule list manually looks like extra work that can be avoided except for the first time (no handshakes are written and we want to monitor all APs).

Update 1.

The tcpdump command should be issued on the device from which the attacks are performed - on orange pi, in my case. It does not alter the meaning of the rest of the discussion.

[dizcza]

On second thought, such an option might be better suited as a separate command of your HCX tools ecosystem because it should be able to merge the results from parsing 22000/pcapng files with a previously saved BPF file.

[dizcza]

In either case, switching to the monitor mode and back can be made inside the tool transparently for the users.

[dizcza]

To give you an idea of what I'm currently doing on python:

rules = [f"not wlan addr1 {m} and not wlan addr2 {m}" for m in macs]
tcprules_gen_string = f"tcpdump -i white {' and '.join(rules)} -ddd > protect.bpf"

[ZerBea]

Please read this: https://en.wikipedia.org/wiki/Berkeley_Packet_Filter and this https://www.kernel.org/doc/html/latest/networking/filter.html

Than you understand that a BPF is (much) more than adding simple rules. A BPF is a form of instructions for a virtual machine, which are interpreted, or compiled into machine code by a just-in-time (JIT) mechanism and executed, in the kernel. Adding such a compiler to hcxdumptool is far beyond my scope. There are several (good) tools that provide this compiler, e.g. tcpdump which is easy to use for beginners. I prefer BPF tools: https://archlinux.org/packages/?q=bpf

BTW: A protect filter has to be written only once - or if you get a new device. The effort (to code a compiler) is far too great.

Your python solution is nice, but I don't want to hard code a tcpdump or a libpcap dependency to hcxdumptool. It is much better to let the user decide for himself which program he uses to generate the machine code.

hcxpcapngtool is a tool that get information from a dump file and to store this information to other files on which other tools (hcxhashtool, hashcat or JtR) can work on. Using a BPF on the dump file doesn't make sense, because the entire filtering is provided by hcxhashtool (which take care about the special requirements of hashcat and JtR). The workflow to filter hashes is: hcxdumptool -> hcxpcapngtool -> hcxhashtool (do the filtering) -> hashcat/JtR

BTW: Each tool has only one task (Linux philosophy): hcxdumptool -> attack hcxpcapngtool -> convert hcxhashtool -> filter

I don't want to bloat the code unnecessarily. You may have noticed that hcxdumptool is going back to the roots (since v 6.3.0).

[ZerBea]

An example that shows the complexity of generating BPF code. We want to allow bradcast frames by BPF:

Such a simple thing: wlan addr3 ff:ff:ff:ff:ff:ff

will become in assembly language:

(000) ldb      [3]
(001) lsh      #8
(002) tax      
(003) ldb      [2]
(004) or       x
(005) st       M[0]
(006) tax      
(007) ldb      [x + 0]
(008) and      #0xc
(009) jeq      #0x4             jt 15   jf 10
(010) ld       [x + 18]
(011) jeq      #0xffffffff      jt 12   jf 15
(012) ldh      [x + 16]
(013) jeq      #0xffff          jt 14   jf 15
(014) ret      #262144
(015) ret      #0

or c language:

{ 0x30, 0, 0, 0x00000003 },
{ 0x64, 0, 0, 0x00000008 },
{ 0x7, 0, 0, 0x00000000 },
{ 0x30, 0, 0, 0x00000002 },
{ 0x4c, 0, 0, 0x00000000 },
{ 0x2, 0, 0, 0x00000000 },
{ 0x7, 0, 0, 0x00000000 },
{ 0x50, 0, 0, 0x00000000 },
{ 0x54, 0, 0, 0x0000000c },
{ 0x15, 5, 0, 0x00000004 },
{ 0x40, 0, 0, 0x00000012 },
{ 0x15, 0, 3, 0xffffffff },
{ 0x48, 0, 0, 0x00000010 },
{ 0x15, 0, 1, 0x0000ffff },
{ 0x6, 0, 0, 0x00040000 },
{ 0x6, 0, 0, 0x00000000 },

and decimal count, accepted by hcxdumptool:

48 0 0 3
100 0 0 8
7 0 0 0
48 0 0 2
76 0 0 0
2 0 0 0
7 0 0 0
80 0 0 0
84 0 0 12
21 5 0 4
64 0 0 18
21 0 3 4294967295
72 0 0 16
21 0 1 65535
6 0 0 262144
6 0 0 0

As mentioned above, there are a lot of good tools that can do it much better than I could ever do.

[dizcza]

What I actually mean is not to rewrite tcpdump from scratch in C (which of course is not worth the trouble) but instead, just come up with a wrapper command that utilizes tcpdump internally given a list of MACs (or a list of .22000/pcapng to extract MACs from) - just like I showed with Python.

Since I have already come up with such Python code, I'll probably just use it as it serves the needs I'm trying to describe. It will still require me to parse MACs from 22000 but I can extend this simple Python program to do it as well.

I do understand why you refrain from adding it to your tool though. It was just an idea.

[ZerBea]

Please take a look at add3. On several cases it can be used instead of a combination of addr1 & addr2.

Also please take a look at tshark (e.g. to get MAC addresses from dump files). example from here: https://wiki.wireshark.org/uploads/__moin_import__/attachments/SampleCaptures/wpa-Induction.pcap

$ tshark -r wpa-Induction.pcap -T fields -e wlan.sa | sort | uniq

00:0c:41:82:b2:53
00:0c:41:82:b2:55
00:0d:1d:06:e0:f2
00:0d:93:82:36:3a
00:0f:66:16:94:73
4a:91:5a:a3:e4:0b

There are good tools (tshark which is 100% compatible to hcxdumptool, tcpdump, bpf-tools, scapy) to collect all information. A python script (like yours - which is a good idea) can be used to put them all together. Pearl, java, php scripts can do the same. I'll say that there is no need to reinvent the wheel again and to code "just another wrapper" to hcxtools.

BTW: The tcpdump example in --help is a very simple example. It is far away to cover the entire potential of a BPF. To cover sepcial cases, you may need a more complex BPF.

[ZerBea]

A BPF can be powerful and fast.

Mostly I use this an advanced BPF like this one:

$ sudo tcpdump -i wlp5s0f4u2 not type ctl subtype ack and not type ctl subtype rts and not type ctl subtype cts -d
(000) ldb      [3]
(001) lsh      #8
(002) tax      
(003) ldb      [2]
(004) or       x
(005) tax      
(006) ldb      [x + 0]
(007) and      #0xfc
(008) jeq      #0xd4            jt 13   jf 9
(009) ldb      [x + 0]
(010) and      #0xfc
(011) jeq      #0xb4            jt 13   jf 12
(012) jeq      #0xc4            jt 13   jf 14
(013) ret      #0
(014) ret      #262144

or in tcpdump high level syntax: not type ctl subtype ack and not type ctl subtype rts and not type ctl subtype cts

Purpose is to filer out unwanted control frames. That reduce CPU cycles of hcxdumtool.

The possibility to include this kind of filer code makes hcxdumptool very flexible - much more than a hard coded wrapper can ever do.

[dizcza]

not type ctl subtype ack and not type ctl subtype rts and not type ctl subtype cts Purpose is to filer out unwanted control frames. That reduce CPU cycles of hcxdumtool.

I hardly believe that anyone knows about it. Perhaps a cheat sheet of such BPF rules on your Wiki would not hurt.

[ZerBea]

As mentioned in README.md section requirements: * detailed knowledge of 802.11 protocol especially knowledge of MAC header and frame types, e.g.: https://witestlab.poly.edu/blog/802-11-wireless-lan-2/

and * detailed knowledge of filter procedures (Berkeley Packet Filter, capture filter, display filter) https://www.wireshark.org/docs/dfref/ and https://tshark.dev/capture/capture_filters/ and https://upskilld.com/learn/using-tcpdump-options-filters-and-examples/