OpenWRT: Big Endian support discussion

[dracode]

With the merge of #380 and #381, hcxdumptool will now run without fatal errors on my MIPS big Endian system, thanks!

I suspect that there are some non-fatal endianness issues still lurking, however. A quick, non-scientific test didn't net me any handshakes in an environment where I definitely expect them, and do get them when using other tools (airodump-ng and aireplay-ng). As most development and testing is probably being done on little endian systems, this seems like an easy place for bugs to creep in.

I'll do some more testing (side by side with BE and LE systems, etc). But any ideas on specific items to test, or areas of the code that may be more prone to endianness issues, would be useful.

[ZerBea]

Good to hear that it is compiling without fatal errors. Now let's hunt for the BE problems.
I don't have a BE system here to test and the target system is a Raspberry Pi.

Can you please attach a pcapng dumpfile recorded by hcxdumptool that include a complete AUTHENTICATION sequence and a pcapng CUSTOM BLOCK:
AUTHENTICATION request from CLIENT
AUTHENTICATION response from AP
ASSOCIATIONREQUEST
ASSOCIATIONRESPONSE
M1
M2
M3
M4

I'm sure, by adding a few debug printf we can find the BE problem quickly.

Thanks.

[ZerBea]

A quick, non-scientific test didn't net me any handshakes in an environment...
Have you analyzed the dump file by Wireshark?

[ZerBea]

Please also comment the output (BE system) of

$ hcxdumptool -v
$ hcxdumptool -L
$ hcxdumptool -I INTERFACENAME

I asked this, because hcxdumptool's requirements are many times higher than the requirements of aircrack-ng.

