ESSID broadcast slow

[uniformsierra]

Hello and thank you for you great work.

I want to test how different client devices react when using this tool, as ap-less. I am trying to limit noise and only communicate with the test clients. I want to test by transmitting only essid(s) I know are in the client list and (hopefully) capture m2 from client who respond.

I have an essid list and am watching the transmissions on another linux computer, however I noticed a few things; 1) Certian USB wifi donlges do not transmit beacons at all (mt7610u, rt2800, ath9k, mt7601, rt8812au) 2) Of the ones working (rtl8187), beacon rate is slow (1 per 1 or 2 seconds). Maybe many unnecesary things are happening in the background and slowing down the broadcast rate?

I am using --disable_ap_attacks and have tried using --disable_deauthenticaiton. Also I am using a fixed channel, so that the clients have a better chance of seeing the beacons than us both hop around.

I understand that to stimulate sleepy clients some other packets may be sent out, taking the radio. What if I used 2 radios - one for lot of beaons (only) and the other for everything else? I am thinking that the clients are not missing the beacons because they are not being sent fast enough.

Should this work or am I doing something wrong?

Thanks again for your work

[ZerBea]

Testing CLIENTs is a great idea. To reduce noise, I recommend to use the Berkeley Packet Filter.

"Certain USB WiFi dongles do not transmit beacons at all (mt7610u, rt2800, ath9k, mt7601, rt8812au)" I can't confirm this. All my devices (mt76 and rt2800usb) transmit exactly that packets, hcxdumptool will deliver to the raw socket. Make sure you don't run a virtual interface. Make sure no other tool take access to the device. Make sure you don't use NETLINK. Do not set monitor mode by iw.

In every case, iw use NETLINK:

$ sudo iw --debug dev wlp39s0f3u1u4 set type monitor
-- Debug: Sent Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [NETLINK HEADER] 16 octets
    .nlmsg_len = 36
    .type = 33 <0x21>
    .flags = 5 <REQUEST,ACK>
    .seq = 1616513473
    .port = 1652560205
  [GENERIC NETLINK HEADER] 4 octets
    .cmd = 6
    .version = 0
    .unused = 0
  [PAYLOAD] 16 octets
    08 00 03 00 03 00 00 00 08 00 05 00 06 00 00 00 ................
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [NETLINK HEADER] 16 octets
    .nlmsg_len = 36
    .type = 2 <ERROR>
    .flags = 256 <ROOT>
    .seq = 1616513473
    .port = 1652560205
  [ERRORMSG] 20 octets
    .error = 0 "Erfolg"
  [ORIGINAL MESSAGE] 16 octets
    .nlmsg_len = 16
    .type = 33 <0x21>
    .flags = 5 <REQUEST,ACK>
    .seq = 1616513473
    .port = 1652560205
---------------------------  END NETLINK MESSAGE   ---------------------------

hcxdumptool use ioctl() system calls:

$ sudo hcxdumptool -m wlp39s0f3u1u4
setting interface wlp39s0f3u1u4 to monitor mode

ath9k and rtl8812au are running into several issues: https://github.com/aircrack-ng/rtl8812au/issues https://bugzilla.kernel.org/show_bug.cgi?id=208111 https://bugzilla.kernel.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=REOPENED&field0-0-0=product&field0-0-1=component&field0-0-2=alias&field0-0-3=short_desc&field0-0-4=status_whiteboard&field0-0-5=content&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced&type0-0-0=substring&type0-0-1=substring&type0-0-2=substring&type0-0-3=substring&type0-0-4=substring&type0-0-5=matches&value0-0-0=ath9k&value0-0-1=ath9k&value0-0-2=ath9k&value0-0-3=ath9k&value0-0-4=ath9k&value0-0-5=%22ath9k%22 so I don't use this devices.

Please notice: To avoid to spam a channel, hcxdumptool doesn't transmit BEACONs within a fixed interval. A BEACON is only transmitted if the channel is empty and a packet of a CLIENT was received. It is not possible to awake a CLIENT from deep sleep. Some CLIENTs will only connect to an AP if it is in a pre-defined GPS range. 802.11 is packet oriented. Running more than one radio, they will interfere.

