Not send disassociate frames capture fali

[LLH-l]

Not send disassociate frames, hcxdump capture fali I repeatedly tested it, If want quickly capture it ,need send disassociate frames, but hcxdump no !

sudo tcpdump -s 1024 -y IEEE802_11_RADIO wlan addr3 APMAC or wlan addr3 ffffffffffff -ddd > attack.bpf or hcxdumptool --bpfc="wlan addr3 APMAC or wlan addr3 ffffffffffff" >attack.bpf or sudo tcpdump -i wlan0 wlan addr3 APMAC or wlan addr3 ffffffffffff -ddd >attack.bpf It shouldn't anything to do with the filter hcxdumptool -c 1a --bpf=attack.bpf or hcxdumptool -c 1a

wlan.fc.type_subtype == 0x0c ||wlan.fc.type_subtype == 0x0a

[ZerBea]

With one exception, there is no need to transmit DISASSOCIATION frames. Instead hcxdumptool transmit a combination of DAUTHENTICATION, ASSOCIATION and REASSOCIATION frames. You can monitor this running tsahrk in parallel on the same interface:

$ tshark -i wlp48s0f4u2u1 subtype reassoc-req or subtype assoc-req or subtype deauth
Capturing on 'wlp48s0f4u2u1'
    1 07:45:43,811550578 cc:ce:1e:dc:3b:ee → ff:ff:ff:ff:ff:ff 802.11 36  Deauthentication, SN=1, FN=0, Flags=........
    2 07:45:43,811588939 ff:ff:ff:ff:ff:ff → cc:ce:1e:dc:3b:ee 802.11 98  Association Request, SN=1, FN=0, Flags=........, SSID="AP_7272"
    3 07:45:43,811645295 cc:ce:1e:dc:3b:ee → ff:ff:ff:ff:ff:ff 802.11 37  Deauthentication, SN=1, FN=0, Flags=........
    4 07:45:43,811646847 ff:ff:ff:ff:ff:ff → cc:ce:1e:dc:3b:ee 802.11 99  Association Request, SN=1, FN=0, Flags=........, SSID="AP_7272"
    5 07:45:43,813733441 ff:ff:ff:ff:ff:ff → cc:ce:1e:dc:3b:ee 802.11 104  Reassociation Request, SN=1, FN=0, Flags=........, SSID="AP_7272"

This method is working like a charm, hcxdumptool successfully attacked the test target in 0m6,510s while running tshark in parallel:

$ time hcxdumptool -c 8a --exitoneapol=7 -bpf=attack.bpf
...
211 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
1 SHB written to pcapng dumpfile
1 IDB written to pcapng dumpfile
1 ECB written to pcapng dumpfile
20 EPB written to pcapng dumpfile

exit on EAPOL M1M2

real    0m6,510s
user    0m0,002s
sys 0m0,006s

The exception: If hcxdumptool got an EAPOL M2 from the CLIENT addressed to hcxdumptool (M1M2ROGUE) it disassociate the CLIENT from hcxdumptool to allow that it can reconnect to its AP.

[ZerBea]

BTW: Your filter prevent that a CLIENT can connect to hcxdumptool. You will never get an EAPOL M1M2ROGUE!

[LLH-l]

I been test and observing this AP for a long time, and what you said about hcxdump, all combination attack no valid on it. use Disassociate attack is valid (e.g wifi_laboratory) I try using mdk4, and captured it on 5s, why

[ZerBea]

I can't reproduce that. All my test targets are attacked successfully.

mdk4 doesn't use a BPF and I guess your capture tools does also not use a BPF. Please run hcxdumptool without BPF. Instead set it to the operation channel of the AP. $ sudo hcxdumptool -c xx try the same with hcxlabtool $ sudo hcxlabtool -c xx --rds=2

Do you get an M2 from the to the AP connected CLIENT?

[LLH-l]

Do you get an M2 from the to the AP connected CLIENT?

No, I run hcxdump for a long time of 10 minutes not get M2 I think your should pay attention to using Disassociate frames to get faster and more valid attack

[ZerBea]

Ok, let's find out what is different:

Run your attack with mdk4 and your capture tool in terminal 1 for 5 seconds. Monitor the traffic with tshark on the same interface in terminal 2. $ tshark -r INTERFACE -w mdk4.pcapng

zip and attach mdk4.pcapng dump file

[ZerBea]

Have you tried hcxlabtool? The attack engine has been modified.

It transmit DISASSOCIATION frames:

$ time ./hcxlabtool -c 8a --exitoneapol=7 --bpf=attack.bpf
starting...

269 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
exit on EAPOL M1M2

real    0m6,964s
user    0m0,000s
sys 0m0,007s

$ tshark -i wlp48s0f4u2u1 subtype disassoc
Capturing on 'wlp48s0f4u2u1'
    1 08:41:07,441173538 cc:ce:1e:dc:3b:ee → ff:ff:ff:ff:ff:ff 802.11 38  Disassociate, SN=1, FN=0, Flags=........
    2 08:41:07,441213633 cc:ce:1e:dc:3b:ee → ff:ff:ff:ff:ff:ff 802.11 37  Disassociate, SN=1, FN=0, Flags=........

BTW: hcxlabtool is the successor of hcxdumptool. In favor of hcxlabtool, hcxdumptool does not receive new feature any longer.

[LLH-l]

Have you tried hcxlabtool? The attack engine has been modified. It transmit DISASSOCIATION frames:

Sorry matter has been delayed hcxlabtool OK, get m1m2 mdk4.attack.zip

[ZerBea]

Thanks. A lot of traffic on the channel and massive packet loss. No ASSOCIATION frames inside. No REASSOCIATION frames inside.

I recommend to use hcxlabtool, because hcxdumptool will not receive improvements any longer.

There are two points on my todo list which prevent a release of hcxdumptool 7.0.0 and hcxtools 7.0.0:

hcxlabtool -> add rcascan
hcxpcapngtool -> support offline GPS evaluation

When that's done, I relase 7.0.0 with all the new features.

[ZerBea]

Closed, because feature has been added to hcxdumptool next generation (current hcxlabtool).