Yahoo! Messenger version 6 (I'm not interested in version 5) stores
the password of the last user logged in, in the registry. But it is in
an encrypted form.

The registry key is: "HKEY_CURRENT_USER\Software\Yahoo\Pager", Name:
"EOptions String".

I need a function that, given inputs EncodedPassword and UserName,
returns the correct DecodedPassword.

It could be in any programming language, as long as the logic or
algorithm is clear.

For testing, I made a Yahoo username: "test1598" with password: "secret".
The encoded password is: "Qey0JgreGczYO6BV4hxrVxTodCg5J71L8Y7mnUDZ9Q--".

As far as I know, it is encoded form of the password, using username
as the key, but I could be wrong.

Thank you.

---

Clarification of Question by daisuki-ga on 19 Jan 2005 01:38 PST

I'm a developer of a currently-selling software product. Our customers
are mainly *legal* investigators from US. For Yahoo! Messenger version
5, we knew the process to decode it. But after several months
researching, we had no success in decoding encoded password of YM
version 6.

It is not used for illegal activities.

---

Request for Question Clarification by cynthia-ga on 19 Jan 2005 08:11 PST

Would a password recovery application, that shows what is under the
asterics, be satisfactory?

~~Cynthia

---

Clarification of Question by daisuki-ga on 20 Jan 2005 03:38 PST

No, I need to decode the password programatically. Usually not all
data is recoverable on the computer that is investigated. Even a
partial password, if it's recoverable, would be useful. That's why I
need to decode the password directly.

---

Clarification of Question by daisuki-ga on 26 Jan 2005 20:15 PST

Some more hints from my trying:
1. It is encoded in base-64 (6 bits for each character), and the
characters used in the base-64 is
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789._"
In the end of encoded string, sometimes it's embedded with "-"
characters (seems to fill the zeros if the total number of bits is not
multiples of 6.
2. The longer the password, the longer the encoded password will be. 
3. You can try to know how YM encode the password, by putting arbitary
user name and password on the login dialog. As long as you checked the
"Save Password" checkbox, the password will be saved even if the
password is not valid.

A researcher will likely avoid this questions unless you can provide a
good reason why you want to do this.  Google Answers does not help
with illegal activty.

--Nelson
(not a researcher)

I'm a developer of a currently-selling software product. Our customers
are mainly *legal* investigators from US. For Yahoo! Messenger version
5, we knew the process to decode it. But after several months
researching, we had no success in decoding encoded password of YM
version 6.

It is not used for illegal activities.

They're probably not encryting the password, it's probably a one-way
hash function. If I recall correctly, you can't decrypt one-way hash
functions. What Yahoo probably does, is hash the password the first
time, store it in the registry, and then the next time you login, they
hash the entered password and compare the hashes. If the hashes are
the same...then you can login. If not, then it is the wrong password.
If a hash function produces the same output for two different password
inputs, then the hash is considered broken. So basically, if they do
this, you're hosed. Common hashes are MD5, and SHA. UNIX does it this
way, and it is fast, Yahoo probably does the same.

http://burtleburtle.net/bob/hash/index.html#one-way

I'm sure it's not a one-way hash function. A product I know can
successfully decode the password. Also, the encoded string gets longer
as the password gets longer.

Trying username "test1598" and password "secret" gives me a variety of
encrypted data stored in the registry:

QfiCrAADb8L6ZtE2wNiZ_35LCzUU2jwUdqv1vWYRfg--
QfiC0QAEAJjHQRNnp3QEVHs3OGf_Vn1o.VICIEJwww--
QfiDWwAGGmCXhvMu6IxzGDGFIEVacThHdBhRjvzCeg--
QfiDbQAGYsSyiSo3Dy7domVYWjJUIlxbHVIfZSgNxw--
QfiDmQAHDvJRsxhwx.cXC5zkQ3ITJ2tpyFQEEJfcjQ--
QfiDxwAHwlRwMDVAwThnTwonjSHUYVHF9Ipn8eR0eA--
QfiD2wAIDiJfRMD6hGW67BQDpTd6Zl8SEJlwUBoSUQ--

those were all in sequence. Interesting things to note are the following:
-7th character is always 'A'
-Same beginning "Qfi" and end "--" for all entries
-Appears to "rotate" through the 4th and 6th characters. Seemingly if
I keep trying this same username/password combination the 'D' in
position 4 will rotate over to 'E'. Sure enough, the next output for
this username/password combo is:
QfiEpgALKS0.eH4luywJ7IDb00QbDDlDK7rvVknhNA-- followed by
QfiEPgAJkMYw7wEzDQjosJDqx_4UexAgmfdCAQAlcQ--
-The 3rd last character seems to switch between a group of 2
characters, at first it is g/w, then A/Q. Incidently, both of these
are 16 ascii characters away from each other.

Changing the password to "secret1" results in:
QfiFpQAPDLTcknbVDc4Jbg9LO1hACeglmBrVgM45qIM-

It appears that the 'A' in pos 7 remains and the QfiF pattern remains.
Changing the username to "test15981" results in:
QfiGRQARe_9EgqD9LCQ.iVECKDRfRnC1NtpOfuYMrQ--

The prefix pattern remains. Maybe they're doing some "enigma"esque
rotation scheme but the first six letters are the same. Pretty
interesting problem.

Thanks very much to you, I didn't realize that every time the password
is saved, the encoded password is different.

So I tried 20 times logging in using username=a and password=a, and
got this result:

Qfi9YwAADhlmyos_pwaGWEwUmZwv_WTfbw8-
Qfi9fQAAdRAwzzOaDiRF.2aoClhtbd5R_PY-
Qfi9igAAqV_4Su1bS5cEoSmHTY.zXfWFTqs-
Qfi9lQAA1DgpSrNKjKA5uVWMTpVjo4Jvx8E-
Qfi9oAAA_uKqRMvIg36sCpIePk3H5jzrGMg-
Qfi9qwABJtwnhK.3pkP_.dh7IC.m8_diNhs-

and so on...

Converting it from 6-bit charset to 8-bit charset, taking the first
bit as the MSB, it results in this pattern:

41 F8 BD 63 00 00 0E 19 66 CA 8B 3F A7 06 86 58 4C 14 99 9C 2F FD 64 DF 6F 0F
41 F8 BD 7D 00 00 75 10 30 CF 33 9A 0E 24 45 FB 66 A8 0A 58 6D 6D DE 51 FC F6
41 F8 BD 8A 00 00 A9 5F F8 4A ED 5B 4B 97 04 A1 29 87 4D 8F B3 5D F5 85 4E AB
41 F8 BD 95 00 00 D4 38 29 4A B3 4A 8C A0 39 B9 55 8C 4E 95 63 A3 82 6F C7 C1
41 F8 BD A0 00 00 FE E2 AA 44 CB C8 83 7E AC 0A 92 1E 3E 4D C7 E6 3C EB 18 C8
41 F8 BD AB 00 01 26 DC 27 84 AF B7 A6 43 FF F9 D8 7B 20 2F A6 F3 F7 62 36 1B

Examining further, I found a lot of hints!

The first 4 bytes is the number of seconds since 1-1-1970.
The next 4 bytes is the number of milliseconds since YM is started.

After trying a lot, I found also, that the last 16 bytes is absolutely garbage!

In an example, 
41 F8 BD 63 00 00 0E 19 66 CA 8B 3F A7 06 86 58 4C 14 99 9C 2F FD 64 DF 6F 0F
\_________/ \_________/ \___/ \_____________________________________________/

  Seconds    ms since    XXX      GARBAGE GARBAGE GARBAGE GARBAGE GARBAGE
 since 1970  YM starts


So, the XXX is the encoded password, and the key of the encoding is
the first 8 bytes + username. (I was able to verify this, If I change
one of the 8 bytes or the username, the password could not be decoded
by YM.)

Since in this trial, the password is "a", which is 0x61, the 66 CA
above should decode into 61 00 (in hex).

Trying this method several times, I found that the password is only
XORed with something (in this case 07 CA, because 66 CA xor 07 CA ==
61 00 which is the string "a" with null terminator)

The problem is now how to get the value that will be XORed with the
encoded password to get the decoded password?

It should be derived from the 8 first bytes + username..

Can someone help me please ... Thank you!

I'm not too convinced that the last part is just garbage. It seems
like all of our one letter passwords always have the '-' character at
the end.

You can see the encoded 6-bit charset password is always multiples of
4 in length, and if you see the bits, it will always multiples of 8.

With no "-":
The last 4 characters: XXXX
convert it to bits: xxxxxx xxxxxx xxxxxx xxxxxx
pack it to 3 bytes: \_______/\_______/\_______/

With 2 "-": (3 "-" never happens)
The last 4 characters: XX--
convert it to bits: xxxxxx xx0000 ------ ------ ('0' means the bit 
                                               is always zero, check it!)
pack it to 1 byte : \_______/

With 1 "-":
The last 4 characters: XXX-
convert it to bits: xxxxxx xxxxxx xxxx00 ------ 
pack it to 2 bytes: \_______/\_______/

These were all obtained at 1-27-2005, at 5:00 pm PST.

QfmOkAA_Mjl6YDHGExlliyJiYty9XnxDSWI-
QfmOkAA_MY0UOW4pwsCRCg87.f0KwecF_mE-
QfmOkAA_Mgrt6AaFNmv5lJXZCOIC3J4MZd0-
QfmOkAA_Mjl6YDHGExlliyJiYty9XnxDSWI-
QfmOkAA_MT.sLho6btbeH1q4moevKgTCMms-
QfmOkAA_MpauzgM59Mrp3z70YNot1m_gwyY-
QfmOkAA_MdsEs2U0qrb8cyid7qKqD9bnek8-
QfmOkAA_M1LhfSrlecAtkGImv0hLX88.DqQ-
QfmOkAA_MZwX4vTz5dk9yUckVmfmy_ilxpk-
QfmOkAA_Mjl6YDHGExlliyJiYty9XnxDSWI-

this was at: 4:59:59
QfmOjwA_MDWZ7vODpw3xAlzdhtqbT2iFt6E-

this was at: 4:59:58
QfmOjgA_KzSgMMRm_esa8O_I1hkA6dAq.nk-

Interesting things about this run include the three EXACT encryptions
done at 5, the first, fourth, and last ones are identical. Also the
first 9 characters are all the same for the same time. For nearly
identical times the first 5 characters are the same. Building a
program that sets the clock to a specific time might help in solving
this problem. At least you could take the time factor out.

More 5:00 encryptions.

QfmOkAA_MnflSA1s3L9xAdLoZ6NgtG9MzY4-
QfmOkAA_MzM4ZYpy7Xm00wEoLiS7t2LppSU-
QfmOkAA_M2GuQK_rt3RF4K0H7.v.BdeLSRY-
QfmOkAA_MnflSA1s3L9xAdLoZ6NgtG9MzY4-
QfmOkAA_MU5LlN_Yc0V5v_SUcPNtrMKbf3k-
QfmOkAA_Mikq3eDe8.OL.ikKr62ZB6e_kBY-

Was able to match the "...A_Mn..." entry too. I'm thinking the
position of the 'n' character is the most precise time it keeps track
of, and once the time is exactly the same then the entire encrypted
string becomes the same.

Hmm, seems interesting. How do you set the time? (what is the windows API name?)
How often do you set it?

Sorry, all I did was change the clock time by hand by double clicking
on the time and trying to click "Sign on" as soon as the second hand
ticked over to 5:00. MSDN probably has some library call that you can
use to set the time.