This command line will allow the test CLIENTs to connect to hcxdumptool: $ hcxdumptool -i interface -o test.pcapng --bpfc=protectmacs.bpfc --disable_deauthentication --disable_ap_attacks --active_beacon -c 1 --essidlist=testbeacon.list

or from hcxlaboratory series: https://github.com/ZerBea/wifi_laboratory $ sudo hcxlabgetm2 -i interface -c 1 --bpfc=protectmacs.bpfc The lab series is a little bit more reacitve, a little bit faster and much more aggressive. Make sure you use a less crowded channel for your test. Make sure you protect all devices which are not part of the test.

From my latest laboratory test (mt76 device): EAPOL pairs (best).......................: 60 EAPOL ROGUE pairs........................: 38

EAPOL pairs (best).......................: 59 EAPOL ROGUE pairs........................: 35

EAPOL pairs (best).......................: 61 EAPOL ROGUE pairs........................: 34

AP-LESS (ROGUE) attack is working as expected. More than a half of the EAPOL messages are requested by hcxlabtool series, while the remaining ones are EAPOL messages from regular APs.

[ZerBea]

Regarding your head line: ESSID broadcast slow That behavior is intended, because hcxdumptool is not hostapd! We do not transmit a BEACON every 100ms like a normal ACCESS POINT. It is important to understand that we can't do this, because if we simulate e.g. 10 different APs and every AP send a BEACON every 100ms, the channel is completely busy by our BEACONs. We only transmit a BEACON, if

• the channel is empty and
• we have time and
• we received a request of a CLIENT.

This is the main part where we decide to transmit a BEACON: https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L5796

[ZerBea]

For your test, use the BPF code to protect all devices (APs and CLIENTs) that are not participating your test. Now hcxdumptool will respond to all remaining requests. That include requests from randomized MACs, too.

[ZerBea]

To understand, what is going on on the RF (Radio Frequency) channel I recommend to read some background information about:

• signal propagation problems
• collisions on the wireless media
• hidden node problem
• admission control
• OFDM (and its guard interval)
• PLCP header

If we want to ignore this mechanisms, it is mandatory to patch the firmware to allow that.

[uniformsierra]

Thankyou for your informative replies. I think I have missunderstood how this tool works, so thank you for your explanation.

I want to stimulate clients from known SSIDs to get M2. I can see hcxdumptool sending various packets out and recovering M1M2ROGUE information for other devices, but it ignores broadcast probes from my target client that I can see the client is sending out (Samsung J1, Android 5.1.1).

I thought that --essidlist did a few things; 1) continuous broadcast beacons from essid list, hoping to stimulate passive scanners 2) responded to any/all broadcast probes with responses from essid list

I understand Is there/should there be a mode which behaves like I think?

[ZerBea]

The following criteria must be met to let hcxdumptool response: CLIENT must transmit an ESSID (undirected or directed PROBEREQUST with ESSID or ASSOCIATIONREQUEST or REASSOCIATIONREQUEST) for which he want to do the AUTHENTICATION. CLIENT must transmit WPA or RSN field within the PROBEREQUEST (we only respond to CLIENTs from which we can expect a PMKID or an EAPOL M2).

In other words: If the CLIENT doesn't request a WPA1/WPA2/WPA2 key version 3 AUTHENTICATION for an ESSID, we do not respond.

Within our BEACON we inform all CLIENTs about our time interval: capap->beaconintervall = BEACONINTERVALL; Now the CLIENT will know, when to expect the next BEACON.

To answer your question: "continuous broadcast beacons from essid list, hoping to stimulate passive scanners" no, only a few ones to avoid spamming the channel

"responded to any/all broadcast probes with responses from essid list" no, only to WPA1/2/2kv3 requests for a given ESSID

BTW: If you discover a way to awake a CLIENT from deep sleep, please let me know. I'll add it immediately to hcxdumptool. Previous attempts (they don't fool latest Apple/Android/WINDOWs and LINUX CLIENTs any longer):

