Hex ch and small problem

[epixoip]

It's not a buffer overflow, and it's not the number of instructions. The issue is hashcat stores keyspace as a uint64 which means the maximum value it can store is 2^64 -1. It cannot work with numbers larger than this. The only way to work around this is to move everything to uint128, which would be... tedious.

And also the keyspace is simply way too large to brute force. You'll never crack the key.

[ccprime]

now I know everything
Thank you guys for the explanation and for your time
and I'm sorry that I was so troublesome

[ccprime]

As I said, you can't BF 3des keyspace (integer overflow, too).

there is a way to run 14100 without "integer overflow" ?
any way ?

[atom]

There's actually two ways: Use multiple masks with N constants in it to divide the total keyspace or a large rewrite of hashcat. But both can't help you. Such an integer overflow just shows that your keyspace is too large to handle, except you have like 500 GPU or so running.

[ccprime]

We cannot do just simple scan? 
Like in des.char just start from 01 03....  etc 
We dont need to calculate how long it takes or how many combinations are 
Just to make it works
I have few tools to brute 3des but they are works only on CPU and ofcourse are too slow 
Also you write somewhere here that for DES can be few diferent keys to encrypt decrypt the same data so i belive that for 3des can be the same 

Just simple scan

Edit 
Yes i know that the CPU is not the same that GPU 
Maybe if we have for example 5k cores use just half?