Android cracking APK files

Reprinted please indicate the source: http://www.blogjava.net/zh-weir/arch...11/352099.html

APK Crack

Before writing this article, I was hesitant to start a Pandora box? Later, we thought that similar Android malware had already been released, indicating that many software security experts or hackers are familiar with this. As a evangelist, I only tell you the secrets that a few people know. As a result, I think I am contributing to the early maturity of the Android software security industry ~!

The so-called APK refers to the application installation file of the Android operating system. The so-called crack is simply interpreted as "cracking ". I specifically refer to decompiling the APK file for assembly-level code analysis, modifying or inserting your own code, re-signing and packaging it as an APK file, in order to change the original behavior of the program.

As described above, we need to crack an APK file. The main process involves three steps: decompilation, code analysis, and re-packaging signature.

Basic preparation

We need some basic tools for some major work. If you are a friend of the Chinese version of Android APK, you should be familiar with these tools:

The first tool is Android-apktool, a tool for reengineering Android APK files. This tool is the core of APK crack. It is used to decompile and repackage APK files. It is a well-known open-source project on Google code. You can obtain its wiki, source code, and other related information on the Google Code webpage. URL: http://code.google.com/p/android-apktool.

The second tool is auto-sign. This tool implements the signature of the APK package and is a small tool.

In addition to these basic tools, you may need to use some other tools, such as dex2jar and JD-Gui, for better code analysis.

Decompilation

If you are a friend of the regular Chinese APK program, you will not be unfamiliar with the decompilation step. However, since this article focuses on the basic process, this step cannot be saved. Therefore, skip this step if you think you are a friend. First, we need an APK to be decompiled. Here I wrote a helloworld APK with the following code:

Package com. zh_weir.helloworld;
Import Android. App. activity;
Import Android. OS. Bundle;
Public class mainactivity extends activity {
/** Called when the activity is first created .*/
@ Override
Public void oncreate (bundle savedinstancestate ){
Super. oncreate (savedinstancestate );
Setcontentview (R. layout. Main );
}
}

We use Android-apktool to decompile this APK. For the use of Android-apktool, I will not do much translation work. Let's provide instructions directly. In a simple sentence, the command line is executed.

