Hi strike1953.
Well, I hope so. I didn't see any chance to save during runtime calculated values in a better way. The option field of pcapng seems to be a good way to do that.
Wireshark is an absolutely fantastic analysis tool (my favourite), so it's good to be compatible with that nice tool. Also I noticed, that wireshark opens a pcapng file much faster than an old cap/pcap file (32bit alignment, permit backward file navigation, ...).
Since hcxtools running in the background of https://wpa-sec.stanev.org/? , pcapng capture files are accepted by the server, as well as gz compressed files (pcapng, cap, pcap).
Last but not least can we provide the following hashcracktool with all values requiered by the cracking procedure:
dumper/attacker -> conversiontool -> hashcracker -> database
(for example: hcxdumptool -> hcxpcaptool -> hashcat -> wpa-sec database)
We do this allready in a very simple way, using the messagepair field in the hccapx record.
Well, I hope so. I didn't see any chance to save during runtime calculated values in a better way. The option field of pcapng seems to be a good way to do that.
Wireshark is an absolutely fantastic analysis tool (my favourite), so it's good to be compatible with that nice tool. Also I noticed, that wireshark opens a pcapng file much faster than an old cap/pcap file (32bit alignment, permit backward file navigation, ...).
Since hcxtools running in the background of https://wpa-sec.stanev.org/? , pcapng capture files are accepted by the server, as well as gz compressed files (pcapng, cap, pcap).
Last but not least can we provide the following hashcracktool with all values requiered by the cracking procedure:
dumper/attacker -> conversiontool -> hashcracker -> database
(for example: hcxdumptool -> hcxpcaptool -> hashcat -> wpa-sec database)
We do this allready in a very simple way, using the messagepair field in the hccapx record.