I have to tell I am not that experienced in such things. My first intuitive thoughts for this problem:
1. Somehow (identifying the program used or simply debugging) determine the decryption method used. You don't have to rev.eng. it completely, it is enough if you know how the first some bytes of a file are decrypted having a password given.
2. Find some files where you know what the content should be. Just an example: .exe files should begin with MZ.
3. Examine what matters in the passwd. Sometimes case doesn't matter, look for such things.
4. Write a small prog that tries all different passwds (different in the sense of 3.) to decrypt just those some special files/bytes and check their content (does the decrypted .exe starts with MZ?). This way you will have some passwd candidates.
5. Iterate this method till you will have only few passwd candidates.

Most encryption methods use one-way calculations that means though it is simple to calculate the result having the pass, it is practically impossible to retrieve the pass having the result.

(Once I was given a crypted dBase V file, I had to retrieve the pass. It turned out that only the lower 4 bits of the characters did matter, and there were lots of tricky calculations with the data where sometimes data were lost because of overflows. These calculations were iterated a lot of times so it was practically impossible to create the inverse.
I cut the decrypt part and put it in a small prog that tried the possibilities and it reported the good pass in some hours. (I just had to correct the upper bits in some letters and I had the word 'shoelace'.))

HTH