WO2016078130A1

WO2016078130A1 - Dynamic loading method for preventing reverse of apk file

Info

Publication number: WO2016078130A1
Application number: PCT/CN2014/092643
Authority: WO
Inventors: 刘鹏
Original assignee: 刘鹏
Priority date: 2014-11-18
Filing date: 2014-12-01
Publication date: 2016-05-26
Also published as: CN104318155A

Abstract

Disclosed is a dynamic loading method for preventing reverse of an APK file. The method comprises the steps of: loading a first Classes.dex file, invoking an Entry.so file, and decrypting an Encrypt'.so file by using the Entry.so file to obtain a decrypted Encrypt.so file; decrypting a second Classes.dex file by using the Entry.so file, to obtain an original Classes.dex file in an APK file before reinforcement processing; dynamically loading the original Classes.dex file, finding a physical address of a source code for storing functions of the APK file, and dynamically loading the source code to a memory; and deleting the decrypted original Classes.dex file from the physical memory. By means of the present invention, decompilation of an existing Android reverse tool can be circumvented, the difficulty in decompilation is increased, and thus the security of the APK file can be greatly improved.

Description

Dynamic loading method of anti-reverse APK file

Cross-reference to related applications

The present application claims priority to the benefit of the priority of the entire disclosure of the entire disclosure of the entire disclosure of the entire disclosure of the entire disclosure of

Technical field

The present invention relates to the field of mobile terminal application security, and in particular, to a dynamic loading method of an anti-reverse APK file.

Background technique

APK (short for Android PacKage) is the Android installation package. You can install the APK file (ie APK app) directly to the Android emulator or Android device terminal device (such as Android smartphone). The APK file is actually in zip format, but the suffix name is modified to apk. On the windows system, you can unzip it directly through the decompression tool (such as winrar software). After extracting the APK file, the general directory structure that can be seen is shown in Table 1 below:

Table 1

The final stage of Android application development is to package the signature, generate APK file for users to download and install, package and package into APK file as shown in Figure 1. It can be seen that if you can reverse the Dex file and AndroidManifest.XML, you can restore the source code of the application APK file. If you add malicious code based on the source code, re-sign and package, you can generate malicious code. APK file.

With the development of Android mobile terminal platforms, third-party applications have emerged in large numbers, and piracy and re-packaging of third-party applications has become increasingly serious. Since the programming language used by the Android platform software is Java, the compiled binary code of the Java source code is extremely easy to be decompiled, which makes the cracking process much less difficult than other programs written in the compiler language. In view of the Android APK file can be easily decompiled by dex2jar and JD-GUI, JAD and other decompilation tools into easy-to-read JAVA code, so that the plaintext strings, library function calls, core function functions, etc. in the code are clear at a glance, so that It is easier for illegal developers to reverse the piracy or core functionality of third-party applications.

Summary of the invention

In order to reduce the risk of the APK file being reversed, the present invention provides a dynamic loading method for the anti-reverse APK file, which solves the problem that the APK file (ie, the APK application) is easy to be decompiled and displayed, and is easy to be leaked. Tripartite application hardening to maximize the security of your APK app.

The invention adopts the following technical solutions: a dynamic loading method of the anti-reverse APK file, which comprises the steps of: loading the first Classes.dex file, calling the Entry.so file, and decrypting the Encrypt'.so file by using the Entry.so file. Processing, get the decrypted Encrypt.so file;

The second Classes.dex file is decrypted by using the Entry.so file to obtain the original Classes.dex file in the APK file before the reinforcement processing;

Dynamically load the original Classes.dex file and find the source code for storing the APK file function. Physical address, dynamically load source code into memory;

Delete the decrypted original Classes.dex file from physical memory;

The first Classes.dex file only contains the file header structure of the original Classes.dex file, the second Classes.dex file and the Encrypt'.so file are stored under the file directory res, and the Entry.so file is stored in the file. Under the directory libs, the anti-reverse APK file is formed by the first Classes.dex file, the AndroidManifest'.xml file, the file directory res, the file directory libs, and the resources.ars file.

Wherein, before decrypting the second Classes.dex file, the step of performing integrity check on the original Classes.dex file is also included.

The integrity check of the original Classes.dex file obtained by decrypting is performed by using the field information contained in the header structure of the first Classes.dex file.

The specific loading of the original Classes.dex file includes: creating a new DexClassLoader object with the source class Classes.dex, and replacing it with the attribute mClassLoader in the default loading class of the system.

Wherein, according to the data_size field and the data_off field information in the file header structure of the original Classes.dex file, and find the physical address of the source code for storing the function of the APK file.

The step of dynamically loading the source code into the memory specifically includes:

Using the custom onCreate method, find the physical address of the source code through the meta-data attribute in the application in the AndroidManifest, and replace it with the Application of the source program;

Remove the existing "first Application file" from the call collection, and create a new Application object app, bind the properties of the original Classes.dex file to the app, and then add the app to the memory call set;

