Android Black Technology Series--the signature verification problem of a blasting application

First, preface

In the previous article said that Android security and decryption are mutually reinforcing, in order to prevent being cracked, many applications do some protection strategy, but the protection strategy is also hierarchical, the general simple strategy is to confuse the code and signature verification, and for signature verification many applications will do, generally now in two ways:

The first type: Signature verification does not pass through the program directly, that is, you will find back to compile two times the packaging failed to run the phenomenon

The second kind: Signature verification does not specify logic by not triggering the program, resulting in no error message, and can not be applied to the phenomenon

Articles about application protection strategies in Android can be seen here: The Battle of attack and defense in Android today we will look at the signature verification of the application case, in the back to compile two times the signature run into the game after the problem, in fact, has analyzed a signature verification problem, The problem there is the problem of a two-time package run failure to compile back. Do not know the students can go here to see: the use of static hack apk app in Android, this kind of running failure of the application is better to solve, because this signature verification is generally at the entrance of the application, so directly at the entrance to add some logs, through the print log can be seen, The entrance is generally the application OnCreate method and the Attachbasecontext method, and after this case we also learn a quick way to locate signature verification: Global Search signatures string, Because we know that if you want to do signature verification, you must call one of the system's API methods: Getpackagemanager (). Getpackageinfo (Getpackagename (), (). Signatures, So after using the JADX tool to decompile the APK, the global search signatures string can be immediately positioned to the method of signature verification.

Second, case analysis

Before the analysis of a case to solve the signature verification, the following use this small game as a simple analysis, the game in the market can be downloaded to:

This article studies the V3.3 version of the. After we download the game, we can use Apktool to decompile, then back to compile the re-signing, installation run:

The game can run successfully, but the card here, cannot enter the game, this time we guessed that he may have the signature verification logic, may put on the local, may also put on the service side, we use the above mentioned technique: in JADX the global Search "signatures" string content:

This time will find a lot of places are in use, in fact, it can be inferred that this game in order to prevent two times packaging in many places have added a signature verification logic, so for the crack is also added a certain degree of difficulty, because there are too many places to verify the signature, so there is not a change, So we solve the problem in a different way: when we run the game, we find that the game card is in the progress bar, so the conjecture is related to the network request, so we analyze his request information through the Fiddler grab packet:

The game opens on these requests, but as a game is not possible on this request, this is also the reason for the jammed, we can do so, with a normal game in the grab bag to see the situation:

This is not a two-time package signature request information, and the above two packaging signature after the request compared, many more requests, you can find a get_user_info this interface is very special, so we can go to JADX Global Search this request interface:

Here you see where the URL is defined and then where the global find usage is:

Click inside to see the method call:

Continue to see where this method is called:

Here are four places to call this method, but can be eliminated in turn, the final positioning is the COM.WEPIE.SNAKE.MODULE.HOME.B.D.E () method, then the following to see how to exclude, you can exclude from the bottom, see the following method:

Then go to the L.A method to view the logic:

Here is actually a request, the request interface is the value of D.R:

See this interface information, but we did not see this request when we grabbed the packet with fiddler:

So this place can be filtered, and the results of the analysis in three other places are similar. So in this way the method is positioned where the call is made:

We're looking at the place where this e-method is called:

Here is called, by invoking the results found, there is the first judgment:

Here is a string to compare the logic of equality, most likely is to compare the signature information, you can view h.a this method:

There seems to be a string construction algorithm, in order to see the final string content, we can create a simple Java project, and then print this method to see the results:

See this final generated string content is: 678A930B9829B54A44F92A840916F7D1, and then look at the O.a method of equals:

This method obtains the application signature information, and then computes the result with MD5. So here we know that the checksum signature logic is to get the application's signature information, then MD5 it, and compare it to the "678a930b9829b54a44f92a840916f7d1" string. Then we signed two times, this judgment is definitely false, so the subsequent logic will not go, there is no subsequent request, found the card in the beginning of the interface.

Then the problem is found, change it is relatively simple, directly decompile the game, and then find the COM.WEPIE.SNAKE.HELPER.F.O.A () method corresponding to the Smali code:

Return this method directly to the "678A930B9829B54A44F92A840916F7D1" string. Some students say this how to change? Are you writing Samli code manually? Certainly not, I can write a simple way to return this string, and then decompile the code to get this piece of smali, but do not manually to write, unless you have the patience and perseverance, anyway I did not. After the replacement is completed, we will be back to compile, two times signed to run the installation game, unfortunately, is still stuck, so you have to go back to see the code:

We modified the signature verification method, entered the first layer of signature judgment, continue to look down the code:

Here is another judgment, point in to view the logic:

Sure enough, here again a signature check method, so also have to manually modify, modify the method and similar above, the P method can be changed:

After the modification succeeds, again compiles the re-signed installation to run, unfortunately is still stuck, cannot enter the game, at this time we in the Times grasps the package to look:

