Pwnagotchi: An A2C Agent That Tunes Its Own WiFi Capture Parameters
(⌐■_■) - Deep Reinforcement Learning instrumenting bettercap for WiFi pwning.
At a glance
- What is it?
- Pwnagotchi is a Python and bettercap tool that runs an A2C reinforcement learning agent against nearby WiFi, adjusting its own parameters to collect crackable WPA material as PCAP files. It is best understood as a long-running experiment on dedicated hardware, not a drop-in auditing utility.
- Who is it for?
- Adopt Pwnagotchi if you have a spare Raspberry Pi class board, a monitor-mode capable WiFi adapter and a willingness to let an A2C agent explore for many epochs before it settles on parameters. Do not adopt it if you need a one-shot site survey or a repeatable test harness, because the capture policy is learned per environment and the last tagged release is v1.5.5 from April 2021 while master continues to move.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 28 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem Pwnagotchi Targets: Passive Handshake Collection Is Dumb
A conventional WiFi capture setup does what you tell it. You pick a channel, you wait, and if nothing usable shows up you have wasted the session. Pwnagotchi attacks that gap. The README describes it as an A2C-based agent that learns from its surrounding WiFi environment to maximize the crackable WPA key material it captures, either passively or by performing authentication and association attacks. The output is PCAP files containing any handshake form supported by hashcat, including PMKIDs and full or half WPA handshakes. The intended user is someone who can leave a small board running in a bag or on a desk for hours, in places with enough access points and client stations to generate learning signal. It is not aimed at an engineer who wants a scripted audit with a known start and end. The README is explicit that time for a Pwnagotchi is measured in epochs, and that a single epoch can last from a few seconds to minutes depending on how many access points and stations are visible. That framing tells you the tool expects to be resident in an environment, not invoked against it.
How the A2C Agent and the LSTM Policy Network Fit Together
The mechanism is narrower than the phrase deep reinforcement learning suggests. According to the README, Pwnagotchi uses an LSTM with an MLP feature extractor as its policy network for the A2C agent, implemented through stable-baselines. Bettercap supplies the radio work: scanning, the authentication and association attacks, and the packet capture. The agent observes the environment through that layer and adjusts what the README calls key parameters over time. The README points to defaults.toml as the file where those parameters live. The learning loop is therefore not a model that recognizes networks. It is a policy that decides how to act given the current view of the environment, and it improves by trial. The README warns directly that early performance will not be impressive, because the agent explores several combinations of key parameters before determining ideal adjustments for the specific environment it is exposed to. That is the honest description of the data flow: bettercap sees, the agent chooses, the capture either produces crackable material or it does not, and the policy updates. Nothing in the supplied material describes a pretrained model shipped with the project, so the practical starting state is an untrained policy plus whatever defaults.toml contains.
Multi-Unit Cooperation Over a Custom dot11 Information Element
The most distinctive design choice in the README is the parasite protocol. Multiple units within close physical proximity can talk to each other by broadcasting custom information elements on top of the existing dot11 standard. The README states that two or more units trained together will learn to cooperate upon detecting each other's presence by dividing the available channels among them. Read that carefully. The advertisement mechanism is deterministic and described as built on dot11, but the cooperation itself is described as learned. That means a fresh pair of units does not begin by splitting channels cleanly. They have to reach that behaviour through the same epoch-by-epoch process that governs single-unit capture. For anyone planning a multi-node deployment, the practical consequence is that the channel division is an outcome to be observed, not a setting to be configured. The README does not describe a manual channel assignment override for the cooperative case, and it does not state how conflicts are resolved when two units pick the same channel.
Getting It Running: What the README and Docs Actually Give You
The repository README does not contain installation commands. It links to https://www.pwnagotchi.ai for documentation and names that site's Usage section, including a page on training the AI, as the place to read about how the unit learns. So the honest answer to how you get it running is that the setup path lives in the external docs, not in the README, and this review cannot reproduce commands that the supplied material does not contain. What the README does give you is the configuration surface: defaults.toml in the repository root holds the tunable parameters the agent adjusts, and the badge block confirms the project is released under GPL3 with the licence text at LICENSE.md. The topics list on the repository confirms the bettercap dependency and the handshake and WPA-PSK focus. If you are evaluating adoption, the first thing to check is the docs site for hardware requirements and the adapter support list, because monitor mode and injection are prerequisites for the authentication and association attacks the README describes.
The Learning Curve Is the Product, and That Is a Real Cost
The README's own instruction is to listen to your Pwnagotchi when it tells you it is boring, and to bring it into novel WiFi environments so it can observe new networks and capture new handshakes. That is a design statement with operational consequences. A unit trained in one location has learned adjustments for that location's access point density, channel usage and client behaviour. Move it somewhere structurally different and you are back to exploration. For a lab that wants a fixed capture configuration, this is the wrong tool, because the policy is not a configuration file you can freeze and ship. For a field researcher who moves between sites, the same property is the point. The trade-off is that you cannot easily attribute a capture result to a specific parameter choice, since the agent is adjusting several at once. If you need explainable, reproducible capture behaviour, a plain bettercap invocation with a fixed channel list will be easier to defend and easier to script.
Where Pwnagotchi Sits Against Plain bettercap
The clearest alternative is bettercap on its own, which Pwnagotchi wraps rather than replaces. The difference in approach is who decides. With bettercap alone, you specify the interface, the channel or channel plan, the attack types, and the capture filters, and it executes. With Pwnagotchi, the A2C agent chooses how to act based on its observation of the environment, and the README frames that choice as maximizing crackable key material. That is a genuine architectural difference, not a packaging difference: one is a tool you drive, the other is a loop that drives itself and improves with exposure. The cost of the second approach is predictability. You give up the ability to state in advance exactly which channels will be visited and which attacks will be attempted. The benefit is that the unit can spend more time where the environment rewards it, which matters when you are leaving hardware unattended for long stretches. If your use case is a timed engagement with a defined scope, bettercap alone is the more defensible choice.
Maintenance, Releases and the Licence Ambiguity
The release history is the first maintenance signal. The most recent tagged release listed is v1.5.5 from April 2021, preceded by v1.5.3 and v1.5.2 in April 2020. The repository itself is not archived and shows a push in August 2026, so master is active even though tagged releases have not kept pace. For an operator, that means the release artifacts and the current source are likely to differ, and you should decide deliberately whether to track master or pin to v1.5.5. Upgrades are not a drop-in operation in the ordinary sense either: a trained policy is tied to the environment it learned in, so replacing the software does not preserve the behaviour you observed. On licensing, the README states the project is released under GPL3 and the badge links to LICENSE.md, but the repository metadata reports the licence as NOASSERTION. Those two signals disagree. Read LICENSE.md and the bundled dependency licences yourself before distributing a built image or combining the code with anything else. This is not legal advice, and the mismatch between the badge and the metadata field is exactly the kind of thing that should be resolved by reading the file rather than the badge.
Editorial conclusion
Adopt Pwnagotchi if you have a spare Raspberry Pi class board, a monitor-mode capable WiFi adapter and a willingness to let an A2C agent explore for many epochs before it settles on parameters. Do not adopt it if you need a one-shot site survey or a repeatable test harness, because the capture policy is learned per environment and the last tagged release is v1.5.5 from April 2021 while master continues to move. Before deploying, verify that your adapter and driver support monitor mode and frame injection, and read LICENSE.md directly: the repository badge and README say GPL3 but the GitHub licence field reports NOASSERTION, so confirm the terms yourself.
Community notes