Capture experim

[LLH-l]

I do a experim
Client in my 5-m range

When use hcxdumptool or hcxlabtool attack a AP ( After disconnecting from the AP ), the client does not reconnect to the AP, In this case, your cannot capture it !
We can use some of those attacks to force it to try connecting to AP behavior again ? or is through trapping ?

[ZerBea]

Do you use a BPF filter?
If yes, the BPF prevent that the CLIENT can connect to hcxdumptool. As a result, you will not get an M1M2ROGUE and 50% of the attack failed.
To avoid this it is mandatory to add the CLIENT_MAC and the BROADCAST_MAC to the BPF:
"wlan addr3 MAC_AP or wlan addr3 ffffffffffff or wlan addr1 MAC_CLIENT or wlan addr2 MAC_CLIENT"

A short notice for other readers:
hcxlabtool does not deauthenticate a CLIENT.
It transmit AUTHENTICATION requests, ASSOCIATION requests or DISASSOCIATION frames, but never ever DEAUTHENTICATION frames.

[LLH-l]

I'm back. After repeated and careful testing
Not enabled and enabled BPF test

1. The client has saved the AP PSK
2. After attacking AP, the client disconnected and did not reconnect again ( seems the AP not respond hcxdump)
3. Capture unconnected client m12 failed(seems client not responding hcxdump)
   I think this is related to the hcxdumptool attack and it state is unstable .( as can be seen from the different results each time )
   It should have nothing to do with BPF

sudo tcpdump -i wlan0  wlan addr3  c43306xxxxxx  -ddd  > attack.bpf
sudo tcpdump -i wlan0  wlan addr3  c43306xxxxxx  or wlan addr3  ffffffffffff  -ddd  > attack.bpf
sudo tcpdump -s 1024 -y IEEE802_11_RADIO  wlan addr3  c43306xxxxxx   -ddd > attack.bpf
sudo tcpdump -s 1024 -y IEEE802_11_RADIO  wlan addr3  c43306xxxxxx  or wlan addr3  ffffffffffff  -ddd > attack.bpf
sudo tcpdump -s 1024 -y IEEE802_11_RADIO  wlan addr1  D0EE07123456  or  wlan addr2  D0EE07123456 or wlan addr3  c43306xxxxxx  or wlan addr3 ffffffffffff  -ddd  > attack.bpf
sudo tcpdump -s 1024 -y IEEE802_11_RADIO  wlan addr3  c43306xxxxxx   or wlan addr3  ffffffffffff or wlan addr1  D0EE07123456  or  wlan addr2  D0EE07123456   -ddd > attack.bpf

Use command

sudo hcxdumptool -c 44b --exitoneapol=4
sudo hcxdumptool -c 44b --exitoneapol=4  --attemptclientmax=100
sudo hcxdumptool -c 44b --exitoneapol=4   --attemptclientmax=100  --attemptapmax=100

sudo hcxdumptool  -c 44b --bpf=attack.bpf  --exitoneapol=4
sudo hcxdumptool  -c 44b --bpf=attack.bpf  --exitoneapol=4   --attemptclientmax=100
sudo hcxdumptool  -c 44b --bpf=attack.bpf  --exitoneapol=4   --attemptclientmax=100  --attemptapmax=100

[LLH-l]

I think we should not waste time on use BPF format

I observed them attack behavior, hcxdumptool use DEAUTH, hcxlabtool use disassociate

hcxdumptool initial attempt DEAUTH frames is valid (Client disconnects AP connection)
hcxlabtool initial attempt disassociate frames is valid (Client disconnects AP connection)

But when the client disconnects fromthe AP connection, if client not have reconnection behavior,
hcxdumptool and hcxlabtool again sending association request frame seems no effect (Client not have reconnection behavior)

We should focus on the issue of associated requests frame (hcxdumptool and hcxlabtool associated requests frame)

[ZerBea]

1. When you have Wi-Fi turned on, your device automatically connects to nearby Wi-Fi networks you've connected to before.
2. You can also set your device to automatically turn on/off Wi-Fi near saved networks.
3. And you can disable that your device automatically connects to nearby Wi-Fi networks.

In case of 2 and 3 there is no chance to get an M2 from the CLIENT.

hcxlabtool has three attack modes:

1. get PMKID
2. get M1M2M3 if a CLIENT is connected
3. get M2 if AP is not in RANGE or CLIENT is not connected

As long as we don't get an M1 or a PMKID hcxlabtool transmits

AUTHENTICATIONREQUESTs followed by ASSOCIATIONREQUESTs if AKM is PSK, we have an ESSID and if no CLIENT is active
ASSOCIATIONREQUESTs if AKM is PSK, if we have an ESSID and if a CLIENT is active
DISASSOCIATION frames if a CLIENT is connect, the AKM is PSK, if we have an ESSID and if MFP is disabled

