hcxtools - solution for capturing wlan traffic and conversion to hashcat formats
(11-17-2022, 01:43 PM)ZerBea Wrote: I suggest to do some tests running two terminals (attached screenshot).
It is important to start the CLIENT first
(...)

Hey, sorry for the late feedback. After your post I quite 'rebuild' my whole workflow and done a lot of scripting to automate things. Got a bit carried away =D
Tested a 2x2 terminal > one server + three clients > Started the clients first, then server. > One client connected, the other ones didn't.
A test with two servers (127.0.0.1 & 127.0.1.1) and one client each went fine, tho.
But since this device runs mainly Realtek and one Atheros, I didn't wanted to invest much energy and time into it and rather wait til my new Mediateks arrive (even tho one 8812AU is a real beast, but lack of ioctl and endless tinkering with drivers is pretty annoying...). So I ran 4 instances of hcxdump in a 2x2 with one iface --active_beacon. Had pretty good results, even with the shit-chips.

So, I was playing around with some filtering (post-hcxdumptool, since I don't filter on the run ATM, even though the BPF works great!) to feed my --mac-skiplist. Doing it like this, to keep the unfiltered list separate:

Code:
hcxpcapngtool --log=${HCXPRFX}.hcxlog --max-essids=2 --csv=${HCXPRFX}.csv --prefix=${HCXPRFX} ${CAPDIR}/* # TODO Check
hcxhashtool -i ${HCXPRFX}.22000 --mac-skiplist=${HCXSKIP} -o ${HASH}

What I was wondering when looking at my combined logs from 4 ifaces:

Code:
❯ grep "ROGUE)..." merged.log | awk '{ print $3,$4 }'
(ROGUE)......: 586ed6c672e4
(ROGUE)......: 586ed6c672e5
(ROGUE)......: 586ed6c672e6
  fcc233d77153
(ROGUE)......: 586ed6c672e4
(ROGUE)......: 586ed6c672e5
(ROGUE)......: 586ed6c672e6
  fcc233d77153
(ROGUE)......: 586ed6c672e4
(ROGUE)......: 586ed6c672e5
(ROGUE)......: 586ed6c672e6
  fcc233d77153
(ROGUE)......: 8c84015cfa22
(ROGUE)......: 8c84015cfa23
(ROGUE)......: 8c84015cfa24
  c8aaccfa512e

Yeah, spot the Atheros! =D
Could they interfere with eachother somehow?
And how are the "random" macs generated? Was glancing through the source but couldn't find anything. (Not that I'm good at C anyway...)
Every day I'm learning something new <3
Reply
The random values are generated here:
seed = Raspberry Serialnumber + time:
https://github.com/ZerBea/hcxdumptool/bl...ol.c#L8219

MAC AP
https://github.com/ZerBea/hcxdumptool/bl...ol.c#L8234

MAC CLIENT
https://github.com/ZerBea/hcxdumptool/bl...ol.c#L8262

ANONCE
https://github.com/ZerBea/hcxdumptool/bl...ol.c#L8273
SNONCE
https://github.com/ZerBea/hcxdumptool/bl...ol.c#L8274

REPLAY COUNT
https://github.com/ZerBea/hcxdumptool/bl...ol.c#L8276

Yes, the interfaces interfere:
from wifi_laboratory:
https://github.com/ZerBea/wifi_laboratory
Code:
Lessons learned (to be continued)
a beautiful status output make the attack tool slow and sluggish.
too many features make the attack tool slow and sluggish.
response time behavior becomes very bad on big ringbuffers.
transmitting too many packets make a channel busy.
a Raspberry Pi is not able to handle more than one interface at the same time.
pselect doesn't like to be interrupted by another timer.
active monitor mode (enabled by radiotap header) is mandatatory on AUTHENTICATION, ASSOCIATION and EAPOL frames!
it is mandatory to ACK NULL and ACTION frames within a 4way handshake!
setting a short preamble in radiotap header is ignored on tx.
entire AUTHENTICATION process should be done running a data rate of 1.0 Mb/s.
there are (much) better ways than injecting stupid DEAUTHENTICATION frames to disconnect a CLIENT.
the most useful frame is an EAPOL M2 frame!

About Realtek:
There are too many third party drivers on git, because most of the stock drivers do not support monitor mode or packet injection. Some of them are compiled with full ioctl() support, while other are compiled with NETLINK only.
https://duckduckgo.com/?q=git+Realtek+wl...&t=ffab&ia

My reference drivers are mt76 and rt2x00. They are well maintained and they are working out of the box while other drivers ones do not:
https://github.com/ZerBea/hcxdumptool/issues/230
https://github.com/ZerBea/hcxdumptool/issues/234

NETLINK has a huge overhead and is pretty asynchronous:
https://www.quora.com/What-are-the-diffe...ls?share=1
fast attacks against multiple targets -> ioctl() system calls
stream nice kitten video via WiFi -> NETLINK messages
If the driver is compiled to use NETLINK only, hcxdumptool will not work on it.
Reply
For testing purpose I added support of more than on interface to hcxlabtool - and removed it again due to heavy interfering:
https://github.com/ZerBea/wifi_laborator...cc840871b6
One interface = excellent results
Two interfaces close together (< 10 m) - interference disaster
Reply
Much obliged!
I wanted to have a look at your "skeleton" for quite some time. I'm not sure if I have enough skill / knowledge to understand the results, but damn, I'm curious.

Yeah, I'm pretty fed up with realtek. Waiting for delivery of a mt76 / rt5370. Should be a much smoother experience, right?

Edit: I've got a question, that doesn't fit in the forum, and I don't want (and can't) annoy you via PM.
Shoot me a pm, if you got a min and feel like it, yea?
Reply
Just send an email notification via hashcat forum to which I can respond or get teh mail addr from here:
https://api.github.com/users/ZerBea/events/public
Reply