Jump to content

Capture Handshakes


Briel
 Share

Recommended Posts

Never used Pineapple before so i decided to order one. After 4-5 hours playing with it I made zero progress. Tested beta and stable firmware, every possible setting and option. In my lab I setup several different WiFi APs and Routers, and simulated working networks... nothing... I never capture a single handshake, despite my best efforts to get at least one. It is true I don't have experience with pineapple, but I have plenty other devices and experience in the field. It should be easy, I mean even my raspberry captures handshakes a lot easier despite the fact it is not originally made for it.

Link to comment
Share on other sites

Routers won't let you capture any handshakes, but I guess you refer to "home routers" that are combined with wireless features. You mention WiFi APs, but what clients have you tried? 2.4 GHz only or 5 GHz? 5 GHz isn't supported out of the box if you don't add a supported 5 GHz USB NIC to the Pineapple. In what way are you capturing handshakes? Do you use the "sit and wait method" or do you deauth?

  • Upvote 1
Link to comment
Share on other sites

Yes I use APs and Routers (with WiFi) specifically as dummy devices to test the pineapple. I use only 2.4GHz as pineapple only have that option. I deauth and use different devices to connect and disconnect from networks, try to simulate conditions of real world WiFI and test the pineapple. I mean I setup the whole thing to test pineapple. After hours and hours I was not able to catch a single handshake. On the other hand I can use my second machine with Kali Linux or my raspberry with WiFi shield to catch handshakes without any problem. With pineapple i have zero success. At this point i think it is very buggy, not supported unit that need a lot of work to be useful. After some reading i understand why many people recommend it... they just talk about older versions and as it seems they are far superior.

Link to comment
Share on other sites

Well, I don't agree to some things you are saying. I can't see how older versions could be far superior. There are no logic arguments behind that. Saying that it is "very buggy" is to take it a bit too far as well. Of course, bugs will always be present, like for any other product/object, but not "very buggy". I haven't experienced the same issues capturing handshakes, far from "zero success". Not sure what your issue might be. I guess you have to explain your method more in detail to be able to spot if there's something in the workflow that might be missing.

  • Upvote 1
Link to comment
Share on other sites

  • 11 months later...

Hi there,

I’d like to chime in, as I too have been having issues capturing handshakes which I think could be the same issue. I believe the software is indeed “buggy”.

I am not able to capture handshakes when PineAP was already enabled before performing the following:

Regarding the process I was able to successfully capture a handshake: 

  • Disable PineAP & save
  • navigate to recon tab
  • Perform continuous recon scan
  • Capture handshake button on selected network
  • Deauth my phone (test example) I can see on the phone that I’m booted from the network
  • Handshake is immediately captured

I seem to be able to capture properly when following the above but it would be nice if this bug was fixed and we didn’t need to “work around”!

Cheers,

F

Link to comment
Share on other sites

12 hours ago, fab said:

Hi there,

I’d like to chime in, as I too have been having issues capturing handshakes which I think could be the same issue. I believe the software is indeed “buggy”.

I am not able to capture handshakes when PineAP was already enabled before performing the following:

Regarding the process I was able to successfully capture a handshake: 

  • Disable PineAP & save
  • navigate to recon tab
  • Perform continuous recon scan
  • Capture handshake button on selected network
  • Deauth my phone (test example) I can see on the phone that I’m booted from the network
  • Handshake is immediately captured

I seem to be able to capture properly when following the above but it would be nice if this bug was fixed and we didn’t need to “work around”!

Cheers,

F

What firmware were you using? Have you reported the bug?

Link to comment
Share on other sites

  • 2 weeks later...
On 6/6/2022 at 5:19 AM, fab said:

Hi there,

I’d like to chime in, as I too have been having issues capturing handshakes which I think could be the same issue. I believe the software is indeed “buggy”.

I am not able to capture handshakes when PineAP was already enabled before performing the following:

Regarding the process I was able to successfully capture a handshake: 

  • Disable PineAP & save
  • navigate to recon tab
  • Perform continuous recon scan
  • Capture handshake button on selected network
  • Deauth my phone (test example) I can see on the phone that I’m booted from the network
  • Handshake is immediately captured

I seem to be able to capture properly when following the above but it would be nice if this bug was fixed and we didn’t need to “work around”!

Cheers,

F

This was the only method for me that worked. Once. When I tried to capture a handshake on a second AP, the Pineapple went back to nothing happening when clicking 'Capture WPA Handshakes.' I also noticed that when running the pineap command, I often get an error that var/run/pineapd.sock does not exist. However, pineapd.lock will be present, and I suspect that it has to do with the interface locking to a specific channel as part of the handshake capture process.

If I'm right, there could be process improvements or even a notification that the interface remains locked.

Link to comment
Share on other sites

On 6/15/2022 at 10:34 AM, DramaKing said:

This was the only method for me that worked. Once. When I tried to capture a handshake on a second AP, the Pineapple went back to nothing happening when clicking 'Capture WPA Handshakes.' I also noticed that when running the pineap command, I often get an error that var/run/pineapd.sock does not exist. However, pineapd.lock will be present, and I suspect that it has to do with the interface locking to a specific channel as part of the handshake capture process.

If I'm right, there could be process improvements or even a notification that the interface remains locked.

Thanks to Foxtrot's post here, I realized that I wasn't quite going about this right. PineAP creates the .sock virtual file when it starts, but after capturing a handshake, it won't do it again. So after looking at Deuce022's post and doing some testing, the process is to disable PineAP, switch to Recon, run a scan to start pineapd, then capture a handshake/deauth, etc. Rinse and repeat as necessary.

Hopefully, there will be a fix in firmware 2.0.

Edited by DramaKing
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...