operating system: Linux (recommended: kernel >= 6.4, mandatory: kernel >= 5.10)
chipset must be able to run in monitor mode. Recommended: MediaTek chipsets (due to active monitor mode capabilities)
driver must (mandatory) support monitor and full frame injection mode
gcc >= 13 recommended (deprecated versions are not supported: https://gcc.gnu.org/)

and hcxdumptool's transmit radio tap headers (two different headers dependent of the attack):
https://github.com/ZerBea/hcxdumptool/blob/master/include/radiotap.h#L51
https://github.com/ZerBea/hcxdumptool/blob/master/include/radiotap.h#L59
are different to the one of aircrack-ng:
https://github.com/aircrack-ng/aircrack-ng/blob/master/lib/osdep/linux.c#L809

It is mandatory that the driver / interface support this.

Some more differences between hcxdumptool an aircrack-ng:
epoll vs select
nsec vs usec
pcapng vs cap

[dracode]

root@OpenWrt:~# hcxdumptool -v
hcxdumptool 6.3.2 (C) 2023 ZeroBeat
running on Linux kernel 5.15.137
compiled by gcc 12.3.0
compiled with Linux API headers 5.15.142
glibc (__GLIBC_MINOR__) is not defined
enabled REALTIME DISPLAY
enabled GPS support
disabled BPF compiler

root@OpenWrt:~# hcxdumptool -L

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

available wlan devices:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  0   4 8cfdf023214b 8cfdf02420eb + wlan0            ath10k_pci (NETLINK)
  1   5 9483c40ca215 f0a22507e54d * wlan1            ath9k (NETLINK)

* active monitor mode available (reported by driver - do not trust it)
+ monitor mode available (reported by driver)
- no monitor mode available

root@OpenWrt:~# hcxdumptool -I wlan1

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

interface information:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  1   5 9483xxxxxxxx f0a2xxxxxxxx * wlan1            ath9k (NETLINK)


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

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

You didn't ask for this one but I am providing it for comparison...

CH  8 ][ Elapsed: 1 min ][ 2023-12-12 06:20 ][ fixed channel wlan1: -1

 BSSID              PWR RXQ  Beacons    #Data, #/s  CH   MB   ENC CIPHER  AUTH ESSID

 9C:D2:1E:2D:04:C9  -31   0        0        0    0  -1   -1                    <length:  0>
 60:26:EF:06:77:40    0   0        0        0    0  -1   -1                    <length:  0>
 FC:7F:F1:2C:EC:A0   -5   0        0        0    0  -1   -1                    <length:  0>
 FC:7F:F1:2C:EE:20  -28   0        0        0    0  -1   -1                    <length:  0>
 FC:7F:F1:2C:ED:80    0   0        0        0    0  -1   -1                    <length:  0>
 FC:7F:F1:2C:EB:00  -17   0        0        0    0  -1   -1                    <length:  0>
 FC:7F:F1:2C:ED:60  -23   0        0        0    0  -1   -1                    <length:  0>
 60:26:EF:06:76:40  -21   0        0        0    0  -1   -1                    <length:  0>
 FC:7F:F1:2C:E0:20  -27   0        0        0    0  -1   -1                    <length:  0>
 B8:27:EB:B5:EB:30   -1 100      649        2    0   8  260   WPA2 CCMP   PSK  test

Same device, same interface, same channel. hcxdumptool does show my "test" AP eventually, but it shows with a blank SSID for a while, or sometimes a 'garbage' non-ASCII character, or sometimes the actual SSID.

root@OpenWrt:~# hcxdumptool -i wlan1 -c 8a
 CHA   LAST   R 1 3 P S    MAC-AP    ESSID (last seen on top)     SCAN-FREQUENCY:   2447
-----------------------------------------------------------------------------------------
   8 06:29:11           b8f853e04baa
   8 06:29:08           5856e8710d2f
   8 06:29:05           64e7d84e983e
   8 06:29:00           b827ebb5eb30 test
   8 06:28:47           b8f853e04ba9
   8 06:28:23           00403664f6b5

This one is from an x86 little endian computer sitting next to it, looks perfect:

┌──(root㉿kali)-[/home/kali/hcxdumptool]
└─# ./hcxdumptool -i wlan0 -c 8a
 CHA   LAST   R 1 3 P S    MAC-AP    ESSID (last seen on top)     SCAN-FREQUENCY:   2447
-----------------------------------------------------------------------------------------
   8 20:40:10 + +     + b827ebb5eb30 test

[dracode]

Another interesting comparison. I downgraded the device to an ancient version (OpenWrt 19.07.8, running hcxdumptool 6.0.1). Same hardware.

root@GL-E750:~# uname -a
Linux GL-E750 4.14.241 #0 Thu Jul 29 19:50:28 2021 mips GNU/Linux

root@GL-E750:~# hcxdumptool -v
hcxdumptool 6.0.1 (C) 2020 ZeroBeat

Demonstrating that the hardware is definitely capable:

root@GL-E750:~# hcxdumptool -i wlan1 -o test.pcap -c 8 --enable_status=127
initialization...
interface is already in monitor mode

start capturing (stop with ctrl+c)
NMEA 0183 SENTENCE......: N/A
INTERFACE NAME..........: wlan1
INTERFACE HARDWARE MAC..: 9483c40ca215
DRIVER..................: ath9k
DRIVER VERSION..........: 4.14.241
DRIVER FIRMWARE VERSION.: N/A
ERRORMAX................: 100 errors
FILTERLIST ACCESS POINT.: 0 entries
FILTERLIST CLIENT.......: 0 entries
FILTERMODE..............: 0
WEAK CANDIDATE..........: 12345678
PREDEFINED ACCESS POINT.: 0 entries
MAC ACCESS POINT........: 14070876d00b (incremented on every new client)
MAC CLIENT..............: c022507094e6
REPLAYCOUNT.............: 61915
ANONCE..................: 5d2c95848fe38c1ce54f6d75eb40406407f20971f4d075104d83dcf22b94049c
SNONCE..................: be9bd84a5dda5636d40e49976701b07a4999674c153f2fc20f86911df27f41d2

02:59:43   8 5228c21586e8 --> b827ebb5eb30 DIRECTED PROBE REQUEST (test)
02:59:43   8 5228c21586e8 <-> b827ebb5eb30 ASSOCIATION (test)
03:00:00   8 INFO ERROR:0 INCOMMING:1401 OUTGOING:542 PMKID:0 MP:0 GPS:0 RINGBUFFER:5
03:00:06   8 5228c21586e8 <-> b827ebb5eb30 MP:M1M2 RC:1 EAPOLTIME:71892 (test)
03:00:06   8 5228c21586e8 <-> b827ebb5eb30 MP:M2M3 RC:2 EAPOLTIME:6868 (test)

But who wants to run such an ancient version in 2023 🤣

[ZerBea]

This ancient version is a WIRELESS EXTENSION (WEXT) dinosaur. Since kernel 6.3 WEXT are deprecated:
7c353a7

[ZerBea]

Attached a modified version of hcxdumptool. Please backup hcxdumptool.c. Than replace it by the debug version. Compile and runt it:
$ sudo ./hcxdumptool -i INTERFACENAME --rds=1 -exitoneapol=7 --tot=5

This version store the traffic from hcxdumptool to the driver, too. That allows to detect mail formed frames caused by an ENDIANESS issue.
hcxdumptool.c.zip

When hcxdumptool has been terminated, please attach the dump file and comment the status output, e.g.:

0 ERROR(s) during runtime
803 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
34 EPB written to pcapng dumpfile

exit on PMKID

[dracode]

Thanks so much for all of your work on hcxdumptool. It's a fantastic tool, and I'm honestly amazed at how responsive you are to feedback and comments. Providing a special debug version is just above and beyond!

Here's the output:

root@OpenWrt:~# hcxdumptool -i wlan1 -c 8a --rds=1 --exitoneapol=7 --tot=5

 CHA   LAST   R 1 3 P S    MAC-AP    ESSID (last EAPOL on top)    SCAN-FREQUENCY:   2447
-----------------------------------------------------------------------------------------
   8 06:42:25           3880dff76a72 r'QL�
   8 06:42:06           b827ebb5eb30 HP-Print-05-ENVY 4500 series
   8 06:42:20           b8f853e04ba9
   8 06:42:19           b8f853e04baa
   8 06:42:12           64e7d84e983e
   8 06:41:40           3880dff76a71
   8 06:41:29           ccf9e49913c6















   LAST   E 2 MAC-AP-ROGUE   MAC-CLIENT   ESSID (last M2ROGUE on top)
-----------------------------------------------------------------------------------------
 06:42:34     ffffffffffff 40b4cd434e57
 06:42:34     ffffffffffff fc15b4d51605
 06:42:34     ffffffffffff b827ebb5eb30
 06:42:34     ffffffffffff 54f15fc17042
 ^C
1 ERROR(s) during runtime
3189 Packet(s) captured by kernel
48 Packet(s) dropped by kernel
1 SHB written to pcapng dumpfile
1 IDB written to pcapng dumpfile
1 ECB written to pcapng dumpfile
225 EPB written to pcapng dumpfile

exit on sigterm
root@OpenWrt:~#

[ZerBea]

If you have no idea how to set up a reproducible test environment, a good starting point is here:
#361 (comment)

[ZerBea]

Thanks. The debug dump file is very helpful and I see the problem.
Now I try to fix it.

BTW:
The ath9k device is fine.
The ath10k_pci not:

Known bugs/limitations
packet injection isn't supported yet

https://wireless.wiki.kernel.org/en/users/Drivers/ath10k

Passive dumpers may work, hcxdumptool (interactive) not.

[ZerBea]

This is an epical fail:
https://github.com/ZerBea/hcxdumptool/blob/master/include/ieee80211.h#L333
And I found some more.

[ZerBea]

Please try latest commit.
$ sudo hcxdumptool -i interface --rds=1

[ZerBea]

These were massive changes. It's possible that I've missed something else.
I'll prepare some more tests.

[ZerBea]

By latest commit (change in Makefile), debugging becomes easy:

# uncomment to enable debug mode
#DEFS		+= -DHCXDEBUGMODE

[dracode]

Okay, I did a git pull and enabled the debug mode.

Here is my first run, where I deliberately turned the wifi on the test phone off and on again to generate EAPOLs, in case you wanted to see.

root@OpenWrt:~# hcxdumptool -i wlan1 -c 8a --rds=1
 CHA   LAST   R 1 3 P S    MAC-AP    ESSID (last EAPOL on top)    SCAN-FREQUENCY:   2447
-----------------------------------------------------------------------------------------
   8 06:05:30   + +     00134a71d389 test





















   LAST   E 2 MAC-AP-ROGUE   MAC-CLIENT   ESSID (last M2ROGUE on top)
-----------------------------------------------------------------------------------------
 06:05:13     00134a71d389 5228c21586e8 test
^C
0 ERROR(s) during runtime
1911 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
675 EPB written to pcapng dumpfile

exit on sigterm

Here is another run where I did not force EAPOLs but did use the test phone to generate some simple HTTP traffic over the link while hcxdumptool was running. Looks like hcxdumptool did not pick up on the client being present.

root@OpenWrt:~# hcxdumptool -i wlan1 -c 8a --rds=1
 CHA   LAST   R 1 3 P S    MAC-AP    ESSID (last EAPOL on top)    SCAN-FREQUENCY:   2447
-----------------------------------------------------------------------------------------
   8 06:07:34           00134a71d389 test





















   LAST   E 2 MAC-AP-ROGUE   MAC-CLIENT   ESSID (last M2ROGUE on top)
-----------------------------------------------------------------------------------------
^C
0 ERROR(s) during runtime
2508 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
748 EPB written to pcapng dumpfile

exit on sigterm

[ZerBea]

Some more information:
hcxdumptool does not REASSOCIATE, DISASSOCIATE or DEAUTHENTICATE a CLIENT if data traffic is in progress.
Most APs are hardened against this attacks.

[ZerBea]

I checked both dump files.

Frame 351: 103 bytes on wire (824 bits), 103 bytes captured (824 bits) on interface wlan1, id 0
    Section number: 1
    Interface id: 0 (wlan1)
        Interface name: wlan1
    Encapsulation type: IEEE 802.11 plus radiotap radio header (23)
    Arrival Time: Dec 12, 2023 07:05:12.534480847 CET
    UTC Arrival Time: Dec 12, 2023 06:05:12.534480847 UTC
    Epoch Arrival Time: 1702361112.534480847
    [Time shift for this packet: 0.000000000 seconds]
    [Time delta from previous captured frame: 0.100315871 seconds]
    [Time delta from previous displayed frame: 0.100315871 seconds]
    [Time since reference or first frame: 20.840005680 seconds]
    Frame Number: 351
    Frame Length: 103 bytes (824 bits)
    Capture Length: 103 bytes (824 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: radiotap:wlan_radio:wlan]
Radiotap Header v0, Length 10
    Header revision: 0
    Header pad: 0
    Header length: 10
    Present flags
        Present flags word: 0x00008000
            .... .... .... .... .... .... .... ...0 = TSFT: Absent
            .... .... .... .... .... .... .... ..0. = Flags: Absent
            .... .... .... .... .... .... .... .0.. = Rate: Absent
            .... .... .... .... .... .... .... 0... = Channel: Absent
            .... .... .... .... .... .... ...0 .... = FHSS: Absent
            .... .... .... .... .... .... ..0. .... = dBm Antenna Signal: Absent
            .... .... .... .... .... .... .0.. .... = dBm Antenna Noise: Absent
            .... .... .... .... .... .... 0... .... = Lock Quality: Absent
            .... .... .... .... .... ...0 .... .... = TX Attenuation: Absent
            .... .... .... .... .... ..0. .... .... = dB TX Attenuation: Absent
            .... .... .... .... .... .0.. .... .... = dBm TX Power: Absent
            .... .... .... .... .... 0... .... .... = Antenna: Absent
            .... .... .... .... ...0 .... .... .... = dB Antenna Signal: Absent
            .... .... .... .... ..0. .... .... .... = dB Antenna Noise: Absent
            .... .... .... .... .0.. .... .... .... = RX flags: Absent
            .... .... .... .... 1... .... .... .... = TX flags: Present
            .... .... .... ..0. .... .... .... .... = data retries: Absent
            .... .... .... .0.. .... .... .... .... = Channel+: Absent
            .... .... .... 0... .... .... .... .... = MCS information: Absent
            .... .... ...0 .... .... .... .... .... = A-MPDU Status: Absent
            .... .... ..0. .... .... .... .... .... = VHT information: Absent
            .... .... .0.. .... .... .... .... .... = frame timestamp: Absent
            .... .... 0... .... .... .... .... .... = HE information: Absent
            .... ...0 .... .... .... .... .... .... = HE-MU information: Absent
            .... .0.. .... .... .... .... .... .... = 0 Length PSDU: Absent
            .... 0... .... .... .... .... .... .... = L-SIG: Absent
            .... ..0. .... .... .... .... .... .... = Reserved: 0x0
            ...0 .... .... .... .... .... .... .... = TLVs: Absent
            ..0. .... .... .... .... .... .... .... = Radiotap NS next: False
            .0.. .... .... .... .... .... .... .... = Vendor NS next: False
            0... .... .... .... .... .... .... .... = Ext: Absent
    TX flags: 0x0018, No ACK, Has Seqnum
        .... .... .... .... .... ...0 = Fail: False
        .... .... .... .... .... ..0. = CTS: False
        .... .... .... .... .... .0.. = RTS/CTS: False
        .... .... .... .... .... 1... = No ACK: True
        .... .... .... .... ...1 .... = Has Seqnum: True
        .... .... .... .... ..0. .... = Order: False
802.11 radio information
IEEE 802.11 Beacon frame, Flags: ........
    Type/Subtype: Beacon frame (0x0008)
    Frame Control Field: 0x8000
        .... ..00 = Version: 0
        .... 00.. = Type: Management frame (0)
        1000 .... = Subtype: 8
        Flags: 0x00
            .... ..00 = DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x0)
            .... .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
    .000 0001 0011 1010 = Duration: 314 microseconds
    Receiver address: ff:ff:ff:ff:ff:ff
    Destination address: ff:ff:ff:ff:ff:ff
    Transmitter address: 28:ef:01:12:50:5a
    Source address: 28:ef:01:12:50:5a
    BSS Id: 28:ef:01:12:50:5a
    .... .... .... 0000 = Fragment number: 0
    0000 1001 0100 .... = Sequence number: 148
    [WLAN Flags: ........]
