hcxtools - solution for capturing wlan traffic and conversion to hashcat formats
Oh, you are right.
Think about auto generating BFP of already captured nets as additional output of wlandump - it would be nice idea.
If it will not be added to your code, I'll probably write python or bash script wrapping it and auto-skipping "done" networks.

Also I think, you should consider adding something similar to this "-E <digit>: stop deauthentications and disassociations if xx complete handshakes received", but less strict, allowing to stop it when got only part of handshake.
It's problematic when client has not enough power to reach our device, but enough to reach AP and it can hear us.
My log is flooded with at least one device like this and probably I'm a bit DOSing them :/
Reply
Well, you're right too. In this case, wlandump-ng and hcxdumptool will work like an intelligent WiFi jammer!
Normally APs and clients use a retry counter (we do the same). Default value is 6 retries, then the AP or the client should stop. Some of them have a very high retry counter value - so your log is flooded. I saw some of them which have an unlimited(!) value.
One single packet from us is enough to to start this process. Right now, an attack stops if we received the matching M2 to our M1. That is more than enough for us, because we get a valid and crackable combination M1M2.

By the way: This is one of the reasons why I didn't recommend a high power WiFi dongle like the ALFAs. It is much, much better to use a common low power device and(!) a high gain external antenna like a panel (>12 dBi) or an omni (> 7dBi). This make shure, that you receive all packets within your transmit range.

Please tell me more about the contence of your flooded log:
Is it flooded with our M1 or the M2 from the client? In both cases we do not DOS.
If the log is flooded with M3 or M4 we're working like an intelligent jammer! In that case the AP is under heavy DOS from his own clients.
Take also a look at the cap file:
If the clients (or the APs) retry bit (in frame control field of mac frame) is set, we can't prevent that behavior - it's an issue of the client (or the AP), even if we stop the attack!
In that case the attacker status display will inform you about this behavior:  (retransmitted)