There are five options to control this:

--m2max=<digit>           : set maximum of received M1M2ROGUE
                             default: 4 M1M2ROGUE
                             to reject CLIENTs set 0
--associationmax=<digit>  : set maximum of attempts to associate with an AP
                             default: 100 attempts
                             to disable association with an AP set 0
--disable_disassociation  : do not transmit DISASSOCIATION frames
--proberesponsetx=<digit> : transmit n PROBERESPONSEs from the ESSID ring buffer
                             default: 1023
--essidlist=<file>        : initialize ESSID list with these ESSIDs

In case of 2 and/or 3, this options do not work: "m2max, proberesponsetx and essidlist"
because the CLIENT neither transmit PROBES nor tries to connect.

This option (--disable_disassociation) should be used to go stealth, because this attack can be detected by an intrusion detection system.

This option (associationmax) should be used if targets are at the limit of range (increase value). If they are close, decrease value.

To make sure we get a PMKID, it is mandatory to run all attack modes.

I have several test targets (APs and CLIENTs) and all of the showing a different behavior:

some APs deauthenticate a CLIENT
some APs disassociate a CLIENT
some CLIENTs deauthenticate from the AP
some CLIENTs disassociate from the AP
some CLIENTs reconnect to the AP
some CLIENTs do not reconnect to the AP
some users manually reconnect to the AP

We can't handle all this by automatic and it doesn't make sense to evaluate incoming DEUTHENTICATION/DISASSOCIATION frames and their reason codes. Instead we stop the attack after xx attempts.

the difference between hcxdumptool and hcxlabtool:
hcxdumplool deauthenticate a CLIENT
hcxlabtool disassociate a CLIENT

But finally the AP or the CLIENT decide - not hcxlabtool/hcxdumptool.

Also you should notice that some CLIENTs deauthenticate and go to sleep for awhile, before they awake and authenticate/associate again.

 Flags: 0x11
    .... ..01 = DS status: Frame from STA to DS via an AP (To DS: 1 From DS: 0) (0x1)
    .... .0.. = More Fragments: This is the last fragment
    .... 0... = Retry: Frame is not being retransmitted
    ...1 .... = PWR MGT: STA will go to sleep
    ..0. .... = More Data: No data buffered
    .0.. .... = Protected flag: Data is not protected
    0... .... = +HTC/Order flag: Not strictly ordered

Flags: 0x01
    .... ..01 = DS status: Frame from STA to DS via an AP (To DS: 1 From DS: 0) (0x1)
    .... .0.. = More Fragments: This is the last fragment
    .... 0... = Retry: Frame is not being retransmitted
    ...0 .... = PWR MGT: STA will stay up
    ..0. .... = More Data: No data buffered
    .0.. .... = Protected flag: Data is not protected
    0... .... = +HTC/Order flag: Not strictly ordered

[ZerBea]

Whats happens if you manually connect to the AP.
Does the device connect to the AP or to hcxlabtool, or to both?

[LLH-l]

If manually connected to AP, can captured in an instant
I think they should all give a try

[LLH-l]

When hcxlabtool start, it should prompt the use wireless card and regulatory domain
It very important, check the wireless card channel situation
and should add Active scan and Passive scan

scan=a
scan=p

interface information:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  1   4 ffffffffffff ffffffffffff * wlan0    rt2800usb (NETLINK)

scan frequencies: frequency [channel] of Regulatory Domain: 00

[ZerBea]

All hcxtools/hcxdumptool/hcxlabtool are controlled by command line options and all all values can be passed running scripts.
Useful information is shown straight after start:

hardware mac
virtual mac
interface name
driver
available frequencies
regulatory domain
scan frequencies

A dialog with the user is not planed, but it can be added in an easy way using simple bash commands.
If you need a dialog, you can code a simple script and pass the options collected by the script to hcxdumptool.
https://stackoverflow.com/questions/18544359/how-do-i-read-user-input-into-a-variable-in-bash

A simple GUI (ncurses) is supported, too.
https://linuxconfig.org/how-to-use-ncurses-widgets-in-shell-scripts-on-linux

The ncurses data sheet is here:
https://blog.codingblocks.com/2017/build-interactive-applications-in-terminal-a-handy-ncurses-cheatsheet/

Here is an example how to use a simple script that request interface name and scan mode
and pass this information to hcxdumptool:

#!/bin/bash

printf "\navailable interfaces\n"
iw dev | awk '$1=="Interface"{print $2}'
printf "\nchoose interface: "
read INTERFACE

