hashcat Forum

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)?

(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?

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!

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....

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??

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.

Hi hulley.
Now you can see hcxtools in action, twice:

1)
wpa-sec moved to hashcat >= 4.0.1 and hcxtools >= 4.0.1
The python client (help_crack.py) is updated to version (0.9.0 / 10 Feb 2018)
BTW: you can help retrieving new PSKs, contributing GPU power (simple run the python client)
if you add the following line to help_crack.py (line 405):
os.system('cat help_crack.net >> wpasec_new.hccapx')
you will get a local copy of every network hashcat is working on.

2) somebody made a video of "Automated Wifi Attacks With HCXTOOLS"
https://www.youtube.com/watch?v=3-IhrlBpoQg

[quote="ZerBea" pid='39238' dateline='1518306361']
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_out, packet, packetsize) to receive a packet and
ioctl(fd_main, SIOCSIWFREQ, &pwrq) to control (in this case switch channel)..........

------------------------------------
Hi ZerBea.

I was testing an internal wifi device: Bus 002 Device 003: ID 174f:1107 Syntek, driver:b43, os/kernel:4.14.0-kali3-686-pae. Everything work fine with wlandump-ng, but not hcxdumptool. Thanks for the info! It's too bad about the 'RTL88xxAU based device' I was about to buy one, just because the RTL88xxAU-chips have everything wifi. I guess I'll just have to get a RT3070 Device instead!

Hi hulley.
Well, the chipsets BCM4311, BCM4312 or BCM4321 require a little more "action" .
As far as I know, they use opensysfs, but I'm not shure. I need some more infos about that interface:

Please run:
$ ls -1 /sys/class/net | grep ^wl

That should give you something like this (wlan interface list):
wlp36s0f3u4u1u3
wlan0
wlan1
...

Then run
$ ls /sys/class/net/wlxxxx/device/inject_nofcs
(where wlxxxx is the b43 interface)

and post the output (if there is an output...)

(02-12-2018, 11:22 PM)ZerBea Wrote: [ -> ]Hi hulley.
Well, the chipsets BCM4311, BCM4312 or BCM4321 require a little more "action" .
As far as I know, they use opensysfs, but I'm not shure. I need some more infos about that interface:

Please run:
$ ls -1 /sys/class/net | grep ^wl

That should give you something like this (wlan interface list):
wlp36s0f3u4u1u3
wlan0
wlan1
...

Then run
$ ls /sys/class/net/wlxxxx/device/inject_nofcs
(where wlxxxx is the b43 interface)

and post the output (if there is an output...)

--------------
Hi ZerBea.
The info:

# ls -1 /sys/class/net | grep ^wl
wlan0
#  ls /sys/class/net/wlan0/device/inject_nofcs
ls: cannot access '/sys/class/net/wlan0/device/inject_nofcs': No such file or directory

I physically go to the dir, /sys/class/net/wlan0/device/ 'inject_nofcs' No such file or directory

When I get the chance I will test your tools with Arch, I note you recommended Arch.