IEEE 802.11 Wireless Management
    Fixed parameters (12 bytes)
        Timestamp: 174
        Beacon Interval: 1,048576 [Seconds]
        Capabilities Information: 0x0431
            .... .... .... ...1 = ESS capabilities: Transmitter is an AP
            .... .... .... ..0. = IBSS status: Transmitter belongs to a BSS
            .... .... .... .0.. = Reserved: 0
            .... .... .... 0... = Reserved: 0
            .... .... ...1 .... = Privacy: Data confidentiality required
            .... .... ..1. .... = Short Preamble: Allowed
            .... .... .0.. .... = Critical Update Flag: False
            .... .... 0... .... = Nontransmitted BSSIDs Critical Update Flag: False
            .... ...0 .... .... = Spectrum Management: Not Implemented
            .... ..0. .... .... = QoS: Not Implemented
            .... .1.. .... .... = Short Slot Time: In use
            .... 0... .... .... = Automatic Power Save Delivery: Not Implemented
            ...0 .... .... .... = Radio Measurement: Not Implemented
            ..0. .... .... .... = EPD: Not Implemented
            .0.. .... .... .... = Reserved: 0
            0... .... .... .... = Reserved: 0
    Tagged parameters (57 bytes)
        Tag: SSID parameter set: "internet"
            Tag Number: SSID parameter set (0)
            Tag length: 8
            SSID: "internet"
        Tag: Supported Rates 1(B), 2(B), 5.5(B), 11(B), 6(B), 9, 12(B), 18, [Mbit/sec]
            Tag Number: Supported Rates (1)
            Tag length: 8
            Supported Rates: 1(B) (0x82)
            Supported Rates: 2(B) (0x84)
            Supported Rates: 5.5(B) (0x8b)
            Supported Rates: 11(B) (0x96)
            Supported Rates: 6(B) (0x8c)
            Supported Rates: 9 (0x12)
            Supported Rates: 12(B) (0x98)
            Supported Rates: 18 (0x24)
        Tag: DS Parameter set: Current Channel: 8
            Tag Number: DS Parameter set (3)
            Tag length: 1
            Current Channel: 8
        Tag: Traffic Indication Map (TIM): DTIM 0 of 1 bitmap
            Tag Number: Traffic Indication Map (TIM) (5)
            Tag length: 4
            DTIM count: 0
            DTIM period: 1
            Bitmap control: 0x00
                .... ...0 = Multicast: False
                0000 000. = Bitmap Offset: 0x00
            Partial Virtual Bitmap: 00
        Tag: Extended Supported Rates 24(B), 36, 48, 54, [Mbit/sec]
            Tag Number: Extended Supported Rates (50)
            Tag length: 4
            Extended Supported Rates: 24(B) (0xb0)
            Extended Supported Rates: 36 (0x48)
            Extended Supported Rates: 48 (0x60)
            Extended Supported Rates: 54 (0x6c)
        Tag: RSN Information
            Tag Number: RSN Information (48)
            Tag length: 20
            RSN Version: 1
            Group Cipher Suite: 00:0f:ac (Ieee 802.11) AES (CCM)
                Group Cipher Suite OUI: 00:0f:ac (Ieee 802.11)
                Group Cipher Suite type: AES (CCM) (4)
            Pairwise Cipher Suite Count: 1
            Pairwise Cipher Suite List 00:0f:ac (Ieee 802.11) AES (CCM)
                Pairwise Cipher Suite: 00:0f:ac (Ieee 802.11) AES (CCM)
                    Pairwise Cipher Suite OUI: 00:0f:ac (Ieee 802.11)
                    Pairwise Cipher Suite type: AES (CCM) (4)
            Auth Key Management (AKM) Suite Count: 1
            Auth Key Management (AKM) List 00:0f:ac (Ieee 802.11) PSK
                Auth Key Management (AKM) Suite: 00:0f:ac (Ieee 802.11) PSK
                    Auth Key Management (AKM) OUI: 00:0f:ac (Ieee 802.11)
                    Auth Key Management (AKM) type: PSK (2)
            RSN Capabilities: 0x0000
                .... .... .... ...0 = RSN Pre-Auth capabilities: Transmitter does not support pre-authentication
                .... .... .... ..0. = RSN No Pairwise capabilities: Transmitter can support WEP default key 0 simultaneously with Pairwise key
                .... .... .... 00.. = RSN PTKSA Replay Counter capabilities: 1 replay counter per PTKSA/GTKSA/STAKeySA (0x0)
                .... .... ..00 .... = RSN GTKSA Replay Counter capabilities: 1 replay counter per PTKSA/GTKSA/STAKeySA (0x0)
                .... .... .0.. .... = Management Frame Protection Required: False
                .... .... 0... .... = Management Frame Protection Capable: False
                .... ...0 .... .... = Joint Multi-band RSNA: False
                .... ..0. .... .... = PeerKey Enabled: False
                ..0. .... .... .... = Extended Key ID for Individually Addressed Frames: Not supported
                .0.. .... .... .... = OCVC: False

