Airgorah: a GTK4 WiFi audit tool that keeps the GUI unprivileged

The problem Airgorah solves, and for whom

Wireless auditing on Linux has traditionally meant memorising aircrack-ng command sequences: putting the interface into monitor mode, scanning, targeting a BSSID, sending deauthentication frames, waiting for a handshake, then running a cracking step against a wordlist. Each step is a separate binary with its own flags, and the state lives in your shell history. Airgorah puts those steps behind a GTK4 desktop interface. The README describes it as software that "can capture nearby WiFi traffic, discover clients connected to access points, perform deauthentication attacks, capture handshakes, and crack the password of access points." That list is the product scope.

The audience is narrow by construction. The project states it only works on Linux, and the legal notice says it is designed for testing and discovering flaws in networks you own, adding that attacking networks you do not own is illegal in almost all countries. So the intended user is a network owner, a consultant with written authorisation, or a lab operator, working from a Linux desktop with a card that supports monitor mode and packet injection. If any of those three conditions is missing, Airgorah is not the right starting point.

How the unprivileged GUI and the polkit agent split the work

The architecture is the most interesting decision in the project. The README states the graphical interface runs as a normal user, so it works under both X11 and Wayland, and that when a privileged operation is needed it launches a small privileged agent called airgorah-agent via polkit, which prompts for authentication once. That is a deliberate separation: the window you look at holds no elevated rights, and the part that touches the wireless interface is a separate process started through the system's authentication framework.

The Cargo workspace mirrors that split. Cargo.toml lists three members: crates/common, crates/agent and crates/gui, with a shared airgorah-common crate at version 0.8.1. So there is a common library holding what both sides need, an agent binary, and the GTK4 front end. The workspace pins edition 2024 and depends on nix with the signal, socket, user and fs features, which is consistent with an agent that manipulates interfaces and users at a low level rather than shelling out for everything.

The practical consequence is a single authentication prompt rather than a password prompt per action. It also means the attack logic lives in a process you did not launch directly, which is worth knowing when you are reading logs or trying to work out which component failed.

Installing Airgorah and running a first capture

The README does not carry install commands. It points to a wiki page at github.com/martin-olivier/airgorah/wiki/Installation, and the badges show a crates.io package and an AUR package, so a Rust toolchain install and an Arch package are the two routes the repository advertises. The README also links a separate Usage wiki page for operating the application. Because no command lines for either route are given on the front page, the honest position is that installation is documented on the wiki, not in the repository readme.

What the repository does show is how the project packages itself. The Dockerfile builds the workspace and then uses fpm to produce three package formats, with the runtime dependencies declared per format:

ENV DEBIAN_DEPS="--depends libgtk-4-1 --depends dbus-x11 --depends iproute2 --depends crunch --deb-recommends aircrack-ng"
ENV REDHAT_DEPS="--depends gtk4-devel --depends dbus-x11 --depends iproute --rpm-tag Recommends:aircrack-ng"
ENV ARCHLINUX_DEPS="--depends gtk4 --depends dbus --depends iproute2 --pacman-optional-depends aircrack-ng"

Read those lines carefully, because they tell you what a working install looks like. GTK4 and a D-Bus session are hard dependencies on every format. iproute2 (or iproute on RPM distributions) is a hard dependency, which fits an application that manages wireless interfaces. aircrack-ng is only recommended or optional, and crunch appears only in the Debian list. The build stage itself installs libgtk-4-dev, libglib2.0-dev, ruby, rpm and libarchive-tools, but that is the packaging image, not your machine.

For a first real use, the sequence the README implies is: install from the wiki instructions, plug in a card that supports monitor mode and packet injection, launch the GUI as your normal user, and accept the single polkit prompt when the agent needs elevated rights. From there the interface exposes scanning, client discovery, deauthentication, handshake capture and cracking. The wiki Usage page is the reference for the actual controls.

Hardware and platform constraints you cannot work around

The requirements section is short and unforgiving. Airgorah only works on Linux. You need a wireless network card that supports monitor mode and packet injection. Neither condition is negotiable through configuration, and neither is something the application can detect its way out of: without monitor mode there is no traffic to capture, and without injection there is no deauthentication step.

This is where most first attempts fail. Laptop-integrated wireless chipsets frequently ship drivers that do not expose monitor mode, and virtual machines generally cannot pass through a wireless interface in a state that supports injection. A USB adapter with a known-good chipset is the usual answer, but that is general wireless-auditing knowledge rather than something the README documents.

There is a second constraint that is easy to miss. The split architecture depends on polkit and on a D-Bus session, both of which appear as hard package dependencies. On a minimal window manager setup or a stripped-down distribution without a working polkit agent, the GUI may start while the privileged agent cannot be authorised, and the README does not describe a fallback path for that case. It also does not document what happens when polkit is absent or when authentication is declined.

Where aircrack-ng alone is the better choice

The obvious alternative is the aircrack-ng suite itself, and the difference is not capability but control flow. aircrack-ng is a set of command line tools: you compose the pipeline, you decide when to switch an interface into monitor mode, you choose the wordlist, and you script the whole thing. Airgorah packages the same class of operations behind a GTK4 interface and a privileged agent, which is why the packaging metadata treats aircrack-ng as a recommendation rather than a requirement.

The trade-off runs in both directions. A graphical tool is easier to drive interactively and harder to automate: there is no documented headless mode and no CLI surface described in the repository, so anything you want to run unattended, repeat on a schedule, or embed in a larger test harness is better served by the command line tools. Conversely, if you are doing one-off audits on your own equipment and you would rather not keep the flag syntax in your head, the GUI removes that friction. The Dockerfile's dependency lines are a useful signal here: the project itself expects aircrack-ng to be present on many systems, which suggests it is not trying to replace the suite so much as wrap part of the workflow.

Licence, packaging and what upgrades cost

Airgorah is released under the MIT licence, stated both in the README and in the workspace package metadata in Cargo.toml. MIT is permissive: it allows use, modification and redistribution with the licence text retained. That matters if you intend to ship a modified build internally, though the legal notice in the README about attacking networks you do not own sits outside the licence and is not something a licence grant can waive. Nothing here is legal advice, and the jurisdiction you operate in determines what you may lawfully test.

Upgrade cost looks low from the release history. The project published v0.8.0 on 2026-08-15 and v0.8.1 the next day, with the previous release, v0.7.4, back on 2025-09-04. The workspace version in Cargo.toml is 0.8.1, matching the latest release. The last push to the repository was on 2026-09-19. Because the version is still 0.x, the maintainer has not promised API stability, and the three-crate workspace means a change in airgorah-common can ripple into both the agent and the GUI.

For packaged installs, the dependencies declared in the Dockerfile are the upgrade surface: a new GTK4 or iproute2 requirement lands in the package metadata and gets resolved by your package manager. For a source build you are compiling a GTK4 application and an agent against a pinned toolchain in the packaging image (rust:1.94.1-slim-bookworm), so a Rust and system-library upgrade is part of the cost. The README does not document rollback or downgrade steps, so pin the version you validated if you need to reproduce a result.

Editorial conclusion

Airgorah suits Linux users who own the networks they are auditing and want a graphical workflow instead of assembling aircrack-ng commands by hand. It is the wrong tool on Windows or macOS, on cards without monitor mode and packet injection, and for anyone without a lawful reason to test the target. Before adopting it, confirm the card supports monitor mode and packet injection, check the polkit prompt appears once when the agent starts, and read the wiki installation page for your distribution.

Frequently asked questions

Official sources

1. License: MIT
2. martin-olivier/airgorah on GitHub
3. Project website
4. README
5. Releases