hccapx is an outdated custom format developed specifically for hashcat.

The hash modes that read this format are deprecated. hashcat refuses -m 2500, -m 2501, -m 16800 and -m 16801 and tells you to use -m 22000 instead. --deprecated-check-disable forces them to run, but the format itself cannot carry what 22000 carries. Convert your capture with hcxpcapngtool and use the 22000 workflow.

The hccapx format is an improved version of the old hccap format. Both were designed for hash mode -m 2500 (WPA/WPA2).

A valid hashcat binary file (with the .hccapx extension) contains one or more instances of the structure documented below. To merge several .hccapx files into one file (for example, multi.hccapx), concatenate them:

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 using cap2hccapx from hashcat-utils to convert .cap files to .hccapx files. Use the generated files as input to hashcat.

hccapx files are binary, not plain-text files. To inspect one, use a hex editor (such as xxd on Linux). If you open an .hccapx file in a text editor, you will see what looks like a random set of bytes.

The structure of .hccapx is detailed below. The screenshot also shows the offsets in a simple example.

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

#define HCCAPX_SIGNATURE 0x58504348 // HCPX

The .hccapx format contains a version number. Version 4 is the latest version of this format. Earlier .hccapx files used version 2. The old .hccap format used 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 takes no action based on this bit, but the information may be useful to third-party tools and for analysis or statistics. Hashcat could also use it in the future.

The message_pair value describes which two messages from the four-way handshake were combined to form the .hccapx structure. The pair always consists of one message from the AP (access point) and one from the STA (client).

The message_pair value also indicates which of the two messages the EAPOL comes from. This is interesting data, but not necessarily needed for hashcat to be able to crack the hash.

It can also be important to know whether only messages 1 and 2 were captured, or whether messages 3 and/or 4 were captured as well. Capturing message 3 or 4 is strong evidence that the connection was established and that the client used the correct password.

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