No ENDIANESS problems any longer.

[ZerBea]

Another epical fail. I have not noticed that debug mode has been enabled:
Okay, I did a git pull and enabled the debug mode.
The first DEBUG mode wasn't designed to run entire attacks. To discover ENDIANESS problems, only a few incoming and all outgoing packets are monitored.
By latest commit this has been fixed. Now incoming frames which are mandatory to run an attack and all outgoing frames are monitored.
Please do not enable DEBUG mode. Compile hcxdumptool and run:
$ sudo hcxdumptool -i interface --rds=1 -c your_operating_channel
If that doesn't work as expected, please enable DEBUG mode run:
$ sudo hcxdumptool -i interface --rds=1 -c your_operating_channel
and attach the pcapng file.

[dracode]

I have run a new round of tests. I ran both the normal and debug versions multiple times, in case of any driver errors. I checked dmesg and didn't notice any ath9k driver messages, but I did notice some messages related to netlink. There were many of these, here is a small snippet:

[ 2765.876527] netlink: 16 bytes leftover after parsing attributes in process `hcxdumptool'.
[ 2767.876259] netlink: 16 bytes leftover after parsing attributes in process `hcxdumptool'.
[ 2769.109298] device wlan1 left promiscuous mode
[ 2773.997533] netlink: 16 bytes leftover after parsing attributes in process `hcxdumptool'.
[ 2774.014319] device wlan1 entered promiscuous mode
[ 2781.034452] netlink: 16 bytes leftover after parsing attributes in process `hcxdumptool'.
[ 2783.034337] netlink: 16 bytes leftover after parsing attributes in process `hcxdumptool'.
[ 2784.331249] device wlan1 left promiscuous mode
[ 2788.919532] netlink: 16 bytes leftover after parsing attributes in process `hcxdumptool'.
[ 2788.935675] device wlan1 entered promiscuous mode
[ 2795.955619] netlink: 16 bytes leftover after parsing attributes in process `hcxdumptool'.
[ 2796.955701] netlink: 16 bytes leftover after parsing attributes in process `hcxdumptool'.

