Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about how to talk about the principle and implementation of Android apk reinforcement. Many people may not know much about it. In order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

The following mainly introduces the principle and simple implementation of apk reinforcement.

1. Common reinforcement methods of apk

(1) Code-level encryption-code obfuscation

Code obfuscation is a common encryption method. The essence is to change the original class name, variable name and method name in the project into names that people can't understand. The common code confusion tool proguard (if you are interested, you can take a look at this tool for yourself: http://t.cn/ELjgHdi). This encryption method only provides minimal protection to the project, which does not mean that it cannot be cracked in reverse; it just means that it is more difficult and requires patience.

(2) Dex file encryption

Dex is a code resource file in Android project, and java code can be decompiled through dex. The shell of dex is a common encryption method. By encrypting and splicing dex files and adding shells, the engineering code can be effectively protected. After the apk project is installed successfully, there will be a process of dex decryption when app starts, and then the decrypted dex file will be reloaded.

The second encryption method is the encryption method that this article wants to share for you. The basic principle is that in the jni layer, the DexClassLoader dynamic loading technology is used to dynamically load the encrypted classex.dex, and the dex file can be attached to the assert or raw directory.

Second, the principle of apk reinforcement

(1) apk file structure

Decompress an apk package and you can see the following directory structure:

Assets: the directory where project resources (pictures, local html, etc.) files are stored

Lib: stores so files compiled by ndk (files compiled by so:C/C++)

META-INF:

What is stored in this directory is signature information, which is used to ensure the integrity of apk packages and the security of the system

CERT.RSA: holds the certificate and authorization information for the application

CERT.SF: holds a list of SHA-1 information resources

MANIFEST.MF: inventory information

Res: the directory where resources (layout xml, layout xml reference pictures, etc.) files are stored

AndroidManifest.xml: manifest file, which describes the name, version, permissions, registered services, and other information of the application

Classes.dex:java source code compiles the compiled dalvik bytecode file, mainly the main part of the code running on the Dalvik virtual machine

Resources.arsc: compiled binary resource file

META-INF files are mainly related to signatures, which ensures the integrity and security of apk. The folder needs to be deleted each time apk re-signs.

The main thing you need to pay attention to is classes.dex files: because apk hardening is mainly about encrypting dex files.

(2) Dex file structure

Mapping relationship between Java Source File and Dex File

Dex files can be understood as compiled and produced by java files, and the intuitive manifestation is that dex files can compile java source code.

The purpose of the dex file is to record the information of all class files for the entire project (usually an Android project)

The dex file is evolved from the class file, the class file has redundant information, while the dex file removes the redundancy and integrates the class information of the whole project.

Dex file structure

The header header contains the information of the dex file, which is also the part that we need to pay attention to. Because there will be modifications to the dex file in the following operation, it is up to the header section to determine whether the correct dex file is correct.

Let's take a look at the information in the header section:

Struct DexFile {

DexHeader header

DexStringId StringIds [StringIdsSize]

DexTypeId TypeIds [typeIdsSize]

DexProtoId ProtoIds [protoIdsSize]

DexFieldId FieldIds [fieldIdsSize]

DexMethodId MethodIds [methodIdsSize]

DexClassDef Data []

DexLink LinkData

}

Dex file header partial structure information

The Header section has three fields to pay attention to: the checksum field, the signature field, and the filesize field.

Checksum field: checksum is a check code field to verify the integrity of dex data

Signature field: signature is a SHA-1 signature field, and dex data integrity check

Signature field: total length of saved classes.dex file

The reason for focusing on these three fields is that there will be a re-splicing of the dex later. These three fields should be modified after dex splicing, and the correct field modification can ensure the correct loading of dex.

(3) the principle of integral reinforcement of Dex files.

The object above is parsed:

Source apk: an apk program that needs to be encrypted. The source dex comes from the source apk.

Shell program: Android project, providing shell dex, shell dex is mainly used as engineering entrance, decrypting source dex, mapping to source dex and other operations

Encryption program: java project, which mainly encrypts the source dex and merges with the shell dex to form a new dex

(4) the loading principle of the whole project

APP startup-- > attachBaseContext () method in custom Application-- > Custom Application project onCreate () method-- > Source Application

