Protocol Analysis TMP

Recently busy, analyzed a very low-end ( very low-end means that you should not be able to replace your existing QQ client to make any possible wishful thinking, she is just an experimental thing ) mobile phone QQ Protocol, is the mobile phone QQ3.0,
The use of the Tcp/http Communication protocol version is 1.4, do not know which year release, at least seven or eight years of the past, it is: The function is very weak !

The main reason is that I want to learn about the network programming experience (this is my 2nd time to get socket programming:-)), and learn how to grasp packet analysis.

The main tools used in the software

Mobile qq3.0:http://www.ruan8.com/soft_5872.html

Kemulator (Java emulator): http://gamevina.us/kemulator-vh/

Wireshark (Protocol analysis): http://www.wireshark.org/download.html

Java Decompiler (Java View (Harmony) tool): http://jd.benow.ca/

Brief introduction to the analysis Process 1. Get Server information

Online analysis of this version of the mobile phone QQ users A few, I also learned that this version is more easy to analyze, the protocol is simple, so ...

First, open this URL: http://conf.3g.qq.com/newConf/kjava/aubin2.jsp

(Note using Unicode encoding, otherwise it might be garbled) and then you'll see something like this:

sererconfig_num=5& serverconfig_type=kqqtcp,kqqtcp,kqqhttp,kqqhttp,kqqhttp& SERVERCONFIG_URL=socket:// 58.60.12.177:14000,socket://211.136.236.88:14000,http://tqq.tencent.com:8000,http://mconn.tencent.com:14000, http://kconn.tencent.com:21001&updataeconfig_num=1& updateconfig_version=2.4.2&updateconfig_must=n & updateconfig_url=http://mq.3g.qq.com/g/s?aid=mqq& updateconfig_helptxt= Please upgrade to 2.4. Version 3 QQ2005 (Java Edition) & Smsservice_num=2&smsservice_name=24 hours online, follow friends & smsservice_address=10661700,1066170056& SMSSERVICE_ text=hq,sqkj%2c| | qqno| | &smsservice_helptxt= do not use mobile Internet, through SMS can be landing QQ, the cumulative online time is really convenient, so you continue to increase the level of QQ!%0 A the current operation needs to be completed by SMS operation, select to send a text message, please follow the SMS prompt to complete the operation! , pay attention to this QQ friend, a friend on the QQ will soon have SMS notice you mobile phone! Anytime and anywhere and TA in QQ "Encounter", the tariff of 10 yuan/month. %0A the current operation needs to be done by SMS operation, select OK will send a text message, please follow the SMS prompt to complete the operation.

which

Sererconfig_num indicates the number of servers currently available
Serverconfig_type represents the server type: KQQTCP represents a TCP server, Kqqhttp represents an HTTP server
Serverconfig_url: Server address
...... (Not important)

Note: The values are separated by commas; Use & symbolic connections between key-value pairs.

As for the mobile phone QQ to use which server, and now do not know, anyway, is one of the filter to try to know.

2. Filtering communication protocols

First open the Wireshark for network packet filtering: Select an active NIC and start.

It should be immediately possible to see that Wireshark has shown a lot of packets ... Too much data, inconvenient to view, so filter show,

Take QQ's first TCP server as an example: Enter the filter expression inside Wireshark's filter expressions and click Apply:

Use Kemulator to run your phone QQ and log in:

Next, if QQ uses the first server, then Wireshark will display the following information:

Yes, you are not mistaken, the agreement can be said to be all clear, completely like the http ...

For example, ver=1.4 representative version number is 1.4, cmd=login that command for login, uin=*** means QQ ....

3. Protocol Analysis

Well, all communication between QQ and server is based on this type of HTTP key-value pair, and some common key-value pairs are listed below:

ver=1.4	Represents the version of the Protocol currently in use, but the version returned by the server may be inconsistent
Con=1	This does not know what the meaning, by viewing QQ code can be seen that it seems to be fixed value 1
cmd=***	The current commands are login, Logout, QUERY_STAT2 and so on.
seq=***	The sequence number of the current command, which identifies the different command sequence numbers, plus 1 on the previous basis on each next send
uin=***	QQ number of the current login, unchanged

