Automatic Handshake Extraction/Separation and hccapx Generation Tool
#1
Hello all,

Quick Summary
Adds 3 new commands to Pyrit by patching pyrit_cli.py.
  1. strip_best_handshakes: Outputs the highest quality handshake for each AP to a single output (.cap) file.
  2. separate_best_handshakes: Outputs the highest quality handshake to a separate output (.cap) file for each AP.
  3. separate_handshakes: Outputs ALL handshakes in the input file to a separate output (.cap) file.
prepareCaptureForHashcat script: Automatically strips the best handshake for each AP and outputs a .hccapx file for each AP containing only the best handshake.


(While reading this, when I refer to "good", "workable', and "bad", I am referring to Pyrit's classification of the quality of the handhsake.)


I created this repository because I noticed a few issues when running hashcat 4.0.1-79-g7f087d0 on my R9 290 GPU. If more than one handshake was included in the .hccapx file, my cracking speed slowed down. If I performed a capture on my home network over 72 hours, with multiple devices connecting/disconnecting, I ended up with over 150 handshakes in my capture file and in the converted .hccapx file. This was enough to slow my cracking speed down from about 116 kH/s to only 14 kH/s (note, all the handshakes were for the same ESSID). Therefore, I wanted a way to separate the different handshakes from my capture file and only use the single "highest quality" handshake in my .hccapx file so I could obtain maximum speed.

The second issue I noticed was that my capture file with over 150 handshakes included good, workable, and bad handshakes. I wonder if this is what was causing the slow down, perhaps the bad handshakes which were also included in the .hccapx file were generating incorrect hashes and thus hashcat was trying to crack multiple hashes instead of only one. Regardless, I was unsure of how hashcat handles multiple handshakes, especially mixed quality ones, so I wanted a way to strip my capture file down to a single handshake so I knew exactly what hashcat was working with.

The functionality may already exist somewhere, but after searching the web for a couple days I was unable to find a way to split a capture file into individual handshakes. Pyrit could separate by ESSID/BSSID but not individual handshakes, the online hccapxsplitter tool could split the .hccapx file into separate handshakes but then I was unable to find a tool which could detect the quality of a handshake in a .hccapx file. I tried looking at the message_pair in the hexidecimal output from hccapx, per this website https://hashcat.net/wiki/doku.php?id=hccapx, but I noticed that a file with a single "bad" handshake had a 00 in the message_pair location and a different file with a single "good" handshake also had a 00 in the message_pair location so that wasn't giving me enough information to classify the handshake contained in the .hccapx file.

Another feature I desired was the ability to automatically output each ESSID in a capture files to a separate .hccapx file. Furthermore, I thought it'd be nice if the entire post-processing of the capture file (stripping, extracting of handshakes) and conversion to a separate .hccapx for each ESSID was completely automated.

Thus, I created this patch and script to fullfil this need that I had. I ran across several threads in different forums with people searching for similar functionality so I thought I would create a repository and share this with anyone else who may find it useful.  The repository link is below.

https://bitbucket.org/JohnDN90/hashcatpreparationtools

If you find this useful, please let me know!  Also if you find a bug or fix a bug I'd appreciate feedback on that as well.

DISCLAIMER: These tools are intended for use with auditing the security of wireless networks for which you have AUTHORIZATION. This means you may either use it on wireless systems which you own or wireless systems which you obtain permission for from the network owner.
Reply
#2
Hi JohnDN90.
That is a nice tool, and a really like that idea. There is also another attempt to do this (https://github.com/hashcat/hashcat-utils/pull/39). I decided to support both with an option to convert raw handshakes (complete unfiltered) from a cap/pcap/pcapng to a hccapx file. Now you can improve your tools...
... and there is no longer need for hcxtools to do this (so I can remove this ones and focus on the attacker/dumper, the conversion tool and EAP authentications).

Please keep in mind that some tools (aircrack suite) only strip M1M2, even if they have M2 or M3. Keep also in mind that the messagepair 0 is used for an ap-less attack. The handshakes are 100% crackable because the attacker asks the client for for the hash data as long as he didn't receive the comlete EAPOL frame.

Cheers
Reply
#3
(01-17-2018, 12:21 PM)ZerBea Wrote: Hi JohnDN90.
That is a nice tool, and a really like that idea. There is also another attempt to do this (https://github.com/hashcat/hashcat-utils/pull/39). I decided to support both with an option to convert raw handshakes (complete unfiltered) from a cap/pcap/pcapng to a hccapx file. Now you can improve your tools...
... and there is no longer need for hcxtools to do this (so I can remove this ones and focus on the attacker/dumper, the conversion tool and EAP authentications).

Please keep in mind that some tools (aircrack suite) only strip M1M2, even if they have M2 or M3. Keep also in mind that the messagepair 0 is used for an ap-less attack. The handshakes are 100% crackable because the attacker asks the client for for the hash data as long as he didn't receive the comlete EAPOL frame.

Cheers


Hi ZerBea,

Thanks for the link to your tool.  Looks like you really put a lot of work into it and have several nice features, I look forward to trying it out. 

I still don't have a complete understanding of which messages are needed to successfully crack, but your comment starting my searching a little more and it looks like any of the message combinations listed at https://hashcat.net/wiki/doku.php?id=hccapx are crackable (assuming the correct password was used for the client which created the handshake)?  If so, that means even the "bad" handshakes according to Pyrit should be crackable, looking at a few of these in Wireshark they contain M1 and M2.  If that's the cause, I'll probably modify the strip_best_handshakes and separate_best_handshakes commands so they output a "bad" handshake if there isn't anything better available.
Reply
#4
Hi JohnDN90.
Pushed an update some minutes ago. Using Option -O will give you raw handshakes (‎comparable to pyrit: --all-handhakes).
You can use every messagepair to recover the key:
M1M2 (not authenticated)
M2M3 (authenticated)
M3M4 (authenticated) (if M4 snonce isn't zeroed)
M1M4 (authenticated) (if M4 snonce isn't zeroed)
as long as the cracker is able to calculate a valid Pairwise Transient Key (PTK) from data of the captured frames.
Therefore you need exact 3 frames:
- one management frame (containing the ESSID)
- one EAPOL frame from the access point (you can spoof that: ap-less attack)
- one EAPOL frame from the client
Both EAPOL frames must be in relation to each other.
Basically that's all.
Reply