Open mecrayavcin opened 3 years ago
No supported chipset/driver I guess. Try running a pure "hcxdumptool" PMKID sniffer (passive), that's what wifite2 uses also. I'll look into it soon
This seems to be a duplicate of #258
I’m using an Alfa rt2800 USB adapter. After wifite fails and I’m at the shell, I can immediately use hcxdumptool and capture 20+ different PMKIDs from APs in my area.
Not a driver issue.
Definitely seems like something with how aircrack-ng is being used to monitor. The PMKID is there. Here is a capture from start to finish, including testing with aircrack-ng and hcxpcaptool. I'm not sure if it matters, but if I run the aircrack-ng command that is listed in pmkid.py the process hangs until I ctrl-c out.
[+] select target(s) (1-100) separated by commas, dashes or all: 15
[+] (1/1) Starting attacks against 94:A6:7E:XX:XX:XX (NETGEAR28) [+] NETGEAR28 (53db) PMKID CAPTURE: Failed to capture PMKID
[+] Finished attacking 1 target(s), exiting
ps ax | grep hcx hcxdumptool -i wlan1mon --filterlist_ap /tmp/wifitefpzudpkb/pmkid.filterlist --filtermode 2 -c 1 -o /tmp/wifitefpzudpkb/pmkid.pcapng
cat pmkid.filterlist 94A67EXXXXXX
root@kali:/wifitefpzudpkb# tcpdump -r pmkid.pcapng -w pmkid.pcap reading from file pmkid.pcapng, link-type IEEE802_11_RADIO (802.11 plus radiotap header), snapshot length 65535 root@kali:/wifitefpzudpkb# aircrack-ng pmkid.pcap | grep PMKID 40 94:A6:7E:20:73:AF NETGEAR28 WPA (0 handshake, with PMKID) ^Croot@kali:~/wifitefpzudpkb# hcxpcaptool -z pmkid.16800 pmkid.pcap
reading from pmkid.pcap
summary capture file: file name........................: pmkid.pcap file type........................: pcap 2.4 file hardware information........: unknown capture device vendor information: 000000 file os information..............: unknown file application information.....: unknown (no custom options) network type.....................: DLT_IEEE802_11_RADIO (127) endianness.......................: little endian read errors......................: flawless minimum time stamp...............: 05.07.2021 18:15:02 (GMT) maximum time stamp...............: 05.07.2021 18:16:50 (GMT) packets inside...................: 108 skipped damaged packets..........: 0 packets with GPS NMEA data.......: 0 packets with GPS data (JSON old).: 0 packets with FCS.................: 0 beacons (total)..................: 48 beacons (WPS info inside)........: 21 beacons (device info inside).....: 2 probe requests...................: 10 probe responses..................: 38 association responses............: 1 reassociation requests...........: 1 reassociation responses..........: 1 authentications (OPEN SYSTEM)....: 5 authentications (BROADCOM).......: 3 EAPOL packets (total)............: 4 EAPOL packets (WPA2).............: 4 PMKIDs (not zeroed - total)......: 1 PMKIDs (WPA2)....................: 1 PMKIDs from access points........: 1 best PMKIDs (total)..............: 1
summary output file(s): 1 PMKID(s) written to pmkid.16800
Hi all, is there any update on this issue? I have the same problem on my raspberri Pi 3 Kali 2021.4a image using the Buildin as well as external USB Wifi Stick
Did anyone find a solution how the pmkid attack does work and find packages with wifite?
Yeah - this has been a known issue for my team for a while - we basically just use bettercap for PMKID attacks because it is way more reliable than wifite.
Is there any update on this known issue? I did not see any improvement regarding capturing of PMKID on the new Kali 2022.1 image.
No updates to wifite since 2018. I think we can assume this issue will probably not be fixed...
Solved here https://github.com/4k4xs4pH1r3/wifite3/issues/11
I took a closer look and judging from what's going on during the "Waiting for PMKID" phase:
2170 pts/2 S 0:39 | \_ zsh
628345 pts/2 Sl+ 0:00 | \_ /usr/bin/python3 /usr/sbin/wifite --pmkid
628429 pts/2 Sl+ 0:00 | \_ airodump-ng wlan0 -a -w /tmp/wifite_eb2hlee/airodump --write-in
628447 pts/2 Z+ 0:00 | | \_ [airodump-ng] <defunct>
629024 pts/2 S+ 0:00 | \_ hcxdumptool -i wlan0 --filterlist_ap /tmp/wifite_eb2hlee/pmkid.
it does look as if the airodump-ng
process used during the initial scanning does not get reaped properly, and it hanging around could possibly be interfering with the subsequent hcxdumptool
run.
I can confirm that the "don't use automatic background-mode detection"-patch I just submitted improves the situation: the scanning now stops immediately when asked to, without any lingering processes!
Unfortunately, PMKID scanning still does not seem to return any findings. 😞 Perhaps the device needs some additional level of mode reset before hcxdumptool
can run properly.
I just pushed support for hcxdumptool v6.3.0 to wifite2.
https://github.com/kimocoder/wifite2
hcxdumptool has been completely rewritten a month ago, therefor PMKID didnt get catched.
PMKID function does not work! I use Kali Linux's lastest version. I use this command wifite --wpa --pmkid --kill
I select an wifi but no PMKID captures! I get always fail error timeout etc. With Hcxdumptool i can get PMKIDS easily.
But Wifite could not capture PMKID And also there are no error messages with wifite. All necessary files are installed.
what is the problem do you think? Thanks