hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - Printable Version +- hashcat Forum (https://hashcat.net/forum) +-- Forum: Misc (https://hashcat.net/forum/forum-15.html) +--- Forum: User Contributions (https://hashcat.net/forum/forum-25.html) +--- Thread: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats (/thread-6661.html) |
RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - Runa - 11-29-2022 (11-17-2022, 01:43 PM)ZerBea Wrote: I suggest to do some tests running two terminals (attached screenshot). 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 What I was wondering when looking at my combined logs from 4 ifaces: Code: ❯ grep "ROGUE)..." merged.log | awk '{ print $3,$4 }' 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 RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ZerBea - 11-29-2022 The random values are generated here: seed = Raspberry Serialnumber + time: https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L8219 MAC AP https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L8234 MAC CLIENT https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L8262 ANONCE https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L8273 SNONCE https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L8274 REPLAY COUNT https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L8276 Yes, the interfaces interfere: from wifi_laboratory: https://github.com/ZerBea/wifi_laboratory Code: Lessons learned (to be continued) 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+wlan+driver&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-differences-between-netlink-sockets-and-ioctl-calls?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. RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ZerBea - 11-29-2022 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_laboratory/commit/ef265f8e6416f389ca7d034105e07dcc840871b6 One interface = excellent results Two interfaces close together (< 10 m) - interference disaster RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - Runa - 11-29-2022 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? RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ZerBea - 12-02-2022 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 RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - airhead - 12-20-2022 (11-29-2022, 06:15 PM)ZerBea Wrote: For testing purpose I added support of more than on interface to hcxlabtool - and removed it again due to heavy interfering: Would interference still exist if multiple adapters, with each operated and listened to a single channel while operating independently in their own "screen" sessions? RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ZerBea - 12-20-2022 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/what-happens-when-wifi-channels-overlap Additional you have to make sure that the interfaces are shielded against HF-radiation from each other. RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - airhead - 12-21-2022 (12-20-2022, 10:23 PM)ZerBea Wrote: Yes. Due to channel overlapping (e.g. on 2.4 GHZ) you can use only three active interfaces at the same time: 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. RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ZerBea - 12-21-2022 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 RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - dork4541 - 09-02-2023 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. |