Android Black Technology Series--analyzing the Protocol encryption principle of a live app and invoking encryption method to construct protocol parameters

First, preface

With the broadcast technology hot, all the Live app, the early live app's various request protocol parameter information did not do any encryption measures, but slowly someone began to use the back door began to brush powder attention tool, you can make a new small Hua Dan minute into the net red. So somewhere in this problem, the live app starts encrypting the network request parameters. So that is the focus of this article analysis. The reverse domain is not only the shelling operation, some cryptographic decryption operations are also very research purposes.

Second, grab the Packet View encryption protocol

This article looks at a live app protocol encryption principle, and how to get the information after encryption, how we use the probe technology, to call his cryptographic functions. First here to find the breakthrough point, no doubt, directly grab the bag, we go to the host page, click after the attention, see Fiddler in the Packet Capture data:

We will find some important information in the request parameter, such as the user's ID, the device's IMEI value, etc. But the most important thing we are concerned about is the S_sg field, because this field is a signature information for the request parameter information. It is also the information that the server needs to make a comparison. If the field is found to be incorrect or not, then the request operation is considered illegal. So we just have to get the correct value of this field to simulate a network request to access this operation.

Third, the analysis of encryption process

Find a breakthrough, this is the field S_sg, open the app's Dex file with JADX, and after you open the Dex file, global search for the S_SG string:

Here we see only one place where the value of this field appears, let's go in and see:

See this method, very excited, feel is the function of cryptographic protocol, and the field can be right, we have this encryption method directly copied out, write a demo after the simulation of encrypted information, sad to find that the data is not on the, and look at the class of this method:

Altogether is a class that interacts with the Web page, stating that the request should not be encrypted in this place. The breach was broken.

Note: Here is the Dex file, not the apk file, because JADX open apk file will parse the resource file, if an app has a lot of resource files, then JADX Open will be stuck, so many classmates asked me why JADX open the APK file will appear the card dead state, This is mainly due to parsing of resource files. So in order to prevent the card to die, directly extract the Dex file, and then open it will not be stuck dead.

We continue to grab the packet information above, that is, the requested URL address, and then go to JADX Global search:

I got it. Check in:

Then the global search for this "User_relation_follow" string:

Search results, click to go to view:

Here we see the annotated way to construct the request information, and here the core class is Inkedefaultbuilder, the global search for this class:

Unfortunately not found, because this app for unpacking operations, there are multiple Dex files:

So we need to use JADX to continue opening his second Dex file for search:

Sure enough, this class was found in the second Dex.

Attention:

It is important to note that after the JADX opens Dex or the APK file, the trace finds that there are no search items to find, and the following assumptions are needed:

First, whether to include multiple Dex files, you can use JADX to open other Dex files for searching.

Second, whether there is a dynamic load plug-in function, global search Dexclassloader Find the plug-in loading location, get plug-in Feature Pack, in the JADX open the plug-in package to search.

Third, if there is a so file, you can use IDA to open the so file, Shift+f12 display all the string information views in so, and then search.

Finally, whether the information originates from the network request return, for example some string information display, possibly is the information which the server returns.

To continue the analysis, click inside to see the definition of this class:

To view his parent information:

See there is a method of URL encryption, more curious. Let's look at this method:

Continue to view this method:

Here you find a network request that will find some information and then set it to a place. We continue to look at the method:

See the definition of the D variable type, generally we see the non-clickable possible this class is not in this Dex file, so we need to go to another Dex file to find, and this case is going back and forth so toss to find information operations, go to another Dex file to search:

Find it, point inside to see:

Here again is a variable A to see his definition:

See, this class is not clickable here, it means that this class is not in this Dex file, go to another Dex file to search:

Discover the definition of this class, and point it in to see:

Originally is a native tool class, there are many native methods inside, including the method of setting information, encrypting and decrypting URL method, etc. Look at what he's loaded so:

Turns out to be these three so files, see Crypto and SSL, get over the encrypted know, this is the OpenSSL encrypted library file, here guess he used this encryption algorithm in the native layer. Regardless, we open this so file with Ida, because we know that Libcrypto and Libssl are library files, so just open its own Libsecret file, and then shift+f12 view his string information page, not before looking at that encrypted field, Search here to see the results:

Indeed found, that encrypted field, we click into the view:

Then click on the X key to see the call place, but unfortunately, the jump past found that the assembly code is not generally more. Let's go back and look at the function of the encrypted URL:

Click to go in, then press F5 to view the corresponding C code:

It's time to start doubting life and Ida is dead. Then simply take a look at the assembly code of this function, which is simply a circle. It's too long. If I rely on static analysis, I do not have the patience and ability. Dynamic debugging? I think it's too bad, there are anti-debugging, various jumps. Do not know debugging to se years.

Iv. Getting encrypted content

So here, I roughly analyze this live app's request protocol has an encrypted signature field S_sg, this value is encrypted in the native layer, encrypted with OpenSSL, but the encryption function is very long and the analysis is more difficult. But you can't just give up. We want this encryption result to get the correct signature information value after we construct the parameters ourselves. Then you need to transform your mind. We may as well just result that the encryption process is not so important to us. So here's one idea: Write yourself a program that calls this cryptographic function in its so file.

We have done the NDK development know that by default the native method is automatically registered with the Jni_onload function in so, but the function in native must follow this format: Java_ class Name _ method name, similar to this:

