Integer overflow detected in keyspace of mask

[baba]

can i know what wrong??? 

Minimum password length supported by kernel: 64
Maximum password length supported by kernel: 64

Watchdog: Temperature abort trigger set to 90c

Integer overflow detected in keyspace of mask: ?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?
1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1

[Chick3nman]

What the hell are you trying to crack? There is almost no way you will ever be able to run a mask that large unless your custom character is like, 1 character. And even then, there must be a better way. A 64 character mask is absolutely not ideal or feasible for basically anything I can think of.

[baba]

What the hell are you trying to crack? There is almost no way you will ever be able to run a mask that large unless your custom character is like, 1 character. And even then, there must be a better way. A 64 character mask is absolutely not ideal or feasible for basically anything I can think of.

-m 2501 -1 abcdef0123456789 ?1??1?.......................

[epixoip]

Keyspace is stored as an unsigned 64-bit integer. 16^64 is much, much larger than 2^64 - 1.

You might want to do the math on how long it would take to crack 16^64.

[Chick3nman]

[ZerBea]

2501 and 16801 hash modes are designed to verify (pre-)calculated PMKs. Latest hashcat use this modes to detect already recovered passwords, by testing the hash against the PMK (take a look at new hashcat potfile format: PMK : ESSID : PSK).

It doesn't make sense to try to recover a PMK by a mask.

BTW:
Captured WPA1/2 hashes (EAPOL and PMKID) are not static. They depend on AP and CLIENT values like MAC and NONCE. Some of them change from connect attempt to connect attempt (NONCE). While the PMK is unique for a WPA1/2 network (unless the PSK doesn't change) old md5_64 and PMKID aren't. This is the reason for the new potfile format!

[baba]

Thankssssssssss
can i know any Exp??? PMK : ESSID : PSK
please how to do??

[undeath]

the answer hasn't changed since last year. https://hashcat.net/forum/thread-7749-po...l#pid41663

[MERON]

Is it possible that we can limit the number of random passwords to be used in brute force so that we can counter the problem of integer overflow 

Ex - say that the length of password is long enough to trigger overflow 
If we command it like hash and compare first 100 trillion permutstions  and save our progress then start for the next 100 trillion or maximum permutations handled by hashcat