Again, I fully agree and it is nice that this tools are used by experienced penetration testers. But also I'm not happy that this tools are used by "script kiddies", e.g. (my definition):
He/she installed K A L I for the first time - but doesn't know anything about Linux.
He/she use a high power WiFi adapter (ALFA, AWUS xxx) - and think more power is the best.
He/she running hcxdumptool/hcxtools or other WiFi related tools (disregarding README.md and help) - and wonder why the results are not as expected.
Very often (unfortunately) the same criteria also apply to a beginner:
That is a dangerous combination and lead to many (unnecessary) issue reports, e.g. missing dependencies. For me, it looks like nobody is reading README.md (it is explained there).
Maybe I'm a little biased, not neutral, blinded by routine and suspect script kiddies everywhere.....
but in any case I expect that the one who wants to know something has read the instructions (README.md and --help) before!
Some words about injecting (stupid) DEAUTHENTICATION packets (possible done by a high power WiFi adapter. I analyzed a lot of dump files (mostly from wpa-sec) to improve hcxdumptool/hcxtools and mostly I saw something like this (which is a good example of what I mentioned above about "script kiddies"):
Transmission of 37245 deauthentication packets
DEAUTHENTICATION (total).................: 37245
during a period of one hour and 20 minutes
timestamp minimum (GMT)..................: 02.06.2022 20:43:52
timestamp maximum (GMT)..................: 02.06.2022 22:03:24
to get a single handshake
EAPOL pairs (best).......................: 1
the entire WiFi channel 9
BEACON on 2.4 GHz channel (from IE_TAG)..: 9
(and some neighbor channels) was jammed by DEAUTHENTICATION packets (especially if a high power adapter was used to inject packets).
WiFi channels are overlapped. Channel 9 is 22 MHz width so the transmission interferes with channel 7, 8, 10 and 11.
https://en.wikipedia.org/wiki/List_of_WLAN_channels
This is not an isolated case. More than 90% of the submitted dump files looking like the one mentioned above:
And this is just the tip of the iceberg.
I don't know which tools are used to attack the target and to dump the traffic, because of a limited dump file format that doesn't include this information. But running hcxdumptool/hcxtools in a right way (using the right options) this behavior could be completely prevented. Please compare the status printed above to status of the the dump file (taken by hcxdumptool) from here:
https://hashcat.net/forum/thread-10805-p...l#pid55471
and you'll see what I mean.
From my point of view, hcxdumptool option "--disable-deauthentication" has a specific right to exist.
By the last comment I didn't mean you. To make that clear (and that it is not emotional) I edited the comment:
Last but not least (to mention it again):
If someone is a beginner or if he/she doesn't know what he/she is doing, it is not a good idea to run hcxdumptool/hcxtools, because hcxdumptool is an area weapon. Running it unconfigured it is acting like a jammer (similar to mdk3/mdk4).
Please take I look at the issue reports:
https://github.com/ZerBea/hcxdumptool/is...s%3Aclosed
https://github.com/ZerBea/hcxtools/issue...s%3Aclosed
and you'll notice that I answer every question and add every feature request (if it make sense). And the same applies to this thread, to the questions asked here and to your questions.
If you take a closer look at the latest commits:
https://github.com/ZerBea/hcxdumptool/co...758a7fde61
https://github.com/ZerBea/hcxdumptool/co...5ad0b61343
https://github.com/ZerBea/hcxdumptool/co...fb4b9cfb22
you'll notice that I have taken up your suggestions.
Especially this one:
https://github.com/ZerBea/hcxdumptool/co...218d42d236
I agree that hcxdumptool should not try to attack everything if a user try to run hcxdumptool only with interface option "-i". That is fixed, now:
Please feel free to ask your questions and to share your ideas how to improve the tools.
BTW:
An example of a working environment:
Raspberry Pi Zero:
https://www.reichelt.de/de/en/raspberry-...ol_1&nbc=1
WiFi adapter:
https://www.reichelt.de/de/en/allnet-wir...GE=EN&&r=1
you'll see the hardware modification (LED and push button) and a power bank:
https://github.com/ZerBea/hcxdumptool/wi...g-system-1
operating system:
Arch Linux (new RPI >= v2) or Raspbian lite (old RPI v1).
command Line:
And the entire system is exactly doing what you want.
May I ask a question:
Which distribution do you use?
Which WiFi adapter do you use?
Luckily hcxdumptool will give you more than one solution to attack your target. Here are four examples using filter options (the results are similar):
If you know your target you can use --bpfc to attack it exactly (bpfc as attack filter).
If you do not know your target (e.g. if the MAC is randomized) but you know all other devices in your neighborhood you can use --bpfc to protect them (bpfc as protect filter).
That is working in transmission and in reception branch.
or you can use filter mode in combination with a filter list
In mode 1 device entries are protected
In mode 2 device entries are attacked
That is working in transmission branch, only. The reception branch remain untouched and every received packet that matches the options (e.g. ipv4, IPv6, EAPOL, WEP, WPA, ...) will stored to the dump file.
I don't know which attack vector is preferred by the user, so I leave hcxdumptool unconfigured by default and let the user decide which option is the best one (with minimal impairment of the neighborhood) for his purpose.
Wireless Networks: The Definitive Guide is an older book, but it is good to learn 802.11 basics.
More information about 802.11 is here:
https://mrncciew.com/
e.g. why are PROBERESPONSE frames more important than BEACON frames:
https://mrncciew.com/2014/10/27/cwap-802...tresponse/
or why it is a good idea to store an (RE)ASSOCIATIONREQUEST frame instead of a single BEACON frame only:
https://mrncciew.com/2014/10/28/802-11-m...qresponse/
https://github.com/kismetwireless/kismet/issues/419
He/she installed K A L I for the first time - but doesn't know anything about Linux.
He/she use a high power WiFi adapter (ALFA, AWUS xxx) - and think more power is the best.
He/she running hcxdumptool/hcxtools or other WiFi related tools (disregarding README.md and help) - and wonder why the results are not as expected.
Very often (unfortunately) the same criteria also apply to a beginner:
Code:
K A L I & ALFA AWUS xxx high power adapter & WiFi attack toolMaybe I'm a little biased, not neutral, blinded by routine and suspect script kiddies everywhere.....
but in any case I expect that the one who wants to know something has read the instructions (README.md and --help) before!
Some words about injecting (stupid) DEAUTHENTICATION packets (possible done by a high power WiFi adapter. I analyzed a lot of dump files (mostly from wpa-sec) to improve hcxdumptool/hcxtools and mostly I saw something like this (which is a good example of what I mentioned above about "script kiddies"):
Code:
$ hcxpcapngtool *.* -o test.22000
hcxpcapngtool 6.2.7-5-gd66ebbf reading from dump.cap...
summary capture file
--------------------
file name.................................: dump.cap
version (pcap/cap).......................: 2.4 (very basic format without any additional information)
timestamp minimum (GMT)..................: 02.06.2022 20:43:52
timestamp maximum (GMT)..................: 02.06.2022 22:03:24
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11 (105) very basic format without any additional information about the quality
endianess (capture system)...............: little endian
packets inside...........................: 75192
ESSID (total unique).....................: 1
BEACON (total)...........................: 1
BEACON on 2.4 GHz channel (from IE_TAG)..: 9
ACTION (total)...........................: 253
PROBERESPONSE (total)....................: 538
DEAUTHENTICATION (total).................: 37245
DISASSOCIATION (total)...................: 10
AUTHENTICATION (total)...................: 40
AUTHENTICATION (OPEN SYSTEM).............: 40
ASSOCIATIONREQUEST (total)...............: 5
ASSOCIATIONREQUEST (PSK).................: 5
WPA encrypted............................: 15472
EAPOL messages (total)...................: 150
EAPOL RSN messages.......................: 150
EAPOLTIME gap (measured maximum usec)....: 25072
EAPOL ANONCE error corrections (NC)......: working
REPLAYCOUNT gap (recommended NC).........: 8
EAPOL M1 messages (total)................: 116
EAPOL M2 messages (total)................: 1
EAPOL M3 messages (total)................: 32
EAPOL M4 messages (total)................: 1
EAPOL pairs (total)......................: 3
EAPOL pairs (best).......................: 1
EAPOL pairs written to 22000 hash file....: 1 (RC checked)
EAPOL M32E2 (authorized).................: 1
PMKID (useless)..........................: 116
frequency statistics from radiotap header (frequency: received packets)
-----------------------------------------------------------------------
not available due to missing radiotap header
Warning: out of sequence timestamps!
This dump file contains frames with out of sequence timestamps.
That is a bug of the capturing tool.
Warning: excessive number of deauthentication/disassociation frames detected!
That can cause that an ACCESS POINT change channel, reset EAPOL TIMER,
renew ANONCE and set PMKID to zero.
This could prevent to calculate a valid EAPOL MESSAGE PAIR
or to get a valid PMKID.
Information: limited dump file format detected!
This file format is a very basic format to save captured network data.
It is recommended to use PCAP Next Generation dump file format (or pcapng for short) instead.
The PCAP Next Generation dump file format is an attempt to overcome the limitations
of the currently widely used (but limited) libpcap (cap, pcap) format.
https://www.wireshark.org/docs/wsug_html_chunked/AppFiles.html#ChAppFilesCaptureFilesSection
https://github.com/pcapng/pcapng
Information: radiotap header is missing!
Radiotap is a de facto standard for 802.11 frame injection and reception.
The radiotap header format is a mechanism to supply additional information about frames,
from the driver to userspace applications.
https://www.radiotap.org/
Information: missing frames!
This dump file does not contain undirected proberequest frames.
An undirected proberequest may contain information about the PSK.
It always happens if the capture file was cleaned or
it could happen if filter options are used during capturing.
That makes it hard to recover the PSK.Transmission of 37245 deauthentication packets
DEAUTHENTICATION (total).................: 37245
during a period of one hour and 20 minutes
timestamp minimum (GMT)..................: 02.06.2022 20:43:52
timestamp maximum (GMT)..................: 02.06.2022 22:03:24
to get a single handshake
EAPOL pairs (best).......................: 1
the entire WiFi channel 9
BEACON on 2.4 GHz channel (from IE_TAG)..: 9
(and some neighbor channels) was jammed by DEAUTHENTICATION packets (especially if a high power adapter was used to inject packets).
WiFi channels are overlapped. Channel 9 is 22 MHz width so the transmission interferes with channel 7, 8, 10 and 11.
https://en.wikipedia.org/wiki/List_of_WLAN_channels
This is not an isolated case. More than 90% of the submitted dump files looking like the one mentioned above:
Code:
timestamp minimum (GMT)..................: 29.05.2022 21:40:58
timestamp maximum (GMT)..................: 29.05.2022 23:37:04
DEAUTHENTICATION (total).................: 202240
EAPOL pairs (best).......................: 1
or
timestamp minimum (GMT)..................: 02.06.2022 18:33:21
timestamp maximum (GMT)..................: 02.06.2022 19:51:43
DEAUTHENTICATION (total).................: 143508
EAPOL pairs (best).......................: 3
or
timestamp minimum (GMT)..................: 02.06.2022 18:55:09
timestamp maximum (GMT)..................: 02.06.2022 20:08:06
DEAUTHENTICATION (total).................: 98732
EAPOL pairs (best).......................: 2I don't know which tools are used to attack the target and to dump the traffic, because of a limited dump file format that doesn't include this information. But running hcxdumptool/hcxtools in a right way (using the right options) this behavior could be completely prevented. Please compare the status printed above to status of the the dump file (taken by hcxdumptool) from here:
https://hashcat.net/forum/thread-10805-p...l#pid55471
and you'll see what I mean.
From my point of view, hcxdumptool option "--disable-deauthentication" has a specific right to exist.
By the last comment I didn't mean you. To make that clear (and that it is not emotional) I edited the comment:
Last but not least (to mention it again):
If someone is a beginner or if he/she doesn't know what he/she is doing, it is not a good idea to run hcxdumptool/hcxtools, because hcxdumptool is an area weapon. Running it unconfigured it is acting like a jammer (similar to mdk3/mdk4).
Please take I look at the issue reports:
https://github.com/ZerBea/hcxdumptool/is...s%3Aclosed
https://github.com/ZerBea/hcxtools/issue...s%3Aclosed
and you'll notice that I answer every question and add every feature request (if it make sense). And the same applies to this thread, to the questions asked here and to your questions.
If you take a closer look at the latest commits:
https://github.com/ZerBea/hcxdumptool/co...758a7fde61
https://github.com/ZerBea/hcxdumptool/co...5ad0b61343
https://github.com/ZerBea/hcxdumptool/co...fb4b9cfb22
you'll notice that I have taken up your suggestions.
Especially this one:
https://github.com/ZerBea/hcxdumptool/co...218d42d236
I agree that hcxdumptool should not try to attack everything if a user try to run hcxdumptool only with interface option "-i". That is fixed, now:
Code:
$ hcxdumptool -i wlp39s0f3u1u1u1
not enough options selected for an attack vector
run hcxdumptool --help to get more informationPlease feel free to ask your questions and to share your ideas how to improve the tools.
BTW:
An example of a working environment:
Raspberry Pi Zero:
https://www.reichelt.de/de/en/raspberry-...ol_1&nbc=1
WiFi adapter:
https://www.reichelt.de/de/en/allnet-wir...GE=EN&&r=1
you'll see the hardware modification (LED and push button) and a power bank:
https://github.com/ZerBea/hcxdumptool/wi...g-system-1
operating system:
Arch Linux (new RPI >= v2) or Raspbian lite (old RPI v1).
command Line:
Code:
$ sudo hcxdumptool -i wlp39s0f3u1u1u2 -c 11 -o test.pcapng --enable_status=15 --bpfc=target.bpfc --active_beaconMay I ask a question:
Which distribution do you use?
Which WiFi adapter do you use?
Luckily hcxdumptool will give you more than one solution to attack your target. Here are four examples using filter options (the results are similar):
If you know your target you can use --bpfc to attack it exactly (bpfc as attack filter).
If you do not know your target (e.g. if the MAC is randomized) but you know all other devices in your neighborhood you can use --bpfc to protect them (bpfc as protect filter).
That is working in transmission and in reception branch.
or you can use filter mode in combination with a filter list
In mode 1 device entries are protected
In mode 2 device entries are attacked
That is working in transmission branch, only. The reception branch remain untouched and every received packet that matches the options (e.g. ipv4, IPv6, EAPOL, WEP, WPA, ...) will stored to the dump file.
I don't know which attack vector is preferred by the user, so I leave hcxdumptool unconfigured by default and let the user decide which option is the best one (with minimal impairment of the neighborhood) for his purpose.
Wireless Networks: The Definitive Guide is an older book, but it is good to learn 802.11 basics.
More information about 802.11 is here:
https://mrncciew.com/
e.g. why are PROBERESPONSE frames more important than BEACON frames:
https://mrncciew.com/2014/10/27/cwap-802...tresponse/
or why it is a good idea to store an (RE)ASSOCIATIONREQUEST frame instead of a single BEACON frame only:
https://mrncciew.com/2014/10/28/802-11-m...qresponse/
https://github.com/kismetwireless/kismet/issues/419