Yahoo! Messenger Protocol

The Yahoo! Messenger Protocol (YMSG) is the underlying network protocol used by the Yahoo! Messenger instant messaging client. Yahoo! Instant Messager supports many features beyond just messaging, including off-line messaging, file transfer, chat, conferencing, voice chat, webcams and avatars.

Overview

The YMSG protocol provides a language and series of conventions for software communicating with Yahoo!'s Instant Messaging service. In essence, YMSG performs the same role for Yahoo!'s IM as HTTP does for the World Wide Web. Unlike HTTP, however, YMSG is a proprietary protocol, a closed standard aligned only with the Yahoo! messaging service. Rival messaging services have their own protocols, some based on open standards, others proprietary, each effectively fulfilling the same role with different mechanics.

One of the fundamental tenets of instant messaging is the notion that users can see when someone is connected to the network—known in the industry as 'presence'. The YMSG protocol uses the mechanics of a standard internet connection to achieve presence—the same connection it uses to send and receive data. In order for each user to remain 'visible' to other users on the service, and thereby signaling their availability, their Yahoo! IM client software must maintain a functional, open, network connection linking the client to Yahoo!'s IM servers.

As some organizations block communication on the port used by Yahoo! IM, either because they choose to whitelist certain types of internet usage (only web surfing and email, for example) or because they seek to blacklist instant messaging services, Yahoo! provides an alternative route for connecting to their service which mimics the HTTP protocol used by the World Wide Web. However, because HTTP has no inherent sense of a persistent connection, Yahoo! instead relies on the client frequently contacting the server in order to approximate the sense of a connection required to give each user presence on the IM network.

Originally the YMSG login procedure suffered from a security flaw known as a replay attack, in which a given password (or other authentication information) is always identically scrambled when sent across the network. This allowed any attacker who witnesses the transmission to merely reproduce the message verbatim in order to successfully log in, without actually needing to know the original password (or other details) which generated it. But some time around 2000 or 2001, Yahoo! upgraded its service to introduce a random element to each login attempt, defeating any further potential for replay attacks.

With the exception of the login authentication details, data sent over a YMSG connection is not encrypted. YMSG uses a binary format in which the text portions of the data are transmitted in plain view. Therefore, while it is difficult for an attacker to seize control of a Yahoo! IM account, it is quite easy for them to read all messages sent to and from the account holder, along with other details such as the list of friends, if the attacker has control of one of the computers through which the data is routed.

Technical overview

The YMSG protocol communicates between the client application, and a server, using a TCP/IP connection on port 5050 by default. Other ports may be used if this port is blocked. Alternatively, an HTTP route is available for clients behind a well-secured firewall, with HTTP requests being used to upload messages from the client, while downloading all messages which have accumulated on the server since the last request.

The client remains logged in for as long as the TCP/IP connection is kept open. Or, in the case of a client connected via HTTP, until the client fails to send a request for some time ('ping' messages are sent every thirty seconds or so).

YMSG packets consist of a twenty byte header, that consists of four bytes for "YMSG", two bytes for the version (current is version 19),two bytes for the vendor id (typically 0), two bytes for the packet length(content only, does not include the 20 byte header), two bytes for the Service(the type of ymsg packet), 4 bytes for the Status(not related to buddy status, though is used to log in as invisible), and four bytes for the Session id. The rest of the packet is a variable length table of key/value pairs, where the key is an ASCII representation of a numeric code representing the field type, and the value is its associated data. A two byte separator, the hexadecimal values C0 and 80, are used to delimit each entry in this table.

Some parts of YMSG rely on other protocols. For example, file transfer is initially negotiated using YMSG, but the actual transfer of the file is done via HTTP. Webcams also use YMSG to discover and request permission to view, but HTTP to actually feed JPEG 2000 images from one client to another. Chatroom categories, rooms and lobbies are retrieved using HTTP as XML documents. Regular webcam connections use H.323. Yahoo! with Voice uses SIP. For calls, VoIP is handled indirectly by Yahoo! servers so the chat client does not have direct access to it. Yahoo! Chat and Conference Voice however use an older form of audio compression called TrueSpeech, developed by the DSP group.

The chatroom categories can be retrieved from here.

Login

The login process is a multi-step process that spans two protocols. The client, after successfully establishing a TCP connection to a ymsg server, sends an authentication packet that contains the user name that the user wishes to log in with to the YMSG server. The YMSG server then responds with an authentication packet containing a challenge string in key/value field 96. The HTTPS process then starts, connecting to login.yahoo.com, and sending the token_get string that is constructed with the username and password of the account the client is trying to log in with. The HTTPS response to the token login if successful will contain a token string. Then another HTTPS request is sent to login.yahoo.com with the token_login that is constructed with the token. If successful, the response will contain three strings: a crumb, Tcookie, and YCookie. The client then combines the crumb and challenge strings and performs an MD5 hash on the combined string, then converts the resulting 16-byte value to a Base64 string, and performs a very negligible amount of manipulation on the resulting Base64 string by making three character replacements ( '+' with '.', '=' with '-', and '/' with '_' ). The resultant Base64 string is then used in building the AuthenticationResponse packet, whose key 307 contains the resultant Base64 string value. The client then sends the AuthenticationResponse packet. If the AuthenticationResponse packet is successful, the client then will receive the List, ListV15, StatusV15, NewMail, Ping, and any number of Y7 Buddy Authorization and Message packets (for offline messages, and buddy requests). The List packet contains all the aliases to the user accounts YahooID, the ListV15 contains the users friends, groups, and ignored user list. The StatusV15 packet contains the users from the listV15 that are online, busy, or idle, as well as any status messages those users may have, and potentially a string that represents the resource on another HTTP server that is that user's display image.

See also

This article is issued from Wikipedia - version of the 7/12/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.