I captured a 4-way handshake in Kismet, downloaded it and tried to run cap2hccapx on it, but get told Networks detected: 0.
The .pcap opens fine in WireShark, so I don't think it is damaged at all. I have also tried aircrack-ng and it displays a blank ESSID and says No matching network found - check your essid.
It is from an iPhone AP, so it's named "[name]’s iPhone". Could the non-ascii apostrophe be at fault?
Kismet's web UI displays the apostrophe as \515250\504848\505149.
hashcat: 5.1.0
hashcat-utils: 1.9
Windows: 10 1809 17763.437
Convert your cap file with hcxpcaptool from
https://github.com/ZerBea/hcxtools
It will show you information about the cap file and convert it to hccapx
cap2hccapx is now obsolete and should not be used anymore.
@ C-Sky91
Please attach capfile. I would like to take a look inside.
(05-02-2019, 12:31 PM)Mem5 Wrote: [ -> ]Convert your cap file with hcxpcaptool from https://github.com/ZerBea/hcxtools
It will show you information about the cap file and convert it to hccapx
cap2hccapx is now obsolete and should not be used anymore.
hcxpcaptool worked. Thanks.
(05-02-2019, 05:09 PM)ZerBea Wrote: [ -> ]@ C-Sky91
Please attach capfile. I would like to take a look inside.
[
attachment=658]
@ C-Sky91
Thanks for the cap file. Unfortunately the attached cap file is cleaned deadly. It doesn't contain an ESSID.
Only 4 packets inside:
packet 1: EAPOL M1 - replaycount 1
packet 2: EAPOL M4 (zeroed) - replaycount 2
packet 3: EAPOL M1 replaycount 1 (nonce-error +1)
packet 4: EAPOL M2 replaycount 2
This cap file is useless!
Did you run (too many) deauthentications? EAPOL timer of AP was destroyed between packet 2 and packet 3.
BTW:
If you need to clean a cap file, tshark is a good friend:
$ tshark -r inputcapfile -R "(wlan.fc.type_subtype == 0x00 || wlan.fc.type_subtype == 0x02 || wlan.fc.type_subtype == 0x04 || wlan.fc.type_subtype == 0x05 || wlan.fc.type_subtype == 0x08 || eapol)" -2 -F pcapng -w outputpcapngfile
or (if you prefer ancient formats)
$ tshark -r inputcapfile -R "(wlan.fc.type_subtype == 0x00 || wlan.fc.type_subtype == 0x02 || wlan.fc.type_subtype == 0x04 || wlan.fc.type_subtype == 0x05 || wlan.fc.type_subtype == 0x08 || eapol)" -2 -F pcap -w outputpcapfile
https://cloudshark.io/articles/5-reasons...to-pcapng/
Hmm. I'm not de-authing the AP. Just waited for a handshake naturally.
Maybe it's Kismet. I'm getting the pcaps from it instead of the usual airodump-ng.
the recommended tool for capturing handshakes is hcxdumptool
The EAPOL messages inside your pcap file are from 2 different EAPOL sequences.
packet 1 and packet 2 from the first EAPOL sequence (with a packet loss of a M2 and a M3)
packet 3 and packet 4 from the second EAPOL sequence.
Instead of increasing the replaycount, the AP increased the ANONCE by 1 (ea -> eb).
ANONCE M1 EAPOL sequence 1:
aebc89c23c875586de2130d2859352d64e9fc9602feffdfa3464b42bc46e8aea
ANONCE M1 EAPOL sequence 2:
aebc89c23c875586de2130d2859352d64e9fc9602feffdfa3464b42bc46e8aeb
Possible reasons:
Heavy packet loss or too many stupid deauthentications (or a combination of both).
BTW:
hashcat is able to handle a detected (we use the message pair field for this) packet loss on little endian and/or big endian APs running option --nonce-error-corrections.
Unfortunately, neither kismet nor aircrack is able to detect and handle this behavior.
There is no ESSID inside the pcap file, so you can't convert it for hashmode -m 2500!
$ hcxpcaptool -o test.hccapx 4202770DF706493E_ADD88A96BC720000-handshake.pcap
reading from 4202770DF706493E_ADD88A96BC720000-handshake.pcap
summary:
file name....................: 4202770DF706493E_ADD88A96BC720000-handshake.pcap
file type....................: pcap 2.2
file hardware information....: unknown
file os information..........: unknown
file application information.: unknown
network type.................: DLT_IEEE802_11 (105)
endianness...................: little endian
read errors..................: flawless
packets inside...............: 4
skipped packets..............: 0
packets with GPS data........: 0
packets with FCS.............: 0
EAPOL packets (total)........: 4
EAPOL packets (WPA2).........: 4
best handshakes..............: 1 (ap-less: 0)
But, if you have a PMK list, you can convert your handshake for hashmode -m 2501:
$ hcxpcaptool -O test.hccapx 4202770DF706493E_ADD88A96BC720000-handshake.pcap
reading from 4202770DF706493E_ADD88A96BC720000-handshake.pcap
summary:
file name....................: 4202770DF706493E_ADD88A96BC720000-handshake.pcap
file type....................: pcap 2.2
file hardware information....: unknown
file os information..........: unknown
file application information.: unknown
network type.................: DLT_IEEE802_11 (105)
endianness...................: little endian
read errors..................: flawless
packets inside...............: 4
skipped packets..............: 0
packets with GPS data........: 0
packets with FCS.............: 0
EAPOL packets (total)........: 4
EAPOL packets (WPA2).........: 4
raw handshakes...............: 2 (ap-less: 0)
best handshakes..............: 1 (ap-less: 0)
1 handshake(s) written to test.hccapx
$ hashcat -m 2501 test.hccapx pmklist
hashcat (v5.1.0-928-g75b92c1a) starting...
Session..........: hashcat
Status...........: Exhausted
Hash.Name........: WPA-EAPOL-PMK
Hash.Target......: (AP:72:bc:96:8a:d8:ad STA:5c:96:56:3b:a4:49)
Time.Started.....: Fri May 3 00:04:35 2019 (0 secs)
Time.Estimated...: Fri May 3 00:04:35 2019 (0 secs)
Guess.Base.......: File (pmklist)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 3646.0 kH/s (0.00ms) @ Accel:1024 Loops:1024 Thr:32 Vec:1
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 116775/116775 (100.00%)
Rejected.........: 0/116775 (0.00%)
Restore.Point....: 116775/116775 (100.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidates.#1....: d7b5bc304e4c71f3c3949ea1ac49e0c97d4ce6f9769c28b16a6f5ae5f838a627 -> ffffc8bf6d3399cb2109c27f6fb93059aed1a813f2d961bc33033f75d03c0bd8
Hardware.Mon.#1..: Temp: 35c Util: 11% Core:1071MHz Mem: 900MHz Bus:4
Started: Fri May 3 00:04:26 2019
Stopped: Fri May 3 00:04:37 2019