AES-128 and Integer overflow detected in keyspace of mask

[strcmp]

Hi.

I'm trying to make myself familiar with hashcat.
I would like to get the right command arguments to crack 16 bytes crypt to 16 bytes plain using AES-128 (also 16 bytes).
All hex!

Code:

$ hashcat-7.1.2>hashcat -m 26401 hashes.txt -o cracked.txt -a 3 ?h?h?h?h?h?h?h?h?h?h?h?h?h?h?h?h -w 4
...
OpenCL API (OpenCL 3.0 CUDA 13.0.84) - Platform #1 [NVIDIA Corporation]
=======================================================================
* Device #01: NVIDIA GeForce RTX 2080 SUPER, 8191/8191 MB (2047 MB allocatable), 48MCU

./OpenCL/m26401_a3-optimized.cl: Pure kernel not found, falling back to optimized kernel
Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 16
Minimum salt length supported by kernel: 0
Maximum salt length supported by kernel: 51

Hashes: 2 digests; 2 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Optimizers applied:
* Optimized-Kernel
* Zero-Byte
* Not-Iterated
* Single-Salt
* Brute-Force

Watchdog: Temperature abort trigger set to 90c

Host memory allocated for this attack: 1065 MB (51006 MB free)

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

Started: Thu Oct 09 17:25:39 2025
Stopped: Thu Oct 09 17:25:42 2025

When I use a mask of 15 bytes only, it works.
17 bytes is beyond hashcat design.
Can I do something to make this 16 bytes mask work?

Thanks

[penguinkeeper]

Firstly, you're using ?h which is hexadecimal, so it would search for abcdef0123456789, not full bytes, which would be ?b
Secondly, 16x?h itself is absolutely gigantic, it's 18.4 quadrillion / ~18,446,744,000,000,000,000 possible candidates, which isn't even close to the actual size of what you want to do, which is 16 bytes with ?b. In that case, it'd be 340,282,366,920,938,463,463,374,607,431,768,211,456 possible candidates, both of which are entirely unsearchable, especially by a 2080 Super.

AES-128 remains mostly secure and the only way to crack the keys without any other information is to know a large portion of it

[strcmp]

Thanks for the fast response!

Actually, it's all hex. I forgot to mention in the OP (corrected).
Example of hashes.txt

Code:

45a32b45274d523f29528e53f4eea320:64b25e189238b3cc59e46e39ff726432

I also came up with 3.4e38 candidates.

What if I would know the first 2 (of the 16) bytes of the key?
This would reduce the candidates to 14.
What would be the mask syntax?

[penguinkeeper]

In your example, you have 32 hexadecimal characters, which makes your mask half the size it should be, which blows it up into the same 3.4e38, which also makes it unsearchable. Even if you have the first 2 bytes, it doesn't matter and is still far, far, far from searchable but you can just replace the "?h"es with your known character, like "b3?h?h?h..."

[strcmp]

In your example, you have 32 hexadecimal characters, which makes your mask half the size it should be, which blows it up into the same 3.4e38, which also makes it unsearchable. Even if you have the first 2 bytes, it doesn't matter and is still far, far, far from searchable but you can just replace the "?h"es with your known character, like "b3?h?h?h..."

Feasibility - yes, not possible, but as I said, I try to get the correct command syntax

Mask - not sure if your mask is correct. I'm looking for hex code.
Assuming I know the first (0x00) and the last byte (0xFF).
1. "00?h?hff" -> "Candidates.#01...: 00acff -> 00f7ff"
2. "00?b?bff" -> "Candidates.#01...: 00niff -> $HEX[3030ffff6666]"

1. is your mask. I believe this is text in hex code, but I need hex.
2. with "?b", it's wrong as well.

Adding the argument "--hex-charset" does the job (I believe).
3. "00?b?bff" -> "Candidates.#01...: $HEX[006172ff] -> $HEX[00ffffff]"

I don't know why the candidate doesn't start with 0x000000ff, but the mask looks fine this time.

[Chick3nman]

This is normal. Hashcat doesn't run "0 1 2 3 4 5 6 7 8 9" in order for masks, it runs an optimized ordering using a built in markov model trained on real passwords to bring the "most likely to be real" to the front of the keyspace. It will still test everything, just in the order the markov model dictates.

[penguinkeeper]

(And if you want to turn off the above, you can use --markov-disable but there's no reason to)