Since the component Provider is registered by the system before the onCreate method, the app is bound to the context of the Provider in the source program, and then the system-level onCreate method is started.

Compared with the prior art, the present invention has the following beneficial effects:

The APK files that are reinforced by the above-mentioned hardening methods are reverse-compiled using the most popular Android reverse tool dex2jar and apktool respectively. Since the reversed compiled first Classes.dex file does not have source code, the main function of implementing an APK file is implemented. The source code is still stored in the original Classes.dex file, but the original Classes.dex file is encrypted into the second Classes.dex file and stored in the specified file directory. It is difficult to find the decrypted first by using the reverse tool dex2jar and apktool. The second Classes.dex file, even if the second Classes.dex file is found, cannot be decrypted because the Encrypt'.so file for decrypting the second Classes.dex file cannot be found, thereby effectively preventing the APK file from being reversely modified and leaking. It can be seen that after the reinforcement method mentioned in the present application is used for reinforcement, the encryption of the source code of the APK file is realized, and the decompilation of the existing Android reverse tool can be avoided, thereby greatly improving the security of the APK file. .

DRAWINGS

FIG. 1 is a schematic diagram of a package and package process of an APK file.

2 is a schematic flow chart of a method for reinforcing an anti-reverse of an APK file of the present invention.

Figure 3 is a comparison diagram of the file directory structure before and after the APK file is hardened.

FIG. 4 is a schematic diagram of a process of dynamically loading an APK file after reinforcement.

detailed description

In order to facilitate the understanding of the technical solution of the present application, the applicant first introduces the classes.dex file in the APK file directory structure in detail:

The classes.dex file is a java bytecode file generated after the java source code is compiled. However, since the dalvik virtual machine used by Android is incompatible with the standard java virtual machine, the dex file is different from the class file in terms of file structure and opcode. The classes.dex file consists of three parts: the file header, the index area, and the data area. Among them, the structure of the header part of the classes.dex file is defined as shown in Table 2 below.

Table 2

In the Android source code, the implementation of the Dalvik virtual machine is located in the dalvik/ directory, where dalvik/vm is the implementation part of the virtual machine and will be compiled into libdvm.so; and dalvik/libdex will be compiled into the libdex.a static library as dex Tools; dalvik/dexdump is a decompile tool for .dex files; virtual machine executables are located in dalvik/dalvikvm and will be compiled into dalvikvm executables.

When running the APK file on the Android platform, first load the decompressed APK file and verify the integrity by the Dalvik virtual machine (in the Android source code, the Dalvik virtual machine is located in the dalvik/ directory), extract the Classes.dex file, and then execute the classes. The bytecode in the dex file. When executing the classes.dex file, the Dalvik virtual machine first checks the checksum field and the siganature field of the header portion of the file to ensure that the classes.dex file is not corrupted or tampered, and then based on the offset of other structures defined in the file header. And length information for addressing resolution and execution. Finally, the dalvik virtual machine reads the instructions and data from the classes.dex file, and then runs the program logic of the APK file.

Referring to Figure 2, a preferred embodiment of the present invention includes the following implementation steps:

Step S11: Copy the original Classes.dex file in the APK file to be hardened, delete the function source code of the APK file in the copied Classes.dex file, and save the first Classes.dex file. Therefore, the first Classes.dex file only retains the file header structure of the original Classes.dex file, and does not contain the function code of the APK file.

Step S12: Encrypt the original Classes.dex file with a preset encryption and decryption algorithm to obtain a second Classes.dex file. Therefore, the main function code of the APK file is still in the second Classes.dex file, hiding and protecting the second Classes.dex file is the hardening of the APK file. It is also an important part of preventing APK files from being reversed.

Step S13: Generate an Encrypt.so file for decrypting the second Classes.dex file, and perform secondary encryption on the Encrypt.so file to obtain an Encrypt'.so file.

Step S14: Generate an Entry.so file, which is an entry file when the APK file is run, and decrypts the Encrypt'.so file into an Encrypt.so file by calling the native method in the entry file Entry.so.

Step S15: Point the source entry of the original AndroidManifest.xml file in the APK file to be hardened, and change the file to point to the first Classes.dex file, and the modified file is recorded as the AndroidManifest'.xml file.

Step S16: storing the second Classes.dex file and the Encrypt'.so file in the file directory res, and storing the Entry.so file in the file directory libs, to the first Classes.dex file and the AndroidManifest'.xml file. The file directory res, the file directory libs, and the resources.ars file are packaged and packaged, and then the signature file is used to sign the package file, which completes the reinforcement of the APK file. Specifically, a comparison of the file directory structure of the APK file before and after the reinforcement is shown in FIG. 3 .

When the reinforced APK file is running, as shown in FIG. 4, the loading operation process includes the following steps:

Step S21: According to the source program entry point in the AndroidManifest'.xml file, when the reinforced APK file is running, the first Classes.dex file is first loaded by the Dalvik virtual machine.

Step S22: The Entry.so file is called by the first Classes.dex file, and the Encrypt'.so file stored in the file directory res is decrypted by using the Entry.so file to obtain the decrypted Encrypt.so file.

