hcxtools - solution for capturing wlan traffic and conversion to hashcat formats

[Runa]

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

[ZerBea]

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.

[ZerBea]

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

[Runa]

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?

[ZerBea]

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

[airhead]

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

Would interference still exist if multiple adapters, with each operated and listened to a single channel while operating independently in their own "screen" sessions?

[ZerBea]

Yes. Due to channel overlapping (e.g. on 2.4 GHZ) you can use only three active interfaces at the same time:
https://serverfault.com/questions/152920...ls-overlap

Additional you have to make sure that the interfaces are shielded against HF-radiation from each other.

[airhead]

Yes. Due to channel overlapping (e.g. on 2.4 GHZ) you can use only three active interfaces at the same time:
https://serverfault.com/questions/152920...ls-overlap

Additional you have to make sure that the interfaces are shielded against HF-radiation from each other.

That would be true regardless of whether I'm mobile or stationary when using hcxdumptool, yes?. What if I'm using multiple adapters with the '--silent' parameter in a passive listening mode while moving, would there be any issues? I know Kismet can utitlized multiple adapters natively since it's only purpose is to 'observered' and not interact with the targets. I understand at that point, i might as well be using Kimset, given the fact that the two tools serve entirely different purposes. Curiosity..if you will.

[ZerBea]

Running hcxdumptool in passive mode, you can run several instances:

hcxdumptool -i wlan0 --silent -c 1
hcxdumptool -i wlan1 --silent -c 2
...
hcxdumptool -i wlan12 --silent -c 13

Running hcxdumptool in silent mode is not a good idea, because you'll loose many (good) information:
https://github.com/kismetwireless/kismet/issues/419

[dork4541]

ZerBea your tools are awesome! I appreciate your work.

I have a question about the future of the nmea_pcap feature.

To my knowledge there is no accepted standard for how pcap-ng handles GPS data. Do you have any plans to embed GPS data in the pcap-ng output similarly to how Kismet embeds this data https://www.kismetwireless.net/docs/dev/pcapng_gps/, or do you plan to leave this in raw nmea your own custom block? It would be nice to have GPS data in the EPB and use existing scripts to analyze like Kismet data.

Thanks.