Active monitor mode

[v74863]

Hi, ZerBea

Please explain in simple words
what is the main advantage of the active monitor mode vs monitor mode.

Please mention two cases:

• in general
• for hcxdumptool in particular

I read that
To perform ultra fast PMKID attacks, hcxdumptool use this mode
#375

What you meant by ultra fast?
How fast attack will be in active monitor mode vs just monitor mode?

I think this question is a good candidate for the frequently asked questions
and deserves a separate post.

Thanks in advance.

[ZerBea]

If an interface support active monitor mode incoming frames addressed to the MAC of the interface are acknowledged (ACK) by the interface.
If the target receive the ACK frame, it transmits next frame.
If the ACK is missing it doesn't transmit the next frame. Instead it re-transmits the old frame up to 7 times.
That is a huge performance decrease, because the channel is locked 7 times longer.
If hcxdumptool requests a PMKID running an interface that does not support active monitor mode, this will take 7 times longer.

To answer the question:
How fast attack will be in active monitor mode vs just monitor mode?
It will be up to 7 times faster.

[ZerBea]

You may have noticed that hcxdumptool's options have been changed by this commit:
8d3f24e

-A             : ACK incoming frames
                  INTERFACE must support active monitor mode

As of today, only mt76x0u and mt76x2u really support active monitor mode.
openwrt/mt76#839

[v74863]

It will be up to 7 times faster.

Well, sounds great, but I haven't noticed a significant decrease in attack time.

I did a quick test. For example,
time sudo hcxdumptool -i wlan1 -w dump.pcapng -c 1a -A --bpf=attack.bpf --exitoneapol=1

In fact, the same time (about 7 seconds) was required to retrieve PMKIDs from three different APs.
I attacked each AP separately, with and without -A

I was using a modern laptop with the latest version of Arch Linux and USB WiFi
mt76x0u driver (Ralink Technology, Corp. MT7610U ("Archer T2U" 2.4G+5G WLAN Adapter)

So it seems to be only a theoretical advantage, or am I wrong?

By the way, you mentioned ultra fast PMKID attack.
Does that mean that EAPOL M2 and M3 attacks do not have the benefit of active monitor mode even theoretically?

Whether it is mandatory to be in monitor mode for any attack?
Is it possible to perform some limited attack, say, in managed (station) mode
if you already know the channel and the mac-address of the access point?

By the way, I noticed that hcxpcapngtool specifies the timestamp as GMT

timestamp minimum (GMT)..................: 12.12.2023 10:11:01
timestamp maximum (GMT)..................: 12.12.2023 10:11:09

But it's actually local time on my laptop, not GMT.

Thanks in advance.

[ZerBea]

I am talking about time gaps in layer 1 while you are talking about time gaps during processing hcxdumptool in user space.
To measure this, you need a spectrum analyzer.

By the way, you mentioned ultra fast PMKID attack.
Does that mean that EAPOL M2 and M3 attacks do not have the benefit of active monitor mode even theoretically?

This has been answered:
If an interface support active monitor mode incoming frames addressed to the MAC of the interface are acknowledged (ACK) by the interface.
Frames of a 4way handshake are either addressed to an AP or to a CLIENT, but never to the MAC of the attack device.
Changing the MAC of the attack device via NL80211 is a slow process, It doesn't make sense to do that.

Is it possible to perform some limited attack, say, in managed (station) mode
if you already know the channel and the mac-address of the access point?

That can be done via a patched wpa_supplicant or a patched hostap.

[ZerBea]

active monitor mode:

<- AUTHENTICATIONREQUEST
-> ACK
-> AUTHENTICATIONRESPONSE
<- ACK
<- ASSOCIATIONREQUEST
-> ACK
-> ASSOCIATIONRESPONSE
-> ACK
-> M1
<- ACK

passive monitor mode:

<- AUTHENTICATIONREQUEST
-> ACK
-> AUTHENTICATIONRESPONSE
-> AUTHENTICATIONRESPONSE R1
-> AUTHENTICATIONRESPONSE R2
-> AUTHENTICATIONRESPONSE R3
-> AUTHENTICATIONRESPONSE R4
-> AUTHENTICATIONRESPONSE R5
-> AUTHENTICATIONRESPONSE R6
-> AUTHENTICATIONRESPONSE R7
<- ASSOCIATIONREQUEST
-> ACK
-> ASSOCIATIONRESPONSE
-> ASSOCIATIONRESPONSE R1
-> ASSOCIATIONRESPONSE R2
-> ASSOCIATIONRESPONSE R3
-> ASSOCIATIONRESPONSE R4
-> ASSOCIATIONRESPONSE R5
-> ASSOCIATIONRESPONSE R6
-> ASSOCIATIONRESPONSE R7
-> M1
-> M1 R1
-> M1 R2
-> M1 R3
-> M1 R4
-> M1 R5
-> M1 R6
-> M1 R7

While a station is transmitting its frame, the channel is busy. No other station is allowed to transmit during this time.

Also, some APs terminate the AUTHENTICATION, if they do not get an ACK.

To really see what is going on on the channel, setup a second physical interface and monitor the entire traffic in parallel,

[v74863]

Brilliant explanation, thank you!
It seems that the decrease in attack time was not noticed due to the small amount of traffic required for this attack
and the fact that the channel was almost free.

[ZerBea]

Correct, but it will be huge if hcxdumptool attacks all targets in range simultaneously.
Running hcxdumptool on a small system like a Raspberry Pi Zero makes it mandatoryto count CPU cycles (of the system and of the device).
Above, I just mentioned the tip of the iceberg.
passive monitor mode:

AP ASSOCIATIONRESPONSE -> INTERFACE -> DRIVER -> PACKET SOCKET -> HCXDUMPTOOL (process this frame)
AP ASSOCIATIONRESPONSE R1 -> INTERFACE -> DRIVER -> PACKET SOCKET -> HCXDUMPTOOL (process this frame)
AP ASSOCIATIONRESPONSE R2 -> INTERFACE -> DRIVER -> PACKET SOCKET -> HCXDUMPTOOL (process this frame)
AP ASSOCIATIONRESPONSE R3 -> INTERFACE -> DRIVER -> PACKET SOCKET -> HCXDUMPTOOL (process this frame)
AP ASSOCIATIONRESPONSE R4 -> INTERFACE -> DRIVER -> PACKET SOCKET -> HCXDUMPTOOL (process this frame)
AP ASSOCIATIONRESPONSE R5 -> INTERFACE -> DRIVER -> PACKET SOCKET -> HCXDUMPTOOL (process this frame)
AP ASSOCIATIONRESPONSE R6 -> INTERFACE -> DRIVER -> PACKET SOCKET -> HCXDUMPTOOL (process this frame)
AP ASSOCIATIONRESPONSE R7 -> INTERFACE -> DRIVER -> PACKET SOCKET -> HCXDUMPTOOL (process this frame)

versus active monitor mode

AP ASSOCIATIONRESPONSE -> INTERFACE -> DRIVER -> PACKET SOCKET -> HCXDUMPTOOL (porcess this frame)
INTERFACE -> ACK
AP EAPOL M1 -> INTERFACE -> DRIVER -> PACKET SOCKET -> HCXDUMPTOOL (process this frame)

[ZerBea]

For this real world example (handling of an AUTHENTICATION) I added some measurement code:

AP AUTHENTICATIONRESPONSE -> INTERFACE -> DRIVER -> PACKET SOCKET -> HCXDUMPTOOL (process this frame)
handling of AUTHENTICATION took  0.000021 seconds to execute 

If that happens 7 times more, we are at 0.000168 seconds +/- due to rounding error of the measurement.