This time more than before a config_v3_android request, but there is no get_user_info request! So we have to look at the code logic, but from the request results, our previous two signature verification changes have worked, continue to look at the following code:

Here we can see that there is a logic to set the progress bar, and there is a tag=999 log, it seems to be a progress bar to take configuration information, then we can view this log information:

See this log information, found that there is a start to retrieve config to get the success of config, but there is no log, so here is supposed to be in the local parsing this configuration information when there is a judgment, we search the global string Information "getconfigandroid":

The first piece of information is what we want, click to enter:

Sure enough there is a judgment, go to view:

It's the logic of the signature check again, okay, we have to change this again. COM.WEPIE.SNAKE.HELPER.B.A.I () Method:

After the successful modification, once again compiled two times signed installation run, this time finally run successfully, into the game interface.

Third, signature verification cracking scheme

Well, here we summarize how to solve the problem of applying two-time signature verification:

The first step: After opening the application in JADX, the global search string content: "Signatures", this can be located to get the application signature information, and then you can trace the verification of the place.

The second step: in the first step of the search results are more than the case, we can use the application of the effect of the two ways:

• The first way: if the application fails to run, it may be the signature check logic at the application entrance and exit the program if the checksum fails. The general entrance is the OnCreate method and the Attachbasecontext method in the application.
• The second way: if the application can run, but the card in a certain place, we can use the packet capture technology to analyze where the application is running to get stuck, because the current application will have a request, if it is stuck, then the request will be different from the original package request, can be based on different request results to trace the code logic, Just like the case of this article.

The above is my summary of the signature verification of the approximate solution steps and methods, but there must be other scenarios, such as some applications will put the signature into the native layer, but these check logic can be processed, but also some applications put the signature information on the server to verify, this is also can be handled. Placed in the native layer, the end is also through the Java layer to do the connection access, as long as the Java layer, then you can find the verification method of the place, placed in the server check, or can be captured by the packet to view the request to solve.

Iv. Signature Verification hack follow-up

From the above look in fact in the application to protect the time, signature check this way is not hundred percent security, can only prevent some crack small white. In fact, this article can be found in the case, this application actually want to through a number of local signature verification to achieve global verification, this article can be seen we do three times the signature verification method code modification is successful, and the subsequent version does not rule out that they will continue to increase, as well as other local logic has also done signature verification.

From this article can also be seen if an application in many places have done signature verification, then our manual modification will be very troublesome, in fact, here is the idea: get the application's signature method is fixed: Getpackagemanager (). Getpackageinfo ( Getpackagename (), (). Signatures, we can directly modify the application of application information, through the reflection mechanism, the validation of the object's string content set to the signatures, white is to use reflection to modify the application's signature information, In this case, all the signatures in the application are the specified signature value we set, that is, the constant string content of the pair, and all the signature check methods return True. This idea this article no longer tries, interested classmates can try. is a reflection call. Some students may be wondering how to use the signature acquisition method for hook applications without xposed. It must be noted here, why we have to solve the signature verification, is because we want to two times the signature package, and xposed Hook is not required two times packaging, the main hook to find, do not have to carry out two packaging installation can be realized. The two ways of thinking are different, pay attention to ha!

V. Advice on application safety protection

Through this case, in fact, the application of protection has these recommendations: first of all, on the application of signature check this logic, you can do a more secure point, is in the native layer with reflection call system to obtain the signature method, and then directly in the native layer to compare, if the signature is found to be incorrect, quit the program, All on the native layer, so the safety factor will be high!

But this is not the safest, the safety point is to consider the reinforcement scheme, now a lot of reinforcement platform, choose the Enterprise version of the reinforcement, for the crack difficulty that is sure to increase. But there is a drawback of consolidation, is the problem of crash rate, because the understanding of the reinforcement principle of the students know that the reinforcement platform will involve so logic, and Android because the model and system version complex, resulting in poor compatibility, there will be a certain degree of consolidation crash rate, and for some users more than the number of applications and games, They can't stand the crash rate, so they give up the reinforcement. But hardening is still a relatively safe strategy!

Serious statement: The purpose of this article is only one, through a case to analyze the current application of the signature check logic, how to crack this verification method, if someone use this content for any commercial purposes and illegal profit, bring any legal liability will be borne by the operator, and the author of this article does not have any relationship, So still sincerely hope that everyone holds the purpose of technical learning to read this article, thank you very much!

Vi. Summary

In this paper, a case analysis of the application of signature information verification of the protection strategy to crack, and finally summed up the current signature verification protection strategy of the shortcomings and improve the place, how to achieve a higher safety factor protection. But it is not the safest, because there is no absolute security! Safety and reverse are mutually progressive! Together to promote social progress and technological innovation!

Android Black Technology Series--the signature verification problem of a blasting application