The tools are designed to be used ‎if you are highly mobile (that's a reason why I like your Android solution) to capture as much M2 as possible. All important packets (we need them to do forensics and client tracking - I do not mean BEACONs, as the information contained therein is much too general) are saved to the capture file. If you take a look into the source from hcxpcaptool you'll see that ‎the analyzed data went in there (new frame header). Same with the PSKs (cracked.txt from wpa-sec). We we strictly follow the "intelligence cycle".  Well, your post (feedpack/feature request) is also a part of this cycle. I'll try to find a solution - but it's still an issue of the client / AP (retry counter value).

For example:
Use a mobile device (raspberry)  and sit down on a main street near of a traffic light.
In the phase of red light you will receive many M2s from the clients in the stopped cars (incl. AndroidCar WiFi systems).
Same on a bus stop or a railway station.
A crowded downtown or a department store will bring you also many M2s.
Collect this M2s and(!) the output of the  -e -u (wlancap2hcx) or -E -I -U options (hcxpcaptool).
We found many PSKs using a rule on this collected data.

It's also important to analyze the contence of the cap file to find more interesting packets (or packets out of protocol).

If you use hcxtools stationary, you must configure the BPF (-F wlandump-ng) or the blacklist (-B hcxpcaptool)
Reply
I'm trying to use it with Samsung Galaxy S4 (without any external wifi or antenna) as a stationary device and don't want to kill internet access to any of my neighbors :/

I need to create BPF for wlandump-ng, but what with keeping disconecting everyone who's I'm not abled to hear while reconnecting? I've got part of handshake and for me it's enough, why still keeping this client disconnecting?

Also is there possibility to channel hop behind all supported (by interface) bands? I only can it make to hop in one band at once (of 3 supported)
Reply
Also I've just spotted problem with hopping:
It's not changing channel if it is 52 or more
Code:
jfltexx:/sdcard/wifi # wlandump-ng -i wlan0 -C 36 -o /sdcard/wifi/cap/ -B -U -D -d -s                                                                                                                                                                                          
start capturing on channel 36 using mac_ap 28ef01cadfe7 (stop with ctrl+c)...
09:12:58  36 <censor> --> ffffffffffff beacon: TP-LINK_5GHz_<censor>
09:12:58  36 <censor> --> ffffffffffff beacon: TP-LINK_5GHz_<censor>
d09:13:10  36 <censor> --> ffffffffffff beacon: TP-LINK_5GHz_<censor>
09:13:11  40 <censor> --> ffffffffffff beacon: TP-LINK_5GHz_<censor>
09:13:12  40 <censor> --> ffffffffffff beacon: TP-LINK_5GHz_<censor>
^Cannel:  52, received packets: 9, pcaperrors: 0              
terminated...
jfltexx:/sdcard/wifi # wlandump-ng -i wlan0 -C 52 -o /sdcard/wifi/cap/ -B -U -D -d -s                                                                                                                                                                                          
start capturing on channel 52 using mac_ap 000e2aa7ec2e (stop with ctrl+c)...
^C
terminated...
jfltexx:/sdcard/wifi # time wlandump-ng -i wlan0 -C 56 -o /sdcard/wifi/cap/ -B -U -D -d -s                                                                                                                                                                                    
start capturing on channel 56 using mac_ap 7ce4aa6ac19f (stop with ctrl+c)...
^C
terminated...
   0m15.11s real     0m00.02s user     0m00.01s system
jfltexx:/sdcard/wifi # time wlandump-ng -i wlan0 -C 60 -o /sdcard/wifi/cap/ -B -U -D -d -s                                                                                                                                                                                    
start capturing on channel 60 using mac_ap 00bb3af5fb7d (stop with ctrl+c)...
^C
terminated...
   0m14.35s real     0m00.00s user     0m00.02s system
jfltexx:/sdcard/wifi # time wlandump-ng -i wlan0 -C 64 -o /sdcard/wifi/cap/ -B -U -D -d -s                                                                                                                                                                                    
start capturing on channel 64 using mac_ap 00259d66eb7d (stop with ctrl+c)...
^C
terminated...
   0m16.97s real     0m00.01s user     0m00.01s system
jfltexx:/sdcard/wifi # time wlandump-ng -i wlan0 -C 100 -o /sdcard/wifi/cap/ -B -U -D -d -s                                                                                                                                                                                    
start capturing on channel 100 using mac_ap 00507909affa (stop with ctrl+c)...
^C
terminated...
   0m09.81s real     0m00.00s user     0m00.02s system
Reply
If you use the -F (wlancap2hcx) or the -B (hcxpcaptool) option and add all mac_addr from your neighbourhood you don't "destroy" their traffic.
Channel hopping capabilites are limited to the driver and, if installed the regulatory domain. If the driver and the domain supports this, it will work (example channel 14).

On channels 52 and above "Indoors/DFS/TPC" is activated by the driver/domain. Otherwise you will jam weather RADAR!


Well, I have a S4 LTE-A (GT-I9506), too - running lineage. Soon as I have time, I'll try it.
Right now, our ultimate ambition is hcxtools integration to wpa-sec (RealEnder still need a week to go - you can watch progress here: https://github.com/RealEnder/dwpa/tree/hcxtools) and full implementation EAP (incl. VPN, TLS, WPS, ... - I'm still waiting for the crackers hashcat and JtR to become ready - didn't see a feature request for EAP on their issues pages, yet).

Did you take a look into your caps (retry bit set)?
Reply
(02-06-2018, 10:25 AM)ZerBea Wrote: If you use the -F (wlancap2hcx) or the -B (hcxpcaptool) option and add all mac_addr from your neighbourhood you don't "destroy" their traffic.

I mean.. I know, but I want it to catch handshake and automagically stop "destroying" :/
I want only to catch unique (I mean 1 certainly valid for one AP or at least AP+Client set) handshakes.
Do I have to restart wlandump every 5 minutes and parse .pcap's myself to generate BPF?

(02-06-2018, 10:25 AM)ZerBea Wrote: Channel hopping capabilities are limited to the driver and, if installed the regulatory domain. If the driver and the domain supports this, it will work (example channel 14).

I mean when I set -C 10, wlandump is hopping only at 1-11 and when -C is eg. 40 its hopping
I would like it to hop at 1-11 + 36-64 + 100-165 as supported by my chipset. Is it possible to set it up like that?

(02-06-2018, 10:25 AM)ZerBea Wrote: On channels 52 and above "Indoors/DFS/TPC" is activated by the driver/domain. Otherwise you will jam weather RADAR!

Yeah, I know. Is that why it stops hopping and doesn't update it's status?
Maybe it should skip that channel or something, but why it just stops doing anything?

(02-06-2018, 10:25 AM)ZerBea Wrote: Well, I have a S4 LTE-A (GT-I9506), too - running lineage. Soon as I have time, I'll try it.

Just `git clone --recursive https://github.com/seemoo-lab/nexmon` and build it from utilities directory.
I'll make pull request today so nexmon will include your tools as git submodule from my repository ;D

PS. Maybe you should enable issues feature to your repository?
Reply
All above requests are implemented in hcxdumptool:
user defined scanlist:
-C <digit>     : comma separated scanlist (1,3,5,7...)
not supported channels are skipped
(BTW: wlandump-ng shows you the last working channel, while it tests the driver for the next channel. It will rest on this channel untill all other channels are tested).

Blacklist:
-B <file>      : blacklist (do not deauthenticate clients from this hosts - format: xxxxxxxxxx)
Attack stops if we retrieved an M2 (but we can't stop the retry attempts from APs and clients).

"Maybe you should enable issues feature to your repository?"
Not yet, because hcxtools are under heavy development

And keep in mind hcxtools are designed to work in a closed system (requirements):
Linux (recommended Arch)
Raspberry Pi (Recommended: A+ = very low power consumption or B+)

and tested drivers:
USB ID 148f:7601 Ralink Technology, Corp. MT7601U Wireless Adapter
USB ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter
USB ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter
USB ID 0bda:8187 Realtek Semiconductor Corp. RTL8187 Wireless Adapter
USB ID 0bda:8189 Realtek Semiconductor Corp. RTL8187B Wireless 802.11g 54Mbps Network Adapter
USB ID 0cf3:9271 Qualcomm Atheros Communications AR9271 802.11n
PCIe RTL8821AE 802.11ac PCIe Wireless Network Adapter

All other combinations of hardware and OS are untested. It may work or it may not work. If it doesn't work, try to adapt it - I'll help if I can.
But feature requests that will slow down this compilation (ARCH & RASPBERRY & tested WiFi dongle) will be ignored on the git branch. I've seen too much OS- (latest was K*A*L*I), driver- or hardware related issues to take care about that.

If you're at home, it should take only a few minutes to retrieve a complete networklist from the neighbourhood (wlanrcascan) and another few minutes to put them into the BPF or the blacklist. You can use different lists for different operation areas. This are my command lines:

mobile or first operation in a new area:
hcxdumptool -i $WLANDEV -o $ARCHIVNAME.pcap -B blacklistown1 -c 1 -t 5 -D

stationary or operation in an allready discovered area:
hcxdumptool -i $WLANDEV -o $ARCHIVNAME.pcap -B blacklistown2 -c 1 -t 15

mobile means not longer then 65 seconds on the same place (13 channels x 5 seconds)
retrieve as many new PSKs/PMKs, identities, usernames, M2s as possible to find weakness in protocol or user behavior.

stationary means the raspberry is running for at least more than one day (usually a week or longer)
because we are on the longterm hunt for PSKs/PMKs and the matching M2 found in wlan traffic from the neighbourhood. That takes time!
Reply
I have been asked to explain this 2 commadlines and the behavior of the tool

hcxdumptool -i <interface> -o dumpfile.pcap -B blacklistown1 -c 1 -t 5 -D
-B inside are the mac_ap we do not want to deauthenticate or disassociate
-t is the rest time on the chanel
-D run deauthentications/disassociations until we receive the first M2 from a connected client - then stop the attack

hcxdumptool -i <interface> -o dumpfile.pcap -B blacklistown1 -c 1 -t 15
The same like above, but we do not send deauthentications or disassociations.
We are waiting for a client that attempt to connect us by proberequest - than we will answer him with a proberesponse.
If the client accept this, first the authentication, second the association und third transmitting of the M1 follows.
If we got the clients M2 we ack this (like a regualar AP) and stop sending M1.
The complete behavior of the client after this point solely and exclusively depend on his retry counter.
If he is stupid, he will try it again, and again, and again - regardless whether we answer or not.



But let's do some stats:
hcxdumptool -i <interface> -o dumpfile.pcap -B blacklistown1 -c 1 -t 5 -s
running for 2 minutes

$ hcxpcaptool -V dumpfile.pcap
start reading from dumpfile.pcap
                                             
summary:                                        
--------
file name..............: ws2.pcap
file type..............: pcap 2.4
network type...........: DLT_IEEE802_11_RADIO (127)
endianess..............: little endian
read errors............: flawless
packets inside.........: 4532
skipped packets........: 0
packets with FCS.......: 0
WDS packets............: 7
beacons................: 2461
probe requests.........: 38
probe responses........: 147
deauthentications......: 2
disassociations........: 1


The biggest jammers are the APs in the neighbourhood......
Every regular AP transmit every 100ms his stupid and useless BEACON.

Deauthentications and disassociations came from a regular AP - not from us.
So, no DOS and no jamming from us....
Reply
Hi ZerBea.

I can't get [hcxdumptool -i wlanX -t 5 -c 1 -o test.cap]  to work, stop after seconds but [wlandump-ng -i wlanX -t 5 -c 1 -o test.cap] work fine. what am I missing, whats is the deference between the new and the old??
Reply
Hi hulley.
The main difference between wlandump-ng an hcxdumptool is libpcap.
wlandump-ng use libpcap and hcxdumptool use raw sockets. Using raw sockets is extreme hardware near.
We open three raw sockets: one for read, one for write and one for control (channel switch) and receive a filedescriptor for each socket. Now we can use a simple
write(fd_out, packet, packetsize) to send a packet,
read(fd_in, packet, packetsize) to receive a packet and
ioctl(fd_main, SIOCSIWFREQ, &pwrq) to control (in this case switch channel).

Right now this code supports this drivers in combination with a kernel >= 4.9:
USB ID 148f:7601 Ralink Technology, Corp. MT7601U Wireless Adapter
USB ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter
USB ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter
USB ID 0bda:8187 Realtek Semiconductor Corp. RTL8187 Wireless Adapter
USB ID 0bda:8189 Realtek Semiconductor Corp. RTL8187B Wireless 802.11g 54Mbps Network Adapter
USB ID 0cf3:9271 Qualcomm Atheros Communications AR9271 802.11n
PCIe RTL8821AE 802.11ac PCIe Wireless Network Adapter

Furthermore hcxdumptool needs full access to the interface.

Maybe we can find a solution:
Which kernel do you use (uname -r)?
Which driver (usb devices: lsusb or lsusb -t or  pci devices: lspci) is used?
How many packets are captured in test.cap
Do we have malformed packets inside?

The following devices don't work:
Bus 005 Device 006: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
Bus 005 Device 007: ID 7392:a812 Edimax AC600 (and every RTL88xxAU based device)
and some of the newer ALFAs (https://github.com/derv82/wifite/issues/112) and intel iwlagn.

Please try some other options:
hcxdumptool -i wlanX -s -T 100000 -t 15 -D -C 1,6,11  -o test.pcap

-s = we want status out
-T = we increase the maximum error value  (and hope hcxdumptool will not stop after a few seconds, so we retrieve some more informations)
-C = we use a scan list (in this case only channels 1,6 and 11 - maybe the driver failed to set/get channel 14 and/or 5GHz channels - if no errors appeared you can use this scanlist -C 1,3,5,7,9,11,2,4,6,8,10,12)
instead of the build in scanlist:
1,36,3,40,5,44,7,48,9,52,11,56,13,60,2,64,4,100,6,104,8,108,10,112,12,116,14,120,1,124,3,128,5,132,7,136,9,140,11,149,13,153,2,157,4,161,6,165,1,11,8,6,10,12,
-D = we run deauthentications, too (stress test for the driver)
-t 60 = we stay a little bit longer on a channel (maybe driver doesn't like ioctl SIOCSIWFREQ to switch channel)

and let's see what happens....

BTW:
we use channelsteps of 2 channels because if we are in the near field of an AP or a client the neighbour channel is under attack, too)

The same difference is between wlancap2hcx (libpcap) and hcxpcaptool (no libpcap).
In addition, hcxpcaptool detects more WLAN/LAN protocols (mainly hash based authentications) than wlancap2hcx. To get benefit of this, use wlandump-ng/hcxpcaptool option -l to capture IP based traffic.
Reply