• transmit Boardcast BEACON with wildcard ESSID
• transmit BEACON with ESSID
• transmit "self" ACK

[uniformsierra]

OK, i do some tests. I am not a coder, so I cannot adjust behaviour as I would like, so have improvised.

My client = Samsung J1, Android 5.1.1. I have assosciated it to an AP, then powered the AP off. I observe the client making broadcast probe requests (dest bssid ff:ff:ff:ff:ff:ff) with no ESSID info inside. hcxdumptool ignores this and does not respond. From what you say, this is as we expect.

I take my hcxdumptool radio (mt7610) and desensitise it to noise. I flash an esp8266 with a 'beacon spammer' programmed to my AP SSID (with WPA2 flags and random generated MAC) and move it out of range of the hcxdumptool radio. I take client and place it between both. It can 'see' the beacon spammer and the hcxdumptool radio can 'see' client. Now I turn client wifi on, hcxdumptool sees and association attempt with the esp so hcxdumptool responds and i capture M2. I confirm this is correct data using hcxpcapngtool > hcxhashtool > hashcat.

Need more tests, but if this works why cannot we broadcast more beacons for known SSIDs?

Also I now know to use bpf filters but for now am not using. I set --stop_client_m2_attacks=4 to stop noise on the few close clients but noticed hcxdumptool still sending AP packets for these clients. Not sure if this is right?

[ZerBea]

"Need more tests, but if this works why cannot we broadcast more beacons for known SSIDs?" We can't do this, because the bandwidth on a channel is limited. Only one station can transmit, all others receive, because we are packet oriented. We can't transmit and receive at the same time (like the combination of an ESP8266 and hcxdumptool). That is coded in the firmware of every device. To ignore this, a patched firmware and driver is mandatory, e.g.: https://github.com/vanhoefm/modwifi The more we transmit, the less we receive.

Please answer yourself this question: ESSID length 1 to 32 characters - we do not know the length. According to 802.11 all characters are allowed - we do not know them (makes 31 to the power of 255) Common BEACON interval is one BEACON/100usec == 10 BEACONS a second The target probes WILDCARD and we don't know the ESSID of the target. We have to transmit every BEACON at least 10 times, to make sure the CLIENT get it correct. We are not alone on the channel. There are BEACONs of other APs and traffic of other APs and CLIENTs on the channel. The device will wait for its (free) time slot, before it transmit. What do you think, how many BEACONS we have to transmit until we hit the matching ESSID to which the CLIENT respond?

At this point hcxdumptool decide to stop BEACONing for this CLIENT and start listening fo new targets.

"...but noticed hcxdumptool still sending AP packets for these clients" Can you please specify this packets (PROBEREQUEST, AUTHENTICATION, ASSOCIATION, EAPOL)? hcxdudmptool will respond to every PROBEREQUEST (regardless of -stop_client_m2_attacks=4), because that is usual AP behavior and not an attack. That is wanted, to awake other CLIENTs on the channel, using the same ESSID. But it should not respond to AUTHENTICATION requests or ASSOCIATIONs requests any longer. If you discovered this, it is a bug.

Please notice, that packets are enqueued by the driver and by the firmware as long as the channel is busy and transmitted only if the channel is free. If we deliver 10 packets via raw socket to the driver, it will take a while until they are going over the air (coded in firmware and driver to avoid spamming a channel).

[ZerBea]

BTW: "I flash an esp8266 with a 'beacon spammer' programmed to my AP SSID " How long will it take for the ESP8266 if you do not program the AP ESSID and instead try all ESSID combinations?

[ZerBea]

"I flash an esp8266 with a 'beacon spammer' programmed to my AP SSID (with WPA2 flags and random generated MAC) and move it out of range of the hcxdumptool radio. I take client and place it between both. It can 'see' the beacon spammer and the hcxdumptool radio can 'see' client. Now I turn client wifi on, hcxdumptool sees and association attempt with the esp so hcxdumptool responds and i capture M2. I confirm this is correct data using hcxpcapngtool > hcxhashtool > hashcat."