printf "\nchoose scan mode (active/passive): "
read SCANMODE

sudo hcxdumptool -i "$INTERFACE" --rcascan="$SCANMODE"

copy the content to a file e.g. named example and make it executable.

$ ./example
available interfaces
wlp22s0f0u4
wlp48s0f4u2u4

choose interface: wlp22s0f0u4

choose scan mode (active/passive): active

Requesting physical interface capabilities. This may take some time.
Please be patient...

interface information:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  2   5 74da38cc46ab 74da38cc46ab * wlp22s0f0u4      mt7601u (NETLINK)

available frequencies: frequency [channel] tx-power of Regulatory Domain: DE

  2412 [  1] 20.0 dBm	  2417 [  2] 20.0 dBm	  2422 [  3] 20.0 dBm	  2427 [  4] 20.0 dBm
  2432 [  5] 20.0 dBm	  2437 [  6] 20.0 dBm	  2442 [  7] 20.0 dBm	  2447 [  8] 20.0 dBm
  2452 [  9] 20.0 dBm	  2457 [ 10] 20.0 dBm	  2462 [ 11] 20.0 dBm	  2467 [ 12] 20.0 dBm
  2472 [ 13] 20.0 dBm


scan frequencies: frequency [channel] of Regulatory Domain: DE

  2412 [  1]	  2437 [  6]	  2462 [ 11]

As show above, there is absolutely no need to add this functions (which can be done via bash) to hcxdumptool.
The only thing you need is to code a few scripts tailor-made for your needs.

[LLH-l]

![205343]
![3-04 205305]

hcxdumptool  --rds=1 --rcascan=p
hcxdumptool  --rds=1 --rcascan=a

hcxdump cannot scan to this two hidden signal

./hcxlabtool -c 1a --bpf=a.bpf --rds=3
./hcxlabtool -c 1a

When using hcxlabtool and hcxdump capturing it , not display this two hidden target signal

Test kernel 
uname -r
kernel 6.6.4 and kernel 6.6.9

[ZerBea]

First of all: airodump-ng is not the reference (it shows only limited and filtered information).

If you want to perform an analysis (e.g. as reference) of the WiFi traffic I strongly recommend to use a network protocol analyzer like tshark or Wirshark and in case of a simple raw dump dumpcap.

Please take a look at the signal strength, displayed by airodump-ng. It is "-1" (the rate is "-1", too).

Now please read the description of airodump-ng here:
https://www.aircrack-ng.org/doku.php?id=airodump-ng
" If PWR is -1 for some access points, it means the access point is out of range".

(PWR == -1) && (rate == -1) -> there is no signal!

BTW:
hcxdumptool shows BEACONs with hidden or zeroed ESSIDs.
Running an active scan or in attack mode (if a CLIENT is connected) it tries to get the real ESSID of the AP.

[LLH-l]

Okay, end the topic ,thanks

[ZerBea]

The workflow is always the same:

run hcxdumptool or hcxlabtool
run tshark or Wireshark in parallel on the same interface (and the same BPF as hcxdumptool/hcxlabtool)
compare the dump files
reference the dump files

BTW:
That is not limited to hcxdumptool/hcxlabtool

run airodump-ng and/or aireplay-ng
run tshark or Wireshark in parallel on the same interface
compare the dump files
reference the dump files

[LLH-l]

In based linux i386 capture pmkid fail
e. g kali-linux-2024.1-live-i386

[ZerBea]

Thanks for that information. I'm sure KALI i386 users are interested in knowing this.
It is not easy to configure and customize KALI Linux. But this is imperative because otherwise it won't work as expected.

BTW:
Recommended distributions are Arch Linux and OpenWRT.
If you install one of them, you learn Linux from scratch and you exactly know what services are running and how they are configured.
That is definitely not the case if you install a distribution by GUI installer using its default configuration.

It is theoretically possible to compile hcxdumptool for other systems (e.g. Android) and other distributions (e.g. KALI) and other operating systems (BSD) as well, but there is no support and feature requests will be rejected README.md.

[LLH-l]

Okay, I don't use i386,it nothing do with me report completed now can end the topic

[ZerBea]

There are hundreds of Linux distributions. Each of this distributions is using its own kernel configuration, own default configuration and own drivers (in case of KALI).
I don't want to install them all to make sure that hcxdumptool is working as expected.
And I don't want to give advices how to compile/install hcxdumptool on this distributions.
Someone who installs KALI should know what they are doing.

[LLH-l]

No right we all speculations is incorrect, It should have nothing to do with the system

Again try test it ..
Use yesterday success captured it device
Today, again using the same device try capturing PMKID, test failed
Including use same wireless card system and command