WPAx: proposal for a new hash line format (successor of hccapx)

[ZerBea]

hccapx is a custom format, specifically developed for hashcat.
The structure of .hccapx is fix and we are not able to handle
new "attack verctors" like PMKID. Also we waste GPU time,
because we have to run hashcat on WPA-EAPOL-PBKDF2 (2500)
and WPA-PMKID-PBKDF2 (16800) even we have a PMKID hash
and an EAPOL hash using the same network name. If we combine
both hashmodes to a single hashline, we will get full advantage
of reause of PBKDF2 on both hash types. Therefore we need a
new and more flexible hash format.
Handle WPA-EAPOL-PBKDF2 (2500) and WPA-PMKID-PBKDF2 (16800)
and WPA-EAPOL-PMK (2501) and WPA-PMKID-PMK (16800) in a single hashline.

1
The following entries are mandatory to calculate the PMK
using PBKDF2:
ESSID

2
The following entries are mandatory to crack the hash
in hash mode WPA-PMKID-PBKDF2 (16800):
mac_ap
mac_sta
PMKID

3
The following entries are mandatory to crack the hash
in hash mode WPA-EAPOL-PBKDF2 (2500):
mac_ap
mac_sta
nonce_ap
EAPOL_sta

In case of hash modes WPA-EAPOL-PMK (2501) and
WPA-PMKID-PMK (16800), we do not need step 1.

In case of AKM-defined 4-weay handshakes (WPA3, SAE, FILS, EAP),
we do not need step 1, too.
https://hashcat.net/forum/thread-7717-post-42759.html#pid42759

Also we should use a hexified hashline (only hex values, especially for ESSID)
like we do it allready by 16800 hashlines. We get advantage to
handle this hash lines with simple bash commands instead
of several tools to retrieve informations about the binary hccapx.
Also hexified ASCII hash lines can be can be easily posted
in varius forums (hashkiller, antichat,...).

Putting this ideas into a single hashline, it could look like this one:

hashcat should run WPA-PMKID-PBKDF2 and WPA-EAPOL-PBKDF2 on this hashline
mac_ap * mac_sta * PMKID * ANONCE * ESSID * EAPOL

hashcat should run WPA-PMKID-PBKDF2 on this hashline
Received only a PMKID
mac_ap * mac_sta * PMKID * * ESSID*

hashcat should run WPA-EAPOL-PBKDF2 on this hashline
mac_ap * mac_sta * * ANONCE * ESSID * EAPOL

hashcat should run WPA-PMKID-PMK and WPA-EAPOL-PMK on this hashline
mac_ap * mac_sta * PMKID * ANONCE * * EAPOL

hashcat should run WPA-PMKID-PMK on this hashline
Received only a PMKID
mac_ap * mac_sta * PMKID * * *

hashcat should run WPA-EAPOL-PMK on this hashline
mac_ap * mac_sta * * ANONCE * * EAPOL

Additional we can add a control field (0000) to
allow hcxtools to parse informations to hashcat,
like:
message_pair
use only PMK mode
use only EAPOL mode
has is AKM-defined and requires SHA_384 mic calculation instead of SHA-256
...
example:
mac_ap * mac_sta * PMKID * ANONCE * ESSID * EAPOL * control_field

[magnumripper]

only hex values, especially for ESSID

Also, IIRC when parsing the ESSID hex field we should store the length and never use strlen() on the resulting data. So an ESSID of 6d6167006e756d should have length set to 7.

[ZerBea]

Hi magnum.
Are you sure, we need an additional ESSID len field in the new hash line?
For example:

• 6d6167006e756d *
  The parser must do a validity check
  1: count characters between the 2 stars: 14
  2: ESSID len = chars /2
  3: Do we have hex values (%2 ==0) and are they valid (0..9, a..f, A..F)

It's similar to the 16800 hash line ESSID (which doesn't contain an ESSID len field).

[ZerBea]