Then we can in our own program, the app's that secret class copy of the past, but be sure to note that the package name must not change:

Then call the native method directly in your code:

Unfortunately, the result of the call, there is no encrypted field information. So here we'll find out what settings are missing. Let's look back at the Java layer code:

Here's a set method that has been found in the previous analysis, where he calls:

Here is a Secretdatamodel class, which should be the data obtained from the Web request, and then parse to construct this class to see the class definition:

See here, found that the third-party JSON parsing package has been used, the annotation directly resolves the field values. But we search this class globally, tracking is too troublesome, here is another way to track the code, that is, using xposed to intercept the constructor of this class, and then internally print the stack information to see the method call path, this method I have used before. This article is able to better reflect:

Because the application is a multi-dex file, the hook must first hook his application class attach method to get the correct class loader, the correct loading of the class information needs to hook, or error. This has been told a lot of times. Then is the use of automatic throw exception to print the method call stack information, installation run, restart effective to look at the log:

Here, he used Google's Gson library to parse the JSON data, and saw that the JSON data is passed from the following two methods, to see the method of this class:

Click to go to view:

In order to see the JSON data returned, we are intercepting this method and printing the returned JSON data to see what it is:

Run the module, restart the effective, look at the log information:

Seeing this JSON data, this time, return to see Secretdatamodel that call set method:

See these four parameter values, the first one is the context does not explain, the second is the Servertime field value, the third is the Startcode field value, and the fourth is the RunCode field value. These three fields can be found in the JSON printed above, and we'll format the JSON to look at:

With these three values and the context variable, call Secret's native method set directly to see if the value of the field after encryption is correctly obtained:

Run the demo program to see the log information:

See, the settings are successful, and getting the encrypted fields is successful. Here we have succeeded in obtaining the S_SG value of the encrypted field.

V. Obtaining cryptographic configuration information

But it's not over yet, because we've found that the three set value fields are obtained from the network, and we need to know which URL to get, which is still very difficult from code tracking, so we also need to use hooks to print the stack information of the method to track the code, Get stack information for JSON data by printing above:

See this class of access to get JSON data, go inside to see:

While the parameters passed in are viewed:

See there is a Geturl method, is to get access to the URL value, we can do this hook operation, print this URL access address:

Run the module, restart the effective, look at the log information:

Here we print the JSON data we want, there are several URLs, we are going to fiddler to observe the data returned by these URLs, and finally navigate to this is the URL to return the data information:

Six, combing the encryption process

We're done analyzing the protocol encryption process for live apps, and here's a summary:

First step: Get configuration information before encryption via the/USER/ACCOUNT/TOKEN_V2 interface

The second step: set the information obtained by the first step through the native method (set method).

The third step: using the native method to encrypt the URL value of the Java layer stitching parameter return (Encryurl method)

Then we can do this, our own protocol demo program, in the Java layer splicing good parameters, and then call the native method of So, return the URL of the encrypted field, and then can parse out this field is encrypted information. We can process this network request in batches. such as brush powder, watch live, like and so on operation. Of course some students will think this operation is actually not the real meaning of the crack encryption algorithm. It does not count, but we get what we want, the process is not so important, and in this process, we learned a lot of reverse techniques.

Vii. Summary of Reverse techniques

First, when using JADX to open the APK card to die, remember to extract the Dex file, in the JADX to open the Dex file.

Second, for multi-Dex applications, when using xposed for hooks, it is necessary to intercept the attach method of the application class to get the correct classloader. Otherwise the interception failure will be reported.

Third, when we use JADX for global search content, found that there is no search results, we may need to consider the following aspects:

• 1. If you have more than one Dex file, you can use JADX to open other Dex files for searching.
• 2, whether there is a dynamic loading plug-in function, global search Dexclassloader Find plug-in loading location, get plug-in Feature Pack, in the JADX open plug-in package to search.
• 3. In the presence of so files, you can use IDA to open the so file, Shift+f12 display all the string information views in so, and then search.
• 4, whether the information from the network request return, such as some string information display, it is possible that the server returned information.

Finally, when we use JADX for code tracking is very difficult, it is also possible to use xposed interception of the specified method, printing stack information to track code, is also an efficient way.

When you use the JADX right-click method to see the call path and find no results, then see if this method is a method or an abstract method in an interface implemented by the class. Go to the parent class or the method in the interface and right-click on the call path.

Six, in the case of not concerned about the process, only concerned about the results of the scene, you can construct an app to invoke the program's so, to get the results we want, this way must remember that many of the following scenes will be used. It can be used to sniff the functions of some functions in so. For example, by invoking a method in so, input the regular data, see whether the output conforms to a certain law, through the law to crack the encryption algorithm.

Viii. Summary

This article is a bit more, thanks to the live app developers to provide such a good sample of research, of course, the last thing to say is: Security protection strategy is not enough, we can see in this article we use to call his so to get encrypted information, this method can be used in many apps, for those we do not care about the process, This method is not only concerned with the content of the result. So how do you avoid this security problem as a developer? A lot of people first think of: In so the Jni_onload method to determine whether the signature information is correct, not correct directly exit. This is indeed a precaution. But if I used the Kstools tool principle, the direct hook system of the PMS service intercept the acquisition of signature information method, return the correct application signature information, this protection strategy is invalid. So: security is not the reverse. Both are making progress.

Android Black Technology Series--analyzing the Protocol encryption principle of a live app and invoking encryption method to construct protocol parameters