Pwnagotchi captures WPA key material from every network in range, and nothing in the repo bounds that

The default target set is every network in range, and the repo defines no scope

Pwnagotchi is a Raspberry Pi that runs bettercap to collect WPA key material, and the README describes two ways of doing it: passively, or by performing authentication and association attacks. What it collects is written into PCAPNG files, in any handshake form hashcat accepts, and it names PMKIDs along with full and half WPA handshakes. The captured material is the point of the device.

So the honest framing has to come before any feature. Nothing in the README, the wiki link, the packaging directories or the build files describes a way to tell the device which networks are permitted. There is no allowlist, no scope file, no dry-run that captures without transmitting, and no documented abort switch. A unit that is powered on in a building is acting on every access point it can hear, by design, and the operator's authorization covers the location rather than the individual networks in it.

That is not an accusation, it is the shape of the tool. Bettercap underneath is a general purpose assessment engine and this is one specific harness around it on dedicated hardware. The practical consequence is that the authorization question is decided by where you put the box, not by configuring the box.

The parasite protocol is a broadcast, so a running unit announces itself

One feature is worth reading closely because it answers a question people ask about this kind of device, which is whether it is visible. The README says that multiple units within close physical proximity can talk to each other, advertising their presence by broadcasting custom information elements, using a parasite protocol credited to evilsocket and built on top of the existing dot11 standard.

Read literally, that is a beacon. The devices are not hiding their presence from each other; broadcasting custom information elements over dot11 is the mechanism, and the standard carries it. Anything in range that knows to look for those elements can enumerate the units nearby, which also means the units can find each other without any server or pairing step.

That cuts both ways for an operator. The feature is what makes a group of these things aware of each other, and it is also the reason the presence of one is not a secret on the air. Nothing in the repository describes a mode that disables the broadcast, which is worth knowing before the device goes somewhere it should not be conspicuous.

The learning component is gone from the code and still named in the package description

The README is unusually direct about a removal. The older Pwnagotchi had AI that helped it learn from its environment, and it was taken out because it seemed to destabilize the Wi-Fi firmware, with the stated goal of more uptime and longer battery life when carrying the device on a walk.

The removal left traces that a reader can verify. The default branch of the repository is named `noai`. In pyproject.toml the dependency list carries a comment recording what went: numpy, gast and shimmy, described there as AI training pipeline dependencies only. Neither the repository description nor the README now mentions learning.

One description did not get updated. The `description` field in pyproject.toml still reads as deep reinforcement learning instrumenting bettercap, while the repository's own description field says only that it is a Raspberry Pi instrumenting Bettercap. So the metadata a package index shows and the metadata the repository shows disagree about whether the machine learning is still there, and the dependency comment is the one that matches the code.

bettercap and pwngrid arrive as submodules, and the Makefile says the pointers float

The Python dependency list does not contain bettercap. It contains the things a Python process would import: flask with flask-cors and flask-wtf for a web interface, scapy for packet work, pycryptodome, gpiozero with the RPi GPIO bindings, spidev, smbus and smbus2 for hardware buses, inky for the display, pisugar for the battery partner, tweepy, websockets, PyYAML and the toml pair. The engine itself arrives a different way.

The Makefile has a target whose comment says the image build needs bettercap, pwngrid and the nexmon trees, and it runs `git submodule update --init --recursive`. Beside it is a second target that fetches the tip of whatever branch `.gitmodules` tracks, and its comment is the most useful sentence in the build system: this deliberately changes what the next image contains, because bettercap, pwngrid and the nexmon sources all float, so the resulting pointer bumps should be committed and test-built rather than left dangling in a working tree. The target echoes the same reminder after it runs.

So a fresh clone builds something, and a rebuild months later builds something else. There is a `.gitmodules` at the root, and the reproducibility burden is on whoever commits next.

Wi-Fi support is one Broadcom kernel driver version, patched and built with DKMS

Three Makefile variables point at the same driver: the DKMS package directory is `stage3/03-nexmon/brcmfmac-nexmon-dkms`, the output goes to `stage3/03-nexmon/files`, and the source is a patch tree at `stage3/03-nexmon/nexmon/patches/driver/brcmfmac_6.18.y-nexmon`. The 6.18.y in that path is a Linux kernel driver series, which is what makes the build host specific rather than device specific.

The build prerequisites listed in the same file read like a provisioning document: make, git, quilt, qemu-user-static, debootstrap, zerofree, libarchive-tools, curl, pigz, arch-test, qemu-utils, qemu-system-arm, qemu-user, plus the aarch64 and armhf cross compilers. Building the DKMS package additionally needs debhelper, dh-sequence-dkms and dpkg-dev, and publishing a driver release needs the GitHub CLI. WORK_DIR is allowed up to 20GB of storage before the image is assembled, and DEPLOY_DIR is where the finished image lands.

The practical reading is that the device is a Linux kernel build with an application on top, not an application install. Kernel updates and driver patches are the maintenance surface.

A 32-bit legacy config, a headless config, and an Android privacy policy at the root

The tree is organised by image variant. There are `config-32bit`, `config-64bit` and `config-headless`, paired with `pi-gen-32bit` and `pi-gen-64bit`, and two overlay directories, `stage3/` and `stage3-headless/`. The README names the hardware split: the 32-bit Raspberry Pi Zero W works on older versions with no new releases, now treated as a legacy device, while the Zero 2 W, Pi 3, Pi 4 and Pi 5 are the 64-bit targets. pyproject requires Python 3.11 or newer, and the version is dynamic, read from `pwnagotchi.__version__`, with package discovery limited to `pwnagotchi` and excluding `stage3`.

Smaller things worth naming. A file called `pwndroid_privacy_policy` sits at the root with no extension, which belongs to the Android sibling rather than to this project. The repository license field carries no recognised identifier, while the README states GPL3 and pyproject points `license` at `LICENSE.md`. The homepage in the repository metadata is plain http, while every URL in pyproject, including the same page, uses https. Release numbering has four parts, and two of the recent tags, v2.9.5.7 and v2.9.5.8, were published on the same day, 2026-08-18, hours apart. The last push to the `noai` branch was on 2026-09-28.

Editorial conclusion

Run this only on hardware you own, in an environment where the networks in range are yours or are covered by a written authorization, and treat that as a precondition rather than a preference. The reason is structural: the default behaviour of the device is to act on whatever is nearby, and neither the README, the wiki link nor the build files describe an allowlist, a scope file, a dry-run mode or a documented abort path. Three further things to verify before you commit. The parasite protocol is a broadcast, so a unit running this is visible to other devices that look for those information elements. The image is not reproducible from a fresh clone, because the Makefile says outright that the bettercap, pwngrid and nexmon submodule pointers float and have to be committed and test-built by hand. And the Wi-Fi support depends on one Broadcom kernel driver version patched through nexmon and built with DKMS, so a kernel update is a support question, not a package update.

Frequently asked questions

Official sources

1. Issues
2. jayofelony/pwnagotchi on GitHub
3. Project website
4. README
5. Releases