Deauth questions / possible issues

[matrix224]

I'm back once more with some other things regarding Deauth!

1. When selecting an AP in the Deauth::select() method, is the intention that it doesn't use the same channel as was selected in the Channel::cycle() method? Currently it is not using it from what I can tell, but it doesn't affect functionality.
   • My understanding is that calling WiFi.scanNetworks() with no parameters scans all channels. If you use a specific channel, you're morel likely to find no APs I would guess since you're targeting just that one channel. I only ask this because I've modified my Minigotchi to communicate directly with my Pwnagotchi over serial and sync their channels, and it was all working fine except when it scanned for APs. The channel in the Channel class was synced fine, but it would end up scanning APs on other random channels when it got to Deauth::select(). I updated the code to do WiFi.scanNetworks(false, false, Channel::getChannel()); instead of just WiFi.scanNetworks() and that ended that issue, but I'm thinking this really only matters for my specific use-case.
2. When Deauth::select() doesn't find any APs, it can lead to issues. I'm unfortunately not well versed in C, so I'm not entirely sure where the issue lies. But basically when it finds no access points, it leads to some exception and the entire unit crashes + restarts. I avoided this by updating the code to just return; if no APs are found since I figured there's nothing to deauth in that case anyway, which works fine. The downside is that Deauth::deauth() yells at me because it thinks I broke the select method :(
3. Part of above, if an AP is selected and then on the next call to Deauth::select() it can't find any APs, it still has the old values set in Deauth::randomIndex and Deauth::randomAP, which leads to other random issues from what I can tell. I think those two values should be cleared first before doing anything else in Deauth::select()

[dj1ch]

My understanding is that calling WiFi.scanNetworks() with no parameters scans all channels. If you use a specific channel, you're morel likely to find no APs I would guess since you're targeting just that one channel. I only ask this because I've modified my Minigotchi to communicate directly with my Pwnagotchi over serial and sync their channels, and it was all working fine except when it scanned for APs. The channel in the Channel class was synced fine, but it would end up scanning APs on other random channels when it got to Deauth::select(). I updated the code to do WiFi.scanNetworks(false, false, Channel::getChannel()); instead of just WiFi.scanNetworks() and that ended that issue, but I'm thinking this really only matters for my specific use-case.

I don't think it takes any arguments, it might but it's a lot easier to find AP's when you have access to multiple channels. When the minigotchi does hop channels the purpose is to search for a pwnagotchi, send pwnagotchi advertisments, etc, while Deauthing is meant to attack other AP's on different channels

When Deauth::select() doesn't find any APs, it can lead to issues. I'm unfortunately not well versed in C, so I'm not entirely sure where the issue lies. But basically when it finds no access points, it leads to some exception and the entire unit crashes + restarts. I avoided this by updating the code to just return; if no APs are found since I figured there's nothing to deauth in that case anyway, which works fine. The downside is that Deauth::deauth() yells at me because it thinks I broke the select method :(

When Deauth::select() doesn't find any APs, it can lead to issues. I'm unfortunately not well versed in C, so I'm not entirely sure where the issue lies. But basically when it finds no access points, it leads to some exception and the entire unit crashes + restarts. I avoided this by updating the code to just return; if no APs are found since I figured there's nothing to deauth in that case anyway, which works fine. The downside is that Deauth::deauth() yells at me because it thinks I broke the select method :(
Part of above, if an AP is selected and then on the next call to Deauth::select() it can't find any APs, it still has the old values set in Deauth::randomIndex and Deauth::randomAP, which leads to other random issues from what I can tell. I think those two values should be cleared first before doing anything else in Deauth::select()

I figured out the problem to that, essentially regardless I made the mistake of making it write values to the deauthentication frame we're sending regardless of if it was found or not

this was pretty much the mistake i made

void Class::selectAP() {
    Class::aps = scanForAP();
    
    if (Class::aps > 0) {
        getRandomAp();
    } else {
        ApNotFound();
    }
    
    // we would write blank info causing the crash most likely
    setUpDeauth();

    // doesn't know what to print
    printApInfo(); 
}

when it was supposed to be more like

void Class::selectAP() {
    Class::aps = scanForAP();
    
    if (Class::aps > 0) {
        getRandomAP();
        setUpDeauth();
        printApInfo();
    } else {
        ApNotFound();
    }
}

[dj1ch]

If you have any more questions, let me know, I should have pushed a fix recently to the development branch

[matrix224]

I don't think it takes any arguments, it might but it's a lot easier to find AP's when you have access to multiple channels. When the minigotchi does hop channels the purpose is to search for a pwnagotchi, send pwnagotchi advertisments, etc, while Deauthing is meant to attack other AP's on different channels

Yeah that's what I was guessing as I looked into it more. The method can take arguments but for general use it makes sense how it is now I think. I was just curious about it since I was modifying mine to sync it to my actual Pwnagotchi so they can work in tandem, and I had initially expected setting the channel meant setting it for everything (advertising, friend-finding, scanning, deauth, etc) in that run.

I figured out the problem to that, essentially regardless I made the mistake of making it write values to the deauthentication frame we're sending regardless of if it was found or not

Got it, I figured it was something along those lines but I wasn't sure where exactly it went wrong in there.

If you have any more questions, let me know, I should have pushed a fix recently to the development branch

I think that's all I've got for now, thank you for getting back to me on everything!

[dj1ch]

I think that's all I've got for now, thank you for getting back to me on everything!

No problem, I'll close this issue now since this is resolved. Thanks for supporting the project!