Please note, this is a STATIC archive of website hashcat.net from 08 Oct 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.

hashcat Forum

Full Version: [Newb] Mask attack on FNV1a-32
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi guys,

I have 10 hashes of an ASCII string, hashed with FNV-1a 32bit variant, which i'd like to get the original string from back.
I searched the supported hashes list but FNV isn't there, google pointed me to an issue which didn't seem of any relevance.
Is it somehow possible to use Hashcat for this task? I know FNV isn't a cryptographic hash.
Writing my own hashcracker for this seems a really big job, which I'd like to avoid.

I also know that a lot of collisions could be discovered, but it know (parts of) the mask of these string:
/(prefix\.)([a-z0-9_]+.)+([A-Z][a-zA-Z0-9]+)/
This is basically a package name, i can definitely recognize the correct one if it see it. The total length of the string shouldn't be longer than 60 chars.

What are my options if this is not possible with (the current version of) HashCat?
Should i then look into trying to fork and introduce this behaviour myself? If yes, any quick-start pointers on how?

Thank you in advance,
Bert
There's no way to get back the original string, since there's too much data lost. All you can do is to collide it. Since it's a 32 bit checksum, you will be flooded with possible collisions, even on CPU.
(07-14-2018, 11:03 PM)atom Wrote: [ -> ]There's no way to get back the original string, since there's too much data lost. All you can do is to collide it. Since it's a 32 bit checksum, you will be flooded with possible collisions, even on CPU.

Hi Atom, thank you for your reply.

I had to think a bit about what you mean with "All you can do is to collide it.". I suppose you meant that i should find another value which hash result is the same as one of the hashes i have?
That's sadly not a solution to my problem, because i'm trying to recover the exact semantics encoded within the original strings.
I thought there might have been a slight chance at recovery through some incremental tinkering on a matching formula, but you're right. 32 bits is not a big space.
Given this information i have to figure out something else.

Thank you for your time.