CN107273723A - A kind of Android platform applied software protection method based on so file shell addings - Google Patents

Abstract

The present invention proposes a method for protecting application software on an Android platform based on so file packing. In the method, the decryption and dynamic loading operations of the dex file are all placed in the protected so file, and at first the protected so file is After the function is asymmetrically encrypted, the entire protected so file is asymmetrically encrypted, and the two keys are stored in the server, which combines server verification technology to ensure the security of the source code. Secondly, set the section-related fields in the so shell file to random numbers, which increases the difficulty of static decompilation. At the same time, set the relevant verification fields during the loading of the protected so file to 0, which increases the difficulty of memory dump attacks. Finally, the so shell file is used as a custom Linker to load the protected so file. After the loading is complete, all the Program Headers of itself and the protected so file are set to 0 to prevent memory dump attacks and attacks that modify the system Linker.

Description

A protection method for Android platform application software based on so file packing

technical field

The invention relates to the field of software information security research, in particular to an Android platform application software protection method based on so file packing.

Background technique

The Android system is a Linux-based, open source smartphone operating system launched by Google in November 2007. Since its launch, the system has swept the global mobile smart terminal market with its open source features, and has been supported by a large number of developers and many manufacturers. It has gradually become the most popular operating system for mobile terminals. Although the Android platform adopts a multi-level security protection mechanism, due to the defects of the Android platform itself, using the easy-to-decompile Java language, its software is still threatened from various aspects, and the most important threat is the reverse attack. That is to crack the key parts of the software through reverse engineering, so as to obtain software information or implement a series of malicious attacks. The general steps of reverse Android software are: first decompile it, then read the disassembled code, if necessary, dynamically debug it, inject or directly modify the disassembled code after finding a breakthrough, and finally recompile the software for testing .

The apk application in the Java layer is very easy to be reversed to obtain the Java source code, while the native program in the Native layer has higher security, and at the same time directly deals with the CPU, not only is it difficult to reverse, but also the performance of the program is improved. Since the so files in the Native layer are difficult to be statically decompiled, most of the attacks on so files are dynamic debugging and memory dump analysis, and even the automatic attack on so files can be realized by modifying the system linker to obtain decrypted data.

Contents of the invention

In order to solve the above-mentioned problems, the present invention proposes a method for protecting the Android platform application software based on so file packing, the method modifies the so file and encrypts the key functions of the protected so file, and simultaneously the so file is used as an automatic Define Linker to load protected so files, which can not only resist static decompilation of so shell files, but also increase the difficulty of dynamic analysis of protected so files, and combine remote server verification to ensure that the source code is not tampered with, thus achieving the protection of Android Purpose of the application.

A kind of Android platform application software protection method based on so file packing that the present invention uses mainly is divided into two processes of packing and unpacking, specifically comprises the following steps:

(1) Find the function in the protected so file and use the key to perform asymmetric encryption, and the key is placed on the server;

(2) After the protected so file is modified, use the key to asymmetrically encrypt the protected so file, and the key is stored in the server;

(3) Embedding the protected so file through the above encryption into the tail of the so shell file;

(4) Modify the so shell file;

(5) When the program is running, after the so shell file is loaded by the system Linker, the control is transferred to the so shell file;

(6) The server returns the key, and the so shell file decrypts the protected so file;

(7) The so shell file imitates the system Linker to load the protected so file, returns the key from the server to decrypt the function of the protected so file, after the loading is completed, modify the so shell file and the protected so file;

(8) The protected so file executes the function of decrypting and dynamically loading the dex file, and transfers control to the source program.

In step (1), the logic of dynamically loading and decrypting the dex file is first implemented in the protected so file, and the algorithm for encrypting its function is AES;

In step (2), the relevant check fields during the loading of the protected so file are set to 0 and then encrypted, and the encryption algorithm is AES;

In step (3), the so shell file realizes the logic of Linker operation and decryption so file;

In step (4), the main operation is to set random numbers to the fields related to section in the so shell file;

In step (5), when the program is running, it is guaranteed that the system Linker first loads the so shell file;

In step (6), the encrypted protected so file is stripped from the so shell file, and then decrypted and function decrypted;

In step (7), the so shell file is used as a custom Linker to skip the verification file operation when loading the decrypted protected so file, and at the same time, after the loading is completed, all the program headers of the so shell file and the protected so file are set to 0 ;

In step (8), after the protected so file is decrypted, the function pointers of openDexFile, getClassNameList and defineClass (defineClassNative) in the liddvm.so library are first obtained to realize the dynamic loading function.

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