First test, normal unmodified code exactly as it comes out of github:

root@OpenWrt:~# hcxdumptool -i wlan1 --rds=1 -c 8a
 CHA   LAST   R 1 3 P S    MAC-AP    ESSID (last EAPOL on top)    SCAN-FREQUENCY:   2447
-----------------------------------------------------------------------------------------
   8 01:05:03           00227e34d1a9 test





















   LAST   E 2 MAC-AP-ROGUE   MAC-CLIENT   ESSID (last M2ROGUE on top)
-----------------------------------------------------------------------------------------
^C
0 ERROR(s) during runtime
2073 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
2 EPB written to pcapng dumpfile

exit on sigterm

Second run, nearly identical results:

0 ERROR(s) during runtime
1225 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
2 EPB written to pcapng dumpfile

Neither time did hcxdumptool seem to detect that there was a client present, but there was.

So I switched to debug mode:

root@OpenWrt:~# opkg remove hcxdumptool
Removing package hcxdumptool from root...
root@OpenWrt:~# opkg install hcxdumptool_debug.ipk
Installing hcxdumptool (6.3.2-1) to root...
Configuring hcxdumptool.
root@OpenWrt:~# hcxdumptool -i wlan1 --rds=1 -c 8a
 CHA   LAST   R 1 3 P S    MAC-AP    ESSID (last EAPOL on top)    SCAN-FREQUENCY:   2447
-----------------------------------------------------------------------------------------
   8 01:08:04           00227e34d1a9 test





















   LAST   E 2 MAC-AP-ROGUE   MAC-CLIENT   ESSID (last M2ROGUE on top)
-----------------------------------------------------------------------------------------
^C
2 ERROR(s) during runtime
1871 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
722 EPB written to pcapng dumpfile

exit on sigterm

Second test, nearly identical:

1 ERROR(s) during runtime
1784 Packet(s) captured by kernel
65 Packet(s) dropped by kernel
1 SHB written to pcapng dumpfile
1 IDB written to pcapng dumpfile
1 ECB written to pcapng dumpfile
684 EPB written to pcapng dumpfile

Still nothing seen from hcxdumptool about the client, so at this time I did a quick capture with airodump-ng to verify that the client was indeed visible on the air:

