Title: Decoding the decoding process of the front-end request and response packets once

That is, after the last decryption, the development team did not give up. After a few months, the return package was also encrypted. And compressed and obfuscated front-end js

According to observations, it is initially believed that the server also performs the same RSA+Aes encryption, and then sends the key and iv after RSA encrypted and the data fields encrypted by Aes together. But for us, this actually adds to the insult to the system and reduces the security of the system. Because this will allow the front-end to decrypt the rsa+aes, the rsa private key will definitely exist in the front-end!

Start the operation 1. Search the encryptIv field in the old rules, find the suspected decrypted part, press the breakpoint and submit the login request

Burp grabs the packet and returns the packet and extracts the data field

Extract the key and iv values of the AES decrypted by RSA at the breakpoint

Put n and a from the front-end breakpoint as key and iv into the Guigui JS debugging tool to try decryption. The decryption is successful, which means that there is no problem with the idea. That is, the code here decrypts the encryptIv and encryptKey from the server to the original key and offset of aes.

2. According to the decryption code, find the rsa private key (p.d), and the display is incomplete. Copy a ctrl+f to search for the complete rsa private key.

Use jsencrypt.js script to decrypt and find an error. The reason is that the original js calls the browser's window and navigator methods. These two are used to obtain browser window information and mouse position information to generate random numbers

Through searching, I found that someone had changed the original JSEncrypt first, removed the window and navigator methods to use it. Post address: https://bbs.125.la/forum.php?mod=viewthreadtid=14113049

Debugging successfully using Guigui JS

3. The last step is to improve the writing of automated encryption and decryption scripts. The old rules are still a combination of mitmweb+burp. The browser first proxyes to burp, and then burp secondary proxys to mitmweb to execute python scripts, and then sends them to the server. The general idea is as follows:

In fact, I thought that 90% had been completed, and the remaining 10% were written to write automated scripts. As a result, this 10% took several days because of the reason why the call to js decryption was not successful. Afterwards, it is solved, and generally speaking, it has something to do with the AES algorithm, js, and python. We can talk about this big pit in detail next issue! Skip this part today.

Finally, the last script added the code to cancel the front-end decryption and the code to mitmweb help decrypt the response.

The debugging was successful, the burp was comfortable and the whole process was clear.

By the way, huh? I found a high-risk vulnerability that returned to the front end with a verification code hahaha. But I am kind-hearted. Since this encryption and decryption will not be solved for a while, it is Friday now, so let’s call it development and fix the vulnerability next Monday. Let's leave the specific new code part until next time, let's talk about it together with AES when decrypting this big pit.