Existing Android application program protection technology exists the problems such as so file is easily analyzed dynamically or encryption algorithm is too simple, and the present invention has following advantage:

1. The traditional encryption method is to embed the protected so file in the shell file, which is loaded and linked by the system Linker, and the attacker can even realize automatic unpacking through the modified system Linker. The so shell file imitates the system Linker to load the protected so file, which can effectively prevent the way of modifying the system Linker attack.

2. Since so files are difficult to be statically decompiled, the main attack method on so files is dynamic analysis, and the most common attack method is to dump so files in memory. In the method designed by the present invention, file structure modification is carried out to so shell file to prevent static decompilation, before and after so shell file loads protected so file, so shell file and so file are modified, thereby make attacker unable to pass keyword in Obtain the address of the so file in the memory and make the dynamic debugging tool unable to parse the so file.

3. AES encryption is performed on the key function of the protected so file and the entire protected so file. The two keys are placed in the server, and it is difficult for an attacker to obtain the key through the server, which ensures the security of the source code of the so file.

Description of drawings

Fig. 1 is a flow chart of packing the so file in the Android application program.

Fig. 2 is a flow chart of the function pointer for obtaining liddvm.so in the present invention.

Fig. 3 is a flow chart of unpacking the so file when the Android application program is running.

Fig. 4 is a schematic diagram of the process of loading the so file.

detailed description

The present invention will be further described in detail below in conjunction with the embodiments and the accompanying drawings, but the embodiments of the present invention are not limited thereto.

The invention provides an Android platform application software protection method based on so file packing, wherein the packing process is mainly carried out at the computer end, and Fig. 1 is a flow chart of packing, and the specific steps are as follows:

(1) Implement the functions in the protected so file first, mainly including three custom functions to realize dynamic loading and decrypt the dex file, among which the three custom functions to realize dynamic loading are mainly to obtain openDexFile in the corresponding liddvm.so library , getClassNameList and defineClass (defineClassNative) function pointers, Figure 2 is a flow chart for obtaining function pointers. After finding the four function names through the hash symbol table, use the AES algorithm to encrypt the function area, and put the AES key in the server.

(2) During the loading of the so file by the system Linker, the so file will be verified, and the so shell file will be used instead of the system Linker, and the so file will not be verified, but the loading work will be carried out directly. If an attacker uses the system Linker to load the hardened so file, it will inevitably fail to verify the ELF file, resulting in failure to load. At the same time, when the attacker dynamically analyzes the so file, he will search the relevant fields of the relevant so file in the memory to determine the location of the so file, thereby dumping the complete so file. After being encrypted by the function of (1). In this paper, e_ident[16] (file identification), e_type (file type), e_machine (architecture type), e_version (file version), e_flag (file related attributes) are all set to 0, and then the AES algorithm is used to encrypt the received data. Protect the binary stream of the so file, whose AES key is uploaded to the server.

(3) From the link and execution view of the so file, when the so file is loaded, the execution view is used, which has nothing to do with the link view, so the fields e_shoff, e_shentsize, e_shnum and e_shstrndx related to the section can be modified, and at the same time Since when the so file is loaded, the set jump address is the address of the dynamic linker, so e_entry can also be modified. In order to achieve the purpose of static decompilation of the so shell file, the fields e_entry, e_shoff, e_shentsize, e_shnum, and e_shstrndx in the so shell file are set to random numbers.

(4) Embedding the protected so file after (2) encryption into the tail of the so shell file, and encrypting the dex file simultaneously. This example encrypts the dex file with DES, and the encrypted ciphertext and key are embedded in the image of the resource file.

(5) Put the so shell file into the source program apk, sign and pack it, and obtain the program after reinforcement.

The unpacking process is mainly carried out on the Android mobile phone. Figure 3 is the flowchart of running the Android program after hardening. The specific steps are as follows:

(1) Steps 1, 2, 3, and 4 as shown in Figure 4 are the loading and linking process of the so file by the system Linker. In order for the system Linker to load the so shell file first, the so shell file needs to be placed in the initialization of the system Linker stage, that is, the functions specified by .init and .init_array in JNI_OnLoad or the so shell file. In order to reduce tedious operations, the loading process of the protected so file from the so shell file is placed in JNI_OnLoad. After the so shell file is loaded by the system Linker, control is given to the so shell file.

