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: Identifying hash type
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hello there.

I'm actually stumbled as to what those 22 character hashes are.

vwJ8zfry/aXXXGkX+04NgQ
Aa4gbGXXTGH1DeVt7kA5QA
XcIQXXXTfywAEl+3eXHgKA
y5pwXXXvzCUoYBmwil2lpQ

Obfuscated as per the forum rules. Don't seem to be base64. Obtained during a pentest of a custom CRM developed ca. 2002.

hash-identifier (https://code.google.com/p/hash-identifier/) doesn't seem of much help.

Any ideas?

Thanks.
forumhero, i guess you missed

(01-14-2015, 10:52 PM)wflme Wrote: [ -> ]Obfuscated as per the forum rules.

wflme, will be nearly impossible to know with any degree of certainty without having the source. But, it is possible that it is something simple like base64(md5_raw(pass)), then s/=//g

Are they all precisely 22 chars in length?

Do you see X03MO1qnZdYdgyfeuILPmQ in the list anywhere?

Actually a faster way to test might be to just do something like:

Code:
while read h; do echo "$h==" | base64 -d | xxd -p; done < hashlist > new_hashlist

Then try cracking new_hashlist as -m 0 and see what happens.
Quote:wflme, will be nearly impossible to know with any degree of certainty without having the source. But, it is possible that it is something simple like base64(md5_raw(pass)), then s/=//g

Are they all precisely 22 chars in length?
Yep, every one on them is precisely 22 chars long.

Quote:Do you see X03MO1qnZdYdgyfeuILPmQ in the list anywhere?
I don't actually. I assume it's "password".

root@foobar:~# echo "X03MO1qnZdYdgyfeuILPmQ==" |base64 -d |xxd -p
5f4dcc3b5aa765d61d8327deb882cf99

Yes it is. By the way, from what I can tell, "==" is totally optional from /usr/bin/base64's perspective.

Quote:Actually a faster way to test might be to just do something like:

Code:
while read h; do echo "$h==" | base64 -d | xxd -p; done < hashlist > new_hashlist

Then try cracking new_hashlist as -m 0 and see what happens.
You really hit the nail on the head with this one. Turns out those are originally perfectly legit MD5's.

Never would've thought to hex dump the base64 encoded string. Definitely a first for me. Is this even remotely common practice?

Thanks a lot, epixoip. Really saved my bacon there.
Cool, glad that's what it was.

By the way, you're not hex-dumping the base64-encoded string; you're hex-encoding the base64 decoded string. Remember that hashes are binary, so we have to have some way of representing them in a human-readable format. The most common way we do this is encoding with hex or base64.

base64 encoding the raw hash value is common practice with applications written in languages that don't provide a simple hashing API. And oftentimes people feel like if they use an alternate alphabet or remove padding characters that it provides some additional security. It doesn't.
Actually the common practice of storing hashes as a hex-string is just as stupid as using a simple hash function like md5 for protecting passwords. Just a waste of space.