Some words about wlancap2hcx:
wlancap2hcx need the ESSID received before the handshake follows! Mainly the ESSID is taken from an associationrequest (priority 1).
If you got some caps, that are manually cleaned like this one:
http://zalil.su/2602890
M1
M2
M3
M4
beacon
wlancap2hcx will show you that result:
$ wlancap2hcx -o test.hccapx 2602890_DIR-88.cap
start reading from 2602890_DIR-88.cap
5 packets processed (5 wlan, 0 lan, 0 loopback)
found 2 handshakes without ESSIDs (hashcat -m 2501, john WPAPSK-PMK)
Now you have 2 choices
1) use wlangenpmkocl to generate PMK's for ESSID DIR-88 (not a good idea)
2) run wlancap2hcx on this cap twice (first run use option -p)
first run:
$ wlancap2hcx -p merged.cap 2602890_DIR-88.cap 2602890_DIR-88.cap
start reading from 2602890_DIR-88.cap
5 packets processed (5 wlan, 0 lan, 0 loopback)
found 2 handshakes without ESSIDs (hashcat -m 2501, john WPAPSK-PMK)
start reading from 2602890_DIR-88.cap
5 packets processed (5 wlan, 0 lan, 0 loopback)
found 2 handshakes without ESSIDs (hashcat -m 2501, john WPAPSK-PMK)
second run:
$ wlancap2hcx -o test.hccapx merged.cap
start reading from merged.cap
10 packets processed (10 wlan, 0 lan, 0 loopback)
total 2 usefull wpa handshakes
found 2 handshakes without ESSIDs (hashcat -m 2501, john WPAPSK-PMK)
found 2 WPA2 AES Cipher, HMAC-SHA1
and everthing is fine:
$ wlanhcxinfo -i test.hccapx -e
DIR-88
DIR-88
This isn't a bug in wlancap2hcx because the tool is designed to work together with wlandump-ng.
And both tools are working on complete authentications(!) and not on beacons, as a beacon is not part of an authentication sequence.
And keep in mind:
beacons can change!
associationrequests/associationresponses in an authenticationsequence never change!
wlancap2hcx need the ESSID received before the handshake follows! Mainly the ESSID is taken from an associationrequest (priority 1).
If you got some caps, that are manually cleaned like this one:
http://zalil.su/2602890
M1
M2
M3
M4
beacon
wlancap2hcx will show you that result:
$ wlancap2hcx -o test.hccapx 2602890_DIR-88.cap
start reading from 2602890_DIR-88.cap
5 packets processed (5 wlan, 0 lan, 0 loopback)
found 2 handshakes without ESSIDs (hashcat -m 2501, john WPAPSK-PMK)
Now you have 2 choices
1) use wlangenpmkocl to generate PMK's for ESSID DIR-88 (not a good idea)
2) run wlancap2hcx on this cap twice (first run use option -p)
first run:
$ wlancap2hcx -p merged.cap 2602890_DIR-88.cap 2602890_DIR-88.cap
start reading from 2602890_DIR-88.cap
5 packets processed (5 wlan, 0 lan, 0 loopback)
found 2 handshakes without ESSIDs (hashcat -m 2501, john WPAPSK-PMK)
start reading from 2602890_DIR-88.cap
5 packets processed (5 wlan, 0 lan, 0 loopback)
found 2 handshakes without ESSIDs (hashcat -m 2501, john WPAPSK-PMK)
second run:
$ wlancap2hcx -o test.hccapx merged.cap
start reading from merged.cap
10 packets processed (10 wlan, 0 lan, 0 loopback)
total 2 usefull wpa handshakes
found 2 handshakes without ESSIDs (hashcat -m 2501, john WPAPSK-PMK)
found 2 WPA2 AES Cipher, HMAC-SHA1
and everthing is fine:
$ wlanhcxinfo -i test.hccapx -e
DIR-88
DIR-88
This isn't a bug in wlancap2hcx because the tool is designed to work together with wlandump-ng.
And both tools are working on complete authentications(!) and not on beacons, as a beacon is not part of an authentication sequence.
And keep in mind:
beacons can change!
associationrequests/associationresponses in an authenticationsequence never change!