11-20-2021, 05:48 PM
Thank you for sending this, I really appreciate the detail.
So to make sure I understand: The issue is that the Hash Monster is filtering out certain packets (namely, undirected probe requests) before writing to pcap, and the hxcpcapngtool is looking for those, and other useful frames that aren't being properly captured. Also, the additional info that the tool is looking for can only be stored in pcapng format.
Since you rightly pointed out that the output of the Hash Monster is pcap (not pcapng), I ran the capture through the old hcxpcaptool as well:
reading from 0001.pcap
summary capture file:
---------------------
file name........................: 0001.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 (105)
endianness.......................: little endian
read errors......................: flawless
minimum time stamp...............: 01.01.1970 00:29:03 (GMT)
maximum time stamp...............: 01.01.1970 14:53:18 (GMT)
packets inside...................: 1357
skipped damaged packets..........: 0
packets with GPS NMEA data.......: 0
packets with GPS data (JSON old).: 0
packets with FCS.................: 0
beacons (total)..................: 55
beacons (WPS info inside)........: 4
beacons (MESH-ID inside).........: 2
EAPOL packets (total)............: 1274
EAPOL packets (WPA2).............: 1274
PMKIDs (zeroed and useless)......: 1
PMKIDs (not zeroed - total)......: 1
PMKIDs (WPA2)....................: 2
PMKIDs from access points........: 1
best handshakes (total)..........: 5 (ap-less: 0)
best PMKIDs (total)..............: 1
summary output file(s):
-----------------------
0 handshake(s) written to test.pcap
-----
I'm still fuzzy on this point:
>Unfortunately neither cap nor pcap file format is able to store additional information that will help to recover the PSK.
Does this mean that no handshakes or combination of frames captured in pcap format can be used to crack the PSK? Or only that these particular tools want more information to make the process "easier"?
Is there a toolchain for taking pcap files, without the additional frames that hxcpcapngtool is looking for, and pass them to Hashcat for cracking?
So to make sure I understand: The issue is that the Hash Monster is filtering out certain packets (namely, undirected probe requests) before writing to pcap, and the hxcpcapngtool is looking for those, and other useful frames that aren't being properly captured. Also, the additional info that the tool is looking for can only be stored in pcapng format.
Since you rightly pointed out that the output of the Hash Monster is pcap (not pcapng), I ran the capture through the old hcxpcaptool as well:
reading from 0001.pcap
summary capture file:
---------------------
file name........................: 0001.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 (105)
endianness.......................: little endian
read errors......................: flawless
minimum time stamp...............: 01.01.1970 00:29:03 (GMT)
maximum time stamp...............: 01.01.1970 14:53:18 (GMT)
packets inside...................: 1357
skipped damaged packets..........: 0
packets with GPS NMEA data.......: 0
packets with GPS data (JSON old).: 0
packets with FCS.................: 0
beacons (total)..................: 55
beacons (WPS info inside)........: 4
beacons (MESH-ID inside).........: 2
EAPOL packets (total)............: 1274
EAPOL packets (WPA2).............: 1274
PMKIDs (zeroed and useless)......: 1
PMKIDs (not zeroed - total)......: 1
PMKIDs (WPA2)....................: 2
PMKIDs from access points........: 1
best handshakes (total)..........: 5 (ap-less: 0)
best PMKIDs (total)..............: 1
summary output file(s):
-----------------------
0 handshake(s) written to test.pcap
-----
I'm still fuzzy on this point:
>Unfortunately neither cap nor pcap file format is able to store additional information that will help to recover the PSK.
Does this mean that no handshakes or combination of frames captured in pcap format can be used to crack the PSK? Or only that these particular tools want more information to make the process "easier"?
Is there a toolchain for taking pcap files, without the additional frames that hxcpcapngtool is looking for, and pass them to Hashcat for cracking?