Jump to content


Active Members
  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

terraformer's Achievements

  1. @Foxtrot want to comment on the hardware feedback and the desire for channel control, including dwell time? Seem like pretty obvious features imo.
  2. I've had my Mark VII for a while now. I've got pretty extensive experience with WiFi related infosec but the Mark VII is the first time I've touched WiFi Pineapple since the very first version came out that I bought @ DefCon many years ago. The whole experience seems tailored to people not very familiar with 802.11 but I figured instead of just complaining I'd make a list here of suggestions on how to improve both the device and accompanying software. I really have no idea what the intended target audience is since opsec nor a deep level of technical understanding seems to be something this product caters much to. I know some of my software issues can be "solved" by installing third party apps, but since there is a official web interface, I figured it should do most of what needs to be done out of the box. Software Tldr; The software abstracts away almost all indicators of what is actually going on with the device. It might make things easier for people not familiar with WiFi but I think it confuses anyone who has worked with WiFi before. The entire web interface needs a lot of work in my opinion before it can be considered functional. - Refactor the entire WPA Handshake feature. WiFi Handshake capture should be happening passively at all times (I think it already is, which is why the dedicated button is confusing). Focus on channel control instead. - Allow easy control over which channels to monitor and the hopping between them. Make it easy to camp on channels associated with specific networks (which is seemingly what the "capture handshake" button does) and make it possible to easily control channel hopping for different interfaces. This is my primary gripe with the Wifi Pineapple. I always find myself SSH'ing in and checking the state of the wireless interfaces to see what channel they are on. I'd be happy to provide mockups of what I had in mind. I think it's actually very simple and could be similar to what the Kismet web interface already does, but with a few extra bells and whistles. I have my own Kismet fork where I've implemented some of the stuff I had in mind already and I find the added control super useful. - Client deauthentication needs more options, including the number of deauth frames to transmit and the the reason code. Currently the Pineapple just spams deauth frames to the network, making it super obvious what's happening. Even my Unifi gear triggered alerts. I'd also make it easier to verify deauthentication success. - Indicate whether the PTK and/or GTK has been captured. I have no idea what the WiFi Pineapple considers a WPA handshake. You need packet 1+2 or 2+3 for the PTK and GTK along with the beacon frame for the SSID correlation. - Add ability to enter network key and get decrypted data frames directly. Saves me the hassle of doing it afterwards in Wireshark. - Add ability to add MAC addresses to a list of "targets" and get alerts when said targets are observed, either directly or indirectly. - Make it easier to turn off all active WiFi, including the various broadcasted wifi networks. I still havent been able to turn off everything and the WiFi pineapple insists on either broadcasting it's open network or having it running without broadcasting the SSID. I just want it entirely passive for most of the time. Hardware - I have no idea why the Mark VII does not include a more robust hardware package. 5GHz and AC support at a minimum would be appreciated. I know a "enterprise" version is in the pipeline, but again, nothing about the software seems to cater to a "professional" enterprise customer. - I'd love a built in battery which could be recharged over USB-C. - Physical switches to disable the radios, or at least a programmable physical switch that could be used to toggle the active component on/off. - The device needs more system resources in my opinion. Both a better SoC and more RAM in order to handle useful features such as live data frame decryption, multi-interface packet capture, etc.
  3. Thanks for responding. I just see very little technical discussion on here, hence my impression.
  4. Nobody uses it for pen tests because it doesn’t really have any pen testing features. I don’t really understand what the intended audience is to be honest. There is zero technical documentation available and all we have are very simple video demos. The web interface abstracts away any technical aspect of 802.11 related operations. Kismet is an open source tool that is miles better in terms of passive collection and the tools you mentioned work well for active stuff.
  5. I share the impression of the OP. The WiFi Pineapple exposes little to no technical information about what its doing. What channels are being monitored? What the dwell time for each channel? What does the "capture wpa handshake" button actually do? Does it simply camp on the associated channel of the network and wait for handshake data for that particular SSID or does it cover all networks for that given channel? When deauthing, how many frames are sent? What reject code is being used? The WiFi pineapple software gives you answers. Its a device for people who have no clue what 802.11 is and how it works imo.
  6. I dont know. My impression is that Hak5 do not really answer technical questions in here, further supporting my impression that the WiFi Pineapple isnt really for anyone with any sort of intimate knowledge of 802.11.
  7. Client deauthentication seems to work fairly well, at least on the v1.1.0 beta. However, as with most of the features of the Wifi Pineapple, I wanted to know a bit more about how the features are actually implemented. I did a quick recon scan, found a client of my network and clicked the "Deauthenticate Client" button. The client disassociated from the network after a while as intended. Doing a packet capture seems to indicate that the WiFi Pineapple spams out deauthentication frames with reason code 0x0001, causing a bit of a havoc as the client tries to respond to all of them and subsequently I see the client sending out the same number of disassociation requests afterwards. My question is whether there is any reason why the pineapple needs to send out so many deauthentication frames? Usually, a single frame is sufficient. Sometimes you might want to send a few more just to account for congestion or poor signal, but the current implementation seems to be very aggressive. Just scroll through the management frames in the packet capture and you see right away that something fishy is gong on. Suggestion: Allow the user to specify the number of deauthentication frames to send. See screenshots for illustrations.
  8. New update runs fine here too. However, the list of missing features I would consider pretty basic functionality is pretty long. Most of the time I have no idea what the Pineapple is doing. When doing a recon scan: What channels are being utilized? Whats the dwell time per channel? Can I change those parameters? Which radio is being used? And why doesnt the internal card support 5 GHz (I knew this before buying but it seems like such an odd omission. Mini PCIe cards AC cards that support packet injection and monitor mode are like $20 on Amazon. The "Capture WPA Handshakes" feature is a mystery too. Does it simply camp on the associated channel for the selected network and listen for handshakes? Does it filter on SSID based on the selected network? Can I listen for handshakes for multiple SSID's on the same channel? What about listening for handshakes across different channels for different network? Why is there a dedicated "Capture WPA handshakes" function in there in the first place? The UI also doesnt show much in terms of technical information regarding observed networks. What 802.11 standard is being used? How wide are the channels? etc. Tbh, I would do the entire network interface completely differently. Why not do what Kismet does and allow you to simply start passively collecting data on the channels you specify? All while capturing data, including and handshake data that might be caught? You could then add filtering rules to include/exclude networks and devices from being monitored. Can I specify what frame types to collect? Can I decrypt data for networks on the fly if I have the network key and session key? Perhaps the WiFi Pineapple suite is geared towards pentesters with no desire to learn WiFi or having to deal with channels, frame types or 802.11 variants. Hope my feedback make sense. Keep up the great work.
  • Create New...