Yeah, I think you've got the wrong end of the stick.
Let's say I hack a server and I find a password file in plaintext (i.e. let's say the password is "hello", the password would be stored in the file as simply "hello").
Now to make it more secure, the server owner might decide to use a hashing algorithm (such as md5 or base64) to protect the password.
The point of hashing is that you can encrypt the password into a load of garble - but you can't decrypt it, even if you had the entire algorithm in front of you, it is 100% impossible to decrypt it. Sounds sort of impossible but this is how it's done:
I'm going to show you a really basic and really insecure hash. In real life it'd be much more complicated and secure, but the principal is the same.
I enter the password "abc".
The hashing algorithm is "a=1,b=2,c=3, d=4 etc etc".
abc = 1+2+3 = 6.
Therefore if I found the hash of "abc" it'd be "6".
Now I cannot get the actual password back out of that though I can guess. This is called bruteforcing.
You can get programs (such as 'Cain and Abel') that will repeatedly test a hash to try and get the password.
Keeping with our really rubbish hashing algorithm, the program would test it like this:
Test 'aaa': 1+1+1 = 3, is hash '3'? No, try again.
Test 'aab': 1+1+2 = 4, is hash '4'? No, try again.
Test 'aac': 1+1+3 = 5, is hash '5'? No, try again.
Test 'aad': 1+1+4 = 6, is hash '6'? Yes - stop testing.
Using the algorithm "a=1, b=2 etc", if your password is 'abc', you can also enter 'aad' and 'bbb' and countless other combinations. That is a poor algorithm, of course. A good algorithm like md5 would take ages to bruteforce as there are so few possibilities.
Now, having written all that, I'm starting to think you might be wondering where hashes are usually stored..
On a Unix server, generally taking a look around the directory "etc" is always a good idea.
Learning Unix directory structure would be a good idea: http://docweb.cns.ufl.edu/docs/d0107/ar07s03.html
Hope that helped,