A GTK4 desktop GUI for Linux that puts the wireless assessment workflow in one place. 57 modules: Wi-Fi, Bluetooth, RF, router side, and network MITM. Every module is a standalone shell script; the GUI is a view over them, so you can call any of them directly and script them.
Why it's differentMost wireless tooling is deep in one lane. Aircrack-ng is Wi-Fi. Bettercap is network MITM. Bluetooth tooling is Bluetooth. An assessment means five tools, five config files, and no shared view of anything.
To be straight about it: this is partly a wrapper. Responder, mitm6, mdk4, hcxdumptool and hostapd are underneath, and I'm not pretending otherwise. What I built is the integration, the hardware detection, and the reporting. And there are a handful of things here you won't find in the usual tools at all.
Some of what's in itWi-Fi: Recon, deauth, handshake and PMKID capture, WPS including Pixie Dust, WPA3 and Dragonblood, WEP, Enterprise 802.1X, PMF bypass, KRACK, FragAttacks, Evil Twin, Karma, beacon and auth floods, Wi-Fi Direct, client isolation testing, SSID overflow.
MITM and credentials: Responder, mitm6, ntlmrelayx, Router Advertisement poisoning, ARP MITM, rogue DHCP, USB Ethernet MITM.
Router side: TR-064, HNAP, UPnP, SNMP, DNS rebinding, web UI, recovery TFTP and UART.
Plus Bluetooth, sub-GHz, LoRa, Zigbee, Thread, NFC, drone remote ID, and the analysis side: capture analysis, fingerprinting, geolocation, wordlists, live traffic, passive IDS.
Things you won't find elsewhereFrame-level jamming. Not a deauth flood — actual reactive jamming, carrier-sense manipulation and FCS corruption, driven through a modified Atheros driver. This needed porting modwifi to kernel 7.0, which is why almost nobody ships it. You can jam one access point's beacons while leaving the rest of the channel alone.
SSID overflow with real IE-length control. Beacons whose SSID exceeds the 32-byte limit, carrying injection payloads in the same bytes. The published ESP32 tools can't do this — WiFi.softAP() truncates at 32, so they all list it as future work. Building the frame by hand means the length byte is independent of the content, which is the case that actually matters.
Router Advertisement poisoning. mitm6 does DHCPv6 and deliberately skips Router Advertisements, so a network with no DHCPv6 in play is untouched by it. This does RA/SLAAC: one forged packet reconfigures every host's default route and resolver.
Client isolation bypass. Gateway bouncing, port stealing, broadcast reflection, plus an inter-NIC relay to hold the bypass open. From the AirSnitch work (NDSS'26).
USB Ethernet MITM. RNDIS-based, PoisonTap-style, over a USB port.
Router recovery and console. Recovery-mode TFTP, UART/U-Boot guidance, offline flash image parsing. Unusual to find in a wireless tool.
Multi-node capture. Drive a fleet of remote nodes — Pi, VM, laptop — and correlate what they see.
The one I'd argue matters most: it's built to tell you when it failed. Every module has a --selftest. Hardware-gated modules name the hardware they're missing instead of returning an empty result. A module that reports OK while the target is untouched is worse than one that fails loudly, and that's the bug class I'm hunting.
Nothing here is needed to build or launch the app. But most of it won't do anything without at least one of these, so it's worth knowing what each piece buys you.
Essential — a Wi-Fi adapter that can inject. Atheros AR9271 is what I built and tested against: TP-Link WN722N v1, Alfa AWUS036NHA, Technoethical N150.
Intel adapters will not work for anything involving injection. The app detects iwlwifi and tells you so instead of failing quietly, but it will refuse. Monitor mode alone isn't enough. Without one of these, you can browse the interface and read captures, and that's about it.
A second Wi-Fi adapter — for client isolation testing. That module needs two interfaces associated at the same time, one acting as the victim and one as the attacker. Any managed-capable card works as the second; it doesn't need to inject.
Bluetooth adapter — for the eight Bluetooth modules. Classic and BLE recon, SSP, advertising forgery, fuzzing, mesh, tracker hunting, HID injection. A recent adapter is preferable; some of the older CSR dongles won't pass BLE advertising data through.
802.15.4 radio — for Zigbee and Thread. A CC2531, CC2652 or nRF52840 dongle, flashed with sniffing firmware. One radio covers both, because Thread and Zigbee share the same physical layer — they're different stacks on the same silicon. This is also the hardware that gets you toward Matter.
SDR — for RF spectrum, sub-GHz, LoRa and drone Remote ID. An RTL-SDR is the cheap entry point and covers sub-GHz receive. A HackRF adds 2.4 GHz coverage and transmit, which you need for anything that isn't passive. Note that sub-GHz transmission — replay attacks and the like — needs TX-capable hardware; an RTL-SDR can only listen.
NFC reader/writer — for the NFC/RFID module. A PN532 or ACR122U handles NDEF and MIFARE work. A Proxmark3 if you're going past the tag structure analysis into proper card research.
USB-to-UART adapter — for router console access. CP2102, CH340 or FTDI. This is what gets you a U-Boot prompt on a router's serial header when recovery mode won't hand it to you. Worth having a set of dupont leads and, for board-level work, SOIC clips.
GPS receiver — for wardriving. The wardriving module drives Kismet with gpsd, so any receiver gpsd supports works. USB or Bluetooth both fine.
What hasn't been tested yetBluetooth, all of it except recon. I don't have an adapter, so none of those eight modules has run against real hardware. The code is written and reviewed, but that's not the same claim as working.
Same for sub-GHz, LoRa, Zigbee, NFC and drone remote ID. No SDR, no radio hardware here.
Thread does offline pcap analysis fine; live scanning is untested, no 802.15.4 radio.
Jamming needs a modified driver and firmware that isn't shipped. It'll tell you it can't find the driver. That's correct behaviour, not a bug.
What I actually want from testersRun it, and tell me:
Does it start on your distro? GTK4 version, Wayland vs X11, missing dependencies.
Does it get your adapter right? Wrong hardware detection is worse than none.
Modules that report OK but did nothing? This is the one I care about most.
Anything that crashed or wedged your adapter.
And the most useful thing: tools/diag.sh --collect produces a report with distro, kernel, GTK version, adapter and driver, injection capability, dependencies, and per-module selftest results. It replaces MACs and SSIDs with placeholders and strips secrets before writing anything, and it never touches the loot folder. So you can paste it without leaking your neighbours' network names, which I'm not going to ask you to do.
[link] [comments]