1. The custom Application comes from the dex of the shell program. The first half of the new dex synthesized by encryption is the dex of the shell program. There is no problem with this part and can be loaded normally. The attachBaseContext method in the Application will decrypt the source dex and place it in a fixed directory, add the load mapping of dex, and map to the source dex directory.

2. The custom Application project onCreate () method adds the entry for loading the source dex; that is, the application and mainActivity of the source dex.

3. The program starts normally; the source dex is loaded correctly.

Third, the realization of apk reinforcement

Prepare:

SourceProject:

You need to encrypt the source program. Customize the application as follows:

Com. Targetapk

MyApplication, and the main activity is:

Com. Targetapk.MainActivity

JiaguApk:java project, dex encryption merge operation

ShellApk:android project, provide shell dex; custom Application set to:

Org.hackcode.ProxyApplication

SourceProject is a simple Android engineering demo that compiles and generates sourceProject.apk encrypted by shells.

The main function of jiaguApk is to encrypt the dex file in the source sourceProject.apk; then splice it to the shell dex to generate a new dex

ShellApk is a shell project, which is mainly used as a pseudo entrance to encrypted apk. The encrypted apk project will first load the shell project to provide Application:org.hackcode.ProxyApplication, decryption, mapping and other operations.

Overall encryption steps:

1. Decompile the target app (sourceProject.apk) to get the sourceProject file; sourceProject.apk comes from the SourceProject project

two。 Modify the manifest file in the sourceProject file to set the custom Application to "org.hackcode.ProxyApplication"

3. Get the dex file in the sourceProject file and compress it to TargetApk.zip

4. Reverse compile the shell apk:apktool.bat d shellApk.apk to get the shellApk file

5. Get the classes.dex and TargetApk.zip under the shellApk file, encrypt and synthesize the new classes.dex file

6. The newly synthesized class.dex replaces the class.dex in the sourceProject file

7. Delete the META-INF file in the sourceProject file and recompress it into a zip file

8. Re-sign

Step 2 is mainly to load the code in the shell dex; parse the dex correctly.

Step 6 is mainly the work of the jiaguApk project.

JiaguApk key code

The main function of the above code is that the source program dex is compressed into TargetApk.zip and then encrypted and spliced at the back of the shell dex, then a new dex file is generated, and the dex file modifies the header parameters to ensure that the dex file is read correctly.

The first part of the new dex file generated at this time is the code for the shell dex that can be run correctly.

Key Code of shellApk Shell Engineering

AttachBaseContext method:

The main function is to copy the dex in the program apk, decrypt the source dex and put it under the data/data directory; set up the dex load directory mapping.

OnCreate:

The main function is to replace the source application dex's application to make the decrypted source dex loaded correctly, to ensure that the source entry is correct, and to ensure that the project is loaded correctly.

The above is the whole process of apk shell implementation. There is basically no problem with implementation, but the point to note is that the source project has multiple dex problems: when there are multiple dex in the source program, multiple dex are compressed into TargetApk.zip at the same time, and the other steps remain the same. There's no problem with the test!

Fourth, the defects of apk after reinforcement.

(1) the problem of slow loading when opening for the first time. The first opening of the reinforced project will have a delay, and the delay time will be related to the dex size of the source project. Take Puyuan client, for example, there are two dex, a total of about 8m; after reinforcement, the first opening will slow down about 3s; and each time you open it later, there will be a delay of about 2s.

(2) Security. You will find that the source dex file will still fall to the ground, and the jailbreak phone can see it directly under the project's data/data directory. If you get the dex resource, you can also get the java code through decompilation. There is a way not to land on the Internet, but the attempt has not been successful. If any god has a feasible way, you are welcome to share and communicate.

Selected questions:

Q1: can you tell me about .so reinforcement?

Answer: .so decompilation is more difficult than dex decompilation. The general practice is to extract the key java code of the Android project and convert it into a so file. So encryption I just learned how to destroy the .so part of the header file reinforcement.

Q2: what is the VMP (virtual machine) in the reinforcement?

A: the general idea of VMP (virtual software protection technology) is to customize a set of virtual machine instructions and the corresponding interpreter, and convert the standard instructions into their own instructions, and then the interpreter will send their own instructions to the corresponding interpreter.

After reading the above, do you have any further understanding of how to talk about Android apk hardening principle and implementation? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.