Apktool v1.3.2-A Tool for reengineering Android APK files
Copyright 2010 Ryszard wi? Niewski <brut.alll@gmail.com>
Apache license 2.0 (http://www.apache.org/licenses/LICENSE-2.0)
Usage: apktool [-v | -- verbose] command [...]
Commands are:
D [ecode] [opts] <file.apk> [<dir>]
Decode <file.apk> to <dir>.
Opts:
-S, -- no-Src
Do not decode sources.
-R, -- no-res
Do not decode resources.
-D, -- debug
Decode in debug mode. Check project page for more info.
-F, -- force
Force Delete destination directory.
-T <tag>, -- frame-tag <tag>
Try to use framework files tagged by <tag>.
-- Keep-broken-res
Use if there was an error and some resources were dropped, e.g .:
"Invalid config flags detected. Dropping resources", but you
Want to decode them anyway, even with errors. You will have
Fix them manually before building.
B [uild] [opts] [<app_path>] [<out_file>]
Build an APK from already decoded application located in <app_path>.
It will automatically detect, whether files was changed and perform
Needed steps only.
If you omit <app_path> then current directory will be used.
If you omit <out_file> then <app_path>/Dist/<name_of_original.apk>
Will be used.
Opts:
-F, -- force-all
Skip changes detection and build all files.
-D, -- debug
Build in debug mode. Check project page for more info.
If | install-framework <framework.apk> [<tag>]
Install framework file to your system.
For additional info, see: http://code.google.com/p/android-apktool/

Through the apktool D helloworld.apk Command, we have completed a simple decompilation of APK. A folder named "helloworld" is obtained. You can see a manifest file and a decompiled res resource file in the folder. These things are of special interest in Chinese at ordinary times, rather than the focus we should pay attention. Note that a folder named "smali" is used.

After careful observation, you will find that the file structure in this folder is almost the same as that of the Java source code in our android project. The Java file is replaced by the. smali file. Open these. smali files in a text editor and you will find that they are all identifiable and "neat" text files, roughly as follows:

. Class public lcom/zh_weir/helloworld/mainactivity;
. Super landroid/APP/activity;
. Source "mainactivity. Java"
# Direct methods
. Method public constructor <init> () V
. Locals 0
. Prologue
. Line 6
Invoke-Direct {P0}, landroid/APP/activity;-> <init> () V
Return-void
. End Method
# Virtual Methods
. Method public oncreate (landroid/OS/bundle;) V
. Locals 1
. Parameter "savedinstancestate"
. Prologue
. Line 10
Invoke-Super {P0, P1}, landroid/APP/activity;-> oncreate (landroid/OS/bundle;) V
. Line 11
Const/high16 v0, 0x7f03
Invoke-virtual {P0, V0}, lcom/zh_weir/helloworld/mainactivity;-> setcontentview (I) V
. Line 12
Return-void
. End Method

The smali file is an assembly file corresponding to the DEX bytecode file run by the Dalvik virtual machine. If you know the Java Virtual Machine Assembly Language Jasmin, you will find that the syntax of the two is very similar. About smali syntax and other issues will not go deep, if you want to learn more, you can visit the Google Code on the smali project home page: http://code.google.com/p/smali.

Code Analysis and Modification

Even if you don't know the Jasmin syntax, you can easily understand the assembly code above. It should be noted that the Assembly Code decompiled by apktool is also object-oriented, rather than process-oriented. This may be different from the decompilation of C ++.

According to the code above, we can see that this mainactivity class has two member methods. One is the default constructor, and the other is the overloaded oncreate method.

In Java assembly, each member method must first declare the number of local variables used by itself, so as to allocate storage space. For example, if oncreate uses a local variable, it declares:. Locals 1. V0 is used later.

In a non-static member method, P0 represents the reference of this class, which is equivalent to this. P1 is the function parameter. For static methods, because this pointer is not provided, therefore, P0 is the first parameter of the function. (In fact, this pointer is passed to non-static member functions as an implicit parameter ).

By analyzing the assembly code of oncreate above, we can know that it calls the oncreate method of the super class first, and then sets the display of setcontentview. Among them, I, V, and so on represent the function parameters and return variable types. This is a common practice and will not be explained here.

After analyzing this step, do you find a problem? That is, if we modify or delete a statement according to the same syntax, can we modify the program? The answer is yes.

For example, we want this APK program to pop up a toast during runtime, prompting it to be cracked. If Java is used, it should be expressed as follows:

Toast. maketext (this, "I'm cracked! ", Toast. length_long). Show ();

In Java compilation, it should be expressed as follows:

Const-string v0, "I \'m cracked! "
Const/4 V1, 0x1
Invoke-static {P0, V0, V1}, landroid/widget/toast;-> maketext (landroid/content/context; ljava/lang/charsequence; I) landroid/widget/toast;
Move-result-object V0
Invoke-virtual {v0}, landroid/widget/toast;-> show () V

OK, as long as we insert this code into the oncreate of the original program and re-package the program, we can realize that toast is displayed when the program is running.

The modified code is roughly as follows:

# Virtual Methods
. Method public oncreate (landroid/OS/bundle;) V
. Locals 2
. Parameter "savedinstancestate"
. Prologue
. Line 11
Invoke-Super {P0, P1}, landroid/APP/activity;-> oncreate (landroid/OS/bundle;) V
. Line 12
Const/high16 v0, 0x7f03
Invoke-virtual {P0, V0}, lcom/zh_weir/helloworld/mainactivity;-> setcontentview (I) V
. Line 14
Const-string v0, "I \'m cracked! "
Const/4 V1, 0x1
Invoke-static {P0, V0, V1}, landroid/widget/toast;-> maketext (landroid/content/context; ljava/lang/charsequence; I) landroid/widget/toast;
Move-result-object V0
Invoke-virtual {v0}, landroid/widget/toast;-> show () V
. Line 15
Return-void
. End Method

Recompile and package the signature

After modification, We can compile and package the folder. Similarly, we use apktool. Run the apktool B helloworld command to compile and package the program. At this time, two folders will be generated under this folder: Build the folder that stores intermediate files and DIST the folder that stores the final APK files.

If it is convenient, you can view the modified helloworld.apk in the distfolder. However, you must note that this APK file has no signature, so it cannot be installed and run. The last step is to sign the APK.

The signing tool we need is auto-sign. It uses the batch processing command to sign the APK file using signapk. jar. You can use NotePad to open sign. BAT and check its calling relationship. The key is as follows:

Java-jar signapk. Jar testkey. x509.pem testkey. pk8 update.apk update_signed.apk

OK! At this point, the crack for this APK is over. Now install the signed APK program on the simulator or android machine and run it. Everything is the same as we expected ~

How to crack

This article has ended. However, for software security, protection is required for attacks. Otherwise, the entire android industry chain will be destroyed by such crack. Due to limited space, we will not describe the anti-cracking mechanism in detail. I just want to give a brief explanation of the concept and hope you will understand it.

Method 1: Write the core code into the so library using JNI. As the so library is more difficult to decompile and crack, this method has a good effect in preventing decompilation. The disadvantage is that the Java-Layer Code is not protected and can also be tampered.

Method 2: Online signature comparison. During program initialization, the network will compare the running program signature with the official standard signature on the server, so as to make the decompiled program unable to run normally. The disadvantage is that if the code for this part of the online verification is tampered with and skipped, the entire mechanism will become invalid.

Method 3: code obfuscation. To increase the difficulty of code analysis after decompilation, You can confuse the code. The disadvantage is that it can be modified as well (it is said that there are also anti-obfuscation tools that have never been used and do not need to make comments ).

These three methods have their own shortcomings, so it is impossible to achieve perfect software protection by one. However, we can combine several methods to enhance software protection. Kaspersky, which has decomcompiled Android, seems to have the following protection ideas:

Code obfuscation is required, but it is not expected to have good results. During program initialization, the program is initialized directly through the so library of JNI. The program activation part also downloads files through the JNI network, reads the files at the JNI layer, and determines whether the files are activated or not.

Kaspersky places most functional modules on the JNI layer for implementation. If our programs process this way, it will take a lot of effort. Therefore, we just need to learn from its ideas. The procedure is as follows:

Code obfuscation. During initialization, The JNI layer is connected to IOT platform to verify the signature. If verification fails, exit the program at the JNI layer. It is worth noting that the program cannot be started normally if the JNI layer Initialization is bypassed. If this is not guaranteed, it is still very easy to crack ......