(2) As shown in steps 5 and 6 of Figure 4, after the so shell file obtains the control of the system Linker, it first decrypts the encrypted protected so file from the server with the key returned by AES, and then continues to run and use it as an interpreter The key returned by the server is used to decrypt the function AES in the protected so file. The loading link of the so shell file to the protected so file can be implemented completely according to the system Linker, so the source code is similar to the system Linker. The difference is: (1) In the loading and linking phase, the decrypted so file is in the memory, and the file operation needs to be changed into a memory operation. (2) In order to prevent attackers from using various mapping information of soinfo to analyze protected so files in memory, the export table of the protected so file and the export table of the so shell file are merged, and then the protected so file Soinfo is deleted, and the merged soinfo will not be added to the global linked list. When soinfo is needed, the system Linker will directly allocate soinfo. (3) The application program will perform symbol search on the so file, but the protected so file is attached to the so shell file, so the application program cannot access the dynamic symbol table of the protected so file. In order to solve this problem, the dynamic symbol table of the protected so file must be exported to the dynamic symbol table of the so shell file. The symbol lookup process in the dynamic symbol table of the so file involves the symbol hash table, symbol table and string table. A structure, as shown in step 7 of Figure 4, the string table and the symbol table of the protected so file are added to the string table and the symbol table of the so shell file, and the hash table is reconstructed according to the new symbol table, and finally the Put the reconstructed hash table into the so shell file.

(3) Program Header describes the so file structure information related to program execution. According to this information, the size offset of each segment, the virtual address where it is located, etc. can be determined. When loading the so file, the functions ReadProgramHeader, ReserveAddressSpace, and LoadSegments in the load_library function will read the segment whose ProgramHeader loading type is PT_LOAD, and then store the loading result of the Program Header in soinfo, that is, si->phdr=elf_reader. loaded_phdr(), so that the attacker can extract the Program Header by finding the soinfo to analyze and extract the so file. In order to avoid this attack, the so shell file finds the Program Header address of itself and the protected so file through its own information after the protected so file is loaded, and sets all Program Headers to 0.

(4) There are some security issues in using the dynamic loading method of DexClassLoader in the Java layer. Not only will the odex file be generated in the storage space of the mobile phone in the form of a file, but the decrypted dex file will also be stored in the storage space in the form of a file in plain text, so The present invention uses the functions of the liddvm.so library for dynamic loading. The decrypted protected so file finds the encrypted dex file and key from the resource file, uses the key to decrypt the dex file with DES, and then uses the corresponding openDexFile, getClassNameList and defineClass (defineClassNative) in the liddvm.so library to customize The function dynamically loads the dex file and hands over control to the source program.

Claims (7)

1. a kind of Android platform applied software protection method based on so file shell addings, it is characterised in that methods described includes Following steps：

A, ciphering process

(1) to protected so files dynamic load dex files；

(2) asymmetric encryption is carried out to protected so files and its function, and key is uploaded onto the server；

(3) protected so files and so shelf documents are modified；

(4) after protected so file encryptions, its ciphertext is embedded into so shelf document afterbodys, then using so shelf documents as self-defined Linker alternative systems Linker is loaded to protected so files；

B, decrypting process

(5) when program is run, so shelf documents use the key returned from server to be decrypted protected so files first, connect The key for running as Linker and using server to return the function in protected so files to be decrypted, loading is completed Afterwards, itself and protected so files are modified；

(6) in its dex file of Native layers of dynamic load after dex files are decrypted protected so files.

2. the method as described in claim 1, it is characterised in that in step (2), first to during loading protected so files Related check field is encrypted again after being set to 0, is aes algorithm to the algorithm that it is encrypted.

3. method as claimed in claim 2, it is characterised in that also include part field in so shelf documents in step (4) The step of being set to random number.

4. method as claimed in claim 3, it is characterised in that in step (5), program runtime system Linker is first loaded So shelf documents.

5. method as claimed in claim 4, it is characterised in that being protected for encryption is separated by so shelf documents in step (6) So files are protected, then it are decrypted and function decryption.

6. method as claimed in claim 5, it is characterised in that in step (7), regard so shelf documents as self-defined Linker Checking file operation is skipped when loading protected so files after decryption, while to so shelf documents and protected so after the completion of loading The modification content of file is that Program header therein are all set to 0.

7. the method as described in claim 1, it is characterised in that in step (3), the modification content to protected so files is Relevant field is examined all to be set to 0 e_ident, e_type, e_machine, e_version, e_flag in file, to so The modification content of shelf document is e_entry, e_shoff, e_shentsize, e_shnum and e_ in so shelf documents Shstrndx these be set to random number with section relevant fields.