Android obfuscation from entry to mastery

Introduction

As an Android developer, if you do not want to open source your application, you need to obfuscate the code before publishing it, so that even if the code is decompiled, it is difficult to read. Although the concept of obfuscation is easy, many beginners just search for some established obfuscation rules on the Internet and paste them into their own projects without a deep understanding of obfuscation. The purpose of this article is to enable a beginner to independently write obfuscation rules suitable for their own code without any help after reading it.

Say it in advance

Here we will use Android Studio to explain how to perform obfuscation. Android Studio integrates the Java language ProGuard as a compression, optimization and obfuscation tool. It is very simple to use with the Gradle build tool. You only need to set minifyEnabled to true in the gradle file in the project application directory. Then we can add our obfuscation rules to the proguard-rules.pro file.

 android {
 ...
 buildTypes {
 release {
            minifyEnabled true  
            proguardFiles getDefaultProguardFile( 'proguard-android.txt' ), 'proguard-rules.pro'  
 }
 }
 }

The above sample code indicates that the release version is obfuscated. Next, we will first introduce the three major functions of ProGuard and briefly explain their commonly used commands.

ProGuard role

Shrinking: Enabled by default, used to reduce the size of the application, remove unused classes and members, and will be executed again after the optimization action is executed (because some unused classes and members may be exposed again after optimization).

 -dontshrink turns off compression

Optimization: Enabled by default, performs optimization at the bytecode level to make the application run faster.

 -dontoptimize turns off optimization
 -optimizationpasses n indicates the number of times proguard iterates to optimize the code. Android is generally 5

Obfuscation: Enabled by default, increases the difficulty of decompilation, and classes and class members will be randomly named unless protected with keep.

 -dontobfuscate Disable obfuscation

After obfuscation, a mapping.txt file will be generated in the project directory app/build/outputs/mapping/release by default. This is the obfuscation rule. We can use this file to reverse the obfuscated code back to the original code, so this file is very important and should be protected. In principle, the more chaotic and irregular the code is after obfuscation, the better. However, there are some places where we need to avoid obfuscation, otherwise the program will fail to run. So here is what we are going to teach you, how to avoid obfuscation of some of your code to prevent errors.

Basic Rules

Let's first look at the following two commonly used commands. Many people may be confused about the difference between the two.

 -keep class cn.hadcn.test.**
 -keep class cn.hadcn.test.*

One star means that only the class name under the package is kept, and the class names under the sub-packages will still be obfuscated; two stars mean that the class names under the package and the sub-packages are kept. After keeping the class with the above method, you will find that although the class name is not obfuscated, the specific method and variable names in it are still changed. At this time, if you want to keep the class name and keep the content inside from being obfuscated, we need the following method

 -keep class cn.hadcn.test.* {*;}

On this basis, we can also use basic Java rules to protect specific classes from being confused, such as using extend, implement, and other Java rules. The following example prevents all classes that inherit Activity from being confused:

 -keep public class * extends android.app.Activity

If we want to keep the inner classes in a class from being obfuscated, we need to use the $ symbol. The following example means keeping all public contents in the ScriptFragment inner class JavaScriptInterface from being obfuscated.

 -keepclassmembers class cc.ninty.chat.ui.fragment.ScriptFragment$JavaScriptInterface {
 public *;
 }

Furthermore, if you do not want to keep all the contents of a class from being obfuscated, but only want to protect specific contents under the class, you can use

 <init>; //Match all constructors
 <fields>; //match all fields
 <methods>; //Match all methods

You can also add private, public, native, etc. before <fields> or <methods> to further specify the content that is not to be obfuscated, such as

 -keep class cn.hadcn.test.One {
 public <methods>;
 }

This means that all public methods under the One class will not be obfuscated. Of course, you can also add parameters. For example, the following means that the constructor with JSONObject as input will not be obfuscated.

 -keep class cn.hadcn.test.One {
 public <init>(org.json.JSONObject);
 }

Sometimes you still think, I don't need to keep the class name, I just need to keep the specific methods under the class from being confused, then you can't use the keep method, the keep method will keep the class name, and you need to use keepclassmembers, so the class name will not be kept. In order to facilitate the understanding of these rules, the official website provides the following table

Removal refers to whether it will be deleted during shrinking. The above content is the key to master in the obfuscation rules. After understanding, you should be able to understand almost all obfuscation rule files. Combined with the following points,

Precautions

1. The jni method cannot be confused, because this method needs to be consistent with the native method;

 -keepclasseswithmembernames class * { # Keep native methods from being confused
 native <methods>;
 }

2. The classes used for reflection are not confused (otherwise reflection may cause problems);

3. Classes in AndroidMainfest are not obfuscated, so the four major components, Application subclasses, and all classes under the Framework layer are not obfuscated by default. Customized Views are also not obfuscated by default; so there is no need to add many rules posted online to exclude custom Views or obfuscation of the four major components in Android Studio;

4. When interacting with the server, when using frameworks such as GSON and fastjson to parse server data, the written JSON object class is not confused, otherwise the JSON cannot be parsed into the corresponding object;

5. When using third-party open source libraries or referencing other third-party SDK packages, if there are special requirements, you also need to add corresponding obfuscation rules to the obfuscation file;

6. If you use JS calls to WebView, you also need to ensure that the written interface methods are not confused. The reason is the same as in item ***;

7. Parcelable subclasses and Creator static member variables should not be confused, otherwise an Android.os.BadParcelableException will be generated;

 -keep class * implements Android.os.Parcelable { # Keep Parcelable from being confused
 public   static final Android.os.Parcelable$Creator *;
 }

8. When using the enum type, be careful to avoid confusion between the following two methods. Due to the particularity of the enum class, the following two methods will be called by reflection, see the second rule.

 -keepclassmembers enum * {
 public   static **[] values ​​();
 public   static ** valueOf(java.lang.String);
 }

Written in ***

When releasing an app, in addition to setting minifyEnabled to true, you should also set zipAlignEnabled to true. Google Play requires that developers upload apps that are zipAligned. ZipAlign can align the resources in the installation package to 4 bytes, which can reduce the memory consumption of the app at runtime.