CH  8 ][ Elapsed: 30 s ][ 2023-12-17 01:10 ][ fixed channel wlan1: -1

 BSSID              PWR RXQ  Beacons    #Data, #/s  CH   MB   ENC CIPHER  AUTH ESSID

 00:22:7E:34:D1:A9  -14 100      323       96    0   8  260   WPA2 CCMP   PSK  test

 BSSID              STATION            PWR   Rate    Lost    Frames  Notes  Probes

 00:22:7E:34:D1:A9  52:28:C2:15:86:E8  -12   24e- 1e   666      124         test

It was, so I then did a third trial of hcxdumptool.

0 ERROR(s) during runtime
1961 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
879 EPB written to pcapng dumpfile

Again no mention of a client, no + in any of the attack status columns. Running everything the same on a little endian computer next to this pretty reliably will get a handshake in 15 seconds or so.

[ZerBea]

Please try latest git head.
Some more BE problems has been fixed, but not all.

I still need the value of the AUTHENTICATION sequence field and the value of the AID field.
In contrast to all other values, this values must not be converted to LITTLE ENDIAN on my system. So I guess they are little ENDIAN and they must be converted to BIG ENDIAN on a BE system.
But that need to code a special debug version.

[dracode]

Some good and bad changes with this one.

First is a brief look at the official github snapshot version:
Yesterday's version was rendering all SSIDs properly, while today's version is giving nonsense characters. I'm getting one or two real SSIDs, but they seem to be being randomly assigned, sometimes to the wrong MAC-AP, then they disappear, or reappear... There are also far more MAC-APs than yesterday's version showed.
Here I ran it unconstrained to my test AP's channel.

 CHA   LAST   R 1 3 P S    MAC-AP    ESSID (last EAPOL on top)    SCAN-FREQUENCY:   2462
-----------------------------------------------------------------------------------------
  11 00:23:03           e091f5xxxxxx Proper
  11 00:23:03           3cbdc5xxxxxx
  11 00:23:02           e291f5xxxxxx A1Ίu-u
  11 00:23:01           00e04cxxxxxx $�ٴ�0b0?
  11 00:22:56           147ddaxxxxxx
  11 00:22:55           4c55ccxxxxxx
  11 00:22:54           001132xxxxxx K\I
  11 00:22:53           bc5ff4xxxxxx
  11 00:22:51           e6f042xxxxxx
  11 00:22:50           0cc413xxxxxx

Here I ran the official github version constrained to my test channel. It properly detects and gives the proper SSID for my test AP, but also incorrectly gives the same SSID to another nearby AP. Also various broadcast and multicast addresses are being called APs when they aren't. The MAC of my test client device (5228c21586e8) is also showing as a MAC-AP, when it is only a station. I did force an authentication to my test AP during this capture, but no EAPOLs made it into the pcap.

 CHA   LAST   R 1 3 P S    MAC-AP    ESSID (last EAPOL on top)    SCAN-FREQUENCY:   2437
-----------------------------------------------------------------------------------------
   6 00:55:30           0080b3ba0af1 test
   6 00:55:26           e091f5xxxxxx test
   6 00:55:30           b827ebxxxxxx
   6 00:55:30           5228c21586e8
   6 00:55:30           333300000002
   6 00:55:26           333300000016
   6 00:55:25           ffffffffffff
   6 00:55:25           3333ff1586e8














   LAST   E 2 MAC-AP-ROGUE   MAC-CLIENT   ESSID (last M2ROGUE on top)
-----------------------------------------------------------------------------------------
 00:55:31     ffffffffffff 0080b3xxxxxx
 00:55:27     ffffffffffff 5228c21586e8
 00:55:25     0080b3ba0af1 5228c21586e8
 00:55:24     ffffffffffff 3a60d8xxxxxx
 00:55:23     ffffffffffff 36b5baxxxxxx
 00:55:22     ffffffffffff c28acexxxxxx
 00:55:22     ffffffffffff 3283f4xxxxxx
 00:55:22     ffffffffffff 9ee633xxxxxx
 00:55:17     ffffffffffff 40e1e4xxxxxx
 00:55:11     ffffffffffff 1a3ab8xxxxxx
 00:54:49     ffffffffffff 3cbdc5xxxxxx
^C
0 ERROR(s) during runtime
1570 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
21 EPB written to pcapng dumpfile

Next I tried the authseq modified version. This one did notice the client attached to the test target, which is good! I turned wifi off and on on the client a couple of times to force new authentications. authseq and aid stayed always 0, never changed. I looked at the pcap (attached below) and did not see any EAPOL messages.

authseq: 0, aid 0
^C
0 ERROR(s) during runtime
1703 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
19 EPB written to pcapng dumpfile

exit on sigterm

Finally I tried the 'beacon subtype' version. I think the endianness is not detected correctly, I get a different result to yours:

Initialize main scan loop...beacon subtype seen from HOST 0
beacon subtype seen from HOST 0
beacon subtype seen from HOST 0

You mentioned that WEXT is deprecated in kernel 6.3. I note that for OpenWrt 23 (the current release), all platforms are still on kernel 5.15. Perhaps that could be a reason for the netlink message not working as expected?

root@OpenWrt:~# uname -a
Linux OpenWrt 5.15.137 #0 Tue Nov 14 13:38:11 2023 mips GNU/Linux

[ZerBea]

Looks like there are several "openwrt capable devices" out in the wildness and it is worth it to add BE support to hcxdumptool.

[ZerBea]

This is from your BEACON record dump:

Fixed parameters (12 bytes)
    Timestamp: 5053553
    Beacon Interval: 0,004096 [Seconds]
    Capabilities Information: 0x3104

The BEACON has been transmitted, but the capabilities information is wrong.
I'm going to fix the TX branch if the new RX branch is confirmed as working.

[ZerBea]

Lessons learned so far:
yes, radiotap header is LE
yes, 802.11 data is BE (but unfortunately not all)

[ZerBea]

Please try latest git head (no need to enable debug mode, because the TX branch is still unfixed).
You should now get a + in the columns (I hope).

[dracode]

Wow, not only did I get the + but it also appears to successfully deauth and get EAPOL! Great test.

root@OpenWrt:~# hcxdumptool -i wlan1 --rds=1 -c 11a --bpf=attack.bpf

   LAST   E 2 MAC-AP-ROGUE   MAC-CLIENT   ESSID (last M2ROGUE on top)
-----------------------------------------------------------------------------------------
 CHA   LAST   R 1 3 P S    MAC-AP    ESSID (last EAPOL on top)    SCAN-FREQUENCY:   2462
-----------------------------------------------------------------------------------------
  11 21:23:24 + + +   + 001020304050 test
   9 21:23:21         + bc99xxxxxxxx XXXXXXXX
  11 21:23:08         + 244bxxxxxxxx XXXXXXXX
  11 21:23:04         + 58cbxxxxxxxx XXXXXXXX


















   LAST   E 2 MAC-AP-ROGUE   MAC-CLIENT   ESSID (last M2ROGUE on top)
-----------------------------------------------------------------------------------------
 21:23:10     001020304050 5228c21586e8
^C
0 ERROR(s) during runtime
1139 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
42 EPB written to pcapng dumpfile

exit on sigterm

[ZerBea]

Thanks for the test and your patience.

The major attack is the REASSOCIATION attack which is a hundred times more effective than a DEUTHENTICATION attack.
If the counters are fixed, it will be more effective. :)

[ZerBea]