ESSID
These SSIDs can be zero to 32 octets (32 bytes) long.
The 802.11 standards prior to the 2012 edition did not define any particular encoding/representation for SSIDs, which were expected to be treated and handled as an arbitrary sequence of 0–32 octets that are not limited to printable characters. The IEEE 802.11-2012 defines a tag that the SSID is UTF-8 encoded and when interpreting could contain any non-ISO basic Latin characters within it. Wireless network stacks must still be prepared to handle arbitrary values in the SSID field.
That is a good reason to use hex values instead of trying to convert an ESSID to printable characters in hash lines.

EAPOL - we should allow oversized EAPOL len. Found this ones during wpa-sec analysis:
256, 258, 262, 270, 278, 288, 294, 306, 310, 322, 326, 330, 334, 342, 358, 370, 374, 386, 390, 406, 422, 438, 484, 500, 502, 510
$ hcxpcaptool -V --eapol-out=eapols caparchiv/2018*
$ cat eapols | awk 'BEGIN { FS = ":" } ; { print $NF }' | awk '{print length}' | sort | uniq
BTW:
I'm preparing to implement more analysis options to hcxtools.

CONTROL FIELD:
Right now we use pcapng comment field to parse additional informations from attacker/dumper to the conversion tool.
It would be great if we can use a CONTROL FIELD to parse additional informations from the conversion tool to the hash cracker.
attack/dumptool --pcapng--> conversion tool --control field--> hash cracker

And it would be awesome if we can use the potfile to parse additional information from hash cracker to the data base (but this will we another proposal: improved potfile line):
attack/dumptool --pcapng--> conversion tool --control field--> hash cracker --potfile--> data base

Than, to complete the WPAx cycle, we can think about a feed back from the data base to the attacker/ dumper:
data base --xxxxx--> attack/dumptool

[ZerBea]

We have no additional field for MIC and key ver, because we can retrieve them from EAPOL,
as well as the length.
Please keep in mind that we must expect more than the the allready implemented length:
PMK_LEN_MAX 64 (32, as yet)
WPA_EAPOL_KEY_MIC_MAX_LEN 32 (16, as yet)

