dj1ch/minigotchi

Deauth ignore unencrypted AP, reset last used AP

matrix224 opened this issue · 3 comments

Alright I'm back again with a couple more lol

  1. Currently the AP scan will pick up open APs, which I figure there's no point deauthing since there's nothing to actually deauth there. As far as I'm aware there's no way to ignore them in the scan, but we can at least check if our selected AP is encrypted or not and ignore it. I just put this after the check for whitelisted in my local Deauth::select() and it seemed to work fine. I know it's probably not a common case you'd see out in the wild, but I figured if the Pwnagotchi ignores APs like these, the little guy may as well too.
        uint8_t encType = WiFi.encryptionType(Deauth::randomIndex);
        // -1 indicates unknown / unhandled
        if (encType == -1 || encType == ENC_TYPE_NONE) {
          Serial.println("('-') Selected AP is not encrypted. Skipping deauthentication...");
          Display::cleanDisplayFace("('-')");
          Display::attachSmallText("Selected AP is not encrypted. Skipping deauthentication...");
          return;
        }

and e.g.:

('-') Selected random AP: <redacted>

('-') Selected AP is not encrypted. Skipping deauthentication...
  1. From my issue yesterday (128), I had mentioned resetting the last deauthed index/SSID before each new call to select(). I don't think the code change that was made in that issue covered that though and it can lead to possibly odd / unexpected behavior. It doesn't seem to cause any direct issue (e.g. crashes), but I think it's just misleading. Basically imagine this scenario:
    • An AP is selected and deauthed
    • select() gets called again on the next run, but something happened where it wouldn't continue (no APs are found, AP is whitelisted, etc)
    • All of the messages / serial output indicate no deauthing will occur, however Deauth::deauth() only checks that the randomAP that was selected has a length > 0. Since it wasn't reset from the last run, it does in fact have a length > 0
    • It then proceeds to deauth the last AP that was deauthed even though all the other messages and logic indicated it couldn't get an AP and would do nothing right now

From my issue yesterday (#128), I had mentioned resetting the last deauthed index/SSID before each new call to select(). I don't think the code change that was made in that issue covered that though and it can lead to possibly odd / unexpected behavior.

I will get to this when I can, I'm pretty busy this week, feel free to make a PR if you want to make an immediate change.

I think I made those fixes in deauth.cpp just recently, this should have fixed your issue here. Thank you for your patience.

Sorry I had gotten caught up at work after posting this. Thank you for taking a look at it again!