hashcat Forum
Using hashcat (GPU) with simple hash function - Printable Version

+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: Using hashcat (GPU) with simple hash function (/thread-8474.html)



Using hashcat (GPU) with simple hash function - bopfactor - 07-09-2019

Hello, I need to find a string from a hash generated with this simple function:

Code:
uint64_t hash_func(const char *s, size_t len)
{
    uint64_t hash = 0;

    for (size_t i = 0; i < len; ++i)
        hash += (s[i] * s[i] * s[i] * s[i] * s[i]);

    return (hash);
}

Is there any way I could use hashcat with GPU calculations to find the string ? Or if you know any other tool with fast GPU calculations in which I can plug this function I'd be happy to know.

Thanks!


RE: Using hashcat (GPU) with simple hash function - undeath - 07-09-2019

If you implement your own module you can use hashcat for this. btw, that's a bloody stupid hash function.


RE: Using hashcat (GPU) with simple hash function - DanielG - 07-09-2019

Wow what a weird hash, this will have a lot of collisions since the value of every letter is just raised to the 5th power and added, so the order of the letters does not matter (so you will most likely find more than one string). The string "abc" has the same hash as "cba" and "bac" etc...

This is also just some basic addition so making a brute forcer in C and running it on all your CPU cores would already be really fast. You might want to try that before making a GPU variant.

Also if you look at the 'hash' you can also make a guess to the length range of the input. For example assuming standard ascii string input (letters, numbers, special chars) and a hash of 335544320, then if you divide it by 122^5 (letter z) and 32^5 (space) you will see the string length is most likely between 1 and 10 long.


RE: Using hashcat (GPU) with simple hash function - bopfactor - 07-09-2019

(07-09-2019, 04:54 PM)DanielG Wrote: Wow what a weird hash, this will have a lot of collisions since the value of every letter is just raised to the 5th power and added, so the order of the letters does not matter (so you will most likely find more than one string). The string "abc" has the same hash as "cba" and "bac" etc...

This is also just some basic addition so making a brute forcer in C and running it on all your CPU cores would already be really fast. You might want to try that before making a GPU variant.

Also if you look at the 'hash' you can also make a guess to the length range of the input. For example assuming standard ascii string input (letters, numbers, special chars) and a hash of 335544320, then if you divide it by 122^5 (letter z) and 32^5 (space) you will see the string length is most likely between 1 and 10 long.

(07-09-2019, 04:54 PM)undeath Wrote: If you implement your own module you can use hashcat for this. btw, that's a bloody stupid hash function.

Thanks for your replies, I know it's a very simple hashing function, I don't need to find a particular string, just one which fits a given hash, so collisions are fine. Your length guessing trick doesn't seem to be working for high numbers like this one for example: 396018663018502 (the one I have is very similar (same number of digits)), division by 122^5 gives 14652.6609277 and by 32^5 gives 11802275.8668, it's because the function has overflows. Anyway I'll try to implement a C brute forcer running on all my CPU cores as you advised and if it's not enough I'll look into hashcat modules.


RE: Using hashcat (GPU) with simple hash function - DanielG - 07-10-2019

Okay, I tried to run this code locally and there is indeed a bug if I take the code you posted literally.

The code
Code:
hash += (s[i] * s[i] * s[i] * s[i] * s[i]);

does not produce the correct value because on the right side it is multiplying 32-bit ints (that's what my compiler says even though they are chars) before adding it into a 64 bit result. It will overflow before adding so converting that will cause strange results (97^5 will result in 4292372961 instead of the correct value 8587340257 for example). I think this is what you mean with 'it's because the function has overflows'.

If this wasn't the case you could easily calculate back a string to fit any value (by dividing it with the numbers I mentioned earlier).

This unfortunately also means it's a bit harder to make a GPU variant because you need to account for the incorrect adding and overflows.