Complete analysis of Android security attack and defense, decompilation and obfuscation technologies (I)

Complete analysis of Android security attack and defense, decompilation and obfuscation technologies (I)

I have been hesitant to write this article before. After all, it is not proud to decompile other programs. However, from a technical point of view, it is indeed a very useful skill to master the decompilation function, which may not be used very often, that's a headache. In addition, since someone else can decompile the program, we certainly have a reason to protect the program to a certain extent, so code obfuscation is also a technology we must master. In the last two articles, we will perform a full parsing on The Decompilation and obfuscation topics.

Decompilation

We all know that the Android program obtains an APK file after the package is completed. This file can be directly installed on any Android mobile phone. Our decompilation is actually the decompilation of this APK file. Android decompilation mainly consists of two parts: Code decompilation and resource decompilation. We will learn about this one by one.
Before learning, we need to prepare an APK file. To respect all developers, I will not use any software on the market for demonstration, but write a Demo for testing.
Here I want the code to be simpler and better, so we create a new project, add a button in the Activity, and a Toast will pop up when the button is clicked. The Code is as follows:

public class MainActivity extends AppCompatActivity {    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        Button button = (Button) findViewById(R.id.button);        button.setOnClickListener(new View.OnClickListener() {            @Override            public void onClick(View v) {                Toast.makeText(MainActivity.this, "you clicked button", Toast.LENGTH_SHORT).show();            }        });    }}

The resources in activity_main.xml are as follows:

<code class="language-xml hljs "><!--{cke_protected}{C}%3C!%2D%2D%3Fxml%20version%3D%221.0%22%20encoding%3D%22utf-8%22%3F%2D%2D%3E--><relativelayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" android:paddingbottom="@dimen/activity_vertical_margin" android:paddingleft="@dimen/activity_horizontal_margin" android:paddingright="@dimen/activity_horizontal_margin" android:paddingtop="@dimen/activity_vertical_margin">    </relativelayout></code><button android:id="@+id/button" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="Button"><code class="language-xml hljs "></code></button>

Then we pack the code into an APK package and name it demo.apk, and then install it on the mobile phone. The result is as follows:

Okay. Now the preparation is complete. Let's start decompiling the Demo program. Decompilation code

To decompile the code in the APK file, we need to use the following two tools:

Dex2jarThis tool is used to convert dex files to jar files.
: Http://sourceforge.net/projects/dex2jar/files/ Jd-guiThis tool is used to convert jar files into java code.
: Http://jd.benow.ca/

Download the two tools and decompress them. Then we start to decompile the Demo program. After extracting the dex2jar package, you will find many files, as shown in:

Here we want to use the d2j-dex2jar.bat file, of course, if you are a linux or mac system, you need to use the d2j-dex2jar.sh file.
Then We decompress the demo.apk file. If you do not know how to directly decompress the file, you can first rename the file to demo.zip, and then open it with the decompressed software. After decompression, you will find a classes. dex file in it, as shown in:

The classes. dex file stores all the java code. We copy it to the directory decompressed by dex2jar, and enter the same directory in cmd, and then execute:

 

d2j-dex2jar classes.dex

Shows the execution result:

If no error is reported, the conversion is successful. Now, observe the dex2jar directory and you will find an additional file, as shown in:

We can see that the classes-dex2jar.jar file is the jar file that we successfully converted with the help of the tool. But for us, the jar file is not readable, so we need to use the jd-gui tool to convert the jar file into java code.
The following is simple, use jd-gui tool to open the classes-dex2jar.jar file, the result is shown:

OK. It can be seen that our code decompilation has been successful, and the code in MainActivity is very clear, basically more than 90% of the restoration work has been done. However, it is very difficult to restore the code of 100%, because the parameter passed in like setContentView () is actually the id value of a resource, in this case, the decompilation can only restore the corresponding id value, instead of being like R. layout. activity_main provides an intuitive display of code.
In addition, in addition to MainActivity, there are many other code is also decompiled, because the current project has reference support-v4 and support-v7 package, these referenced libraries will also be packaged into classes as part of the code. in the dex file, the code will be restored together during decompilation.
Okay. After learning the decompilation code, let's take a look at how to decompile resources. Decompilation Resources

However, I have observed that the decompressed directory of demo.apk does not contain any resource files, AndroidManifest. xml files, or res directories. Go to the res directory, as shown in:

Isn't all resource files here? In fact, these resource files have been compiled during packaging. If we open them directly, we cannot see the plain text. If we do not believe it, we can open the AndroidManifest. xml file to check the content, as shown in:

As you can see, this code is completely unreadable. Of course, if you open activity_main.xml, the result will not be good:

It can be seen that the original resource file cannot be obtained by directly extracting the APK package, so we still need to decompile the resource.
To decompile Resources in the APK file, another tool is required:

 

ApktoolThis tool is used to restore a maximum of 9-patch images, la S, strings, and other resources in the APK file.
: Http://ibotpeaches.github.io/Apktool/install/

I want to add a few more words about downloading this tool. What we need is the apktool. bat and apktool. jar files. Currently apktool. the latest version of jar is 2.0.3. Here I will download the latest version, and rename apktool_2.0.3.jar to apktool. jar and put them in the same folder, as shown in:

The next work is very simple. We copy demo.apk to the same directory as the two files, then cmd also enters the directory, and execute the following command in cmd:

 

apktool d Demo.apk