Step S23: Decrypt the second Classes.dex file stored in the file directory res according to the preset encryption and decryption algorithm by using the Entry.so file, thereby obtaining the original Classes.dex file in the APK file before the reinforcement processing.

Step S24, using the field information included in the file header structure of the first Classes.dex file, The original Classes.dex file obtained by the decryption is checked for integrity, and after the integrity check, the process proceeds to step S26.

Step S25: The Dalvik virtual machine dynamically loads the original Classes.dex file according to the Android class dynamic loading technology (DexClassLoader program). The specific process is to create a new DexClassLoader object with the source class Classes.dex, and replace it with the property mClassLoader in the default loading class of the system.

Step S26: Find the physical address of the source code storing the function of the APK file according to the data_size field and the data_off field information in the file header structure in the original Classes.dex file, and dynamically load the source code into the memory. Specifically, using the custom onCreate method, the physical address of the source code is found through the meta-data attribute in the application in the AndroidManifest, thereby replacing the Application of the source program; the existing "first Application file" is called from the system. Remove the collection, and create a new Application object app, bind the properties of the original Classes.dex file to the app, and then add the app to the system call collection; finally, because the component Provider is registered by the system before the onCreate method, Bind the app to the context of the Provider in the source program, and then start the system-level onCreate method.

In step S27, the decrypted original Classes.dex file is deleted from the physical memory of the system to prevent the attacker from stealing.

The APK files that are reinforced by the above-mentioned hardening methods are reverse-compiled using the most popular Android reverse tool dex2jar and apktool respectively. Since the reversed compiled first Classes.dex file does not have source code, the main function of implementing an APK file is implemented. The source code is still stored in the original Classes.dex file, but the original Classes.dex file is encrypted into the second Classes.dex file and stored in the specified file directory. It is difficult to find the decrypted first by using the reverse tool dex2jar and apktool. The second Classes.dex file, even if the second Classes.dex file is found, cannot be decrypted because the Encrypt'.so file for decrypting the second Classes.dex file cannot be found, thereby effectively preventing the APK file from being reversely modified and leaking. It can be seen that the reinforcement mentioned in this application is utilized. After the method is hardened, the source code of the APK file is encrypted and hidden, which can avoid the decompilation of the existing Android reverse tool, thereby greatly improving the security of the APK file.

The invention is applicable to a wide variety of general purpose or special purpose computing system environments or configurations. For example: personal computers, servers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, digital TV receivers for Android, programmable consumer electronics, network PCs, small computers, Large computer, distributed computing environment including any of the above systems or devices, and the like.

The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection of the present invention. Within the scope.

Claims

A dynamic loading method for an anti-reverse APK file, comprising the steps of:

Load the first Classes.dex file, call the Entry.so file, and decrypt the Encrypt'.so file using the Entry.so file to get the decrypted Encrypt.so file.

The second Classes.dex file is decrypted by using the Entry.so file to obtain the original Classes.dex file in the APK file before the reinforcement processing;

Dynamically load the original Classes.dex file, and find the physical address of the source code that stores the APK file function, and dynamically load the source code into the memory;

Delete the decrypted original Classes.dex file from physical memory;

The first Classes.dex file only contains the file header structure of the original Classes.dex file, the second Classes.dex file and the Encrypt'.so file are stored under the file directory res, and the Entry.so file is stored in the file. Under the directory libs, the anti-reverse APK file is formed by the first Classes.dex file, the AndroidManifest'.xml file, the file directory res, the file directory libs, and the resources.ars file.
The method for dynamically loading an anti-reverse APK file according to claim 1, wherein the step of performing integrity checking on the original Classes.dex file before decrypting the second Classes.dex file is further included.
The method for dynamic loading of an anti-reverse APK file according to claim 2, wherein the integrity of the original Classes.dex file obtained by decryption is performed by using the field information contained in the header structure of the first Classes.dex file. .
The dynamic loading method of the anti-reverse APK file according to claim 1, wherein the dynamic loading of the original Classes.dex file comprises: creating a new DexClassLoader object with the source class Classes.dex, by reflecting The method is replaced with the attribute mClassLoader in the system's default load class.
A dynamic loading method for an anti-reverse APK file according to claim 1, characterized in that Therefore, according to the data_size field and the data_off field information in the file header structure of the original Classes.dex file, and find the physical address of the source code for storing the function of the APK file.
The method for dynamically loading an anti-reverse APK file according to claim 1, wherein the step of dynamically loading the source code into the memory comprises:

Using the custom onCreate method, find the physical address of the source code through the meta-data attribute in the application in the AndroidManifest, and replace it with the Application of the source program;

Remove the existing "first Application file" from the call collection, and create a new Application object app, bind the properties of the original Classes.dex file to the app, and then add the app to the memory call set;

Since the component Provider is registered by the system before the onCreate method, the app is bound to the context of the Provider in the source program, and then the system-level onCreate method is started.