Exactly this is hcxdumptool behavior as desrcibed here: https://github.com/ZerBea/hcxdumptool/issues/169#issuecomment-805729091 We have an ESSID, we have a cipher suite request and we have a target. hcxdumptool will attack. If we don't have this, we're trying a few BEACONs. If the CLIENT doesn't respond, we give up.

The main part to calculate the PMK for a NETWORK is an ESSID and a PSK: PMK = PBKDF2 (PSK, ESSID, 4096, 256) If we don't have an ESSID an attack is useless.

[n0w1re]

@ZerBea The thing is that there are always a few ESSIDs that are very common, often depending on location factors, like default network names preset by locally popular router manufacturers or internet providers. Also local institutions, hotspot providers and mobile network carriers use fixed ESSIDs for their APs, often rather using EAP than PSK.

As you pointed out hcxdumptool only reacts on clients at least already probing for APs, so silently scanning for known networks ones won't be seen, even if the ESSID they look for is in our --essidlist. So running a multi-ESSID hostapd with four or more well-known network names gives a significantly higher rate of interacting clients than using the same in hcxdumptool --essidlist. Adding --flood_beacon seems to give a slightly better performance, but not that much. The difference is roughly estimated some tenfold for hostapd compared to hcxdumptool on single highly-frequent ESSIDs.

Very probable that trying to get nearer to the 10 Beacons/s of a real AP as an option would help to get more clients out of their passive state current mobile devices are in most of the time when not connected or in deep-sleep. Maybe we could shorten the Beacon length to a bare minimum and/or use a higher bitrate so the load on the channel would be less?

[ZerBea]

@uniformsierra ,I recommend to read this document, to understand the mechanism of clear channel assessment through channel sensing, which is implemented in every firmware and every driver: https://mentor.ieee.org/802.11/dcn/20/11-20-1782-00-coex-discussion-on-the-sensing-threshold-in-unlicensed-spectrum.docx

@n0w1re , unfortunately, some tags are mandatory: AP capabilities ESSID Supported Rates Channel TIM ERP Extended Supported Rates RSN Information WPA Information Element

Please notice: Transmitting 10 different BEACONs with 100msec interval will make a channel busy! If hcxdumptool transmit a BEACON, the channel is busy for all CLIENTs. By default, we only stay 5 seconds on a channel. One BEACON every 100 msec == 10 BEACONs a second == 50 BEACONs during a single stay time. We can't decrease the BEACON interval, because it is mandatory to listen for CLIENTs during this time.

If we want to transmit 10 different BEACONs, we have to transmit every 10msec a BEACON. Within this 10msec, the CLIENT should be allowed to transmit PROBEREQUESTs, AUTHENTICATIONREQUESTs, ASSOCIATIONREQUESTs and EAPOL MESSAGEs. Additional we have to respond to this requests.

For sure, I can add this BEACONing behavior, but it will result in packet losses. hcxdumptool will become a dinosaur. At this time it is already slower than the laboratory series.

BTW: There is a relationship between bit rate, bandwidth and range, we must take care about! A higher bit rate will reduce the range and increase the bandwidth! That result in a packet loss!

[n0w1re]

@ZerBea At least the WMM/WME, the Extended Capabilities and the Extended Supported Rates elements could be scrapped, as they are not needed for our purpose and AFAIK not mandatory if nothing important is to define there. The only point of the packet should be to broadcast the ESSID.

A higher bitrate of course will shorten the range the Beacons can be seen in, but at a higher packet rate there might be more of a chance of getting one Beacon heard, especially with the scanning client only camping on our channel for a very short time and sender or receiver on the move. My guess would be number of packets beats packet range/robustness in most circumstances.

As I've seen, some commonly used home routers beacon at 6Mbit/s where a packet takes about 456µs for 320+ bytes and some bigger installations (probably small cells) 12Mbit/s around 160µs for 240+ bytes. So a shortened packet at 6MBit might be a good compromise.

But if you are sure that hcxdumptool would not cope with this kind of additional load and would impede its core functions, it might not be worth the work to implement it to test if it gives the suspected gain. Do you assume it is a limit purely by the air interface or also by the cpu power of the portable devices it's mostly run on that cause packet loss?

