YMSG Protocol Details
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.
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.
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 AuthenticationRepsonse 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.