Please note, this is a STATIC archive of website hashcat.net from 08 Oct 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.

 

hccapx format description

Description

hccapx is a 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 cap 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

cap2hccapx recommendation

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.

For your convenience, hashcat.net also allows you to convert .cap files on the fly with an easy to use online converter that you can find here: https://hashcat.net/cap2hccapx . It is intended for users who dont want to struggle with compiling the source code of cap2hccapx

Format overview

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).

Screenshot

hccapx_specs.jpg

C Structure

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));

Detailed Structure

Field name Offsets (hex) Offsets (dec) Field description
signature 0x00 to 0x03 0 to 3 the signature (file magic) of .hccapx files, it is always the string HCPX
version 0x04 to 0x07 4 to 7 the version number of the .hccapx file format
message_pair 0x08 8 possible values range from 0 to 5 or 128 to 133 (see message_pair table below) 1
essid_len 0x09 9 the length of the network name (ESSID)
essid 0x0a to 0x29 10 to 41 the network name (ESSID)
keyver 0x2a 42 set to 1 if WPA is used, other values (preferably 2) means WPA2
keymic 0x2b to 0x3a 43 to 58 the actual hash value (MD5 for WPA, SHA1 for WPA2) truncated to 128 bit (16 bytes)
mac_ap 0x3b to 0x40 59 to 64 the mac address of the access point (BSSID)
nonce_ap 0x41 to 0x60 65 to 96 nonce (random salt) generated by the access point
mac_sta 0x61 to 0x66 97 to 102 the mac address of the client connecting to the access point
nonce_sta 0x67 to 0x86 103 to 134 nonce (random salt) generated by the client connecting to the access point
eapol_len 0x87 to 0x88 135 to 136 the length of the EAPOL
eapol 0x89 to 0x188 137 to 392 the EAPOL (max 256 bytes)

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

1 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):

message_pair (hex) message_pair (dec) Highest bit Meaning
0x00 to 0x05 0 to 5 0 Message pair according to table below with replay counter matching
0x80 to 0x85 128 to 133 1 Message pair according to table below, replay counter was ignored

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).

Message pair table

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:

message_pair value Messages of the handshake Source of the EAPOL AP message STA message Replay counter matching
0 M1 + M2 M2 M1 M2 Yes
1 M1 + M4 M4 M1 M4 Yes
2 M2 + M3 M2 M3 M2 Yes
3 M2 + M3 M3 M3 M2 Yes
4 M3 + M4 M3 M3 M4 Yes
5 M3 + M4 M4 M3 M4 Yes
128 M1 + M2 M2 M1 M2 No
129 M1 + M4 M4 M1 M4 No
130 M2 + M3 M2 M3 M2 No
131 M2 + M3 M3 M3 M2 No
132 M3 + M4 M3 M3 M4 No
133 M3 + M4 M4 M3 M4 No

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

Except where otherwise noted, content on this wiki is licensed under the following license: Public Domain