[ZerBea]

It is easy to modify hcxdumptool to test higher rates: Just change the value from 0x02 (1 MBit) to 0x0c (6MBit) here: https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L226 and see what happens, especially if the CLIENT is far away and/or the working channel is busy and/or the neighbor channels are busy.

[ZerBea]

Unfortunately it is a limit by the radio interface (hardware, firmware and driver) and it is limited to the the channel capacity. The CPU power doesn't matter. Even small devices are able to handle the current ring buffer. But every additional parameter will have a price tag.

BTW: Packet loss means that if we transmit a packet, we can't receive at the same time. All packets on the channel, transmitted by other stations (far away) during our transmission time get lost for us. All stations within our range will not transmit unless the channel is free.

[ZerBea]

To add more BEACONing, there are some open questions, because this will have a huge impact on the other attack vectors: How many different default BEACONs should we transmit? How long should be the BEACON interval between 2 of this BEACONs (usual default is 100ms - we must give CLIENTs a chance to answer - that will not happen if we have no listen interval between the BEACONs)? How long should we the stay time on a channel if we will transmit this BEACONs? Shall we transmit the BEACONs on crowded channels (1,6,11) or on all channels (if we do that on empty channels and wait for a possible response, we will not get PMKIDs or 4way handshakes from other channels)? Should we wait for a response after transmit of the BEACON or can we proceed with other attack vectors?

[ZerBea]

Here is a good explanation (much better than I can explain it): "The 802.11 family consists of a series of half-duplex over-the-air modulation techniques that use the same basic protocol. The 802.11 protocol family employs carrier-sense multiple access with collision avoidance whereby equipment listens to a channel for other users (including non 802.11 users) before transmitting each packet. " https://en.wikipedia.org/wiki/IEEE_802.11

[ZerBea]

I added a commit to wifi_laboratory to test that kind of BEACONing. https://github.com/ZerBea/wifi_laboratory/commit/6070cb8566a7ddcc62341d6edadc77a0d073403f

Implementation: We decrease the FDNSECTIMER to 10ms If the channel is empty, we transmit the first BEACON from rgaplist. If the channel is still empty after 10ms, we transmit rank 2 of the list. If the channel is still empty after 10ms, we transmit rank 3 of the list. If we reach rank rank 10, we set the counter to rank 0 and start again. If the ring buffer is empty shortly after start, we will transmit wildcard BEACONs.

Please test, how many BEACONs are transmitted in a real world scenario (crowded channel 6). I don't assume, that we can transmit more than 10 different BEACONs with an interval of 10ms each BEACON on such a crowded channel.

[uniformsierra]

Thank you for your replies and continue work. Sorry for my delay reply.

I understand your concerns with BEACON filling air and not allowing a free medium. For my simple, single device tests I didn't mind, but I see others may like this feature too, so we can try harder. https://wlanprofessionals.com/wifi-ssid-overhead-calculator/

I have run more tests with ESP (I like for simple); first to try see what beacon interval is optimal to trigger this 'stimulation reveal' - it is complex test due to various factors but seem around 30ms is good balance between free medium and chances of hitting the scanning window of CLIENTs (I try use prime number interval ~31). This tested in a channel with approx 5% total utilizaiton at the time.

More tests needed but it seem after sending broadcast/blank probes, Android 10 will send a directed/essid probe, using the client's 'random mac for that network' within 3 minutes, while in range of the ESP broadcasting only SSID with ~31ms interval. Still true even rolling ESP MAC and channel. This may be good for others to know.

For one known ESSID (like my test); can we be always quiet and only respond to any/all proberq with single known SSID, then continue to capture M2? This will make testing clients much easier. For multiple known; if we have 10 known ESSIDs we setup 10 radios on different channels. Each sends out one SSID at ~30ms?

Thank you for FDNSECTIMER, I will use this and the higher rate change to test more things. I'm also thinking bandsteering could help and perhaps also the way WPA3 OWE uses channel passing could be an option to keep medium free. These may need more than one radio.

