Exploring WeChat Access—Processing of Encrypted Messages

In the previous blog post, we introduced the abstract data level of the passive callback interface and implemented an efficient basic function for converting entities to XML. Careful developers will find an option called "Message Encryption and Decryption Method" when modifying the basic configuration of the official account for the first time. The values ​​available for selection after expansion are: "Clear text mode" (default), "Compatibility mode" and "Safe mode (recommended)". So what is this safe mode? How to adapt to safe mode? With these questions in mind, let’s enter the third exploration journey of WeChat access.

Abominable traffic hijacking At the beginning of the article, let me show you two screenshots of mobile phones in normal use:

On the right side of the screen You will see a green water balloon in the lower corner, which is incompatible with the picture to be displayed, and is obviously not done by the designer. Click on the water balloon to display the remaining traffic details in the current communication package.

From the home LAN to the Internet to the IDC computer room intranet, our data links are full of forwarding processes. Our data may be persisted and saved when it is forwarded by any device. Is your office intranet secure? Hackers lurking around you can receive a copy of all data in the LAN by setting a certain network card in the LAN to Promiscuous Mode. Maybe you can't find anything, but your private data has been stolen by others.

Use safe mode to protect user privacy

When safe mode is enabled, the messages received by the passive callback interface change greatly, and the form is as follows:

<xml>
    <ToUserName><![CDATA[gh_38a2de904e09]]></ToUserName>
    <Encrypt><![CDATA[i7b8ccNA9OWDhau/F26aUWKFJ6Jd0imsDQIFPSdSfAg8mHT7rL0kIWSVpcqf6/dVSoOQOQK4T/CS3w96j4k3qcg89M6xn2RGZBs+9JkrsdRig5yhcia1B59akWb1t9QdutXqnl4edAqtXEh8SIs+N2HkOTTVldtOUHpdwLqRYuC4F6ejUoXui4xKuc3oyODR9edfL+xzZ7JfMJ1KUNF/YBJMj/Ba9y/CLLYmdFYOtCMH7tMUz8h+S0XKkHKN6r0ELLCIZJ9+PPlHZcfSGhwMLUeRF1nMIjXGEKHkI0uMcruh7wD96lMU/RFgJDjAk26xbmUYfa3l+34p+txw4R8iD3Q58S8Yekiy3lUsbk+C6eDeefGs1ck23BQ8xWU3AReWH2dEsY6SYIkb3ANeyJmcoIKZfpc/31njp0KcHAxL1Lk=]]></Encrypt>
</xml>

It can be seen that the plain text part retains the original ID of the official account of the message: gh_38a2de904e09, and the rest is encrypted text (this structure allows the same backend system to access multiple official accounts, and then use the ID of each official account settings for separate decryption). Since the encryption structure is not clearly explained in the official document (http://qydev.weixin.qq.com/wiki/index.php?title=Encryption and Decryption Library Download and Return Code), I will give you a detailed explanation here. .

#If the reader has developed network protocols before, it should be easy to understand this structure, a typical variable length message. There must be a mark to indicate the length of the variable-length area. This value shall prevail when reading, and a number of bytes will be read after the fixed-length data. At the beginning of the structure, there is a 16-byte random number. This part of the data has no practical meaning and can be used as random number padding data when returning encrypted messages later.

Safe mode signature verification method

WeChat’s passive callback interface is actually an HTTP POST request. We all know that HTTP requests are divided into request headers and request bodies. WeChat cleverly puts the encrypted XML data in the request body and puts the parameters used when verifying the signature into the request header.

POST /cgi-bin/wxpush? msg_signature=477715d11cdb4164915debcba66cb864d751f3e6×tamp=1409659813&nonce=1372623149 HTTP/1.1
Host: qy.weixin.qq.com
Content-Length: 613
<xml>
    <ToUserName><![CDATA[wx5823bf96d3bd56c7]]></ToUserName>
    <Encrypt><![CDATA[RypEvHKD8QQKFhvQ6QleEB4J58tiPdvo+rtK1I9qca6aM/wvqnLSV5zEPeusUiX5L5X/0lWfrf0QADHHhGd3QczcdCUpj911L3vg3W/sYYvuJTs3TUUkSUXxaccAS0qhxchrRYt66wiSpGLYL42aM6A8dTT+6k4aSknmPj48kzJs8qLjvd4Xgpue06DOdnLxAUHzM6+kDZ+HMZfJYuR+LtwGc2hgf5gsijff0ekUNXZiqATP7PF5mZxZ3Izoun1s4zG4LUMnvw2r+KqCKIw+3IQH03v+BCA9nMELNqbSf6tiWSrXJB3LAVGUcallcrw8V2t9EL4EhzJWrQUax5wLVMNS0+rUPA3k22Ncx4XXZS9o0MBH27Bo6BpNelZpS+/uh9KsNlY6bHCmJU9p8g7m3fVKn28H3KDYA5Pl/T8Z1ptDAVe0lXdQ2YoyyH2uyPIGHBZZIs2pDBS8R07+qN+E7Q==]]></Encrypt>
</xml>

The process of signature generation:

#Through the above calculation, the signature calculated_sign of the current encrypted message is now obtained, and then the parameter msg_signature is obtained from the request header , if calculated_sign and msg_signature are the same, it means that the message has not been tampered with. The mathematical problems utilized by this signature strategy are:
1. The SHA1 digest algorithm calculates all data, and any changes to the final digest will change;
2. The Token is set in advance, and during the transmission process is not included in and cannot be cracked;
3. The introduction of timestamps and random characters makes the ciphertext different every time even if the plaintext is the same, making it more difficult to crack AES encryption

Signature verification successful You can then safely use the decrypted plaintext. The format of the plaintext is consistent with the format introduced in the previous article, so the decrypted business processing logic can be reused.

As a response to safe mode, the returned XML format should also be encrypted. The entire encryption process is in the opposite direction to the decryption process, so I won’t go into details here.

For more WeChat access exploration—encrypted message processing related articles, please pay attention to the PHP Chinese website!