"Turn" Android anti-cracking technology introduction

Http://www.cnblogs.com/likeandroid/p/4888808.htmlAndroid anti-cracking technology introduction

As the internet continues to evolve over the years, Android apps are getting more and more! But then there are more and more problems, the more troublesome problem is: Some criminals use anti-compilation technology to crack the app, modify the code, and then recompile upload to the App Store! By then, if users download these apps, they can cause personal information or money to be lost! Therefore, as a developer of us, it is necessary to learn some of the technical means to prevent cracking!

Brief introduction

Now you want to hack an App, most of them follow a few steps below:

• Anti-compilation App
• View APP source code and modify
• Dynamic debugging (there may exist, after all, after modifying the source code to debug, ha)
• Recompile the APP
• Upload cracked apps to the store

At present, most of the crack only exist in 122 steps, but the following steps will still be someone, so we can not take it lightly! Of course, the last step we're not talking about! I'll take a step below to introduce a way to prevent these steps!

Prevent anti-compilation apps

At present, most of the anti-compilation tools used by most people are: Jdax,dex2jar,jd-gui and other tools, but for our good news is that many of these tools are open source, we can Github find the source of these tools, we can read these sources, And then find a way to prevent them from recompiling, which is to let them crash the software when they decompile your App! For this we can ignore, because to read the code and understand them, is a more time-consuming work may even not be able to read their programs, so we try to put the experience in the next few steps!

Prevent viewing of source code

It's not really going to prevent people from looking at our source code, we're just confusing the code to make it more difficult for others to access our source. In Android we can use Proguard to confuse our code. Here's a look at the pros and cons of code obfuscation:
Advantages:

1. Increase the difficulty of other people cracking the app
2. Compress, optimize, delete code
3. Special role achieved by removing code functionality

Disadvantages:

1. Increase our own debugging difficulty (believe that the mixed code of the students know that after confusion, the app will make a variety of errors)
2. Reflection problems (that is, the corresponding class is not found)

The solution to the problem of the first drawback is to save the file that mappinp.txt this mapping relationship, and when the app is confused, you can quickly pinpoint the location of the bug based on the mapping relationship! The solution to the problem of the second disadvantage is: Do not confuse the class, if you do not know which class that can only run when debugging!
The following is a brief introduction to Proguard's Common syntax:

-libraryjars class_path 应用的依赖包，如android-support-v4-keep [,modifier,...] class_specification 不混淆某些类-keepclassmembers [,modifier,...] class_specification 不混淆类的成员-keepclasseswithmembers [,modifier,...] class_specification 不混淆类及其成员-keepnames class_specification 不混淆类及其成员名-keepclassmembernames class_specification 不混淆类的成员名-keepclasseswithmembernames class_specification 不混淆类及其成员名-assumenosideeffects class_specification 假设调用不产生任何影响，在proguard代码优化时会将该调用remove掉。如system.out.println和Log.v等等-dontwarn [class_filter] 不提示warnning

Here is the standard file content given in Android proguard.cfg

-optimizationpasses5-dontusemixedcaseclassnames-dontskipnonpubliclibraryclasses-dontpreverify-verbose-optimizations!code/simplification/arithmetic,!field/*,!class/Merging/*-keep PublicClass *ExtendsAndroid.App.Activity-keep PublicClass *ExtendsAndroid.App.Application-keep PublicClass *ExtendsAndroid.App.Service-keep PublicClass *ExtendsAndroid.Content.Broadcastreceiver-keep PublicClass *ExtendsAndroid.content. contentprovider-keep public class Span class= "Hljs-title" >com.android. Vending. licensing. ilicensingservice-keepclasseswithmembernames class * {native <methods>;} -keepclasseswithmembernames class * {public <init> ( Android.content.Context, Android.util.AttributeSet);} -keepclasseswithmembernames class * {public <init> ( Android.content.Context, Android.util.AttributeSet, int);} -keepclassmembers enum * {public static **[] values (), public static * * VALUEOF (java.lang.String);}   

You can be based on this template in the increase and deletion check. In addition, I can control whether the log output is printed by code obfuscation:

   class android.util.Log {    public static *** d(...); public static *** v(...); }

In my writing this article, some of the company has been able to make the resource file name confusion, which makes the code more difficult to read! Here is the article: the practice of confusion and protection of Android resources in American Regiment

Prevent dynamic debugging

The so-called dynamic debugging is the use of the detection debugger

Detecting the debugger

The test is simple: When our software detects a connection to the debugger, it terminates the program!
First of all, we AndroidManifest.xml Application add this property in the label android:debuggable="false" , so that the program is not debugging, if someone wants to debug, it is necessary to modify this value, then we just add the code below the short code to detect whether the value has changed, if changed, stop the program.

if((getApplicationInfo().flags &=                  ApplicationInfo.FLAG_DEBUGGABL)!=0){   android.os.Process.killProcess(android.os.Process.myPid());}

This will solve the problem.

Prevent recompilation

When the code is uploaded, it needs to be signed to the app, and each signature file is only available to the app developer, so we can compare it to the content of the signature. But the signature of the file too long is not conducive to comparison, we used to meet the signature content hashCode to compare. Get the code for this value:

   public int getsignature(String packageName) { try { android.content.pm.Signature[] signatures= getPackageManager().getPackageInfo(packageName.toString(), PackageManager.GET_SIGNATURES).signatures; return signatures[0].hashCode(); } catch (PackageManager.NameNotFoundException e) { e.printStackTrace(); return 0; } }

We just get this value after we pack it locally, and then, every time the program runs, we can hashCode compare it with the values we've packaged locally before we get the signature. If it's different, just close the program directly!

NDK Protection

Is that the key code is written in C + + code and has not been studied

Add shell

The existing code is protected by a layer of C + + code and has not been studied

Resources

• Android software security and reverse analysis

"Turn" Android anti-cracking technology introduction