Also please notice, that we have a new key descriptor value (0=AKM-defined instead of 1=wpa1, 2=wpa2 , 3=wpa2 key ver 3) on AKM-defined handshakes.
Exampel is here:
https://hashcat.net/forum/thread-7717-post-42759.html#pid42759
Right now hcxpcaptool will set this value to 3 (AES-128-CNC), so that hashcat is able to run hash mode 2501 on that handshakes (currently that works on SAE, but it's a really, really ugly hack). In future times we can use the control field to parse AKM-defined data to the cracker.

[RealEnder]

Also we should not forget LE/BE/ap-less info in control field. How do you extract MIC and keyver from EAPOL, eg. gor example EAPOL value here: https://hashcat.net/wiki/doku.php?id=hccapx?

[ZerBea]

These are the 2 structs for an authentication frame and a wpa-key frame:

struct eapauthentication_frame
{
uint8_t version;
uint8_t type;
#define EAP_PACKET 0
#define EAPOL_START 1
#define EAPOL_LOGOFF 2
#define EAPOL_KEY 3
#define EAPOL_ASF 4
#define EAPOL_MKA 5
uint16_t len;
uint8_t data[1];
} attribute((packed));
typedef struct eapauthentication_frame eapauth_t;
#define EAPAUTH_SIZE offsetof(eapauth_t, data)

struct wpakey_frame
{
uint8_t keydescriptor;
uint16_t keyinfo;
uint16_t keylen;
uint64_t replaycount;
uint8_t nonce[32];
uint8_t keyiv[16];
uint64_t keyrsc;
uint8_t keyid[8];
uint8_t keymic[16];
uint16_t wpadatalen;
uint8_t data[1];
} attribute((packed));
typedef struct wpakey_frame wpakey_t;
#define WPAKEY_SIZE offsetof(wpakey_t, data)

So it's easy to lay the struct over the EAPOL frame, using bash commands.
Let's take the example from above and get EAPOL data:
$ hcxpcaptool -V sae4way.pcapng --eapol-out=example
reading from sae4way.pcapng
summary:
file name....................: sae4way.pcapng
file type....................: pcapng 1.0
file hardware information....: x86_64
file os information..........: Linux 4.18.16-arch1-1-ARCH
file application information.: hcxdumptool 5.0.0
network type.................: DLT_IEEE802_11_RADIO (127)
endianess....................: little endian
read errors..................: flawless
packets inside...............: 15
skipped packets..............: 0
packets with GPS data........: 0
packets with FCS.............: 0
beacons (with ESSID inside)..: 1
probe requests...............: 1
probe responses..............: 1
association requests.........: 1
association responses........: 1
authentications (SAE)........: 4
EAPOL packets................: 7
EAPOL PMKIDs.................: 1
best handshakes..............: 1 (ap-less: 0)

Now let's get the MICs:
$ cat example | cut -c 189-220
c652368806f943802f8f57789e1a20d1
60e5524831cfaff7438ae1c365b9a9e4

an the key ver:
$ cat example | cut -c 40-40
8
8
8
a
a

explanation:
8 = AKM-defined, pair wise key
a = WPA2, pair wise key (hcxpcaptool attack vector to downgrade to WPA2 - failed!)

Or we can add some options to the conversion tool to extract this informations, additional for a data base.

Please keep in mind that we use only single EAPOL data for this tests, not a complete, new hash line.
If we need fix positions, we should change position from * ESSID * EAPOL * to * EAPOL * ESSID *

[ZerBea]

Maybe it's necessary to increase control field size ( * 00000000 * ) to parse more informations to cracker. Current informations:
nonce error corrections needed on BE
nonce error corrections needed on LE
nonce error corrections needed on BE/LE
no nonce error corrections needed (hash is a result of an AP-LESS attack vector - we should split this)
Information of message pair is not necessary, because we can retrieve this from EAPOL data

new :
use AKM-defined MIC / PMKID calculation (SHA_192, SHA384, SHA_512, AES-128-CNC for SAE/FILS/WPA3)
use PMK len 64
PMKID received from AP or PMKID received from CLIENT (we got the first one of this kind)
no nonce error corrections needed
hash is a result of an AP-LESS attack vector

[magnumripper]

Hi magnum.
Are you sure, we need an additional ESSID len field in the new hash line?

No, I meant when parsing that field we need to look at its length instead of doing a strlen on the result. So hashcat and JtR should have a len field in whatever struct is holding the data, but the input field doesn't need it.

[ZerBea]

I am a little blinded, because I analyzed plenty of cap files during the last week to test the new hash line. Reuse of PBKDF2 over EAPOL and PMKID makes cracking process really, really fast.
The same applies to reuse of PMK over EAPOL and PMKID.
So thanks for your explanation.
BTW:
From my point of view (hcxtools) a concerted hash line for hashcat and JtR would be fantastic!!!

[ZerBea]

Some early words about the potfile.
It would be great to retrieve a potfile line, containing main informations about the result, like this one:
mac_ap * mac_sta * PMK * PMKID * control field * ESSID (in hex) : PSK
Parsing this kind of information, the hash cracker (hashcat) become part of the whole analysis process. It can add additional informations (for example: how the PSK was retrieved) to the control field and parse it to the data base.

[ZerBea]

More words about the potfile:
Right now, hashcat use a md5_64 hash over EAPOL (and some other fields, like mac, anonce, ESSID) to make a hash unique and to remove duplicates. Unfortuneatelay an EAPOL message contains several values of counters and many flags, which changes from hash to hash. So hashcat calculates on every hash a new md5_64. A better way is to use the calculated PMK to make the network (and not the hash) unique. That will work, even if the incomming new hash has no ESSID or a damaged ESSID. That is a real benefit of a combined hash line (2500, 2501, 16800, 16801) and a combined potfile line ((2500, 2501, 16800, 16801). Also it will keep the potfile small.

[ZerBea]

How can we help?