Mode 22000 Bad file descriptor

[Mem5]

Using hashcat-5.1.0 beta 1610 :

Code:

hashcat.exe -m 22000  hash dic

works OK with sample hash WPA*01*9d42bfc4ab79cf3a3a85761efd2a0cf0*e8e61d2bfe07*e21f445660bb*3c3429452aba22e9a7a6*** (passwd hashcat)

but if I add a username :
username:WPA*01*9d42bfc4ab79cf3a3a85761efd2a0cf0*e8e61d2bfe07*e21f445660bb*3c3429452aba22e9a7a6***

Code:

hashcat.exe -m 22000  --username  hash dic
hashcat (v5.1.0-1610-g4b166317) starting...
...
Hashfile 'hash': Bad file descriptor
No hashes loaded.

Why ? Thanks.

[ZerBea]

Using hashcat-5.1.0 beta 1610 :

Code:

hashcat.exe -m 22000  hash dic

works OK with sample hash WPA*01*9d42bfc4ab79cf3a3a85761efd2a0cf0*e8e61d2bfe07*e21f445660bb*3c3429452aba22e9a7a6*** (passwd hashcat)

but if I add a username :
username:WPA*01*9d42bfc4ab79cf3a3a85761efd2a0cf0*e8e61d2bfe07*e21f445660bb*3c3429452aba22e9a7a6***

Code:

hashcat.exe -m 22000  --username  hash dic
hashcat (v5.1.0-1610-g4b166317) starting...
...
Hashfile 'hash': Bad file descriptor
No hashes loaded.

Why ? Thanks.

Wrong hash format. Username isn't allowed in 22000.
Neither PMKID (WPA 01) nor EAPOL (WPA 02) have a username.

[Mem5]

Any reason to not support it ? All other modes have the username implementation.
I guess this is a Feature Request for github

[atom]

As long as -m 22000 has backward compatibility mode enabled, the mode is internally set to binary hashfile. This mean you can actually use a .hccapx as well as a PMKID hashlist as well as the new -m 22000 format hashlist use as input hashfile for this mode.

There was never the possibility to use --username for modes which are registered with OPTS_TYPE_BINARY_HASHFILE.

In a future version in which we will drop backward compatibility mode the --username will work automatically and the same way as in other modes.

[Mem5]

Ok. Legacy..
Mode 16800 does support --username as it's only hex. That's why I thought mode 22000 (hex as well) would support it as well.
Anyway thanks for your common work to merge 16800 and 2500 + optimization + ..

[ZerBea]

We decided not to use ASCII characters, because:

Wireless network stacks must still be prepared to handle arbitrary values in the SSID field!
Using HEX instead of ASCII makes it easier to use common tools on a hashline, because we must not take care about character encoding. And there are tons of them. Read more about character encoding here:
https://en.wikipedia.org/wiki/Character_encoding

802.11 allow every value inside an ESSID. Read more here:
https://en.wikipedia.org/wiki/Service_se...1_network)
"Unlike basic service set identifiers, SSIDs are usually customizable. These SSIDs can be zero to 32 octets (32 bytes) long, and are, for convenience, usually in a natural language, such as English. 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."

The new hashline is designed to be published on websites, too - regardless of the character encoding!

The ESSID (salt) is part of PBKDF2 (PBKDF2(PRF, Password, Salt, c, dkLen)). Missing values, due to false character encoding, will lead to unrecoverable hashes.

[Mem5]

Hi Zerbea,
Fully agree to use hex instead of ASCII.

My initial question was why mode 16800 accepts --username but mode 22000 does not, because both inputs are in hex.
Having a look at the source code I now see that mode 16800 does not have option OPTS_TYPE_BINARY_HASHFILE, like @atom said, while mode 2500 & 22000 do have.

[ZerBea]

Thanks. Now, I understand. Please forgive me - I'm old...
16800 can be used for similar hash types from other sources, too - while 22000 not. 22000 is designed for use on WiFi only.

[Mem5]

No worries
Amazing job you've done BTW.

[ZerBea]

BTW:
This is a nice feature request on the new hashline:
https://github.com/hashcat/hashcat/issues/2290
I'm playing around with latest commit (Atom added this feature). Now it's easy to correlate hashcat hits with hcxpcaptool converted hashlines to find the best options for the next hashcat task. Starting with hcxpcapngtool --all --ignore-ie --eapoltimeout=10000000 --nonce-error-corrections=1024 --max-essids=10 and, as a result of this options, a big hash file, I was able to reduce the hash file size for the next hashcat task by choosing the best options/values.