hccapx is an outdated custom format, specifically developed for hashcat.

The hccapx is an improved version of the old hccap format, both were specifically designed and used for hash type -m 2500 = WPA/WPA2.

A valid hashcat binary hash file (file extension: .hccapx) contains one or more instances of the struct type documented below. If you have several single .hccapx files which you want to merge into a single file (say multi.hccapx), you can accomplish this by just concatenating all files together:

Linux:

cat single_hccapxs/*.hccapx > all_in_one/multi.hccapx

Windows:

copy /b single_hccapxs\*.hccapx all_in_one\multi.hccapx

or select single ones:

copy /b single_hccapxs\1.hccapx + single_hccapxs\2.hccapx all_in_one\multi.hccapx

We strongly recommend that you use cap2hccapx from hashcat-utils to convert .cap files to .hccapx files and use these generated .hccapx files as input to hashcat.

hccapx files are binary files (not plain text files). If you want to inspect this type of files, you should use a hex editor (like xxd on linux). If you try to open .hccapx files directly with you text editor you will only stare at a seemingly random set of bytes.

The structure of .hccapx is detailed belowed and the screenshot/image shows you exactly where the offsets are with an easy example.

The signature of a .hccapx file is always “HCPX” (or 0x58504348):

#define HCCAPX_SIGNATURE 0x58504348 // HCPX

The .hccapx format also contains a version number. The current version is 4 (the first version number used for .hccapx files was 2. You can think about it this way: the old .hccap was version 1).

struct hccapx
{
  u32 signature;
  u32 version;
  u8  message_pair;
  u8  essid_len;
  u8  essid[32];
  u8  keyver;
  u8  keymic[16];
  u8  mac_ap[6];
  u8  nonce_ap[32];
  u8  mac_sta[6];
  u8  nonce_sta[32];
  u16 eapol_len;
  u8  eapol[256];

} __attribute__((packed));

Note: each .hccapx structure has 393 bytes (with offset 0 - first byte - to offset 392 - last byte -)

¹ message_pair was extended with some additional information: the highest bit could be used to indicate if the message pair matching was done based on replay counter or not. Whenever the highest bit (bit 8) was set to 1 it means that the replay counter was ignored (i.e. it was not considered at all by the matching algorithm):

Hashcat currently does not perform any particular action based on this bit, but nonetheless this information could be crucial for some 3th party tools and for analysis/statistics. There could be some opportunity to implement some further logic based on this particular information also within hashcat (in the future).

The message_pair value describes which messages of the 4-way handshake were combined to form the .hccapx structure. It is always a pair of 2 messages: 1 from the AP (access point) and 1 from the STA (client).

Furthermore, the message_pair value also gives a hint from which of the 2 messages the EAPOL origins. This is interesting data, but not necessarily needed for hashcat to be able to crack the hash.

On the other hand, it could be very important to know if “only” message 1 and message 2 were captured or if for instance message 3 and/or message 4 were captured too. If message 3 and/or message 4 were captured it should be a hard evidence that the connection was established and that the password the client used was the correct one.

The following table lists all values currently allowed for the message_pair field:

Note: M1 means message 1 of the handshake, M2 means message 2 of the handshake, M3 means message 3 of the handshake and M4 means message 4 of the 4-way handshake