Limitations in PCAP packet captures

[gcarmix]

kismet should store an ASSOCIATION/REASSOCIATION or PROBERESPONSE, especially if the SSID IE_TAG in the BEACON frame is unset or zeroed.

[ZerBea]

Just to cross-report here too, it would be helpful (calculation of EAPOLTIMEOUT of AUTHENTICATION sequences) for conversion tools to have this kind of frames inside the dump file, instead of a BEACON (that contain less information) only.

[ZerBea]

Added this reference, too https://github.com/s77rt/multicapconverter/pull/6 because it include an example dump file: https://github.com/s77rt/multicapconverter/pull/6#issuecomment-1107361521 which lead to this failed conversion:

$ hcxpcapngtool -o test.22000 cloaked_testwifi.pcap
hcxpcapngtool 6.2.6-1-geb65226 reading from cloaked_testwifi.pcap...

summary capture file
--------------------
file name................................: cloaked_testwifi.pcap
version (pcap/cap).......................: 2.4 (very basic format without any additional information)
timestamp minimum (GMT)..................: 22.04.2022 22:34:48
timestamp maximum (GMT)..................: 22.04.2022 22:34:48
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11 (105) very basic format without any additional information about the quality
endianess (capture system)...............: little endian
packets inside...........................: 5
BEACON (total)...........................: 1
BEACON (SSID wildcard/unset).............: 1
EAPOL messages (total)...................: 4
EAPOL RSN messages.......................: 4
EAPOLTIME gap (measured maximum usec)....: 7623
EAPOL ANONCE error corrections (NC)......: not detected
EAPOL M1 messages (total)................: 1
EAPOL M2 messages (total)................: 1
EAPOL M3 messages (total)................: 1
EAPOL M4 messages (total)................: 1
EAPOL pairs (total)......................: 2

frequency statistics from radiotap header (frequency: received packets)
-----------------------------------------------------------------------
not available due to missing radiotap header

Information: no hashes written to hash files

Warning: out of sequence timestamps!
This dump file contains frames with out of sequence timestamps.
That is a bug of the capturing tool.

Information: limited dump file format detected!
This file format is a very basic format to save captured network data.
It is recommended to use PCAP Next Generation dump file format (or pcapng for short) instead.
The PCAP Next Generation dump file format is an attempt to overcome the limitations
of the currently widely used (but limited) libpcap (cap, pcap) format.
https://www.wireshark.org/docs/wsug_html_chunked/AppFiles.html#ChAppFilesCaptureFilesSection
https://github.com/pcapng/pcapng

Information: radiotap header is missing!
Radiotap is a de facto standard for 802.11 frame injection and reception.
The radiotap header format is a mechanism to supply additional information about frames,
from the driver to userspace applications.
https://www.radiotap.org/

Information: missing frames!
This dump file does not contain undirected proberequest frames.
An undirected proberequest may contain information about the PSK.
It always happens if the capture file was cleaned or
it could happen if filter options are used during capturing.
That makes it hard to recover the PSK.

Information: missing frames!
This dump file does not contain important frames like
authentication, association or reassociation.
It always happens if the capture file was cleaned or
it could happen if filter options are used during capturing.
That makes it hard to recover the PSK.

Information: missing frames!
This dump file does not contain enough EAPOL M1 frames.
It always happens if the capture file was cleaned or
it could happen if filter options are used during capturing.
That makes it impossible to calculate nonce-error-correction values.

session summary
---------------
processed cap files...................: 1

Please also take a closer look at the timestamps:

$ tshark -r cloaked_testwifi.pcap -T fields -e frame.number -e frame.time
1   Apr 22, 2022 22:34:48.378792000 CEST
2   Apr 22, 2022 22:34:48.284874000 CEST
3   Apr 22, 2022 22:34:48.292497000 CEST
4   Apr 22, 2022 22:34:48.295336000 CEST
5   Apr 22, 2022 22:34:48.300662000 CEST

It looks like the BEACON was taken after the handshake was captured, but stored first in the dump file. The conversion tools can handle this on simple dump files, but will fail on dump files captured over a longer period that contain handshakes and PMKIDs of different NETWORKs (especially if the ESSID was changed during capturing time).

Please consider to add the ASSOCIATIONREQUEST or the REASSOCIATIONREQUEST (if used by the CLIENT, we can take the PMKID from here) frame at the beginning of the handshake. Adding an ESSID by hand is not very useful on automated conversion e.g. on a web server.

Please also consider to add more than one M1 frame to allow calculation of NONCE ERROR CORRECTION to detect and compensate missing frames: https://hashcat.net/forum/thread-6361.html

Please also consider to add undirected PROBEREQUEST frames: https://github.com/evilsocket/pwnagotchi/issues/835 This kind of frames are very useful to recover a PSK. An example dump file is here: https://github.com/evilsocket/pwnagotchi/issues/835#issuecomment-598597214