YY 2015 Reverse Analysis (1) Underlying Communication Mechanism
YY 2015 Reverse Analysis (1) Underlying Communication Mechanism
Foreword
Having previously studied the protocol of YY version 6.2, I recently revisited it and found that the current version, 8.3.0.0, has undergone significant changes. Key exchange no longer utilizes ZLIB compression, and all command words have been completely revised. However, the communication algorithm remains unchanged, utilizing RSA + RC4.
Underlying Communication Process
YY’s packet structure consists of a 4-byte length field, a 4-byte command word, and the remaining data. This structure allows for packet segmentation based on the initial 4 bytes. However, other situations exist, such as nested packets. These occur when a command word packet contains one or more sub-command packets. These sub-command packets may be processed independently or require data from the parent packet.
Initially, the client transmits
UDPpackets to several servers (four, in this case) to request IP addresses. The server then provides a list of servers and corresponding lists that support the received client version number.
1 | 61 00 00 00 1E 73 00 00 C8 00 FF FF FF FF FF FF a....s..?....... |
One of these servers responds with 0x741E, providing the requested IP list. (Other servers may also respond, but the client ceases listening after receiving the first valid response). Note that the byte offset +4 within each packet represents the command word (this convention applies throughout the analysis), as exemplified by 0x731E in this instance.
- From the received IP list, the client randomly selects several servers (six in this example) and sends login requests. Five of these requests utilize
UDP, while one usesTCP. The data payload of these packets is identical.
1 | 34 00 00 00 01 14 00 00 C8 00 00 00 00 00 30 80 4.......?.....0. |
- The fastest-responding server replies with the
0x1501command. The byte at offset +0C contains the feedback result. A value of0xC8indicates success, with the subsequent data containing the IP address and port of the designated login server. Other values, such as97 01 00 00, signify an outdated client version requiring an upgrade.
1 | 54 00 00 00 01 15 00 00 C8 00 00 00 C8 00 00 00 T.......?...?... |
- The actual login process commences at this point. The client randomly selects one server from the received login IP list and establishes a connection. Upon successful connection, the client initiates a key exchange by sending a packet to the server. The command word for this packet is
0x1104or0x3204, varying depending on the target server type, as multiple server types are involved in the login process, including verification, channel, and friend servers.
1 | 53 00 00 00 04 11 00 00 C8 00 40 00 E9 03 40 F2 S... ..?@.?@? |
or
1 | 66 00 00 00 04 32 00 00 C8 00 40 00 E9 03 40 F2 f... 2..?@.?@? |
The byte at offset +4 represents the 0x40 byte, which corresponds to the client-generated public key, specifically the N component of the RSA key pair. The byte at offset +0x4E represents the E component of the RSA key pair. This packet serves to inform the server that the subsequently issued RC4 key is encrypted using this RSA public key.
- Upon receiving the client’s key, the server responds with either
0x3304or0x1504. Previously, the key within this packet was compressed usingzlib; however, this compression has been removed, likely for server-side performance optimization.
1 | 50 00 00 00 04 15 00 00 C8 00 40 00 7B 89 12 1B P.........@.{... |
or
1 | 18 09 00 00 04 33 00 00 C8 00 40 00 22 79 01 D6 .....3....@."y.. |
Notably, in addition to the key, the 0x3304 packet also delivers a bytecode module to the client, responsible for initializing the dynamic environment. Numerous subsequent packets follow this pattern, containing dynamic detection code issued by the server.
The 0x40 bytes starting at offset 0C within these two packets contain the RC4 key encrypted with the server’s RSA private key. After decryption, the resulting RC4 key is duplicated, with one copy designated for encryption and the other for decryption. This marks the completion of the YY key negotiation process. All subsequent data exchanged between the client and server will be encrypted using the established RC4 session key.
The algorithm implementations reside within exported functions of the dwUtility.dll library. The table below provides translations for several relevant functions:
| Exported Function Name | Function |
|---|---|
| DwUtility::dwBaseFunc::dwUtilityrgk | Initialize RSA structure |
| DwUtility::dwBaseFunc::dwUtilityrpd | RSA decryption algorithm |
| DwUtility::dwBaseFunc::dwUtilitybb | Convert large numbers to binary |
| DwUtility::dwBaseFunc::dwUtilityrsk | Initialize RC4 structure |
| DwUtility::dwBaseFunc::dwUtilityr | RC4 encryption\decryption algorithm |
These represent a few key algorithms within the dwUtility.dll library, which contains numerous other basic functions available for further exploration.
Analyzing the communication flow solely with a debugger like OllyDbg (OD) proves challenging due to the mixture of encrypted and unencrypted data, coupled with the multitude of connected sockets. To facilitate analysis, a custom tool was developed to display both the raw and decrypted packet data, differentiating packets based on their associated socket.
Picture lost
End
YY employs a parallel login approach, simultaneously sending requests to multiple (N) servers and utilizing the fastest response. This strategy places demanding performance requirements on the login server cluster, as each server must be equipped to handle a potentially large volume of requests. The key establishment process highlights YY’s emphasis on load balancing and efficient resource utilization.
This concludes the present analysis of YY’s underlying communication mechanism. A future analysis will delve into the specific content and structure of YY login packets.
For inquiries or feedback, please contact bughoho[at]gmail.com.