Provisions of the command:  
                    each command ends with \ r \ n, which means that no other \ r \ n can be found in the command field, and that the%0d,\r is replaced with a%0d 
                    each command uses UTF-8 encoding, and the comma that appears in the command, & wait for the URL encoding to be translated, or the command will be interpreted by mistake.

1.    logon command: ver=1.4&con=1&cmd=login&seq={seq}&uin={qq}&ps={ps}&m5=1 &lg=0&lc={lc}&gd={gd}&cke=\r\n 
       Server Response:ver=1.1& cmd=login&seq={seq}&uin=2933278370&res=0&rs=0&hi=60&li=300&sg=***&ssg= 207390864\r\n 
                    SEQ Serial number should be the same as when you send it, or it is wrong.  
                    Res=0 successfully responds to &NBSP on behalf of the server;
                    Rs=0 on behalf of successful, others are failure; If failure: There is an appropriate RA field to identify the error message, such as password error!

If you have a SID or comp field, remember to save it, because some of the commands you don't understand later use them. Other things like Hi and Li don't know what it is.
If there is a VC field, then the need to verify the code information, I have been testing for a long time, has not encountered, temporarily do not say this ...

2. Get all your QQ friends and their basic information
Command: ver=1.4&con=1&cmd=simpleinfo2&seq={seq}&uin={qq}&sid={sid}&xp={xp}&un=0&to= 0\r\n
Reply: ver=1.1&cmd=simpleinfo2&seq={seq}&&uin={qq}&res=0&np=65535&sn=0&un=&fc= &nk=\r\n
XP is calculated in front of the login command, you can see the code behind me.
The res=0 also responds correctly on behalf of the server.
np=65535 means that all of your friends ' information is currently returned, if not, you should not have so many friends.
SN indicates the number of currently returned friend base information (note: I did not write it all)
UN says friend QQ number, comma separated (I didn't list)
FC represents the Avatar ID
NK represents a nickname, separated by commas

3. Get Friends Status
Command: ver=1.4&con=1&cmd=query_stat2&seq={seq}&uin={qq}&sid=&xp={xp}&cm=2&un=0\r\n
Reply: ver=1.1&cmd=query_stat2&seq={seq}&uin={qq}&res=0&fn=1&sn=2&st=10,30&un=. \ r \ n
Does FN mean the finish? I don't know.
The number of SN return information
St Status: 10-online, 20-offline, 30-left, 40-stealth
UN:QQ, corresponding to status one by one

4. Send a message to a friend
Command: ver=1.4&con=1&cmd=cltmsg&seq={seq}&uin={qq}&sid={sid]&xp={xp}&un={qq2}&mg={ mg}\r\n
Reply: ver=1.1&cmd=cltmsg&seq={seq}&uin={qq}&res=0
UN on behalf of friends QQ
MG indicates that the message must be part of a URL-encoded
5 ........
There are several commands, such as add friends, delete friends, I will not write, plus some did not do the test.

4. Analog Login

1. You can get the server IP information by first getting

get/newconf/kjava/aubin2.jsp http/1.1
Accept:text/html, application/xhtml+xml,*/*
user-agent:mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; trident/6.0)
Accept-encoding:utf8
Host:conf.3g.qq.com
Connection:keep-alive
[Blankline]

2. Then set up the socket and connect to the server

3. Sending commands to the server

4. Processing server return

5 .........

5. Effect display

3. End

The article contains only a brief description of some protocol aspects, details, and a complete list of commands (which I do not know) and is not fully listed, if
For reference, please also see the source code below.

Reference article:
Mobile Phone QQ Protocol analysis (a) login
http/1.1 Request-w3school

Source code not completed: Http://pan.baidu.com/s/1c0iYYDa

Author: girl does not cry
Date: April 6, 2014
Contact: QQ-191035066
Address: Http://www.cnblogs.com/memset

Category: socket/socket Tags: socket, socket, mobile QQ, protocol

Reference:

Protocol Simple Research Notes

Crack Research Summary

Sync Protocol

Hearsay, plus the above reference is referred to using the Sync protocol. Last year's project, which referenced the Microsoft Exchange ActiveSync protocol to optimize the message protocol, was finalized for a long period of time, but for some reason it was not, and it was understood that sync was not as simple and useful as it was on the surface.

What's wrong with Sync?

1. Synckey Generate maintenance costs

Synckey is a string in ActiveSync, the client does not need to parse, but the server implementation to use the digital self-increment, need strong consistency, and can not be rolled back.

2. The subscription pattern for messages uses a one-time triggler like zookeeper or every message to push a notification to

One time trigger is able to avoid concurrent notifications when getting messages repeatedly, but increases the cost of interactivity and the complexity of client implementations.

3. Synckey How to get the message

In particular, to support multi-terminal synchronous message, to ensure the synchronization of messages, but also had to send the message after the synchronization of their own (the device can be sent without the message body)

4. Message Push delay aggravation

Sync Message Body Acquisition method: Notify-ack-get-mssage, that is, at least the fourth application package to return messages, under the mobile network is very expensive. The article mentions that the message passes through a separate HTTPS request, then the delay is more severe (well, the new version is not the case ).

Mobile client no longer sync protocol

Capture Packet Analysis version: Android 6.0, packet analysis can be referred to: Android mobile network real-time packet capture

In the WiFi, GPRS network conditions are the same, the client will attempt to use 80, 8080, 443 ports to connect to the server, the message sent, received using a long connection.

Protocol format:

4byte Packet Len (contains 4 bytes itself)

2byte Head Len (contains 2 bytes itself) + 2byte Version (1) + 4byte operation + 4byte SeqId + ....

(Packet len-head Len) Body

Protocol Interaction Mode:

-Client request (one should a, seqid match):

Seqid = 1 starts, increments sequentially, and the server replies to the same seqid as the reply

-Server Push notification (one-way):

Seqid = 0,operation = 7a, client does not need to answer

Main business:

-Heartbeat Pack:

Initiating a client request, operation = 0c, 16 bytes in length, is the smallest package

-Send message:

Initiating a client request, Operation = Ed

A single point of online when the message is sent, the answer carries Synckey, no longer synchronized, multipoint online, through the notification synchronization Synckey, the subsequent article analysis.

-Receive Message:

1. Server Push message, operation = 7a, Body carry message content

When grasping packet analysis, by changing the size of the message body, it is possible to change the length of the first packet to the receiver, which confirms that the message is push.

2. Initiating a client one-way request, which is the reply ACK of the message

Encryption

Not analyzed, generally like WhatsApp, use hash (password/OTP + long connection first request get Randomcode) do RC4 key

Summary:

Now version of the message push, not sync mode, but push +ack way;

From their protocol design, it should be the first to use notify + sync Req + sync Rsp, because the protocol does not support the server to initiate the request;

Now change to sync message + one-way Ack Req push Way, although the protocol is weird, compared to the sync message reception will be more timely. From the previously seen articles are said to use the Sync protocol, it should be the later version has been modified, push way more efficient, and through the sequential Synckey can also repair the lost message.

The following is an example of a notification package:

4 byte:265 Packetlen

2 byte:16 Head Length

2 byte:1 Protocol Version

4 byte:7a operation

4 byte:0 SeqId This is a notification message

4 Byte:unknow Header

....... Body

Web Client

Web clients use a more standard sync protocol, and the Sync protocol is more appropriate for the Web long polling model.

In the mobile client mode, the protocol is binary and has encryption, it is difficult to analyze; focus on the mobile side, the Web-based principal protocol should be kept consistent with the mobile side, the web-side speculation of the overall protocol implementation, JSON is also better analysis.

Synckey changes after receiving a message:　

synckey:1_624161340|2_624162225|3_624162051|11_624161867|201_1420112604|1000_1420104656
synckey:1_624161340|2_624162226|3_624162051|11_624161867|201_1420112631|1000_1420104656

Can be seen:

-Synckey has multiple, should be dealing with different business, where 2 is for all personal messages, discussion group messages, others may be contacts, Friends Circle, subscription number, etc., 201 is the current timestamp.

-The value of Synckey is the number increment, not starting from 0, there should be a fixed initial value.

-When you send a message, you need to send yourself back to Synckey.

-The following is a message incremental synchronization structure, a heap to synchronize the field + whether to modify the Flagmask, the synchronization protocol becomes very concise.

{"Baseresponse": {"Ret": 0, "errmsg": ""}, "Addmsgcount": 1, "addmsglist": [{"MsgId": 1625734358, "Fromusername": "@sssss "," Tousername ":" @ssssssss2 "," Msgtype ": 1," Content ":" Whack to laugh ... "," Status ": 3," Imgstatus ": 1," Createtime ": 1420109883," Voicelength ": 0," Playlength ": 0," FileName ":", "FileSize": "," MediaID ":", "Url": "", "Appmsgtype": 0, " Statusnotifycode ": 0," statusnotifyusername ":" "," Recommendinfo ": {" UserName ":" "," nickname ":" "," Qqnum ": 0," Province ":", "City": "", "Content": "", "Signature": "," Alias ":", "Scene": 0, "Verifyflag": 0, "Attrstatus": 0, "Sex": 0, "Ticket" : "", "OpCode": 0}, "Forwardflag": 0, "AppInfo": {"AppID": "", "Type": 0}, "Hasproductid": 0, "Ticket": ""}], " Modcontactcount ": 0," modcontactlist ": []," Delcontactcount ": 0," delcontactlist ": []," Modchatroommembercount ": 0," Modchatroommemberlist ": []," profile ": {" Bitflag ": 0," UserName ": {" Buff ":" "}," nickname ": {" Buff ":" "}," Binduin ": 0," Bindemail ": {" Buff ":" "}," Bindmobile ": {" Buff ":" "}," Status ": 0," Sex ": 0," Personalcard ": 0," Alias ": "", "Headimgupdateflag": 0, "Headimgurl": "", "Signature": ""}, "Continueflag": 0, "Synckey": {"Count": 6, "List": [{"Key": 1, "Val": 624161340},{"Key": 2, "Val": 624162166},{"Key": 3, "val": 624162051},{"key": One, "val": 624161867},{"key": 201, " Val ": 1420109883},{" Key ": +," val ": 1420104656}]}," SKey ":" "}

At first, the QQ communication protocol is not encrypted, but directly to take the clear-text transmission, to the later use of encrypted transmission, encryption algorithm has not changed, using the Blowfish algorithm, but the key exchange protocol has become more frequent. In fact, TX is also forced, now the Internet users more attention to privacy security than in previous years, so large user volume of communication software, if the user and the other side of the chat information can easily be deciphered by the third party to obtain, then the user will definitely leave her, and to choose those who can more protect personal privacy of people communication software. As a result, over time and in the development of technology, previously designed protocols may be discovered by developers of a number of weaknesses, "malicious" to exploit, will pose some potential risks to TX, He had to modify the protocol (QQ2011 in the official version of the key exchange in the password MD5 calculation added the concept of salt, the salt is the corresponding QQ number, the following will be described in detail).

The preferred transport layer for the QQ protocol is UDP, and if UDP is not logged in, then it will attempt to use TCP for transmission. The port used by UDP is the port used by 8000,TCP is 443, and the application protocol is basically the same, except that the first two bytes are the length of the protocol content (including 2 bytes) when transmitting over TCP.

Each communication in the QQ protocol is provided with a protocol header, such as:

It identifies 11 bytes, the version number, the command word and the sequence number are 2 bytes, the QQ number has 4 bytes, Next is the data part (encrypted), and finally a tail ID of 1 bytes.

When the protocol is restored, the most concern is the command word of the protocol header, which needs to be processed according to different command words, and finally get the key to decrypt the chat content.

QQ Login Protocol key exchange process, first we use Wireshark capture message analysis, observe the main use of the command Word (see the previous header section of the introduction).

Analysis of QQ2011 Landing process

Command word	Meaning
1. Touch Information (0x0091)	Root server say HELLO, if you do some tricks on the message, you can let QQ think that the TX server or network can not access ...
2. Login Request (0X00BA)	Unknown, can not be processed.
3. Login Verify (0X00DD)	Sending a login request to the server requires a password to be used as the key to encrypt the message, and the decrypted message contains the decryption key for step 4th.
4. Login Get information (0x00e5)	Unknown, but the message returned by the server you have to know, because this message contains the key to decrypt the session key message (6th step).
5. Login Verify E3 (0X00E3)	Unknown, can not be processed.
6. Login Send information (0x0030)	The client sends SessionKey to the server and decrypts it using the key obtained in step 4th.

1. Touch Information (0x0091)

This message does not need to be cared for, it is the client to the server at say HELLO ...

2. Login Request (0X00BA)

Unknown, not important here.

3. Login Verify (0X00DD)

Very IMPORTANT!! Getting the session key first has to decrypt the message. But to decrypt the message, you must know the login QQ user password, and user password only users and TX know that the third party is not aware of (there may be "incredible" third party ...) ）。 The encryption algorithm used in data transmission is Blowfish, the algorithm currently from the public data, has not found a loophole. Therefore, in real-time access to the user's chat information, unless the password has been known, or has been brute force to crack the password (here is a brief introduction of how to brute force, the violence here, of course, not the simulation of a QQ client constantly send a login request to the TX server, so it is too slow, and TX there will be records. First of all, the key generation algorithm of the score precipitates this message [not simply using the password as the key], the encryption algorithm (this known, is Blowfish), the second, the other needs to intercept the other's landing message to save to a file, and then write a program, not stop stitching strings, numbers, punctuation, According to the first step to analyze its key generation method to generate a key, and then as the Blowfish algorithm key, to decrypt the message, if the decryption success, congratulations, you brute force cracked a QQ password. But this probability is relatively small, even if there are some, the value of these numbers is not big, pull away ...).

Loginverify Message Decryption key generation method, before the QQ2011 version, is the MD5 (MD5 (PWD)), QQ password to do two times MD5 operation. But after the QQ2011 version (including version 2011), the algorithm made a little change, that is: MD5 (MD5 (Pwd+qq_num)), this modification is actually very necessary, why? Because with the development of hardware technology, as well as the introduction of MD5 Rainbow Table in previous years, the MD5 value of simple password is very easy to find the corresponding MD5 value from the Rainbow table, thus get the original string password, even if TX did two MD5 operations. In the introduction of the Rainbow Table or before (because I do not know is in this before or after, hehe), in the execution of MD5 operation, there is a salt of the saying, very image! Add salt, here, qq_num is salt, so the use of rainbow table to crack the difficulty.

Using the password based on the above algorithm to derive the decryption key, after decrypting the login verify message, you will get a new key, this key is called Verify_key.

Login Verify Reply (0X00DD)

The server responds to the client login verify message, which needs to be decrypted verify_key as a key, and a new key-verify_reply_key is obtained.

4. Login Get information (0x00e5)

After the client receives the login Verify reply message from the server, it uses Verify_reply_key encrypted data to send to the server, which in turn contains a key–get_info_key.

5. Login Verify E3 (0X00E3)

Unknown, this can be done without processing.

6. Login Send information (0x0030)

Use Get_info_key to decrypt the message and get the session key–session key.

Recall: The password is the key, with a password to decrypt the login Verify (0X00DD) message, decrypt the login Verify (0X00DD), to decrypt the subsequent messages. The steps are: passwd, Verify_key, Verify_reply_key, Get_info_key, Session_key.

The previous two simple introduction of the QQ Login protocol key exchange process and the encryption algorithm used, know the two points, it can be restored to its protocol.

Qqdecrypt, through the WinPcap grab bag, real-time QQ chat protocol to restore.

In addition to the chat protocol, we can also restore QQ-related protocols, including but not limited to:

1. qq File Transfer

2, QQ audio transmission

3, QQ video transmission

4. QQ Password Verification Program

5, QQ password to get, yes, you did not read wrong, there is an active method (user login) can get QQ password. Acquired at the network exit, rather than in the way the client hooks.

Protocol Analysis TMP