Jump to content

Unable to capture wpa handshakes


Steve_Jobs
 Share

Recommended Posts

To keep things short I've been experimenting with cracking wpa in aircrack. Everything works fine except a handshake is never captured as I am told when I go to run aircrack against the .cap file. I am using the panda PAU09 which plenty of people say works great, and yes the deauth command does work.

I'm testing this in a home lab type set up so I know for sure the device reconnects to the AP, but for some reason I cannot capture the handshake.

I am using the latest version of kali linux on the rpi, but have also tried on parrot sec os with the same issue

I an following this guide ( https://null-byte.wonderhowto.com/how-to/hack-wi-fi-cracking-wpa2-psk-passwords-using-aircrack-ng-0148366/ ) to the point, substituting my ap's mac.

When I use airodump APs show up but connected clients do not.

Please help

Link to comment
Share on other sites

Can you post all the commands on how you started and capture everything? Might help. Make sure when the card is started in monitor mode, airmon-ng -check shows nothing in the way. Also, airodump-ng, set it to a specific channel with -c # where # is the channel of your AP. If you don't, it will hop all channels and never work properly. After a deauth is run, wait a bit, airodump will show it captured the handshake at the top of the screen. If it doesn't, then it didn't see a handshake, meaning no one connected to it after the deauth, but need to make sure clients were on first, then deauth, then when they reconnect, you should see the handshake. Even when it says it captures it, do it a few times. It can also sometimes show false positives. Then in aircrack, you should get a good file to work with.

Link to comment
Share on other sites

Without being in front of it I'll give you the commands to the best of my memory.  I'll later copy / paste everything.

In this order

airmon-ng start wlan1 

airodump-ng wlan1mon

then I copy the Mac of the ap and take note of the channel

airodump-ng --bssid (mac address) -c 1 --write test1 wlan1mon

-at this point I'm monitoring the specific ap which is one of those mini openwrt routers, no clients ever show up even though they are connected.

from here I've tried a mix of deauth and manually connecting/disconnecting my phone to generate the handshake.  In both cases the handshake does not get captured.

Link to comment
Share on other sites

Either you're on the wrong channel, or monitor mode is not working 100% with your card. Try:

 

"airmon-ng check"

(make sure card is plugged in first, doesn't have to be enabled)

If anything shows, then run

"airmon-ng check kill"

then the check again, and if nothing, then airmon-ng start wlan0(or whatever your card is listed as). Then check that it is actually working with monitor mode:

iwconfig wlan0mon (notice how the name changed after it started in monitor mode, it's no longer wlan0, but is now wlan0mon)

The name is dependent on your card and driver setup, but above is more or less example you can use, just change the card ID

Then airodump-ng wlan0mon -c ## --bssid ##.##.##.##.##.##

or --essid APnamehere which is easier to remember for the name of the AP

 

 

Edited by digip
Link to comment
Share on other sites

Well I tried the same process on my netbook running lubuntu and captured the handshake immediately, and in the process figured out my on board card also supports monitor mode/ injection.

It would seem this is an issue with the raspberry pi 3, could be the arm image.  Maybe I'll take a plain Debian arm image and reroll it with kali tools and see if that's works.  I'm really surprised I can't find anyone else with this problem.

Link to comment
Share on other sites

7 hours ago, Steve_Jobs said:

Well I tried the same process on my netbook running lubuntu and captured the handshake immediately, and in the process figured out my on board card also supports monitor mode/ injection.

It would seem this is an issue with the raspberry pi 3, could be the arm image.  Maybe I'll take a plain Debian arm image and reroll it with kali tools and see if that's works.  I'm really surprised I can't find anyone else with this problem.

If this is specific to the Pi, you may need to update to the re4son kernel, for driver support on the card you're using, or, the card is not compatible for injection and monitor mode to begin with, which is not so much the Pi and Kali, but the card's support. Raspberry's have different drivers though, and some work, some need to be updated, or in some instances, a different kernel depending on the wifi card.

This might fix your issues - https://whitedome.com.au/re4son/re4son-kernel/

But I'm going to think that the Pi, didn't have drivers for that card specifically, where the desktop variants might. Only testing will tell. Also make sure the card, if supposed to work on Kali, works on the other versions of Kali(non Pi /non-arm based). If it does, then seems they need the drivers ported to the Pi and ARM branches, which hopefully Re4son's Pi kernel will fix for you, but not sure if that is one of the cards he has tested. He is working on a bunch of new wifi cards for the Pi though.

Can ping him on twitter to ask if he's tested your specific card  -https://twitter.com/Re4sonKernel

Link to comment
Share on other sites

I captured a handshake with both the onboard card and the panda pau09 from desktop lubuntu no problem.  I'm almost positive it's an arm driver issue.

Thanks for all the help.  I've been forum hopping trying to find a solution and ended up on the kali forums where someone is having the same issue with a Realtek chip card.  I actually just found re4son there and links to his kernel.  I'll update and shoot him a message if it's still not working.

Maybe installing the driver from the panda disk onto the pi would fix this.

Link to comment
Share on other sites

1 hour ago, Steve_Jobs said:

I captured a handshake with both the onboard card and the panda pau09 from desktop lubuntu no problem.  I'm almost positive it's an arm driver issue.

Thanks for all the help.  I've been forum hopping trying to find a solution and ended up on the kali forums where someone is having the same issue with a Realtek chip card.  I actually just found re4son there and links to his kernel.  I'll update and shoot him a message if it's still not working.

Maybe installing the driver from the panda disk onto the pi would fix this.

Unless its a linux driver on the disk, more than likely, it's an NDIS wrapper, and only work for connectivity, and not injection/monitor mode, but without having one to test, i can't say. Good it works from desktop versions, i had a feeling after you mentioned Pi, it's an ARM driver issue, which is not uncommon. Not everything is ported 100% because of the support and testing done by people who have those cards and build the arm branch. Re4son is just a community member, but he's already contributed a lot to the Pi side of the project with his driver updates and kernel testing. Hopefully they get rolled into the main side at some point.

Link to comment
Share on other sites

1 hour ago, Steve_Jobs said:

After updating to reasons newest kernel I am now capturing handshakes on the pi.  Thanks again for the help!

That is awesome!!

Link to comment
Share on other sites

  • 1 month later...
On 10/17/2017 at 4:49 PM, Steve_Jobs said:

After updating to reasons newest kernel I am now capturing handshakes on the pi.  Thanks again for the help!

I have a request for you (or anyone with a Raspberry Pi 2/3) we have an image on Offsec site that is kali 2017.3, which us supposed to have these changes rolled in and fixed for onboard and other cards now. If anyone can test and compare with the Re4son kernel, need to know if they are working the same for wifi cards that were previously having issues. If you're on 2017.2 or older, please update to the latest[ apt update, apt upgrade, apt dist-upgrade ] I want to know how the wifi cards compare, as this should now be fixed.

 

Can get them here: https://www.offensive-security.com/kali-linux-arm-images/

https://images.offensive-security.com/arm-images/kali-2017.3-rpi3-nexmon.img.xz

make sure you match the Sha256sum hash. 1.47gb download (although our site says 0.9) the hash is the proper hash below and on our site.

2017.3

BA0F0DCB9053E6D24218B768553F664AF090CB9C328D291C5A6CFB6415145737

Link to comment
Share on other sites

On 12/11/2017 at 7:48 AM, digip said:

I have a request for you (or anyone with a Raspberry Pi 2/3) we have an image on Offsec site that is kali 2017.3, which us supposed to have these changes rolled in and fixed for onboard and other cards now. If anyone can test and compare with the Re4son kernel, need to know if they are working the same for wifi cards that were previously having issues. If you're on 2017.2 or older, please update to the latest[ apt update, apt upgrade, apt dist-upgrade ] I want to know how the wifi cards compare, as this should now be fixed.

 

Can get them here: https://www.offensive-security.com/kali-linux-arm-images/

https://images.offensive-security.com/arm-images/kali-2017.3-rpi3-nexmon.img.xz

make sure you match the Sha256sum hash. 1.47gb download (although our site says 0.9) the hash is the proper hash below and on our site.

2017.3

BA0F0DCB9053E6D24218B768553F664AF090CB9C328D291C5A6CFB6415145737

Image works like a champ!

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...