The TX branch should now be fixed, too.
The last part is NETLINK. Therfore please debug the NETLINK communication between hcxdumptool and the kernel.
First start the NETLINK monitor mode (nlmon):

$ sudo ip link add  nlmon0 type nlmon
$ sudo ip link set dev nlmon0 up

Start recording:

$ tshark -i nlmon0 -w netlink.pcapng
Capturing on 'nlmon0'
235

or

$ sudo tcpdump -i nlmon0 -w netlink.pcap
tcpdump: listening on nlmon0, link-type NETLINK (Linux netlink), snapshot length 262144 bytes
235 packets captured
235 packets received by filter

run hcxdumptool and wait until teh channel has been changed ate least 5 times.
stop hcxdumptool
stop tshark or tcpdump
please attach the dump file.

[dracode]

Okay, I did the above. I used the BPF but did not lock the channel, and the client was not present. If you need some with the client present I can re-run the test.

root@OpenWrt:~# hcxdumptool -i wlan1 --rds=1 --bpf=attack.bpf

 CHA   LAST   R 1 3 P S    MAC-AP    ESSID (last EAPOL on top)    SCAN-FREQUENCY:   2437
-----------------------------------------------------------------------------------------
  11 22:54:34 + +     + 001020304050 test





















   LAST   E 2 MAC-AP-ROGUE   MAC-CLIENT   ESSID (last M2ROGUE on top)
-----------------------------------------------------------------------------------------
^C
0 ERROR(s) during runtime
345 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
31 EPB written to pcapng dumpfile

exit on sigterm

[ZerBea]

Thanks. That was helpful.
Please try latest commit and check dmesg. Is there still a NETLINK warning?
Please attach nlmon0 dump file so that I can make sure everything is working as expected.
No need to attach the wifi dump, because we know that it the wifi part is working as expected.

[ZerBea]

BTW:
No need to apply a filter to hcxdumptool, because the NETLINK socket is a control socket. There is no wifi traffic inside.

[dracode]

Some good and some bad.

This is all I see in dmesg, which seems good:

[58378.830293] device wlan1 entered promiscuous mode
[58383.845341] device wlan1 left promiscuous mode
[58388.257809] device nlmon0 left promiscuous mode

But this is what happens with hcxdumptool now:

This is a highly experimental penetration testing tool!
It is made to detect vulnerabilities in your NETWORK mercilessly!

BPF is unset! Make sure hcxdumptool is running in a 100% controlled environment!

Initialize main scan loop...root@OpenWrt:~#

It seems to be exiting with a status of 1 before getting to the main interface.

[ZerBea]

Thanks.
The NETLINK message is looking good:

Linux 802.11 Netlink
    Attribute: NL80211_ATTR_IFINDEX
    Attribute: NL80211_ATTR_WIPHY_FREQ
    Attribute: NL80211_ATTR_CHANNEL_WIDTH
    Attribute: NL80211_ATTR_WIPHY_CHANNEL_TYPE
    Attribute: NL80211_ATTR_CENTER_FREQ1
    Attribute: NL80211_ATTR_TX_RATES

and it has been accepted:

Netlink message
    Netlink message header (type: Error)
    Error code: Success (0)
    Netlink message header (type: 0x0019)

By latest commit, the exit(EXIT_FAILURE) has been removed and hcxdumptool should work as expected, now:
6275ea3#diff-8125ff62a279e92c823e77b6ba7da82b2544b5db078008535e0bf8034cbc96f7L2742

That was the best way to terminate hcxdumptool after the expected NETLINK message has arrived.

[dracode]

This is fantastic. Seems to be working pretty well!

I ran this test multiple times:

root@OpenWrt:~# hcxdumptool -i wlan1 -c 11a --bpf=attack.bpf

Usually I get a response that looks like this:

 CHA   LAST   R 1 3 P S    MAC-AP    ESSID (last seen on top)     SCAN-FREQUENCY:   2462
-----------------------------------------------------------------------------------------
  11 02:34:25 + +     + 001020304050 test
  11 02:34:10         + 58cbxxxxxxxx XXXXXXXX
  11 02:34:10         + 244bxxxxxxxx XXXXXXXX
   9 02:34:10         + bc99xxxxxxxx XXXXXXXX


















   LAST   E 2 MAC-AP-ROGUE   MAC-CLIENT   ESSID (last seen on top)
-----------------------------------------------------------------------------------------
 02:34:13   + 001020304050 5228c21586e8 test
^C
0 ERROR(s) during runtime
1024 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
42 EPB written to pcapng dumpfile

exit on sigterm

Attack is successful, hcxpcapngtool gives me a useable hash. It's a bit strange that there's no indicator for message 3, though, as I see it in the pcap with Wireshark.

But occasionally, I get a result like this instead:

 CHA   LAST   R 1 3 P S    MAC-AP    ESSID (last seen on top)     SCAN-FREQUENCY:   2462
-----------------------------------------------------------------------------------------
  11 02:49:35 + + +   + 001020304050 test
  11 02:49:20         + 58cbxxxxxxxx XXXXXXXX
  11 02:49:20         + 244bxxxxxxxx XXXXXXXX



















   LAST   E 2 MAC-AP-ROGUE   MAC-CLIENT   ESSID (last seen on top)
-----------------------------------------------------------------------------------------
 02:49:23     001020304050 5228c21586e8
^C
0 ERROR(s) during runtime
1005 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
38 EPB written to pcapng dumpfile

exit on sigterm

Note the difference, I got a + under the 3 column here, but no + under the 2 below.
hcxpcapngtool does not produce a useful output for this case... but when I look at the pcap file in Wireshark, I see a full sequence of messages 1 through 4. So there may be some sort of lingering oddity here.

I noticed that in the case where message 2 is detected but not message 3, messages 2 and 3 have the same sequence number... likewise where message 1 is detected but not message 2, message 1 and 2 had the same sequence number. Not sure if this is the reason but it seemed suspicious.