[ZerBea]

I think I found a solution. ESSID interval is 10msec, now. We hold all ESSIDs from the ESSID list for 4 hours. Please get latest hcxlabtool. You don't need the ESP any longer. hcxlabtool will get the ESSIDs from your list. https://github.com/ZerBea/wifi_laboratory create an ESSID list that contain your target ESSID(s). run make and test it, running this commands: $ sudo ./hcxlabgetm2 -i interface -essidlist=your_essidlist -c 3 Does the ANDROID CLIENT try to AUTHENTICATE to hcxlabtool? How long does it take until we receive an M2 of the target?

"For multiple known; if we have 10 known ESSIDs we setup 10 radios on different channels. Each sends out one SSID at ~30ms?" That doesn't work, because the channels overlap. We can use 3 channels, only (1,6,11) to avoid interfering each other.

BTW: Make will create 5 tools. Each has a special feature: hcxlabdumpall -> store entire traffic to dump file hcxlabgetm2 -> attack CLIENTs only hcxlabgetm1 -> attack APs only hcxlabgetm1234 -> attack connections between APs and CLIENTs hcxlabgetmall -> do all attacks

That is much (much) faster than doing this like the hcxdumptool way (by options and internal lists).

[uniformsierra]

yes, hcxlabgetm2 works - both clients (android 5.1.1 and 10) have provided m2 (i have verified).

Android 5.1.1 client with broadcast/blank probes communicates with hcxlabgetm2 after about 30 seconds around 26 messages, however this is not enough to crack. Additional messages come after around 45 seconds and these can crack. Using airodump to watch, i see OPN APs start the conversation and can stop hcxlabgetm2 when I see EAPOL captured in airodump.

Android 10 a little different - this takes just over 10 seconds to send over 700 EAPOL frames (as seen by airodump) to hcxlabgetm2, which are crackable.

[ZerBea]

Ok, thanks for your test. Glad to hear that it works. You are an experienced user, so I recommend to use the lab series instead of hcxdumptool. Just remove "-ggdb -fsanitize=address" from the Makefile. and run make install, to get benefit of the lab series. For headless usage, remove -DSTATUSOUT, too.

[ZerBea]

hcxdumptool is designed for users who prefer a beautiful status display more than fast attacks: function follows form.

hcxlab series is designed for experienced users: form follows function.

[uniformsierra]

ok i will continue to use hcxlab, thankyou again for excellent works.

[ZerBea]

Unfortunately it is nearly infeasible to add this feature to hcxdumptool. To perform this attack vector (and several others), it is mandatory to compile it directly into the tool. Maybe by next refactoring of hcxdumptool, but that will take a while.

[ZerBea]

BTW: I increased the ring buffer to 2048 entries. I think it is feasible to do more, if you need: https://github.com/ZerBea/wifi_laboratory/blob/main/include/hcxlabtool.h#L55

[ZerBea]

Some additional info: We stop the attack, if we have received 10 M2: https://github.com/ZerBea/wifi_laboratory/blob/main/hcxlabtool.c#L755 and do not longer accept AUTHENTICATIONs from that CLIENT: https://github.com/ZerBea/wifi_laboratory/blob/main/hcxlabtool.c#L1452

Unfortunately some devices don't accept this and transmit several more M2s. We can't prevent this behavior.

[uniformsierra]

This is excellent ideas - multiple and same time testing can happen now without big mess. Great idea.

[ZerBea]

That was the reason to code the lab series. Nearly everything can be compiled directly into the tools. We have hcxdumptool as part of the distributions and the lab series to open doors to new and enriching possibilities.

[ZerBea]

Improved hcxdumptool BEACONing (based on the knowledge of hcxlabtool) by latest commit: https://github.com/ZerBea/hcxdumptool/commit/27da40beca656309f2dfee1a83ba3dbec4628378

If the CLIENT is in essidlist, it will try to connect to us: $ sudo hcxdumptool -i interface --enable_status=1 --essidlist=essidlist --active_beacon --disable_ap_attacks -c 5