PROGRAMMERS: Yahoo Protocol #2

[zappa_engine]

It may be time to document the other Yahoo protocol (the one where CAPTCHA's are not needed).

So here's some information for developers. Yahoo can talk to clients in two ways. Most of us developers are already familiar with the first way, which is implemented within YtoICS clones and Chessy clones similarly. Yahoo initiates the contact (handshake), sends an encryption key, and information is encoded along with data needing to be packed in UTF format.

The other way, [this protocol information has been edited out, sorry guys].

Anyhow I came across this information while I was trying to log into the games room sans captcha. I realized after examining data packets, there was a different protocol speak going on.

This is something that may be researched further on.

[zappa_engine]

This is the detailing of the first protocol used by JAVA clients, YtoICS clones, and Chessy clones. This is straight off the YICS website.

The Yahoo! Chess Protocol

Handshake

The Y! Chess server operates on port 11999. Upon connection, the server sends the string ``YAHOO!'' (no newline). The proper response is ``Y'' (again, no newline).

As far as number formats, when you see an ``X-byte (whatever) length'' format, the number will be a big-endian.

Encryption/Decryption

After this, the server will send a random sequence of exactly 8 bytes. The first 4 bytes will be used to create an encryption key for outgoing data, and the second 4 bytes will be used to create a decryption key for incoming data.

It is recommended that you store each stream in a separate object instance. As we will see, however, the two stream objects can be from the same class.

The first thing that should be done in the instantiation of the objects is to initialize the key, which should be a 4-byte signed integer. Set this integer to the value of the key. For example, if the 4 bytes were, in hex, 44 90 07 6f, the key would have the value 1150289775.

Now that the key is initialized, you can begin streaming data through it. When the decryption/encryption function receives the data, it must iterate over every character of it. For each character, you must:

1) Multiply the key by 83 and overwrite the old key with this new one. Note that overflowing is desired. (In Perl you have to jump through some hoops to get overflowing to happen.)

2) XOR the current character with the key value. Overflowing is desired here too. (In Perl, just modulus the final value by 256.)

This function will both encrypt and decrypt the same data so long as the same key is used.

UTF strings

The Yahoo! Chess server mainly uses UTF strings, which are composed of a 2-byte numerical length indicator, and then the actual string. So the string ``Hello, World!'' would be encoded as such:

00 13 48 65 6c 6c 6f 2c 20 57 6f 72 6c 64 21

So whenever you see a format indicator that says ``UTF handle'', what it really means is ``2-byte handle length, (handle length)-byte handle''.

NOTE: UTF strings are actually a bit more complicated, but you don't need to worry about that unless you're in a locale that uses a Multi-Byte Character Set (MBCS).

Logging In

Normally servers require a username and password first, right? Well the Yahoo! Chess server wants to know what room you want to enter first. First send an 'o' (hex 6f), and then the UTF room ID. For example, to enter room ``games.room.chess_y'':

6f - The 'o'.

00 12 - 18 characters in the ID. (Remember that 18 in hex is 12.)

67 61 6d 65 73 2e 72 6f 6f 6d 2e 63 68 65 73 73 5f 79 - ``games.room.chess_y''.

The server's response will be identical. 6f and UTF room ID. After this the server will send a 4-byte numerical ID for the room. Store this for later use.

After that, the server will immediately send 64, the 4-byte numerical room ID, and a UTF data packet. Inside the data packet are three UTF strings. The first should be ``GAMES''; if it's not, then something went wrong and the client should disconnect. The second and third are merely version indicators for the Java applet, and may be ignored. (Each build of the Java applet has different strings here so older versions that have been cached can inform the user that there is a newer version available.)

The client then replies with the login information. This is constructed mainly from the Java applet's parameters, which means you'll need to log in to Yahoo! on the web and get the applet page each time for your login cookie. As with the server, the 64 opcode is used, but with the following format:

Format: 4-byte room ID, UTF packet data.

Packet data format: 1-byte boolean, UTF ``cookie'' param, UTF ``ycookie'' param, UTF ``agent'' param, UTF ``intl_code'' param.

The boolean is on only under a specific circumstance, and I'm not exactly sure what that is. Just write a null byte for now.

A few typical values: The ``cookie'' param is just ``id='' and the Yahoo! ID; for example, ``id=crazycomputers''. The ``agent'' field is just a loop-back of the browser's user-agent identification string. Use whatever you want here. The ``intl_code'' is ``us'' in the United States.

The ``ycookie'' param is created by the main login server, and deciphering it is another project altogether. Just have your client login to Yahoo! via HTTP, and retrieve it from the Set-Cookie response.

To complete the login process, the server will send 64, the numerical room ID, and a UTF string. The string will contain a 1-byte boolean and a UTF string. If the boolean is on, then the string is an error message, and the client should immediately disconnect and display the message to the user. If the boolean is off, then the string is the user's handle.

After this, the login process is complete.

[zappa_engine]

Great news. This protocol has been solved. Actually it was solved about 3 days ago. I have been working with matematiko to flesh out some code to make this compatible with YtoICS code. However, I will not be releasing this work within STUCI Classic for the foreseeable future. It was decided between the two of us that we would rather not showcase public code to by-pass captcha because Yahoo has seen a great downturn of automatic spammers and we would like to keep it that way.

I'm not sure if matematiko will release a version of YaY with this new technology in it, and I haven't decided that I will find a Perl to EXE compiler to obfuscate the code from public view. Anyhow, I most likely won't because of license of STUCI Classic requires I release the source code if I release a binary of the file, so sorry guys. It will be featured within STUCI Windows sometime though so .

And hopefully, this is a message to matematiko, when you compile an EXE, you use extra software to obfuscate the code so people can not decompile the .EXE, otherwise this new technology may end up public anyways.

[matematiko]

Advice very well taken.

And no, no plans to release this in the near feature and if ever release to the public, will be in VB with a code started from scratch and I do not see this happening in a couple of years. For now I will use this only on my personal PC.

Based in the discussion generated over YtoICS Reborn, I will make a release of YaY when I come back from work and include the source code.

[matematiko]

Well...I am sorry folks but I changed my mind about making the source public. You either gonna have to trust me or switch to another script or program, as long as there is plenty of engine-players in Yahoo who to play against I don't mind if they use STUCI or YaY or whatever else.

I will only provide the code to zappa_engine upon request.

Cheers and forgive me for my change of mind.