In this case, D is the idea of decode. we need to decode the demo.apk file. In addition to this basic usage, we can add some additional parameters to control more decode behaviors:

-FIf the target folder already exists, force Delete the existing folder (if the target folder already exists by default, decoding fails ). -OSpecify the name of the target folder to be decoded (the APK file name is used by default to name the target folder ). -SIf the dex file is not decompiled, the classes. dex file will be retained (the dex file will be decoded to the smali file by default ). -RDo not decompile the resource file, that is, the resources. arsc file will be retained (resources. arsc will be decoded into a specific resource file by default ).

The execution results of the preceding commands are as follows:

This indicates that the decompilation resource is successful.
Of course, even if you perform the same operations as me, The Decompilation may fail here. For example, the following error will be reported:

The cause of this error is probably that you have used an earlier version of apktool for decompilation, and then apktool will C:\Users\Administrator\apktool\frameworkA directory named 1.apkAnd then re-execute the decompilation command.
Now you will find that there is an additional Demo folder in the current directory, which stores the decompilation results. We can open AndroidManifest. xml to take a look, as shown in:

How is it? In this way, you can fully understand it. Then you can go to res/layout and check the activity_main.xml file, as shown in:

As you can see, the content in activity_main.xml is basically the same as that in the source code. The outer layer is a RelativeLayout, and the inside is a Button. You can go to other directories to check other resources, which can be restored normally. In this way, we have mastered the method of decompiling resources.

 

Repackage

Can we repackage decompiled folders into an APK file? The answer is yes, but I really don't know why we can do this. Some people will say that the Chinese language is correct. The Chinese language is indeed to decompile an APK and then translate the resources and repackage them, but in any case, this is still to crack other people's programs, so I do not think this is a glorious thing. In this case, we will not discuss the right or wrong things of ourselves. Here we will only learn the related knowledge of repackaging from the technical point of view.
First, let's take a look at the package directory situation after decompiling through apktool, as shown in:

The original AndroidManifest is stored in the original folder. xml file. The res folder stores all decompiled resources, and the smali folder stores all decompiled code, AndroidManifest. xml is the manifest file after decompilation and restoration. The smali folder is worth mentioning here. If you enter this folder, you will find that its directory structure is almost the same as the src directory structure in our source code, the main difference is that all java files become smali files. The smali file is actually the real source code, but its syntax is completely different from that of java. It is a bit similar to the Assembly syntax and is the register language used by the Android virtual machine. The syntax structure is roughly as follows:

Looks dizzy, right? But if you can understand the smali file, you can do terrible things-you can modify the logic in the application and crack it at will!
However, I am not very interested in this kind of black technology, so I have not made any specific research, but even so, I can make some modifications to the logic of the program. For example, when we click the button you clicked buttonThe logic of Toast is written in the anonymous class of the event when the MainActivity button is clicked. Therefore, after this code is decompiled, it will definitely be in MainActivity $1. in the smali file, let's take a look. Some code is as follows:

Although I can't understand most of the Code, the first line is too obvious. Isn't the content displayed by Toast defined here? If we want to drop the Demo program hack, you can change this string. For example, you can change it Your app is been hacked.
There are a lot of online materials about the syntax of smali. If you are very interested in this technology, you can search for it online. Here I will just give a brief introduction, I will not go into depth on the relevant knowledge.
After changing a code, let's change a resource. For example, if you want to change the Demo application icon, you must first prepare a new image, as shown in:

 

And then copy it to all folders starting with res/mipmap to complete the replacement operation.
After two changes, we can re-package the decompiled Demo folder into an APK. In fact, this is very simple. You only need to execute the following command in cmd:

apktool b Demo -o New_Demo.apk

. Shows the execution result:

Now you will find that a new APK file is generated under the same level directory:
Kernel + 87EvP7E2KO/kernel/vOxLz + kernel/kernel + zbrDwcujrM + kernel/kernel + rPJ0ru49sepw/vOxLz + kernel/vD/MHuvs2/ ydLUvfjQ0Mepw/vBy6Osw/zb71_xyr3i58/Co7oNCjxwPiZuYnNwOzwvcD4NCjxwcmUgY2xhc3M9 "brush: java; "> Jarsigner-verbose-sigalg SHA1withRSA-digestalg SHA1-keystore signature file name-storepass signature password the alias of the APK file name to be signed

The jarsigner command file is stored in the bin directory of jdk. You need to configure the bin directory in the system environment variable to execute this command at any location.
The signed APK file can now be installed on the mobile phone. However, before that, Android strongly recommends alignment of the signed APK file, this can make our program run faster in the Android system. The alignment operation uses the zipalign tool, which is stored in/build-tools/ Directory, configure this directory to the system environment variables to execute this command anywhere. The command format is as follows:

zipalign 4 New_Demo.apk New_Demo_aligned.apk

4 indicates that the fixed value cannot be changed, and the APK file name to be aligned and the aligned APK file name are specified later. After running this command, a new_demo_aligned.apk file will be generated, as shown below:

This new_demo_aligned.apk is the file after we re-package the signature aligned.apk. Now we have installed it on the mobile phone, as shown in the following figure:

As you can see, the app icon has been successfully changed to basketball, and the prompt "Toast" popped up after clicking the button is also changed to the modified text, indicating that the repackaging operation has been successful.

 

All right, we have mastered the three theme content: decompilation code, decompilation resources, and re-packaging. Here is the content about decompilation, the next article will introduce the related Android code obfuscation technologies.