Another test case is maybe working as intended, but I will mention it anyway for the sake of completeness. When I run the test like this:

root@OpenWrt:~# hcxdumptool -i wlan1 -F --bpf=attack.bpf

Simulating a case where I know the MACs but am not sure of the precise channel in advance.

Then the results are not so great. I can see the phone get deauthenticated and then reauthenticate, but hcxdumptool is not catching it. I assume the tool has hopped to another channel before the phone reconnects and misses it. Understandable. But then even if I leave the tool running for quite a long time it doesn't seem to reattack the same target, so I never get the handshake for the target specified in my BPF file.

[ZerBea]

Thanks for the test and the dump files.
The content of them is exactly what was expected.
Let me explain the column.
AP display
R = target AP respond to hcxdumptool (+) - empty column attack stopped (see next column) or target does not respond
1 = target AP respond with M1
AP must be in range
3 = M2M3 from target AP and associated CLIENT, hcxpcapngtool can build a MESSAGEPAIR and hashcat can work on it
AP and CLIENT must be in range
P = M1 contain a PMKID
S = WPA-PSK AKM is in use (otehr AKMs are not supported, because hashcat and JtR can't handle them.

CLIENT display below:
E = target CLIENT respond with EAP-ID
CLIENT must be in range
2 = target respond on hcxdumptool request with M2 (M1M2ROGUE or AP-LESS attack), hcxpcapngtool can build a MESSAGEPAIR and hashcat can work on it
CLIENT must be in range

If you specify an attack BPF it is good to now which channel is in use
Than run hcxdumptool on the operating channel of the AP.
If you prefer to scan all channel, just increase the stay time on the channel.

The default scan channels are 1a,6a,11a because the entire range (all channels is a way too big to perform successful attacks "in time").

[ZerBea]

hcxpcapngtool status show the difference:
attack on AP with connected CLIENT (status shown in AP display of hcxdumptool)

$ hcxpcapngtool 20231223024914-wlan1.pcapng
...
EAPOL pairs (best).......................: 1
EAPOL M32E2 (authorized).................: 1

attack on CLIENT (status shown in CLIENT display of hcxdumptool)

$ hcxpcapngtool 20231223023515-wlan1.pcapng
EAPOL ROGUE pairs........................: 1
EAPOL M12E2 (challenge)..................: 1

[dracode]

Thanks for the explanation!

I found the problem on my side: I was using an older version of hcxpcapngtool (v6.2.4) that wasn't able to create the hash file for one of those. Switching to the latest version got a hash for both files.

Everything seems great, thanks for dedicating so much time to making this tool. Are there any remaining endian related items that you would like me to test?

[ZerBea]

I think, all BE uint 16, 32 and 64 values should be BE ready, now.

Due to several changes it is mandatory that hcxdumptool and hcxpcapngtool version numbers are matching., because none of the tools can handle data from newer tools. They are backward compatible only.

BTW:
It would be nice (for other opwenwrt users) if you describe (in short terms) how you installed hcxdumptool on opwnwrt.

[dracode]

Compiling software for OpenWrt is a bit of a chore. Most devices that run OpenWrt are routers, with the resource constraints you would expect -- not a lot of RAM or storage. So running the build environment on the device itself is usually not practical. For this reason, the OpenWrt people have developed an elaborate cross-compiling setup that can produce builds for all the huge variety of OpenWrt devices out there -- little endian, big endian; MIPS, ARM, x86 processors...

The basic overview is:

• Install the build system
• Set up the build system
• Configure it for your particular device
• Build a complete image for your device following the steps given above, to build all dependencies (tool chains, etc)
• Build a single package

Which, honestly, is way too much trouble for 99% of people. It took me many hours to get to that point.
The easiest answer for people who want the new version will be:

• Wait for hcxdumptool/hcxtools to issue a new release (v6.3.3?)
• Wait for a PR to the OpenWrt project updating the package feeds
• Wait for the next SNAPSHOT build that incorporates the new version
• Download the .ipk (OpenWrt package) for hcxdumptool/hcxtools from the snapshot site and install it on their current OpenWrt 23.05 system

[ZerBea]

Thanks. I'm sure this will be helpful for other opwnwrt users.
Version 6.3.3 release is planed in early January.
There are still some driver workarounds (broken active monitor mode on e.g. mt7921u) to do.

[kimocoder]

"
root@OpenWrt:# hcxdumptool -v
hcxdumptool 6.3.2-197-gf2d12ac (C) 2024 ZeroBeat
running on Linux kernel 5.15.148
compiled by gcc 12.3.0
compiled with Linux API headers 6.1.75
glibc (GLIBC_MINOR) is not defined
enabled REALTIME DISPLAY
enabled GPS support
disabled BPF compiler
root@OpenWrt:#
root@OpenWrt:#
root@OpenWrt:# uname -a
Linux OpenWrt 5.15.148 #0 SMP Sun Feb 4 00:12:51 2024 aarch64 GNU/Linux
root@OpenWrt:#
root@OpenWrt:#
root@OpenWrt:~# airmon-ng

PHY Interface Driver Chipset

phy0 wlan0 mt798x-wmac Not pci, usb, or sdio

root@OpenWrt:#
root@OpenWrt:#
root@OpenWrt:~# hcxdumptool -i wlan0 -w capture.pcapng

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

failed to get interface list
PACKET_STATISTICS failed

1 ERROR(s) during runtime
Possible reasons:
driver is broken
driver is busy (misconfigured system, other services access the INTERFACE)
0 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
Warning: too less packets received (monitor mode may not work as expected)
Possible reasons:
no transmitter in range
frames are filtered out by BPF
driver is broken
0 SHB written to pcapng dumpfile
0 IDB written to pcapng dumpfile
0 ECB written to pcapng dumpfile
0 EPB written to pcapng dumpfile

root@OpenWrt:~#
"