Skip to content

Pwnagotchi re-attacks APs with existing handshakes after every reboot #551

@CoderFX

Description

@CoderFX

Bug Description

Pwnagotchi keeps attacking the same APs over and over again, even when it already has valid handshake files (.pcap) on disk. After every reboot or service restart, the in-memory _handshakes dict in agent.py starts empty, so _has_handshake() returns False for every AP — including ones where a handshake was captured hours, days, or weeks ago.

This means the device wastes its limited energy and airtime re-attacking the same nearby APs instead of going after new targets it hasn't captured yet. In practice, if you live next to 5-10 APs with strong signals, those same APs get hammered every single epoch while new or weaker APs in the vicinity never get a chance.

Steps to Reproduce

  1. Let pwnagotchi run and capture handshakes from nearby APs
  2. Reboot the device (or restart the service)
  3. Observe the logs — it immediately starts deauthing and associating with the same APs it already has .pcap files for

Example from logs — a nearby AP gets attacked every ~2 minutes despite having a large handshake file already on disk:

[19:20:17] sending association frame to MyNeighborAP (xx:xx:xx:xx:xx:xx)
[19:22:39] sending association frame to MyNeighborAP (xx:xx:xx:xx:xx:xx)
[19:25:06] sending association frame to MyNeighborAP (xx:xx:xx:xx:xx:xx)
[19:27:08] sending association frame to MyNeighborAP (xx:xx:xx:xx:xx:xx)
...repeating every 2 minutes indefinitely

Root Cause

Agent.__init__() initializes self._handshakes = {} and only populates it from:

  • Bettercap handshake events during the current session
  • The recovery data file (which may not always exist)

It never checks what .pcap files already exist in the handshakes directory. So every restart is a clean slate — the device has no idea it already pwned half the neighborhood.

Expected Behavior

On startup, pwnagotchi should scan the handshakes directory for existing .pcap files and skip APs that have already been successfully captured. This way the device focuses its energy on new targets, maximizing the number of unique handshakes captured over time instead of redundantly attacking the same APs.

Impact

  • Wastes battery life on redundant attacks against already-captured APs
  • Reduces the number of new unique handshakes captured per session
  • Nearby APs with strong signals dominate the attack queue, starving weaker/farther APs of attention

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions