Method, device, storage medium and apparatus for loading hardened elf file

Abstract

The application relates to the technical field of loading of reinforced ELF files, and discloses a loading method, a device, a storage medium and an apparatus for the reinforced ELF files. According to the application, a preset initialization function is called according to dynamic link library interface information in a reinforced ELF file; a decryption function and relocation information are obtained according to the preset initialization function; and the reinforced ELF file is decrypted and relocated according to the decryption function and the relocation information, so that the loading of the file is realized. Therefore, the dynamic link library interface information is arranged on the reinforced ELF file, the preset initialization function is called through the dynamic link library interface information, the decryption function and the relocation information are obtained, the loading of the reinforced ELF file is realized, the JNI_OnLoad function on the android platform is avoided, the loading of the reinforced ELF file of all platforms can be realized, and the compatibility of the reinforced ELF during loading is improved.

Description

Technical Field

[0001] This invention relates to the field of loading hardened ELF files, and more particularly to loading methods, devices, storage media, and apparatuses for hardened ELF files. Background Technology

[0002] Existing SO hardening technologies are Android-customized SO hardening techniques. The SO content is placed as data within the shell code, which is then compiled into a separate SO file and the SO data is released to memory. Due to Android's SO loading mechanism, if the SO is called through the Java layer, the JNI_OnLoad function will definitely be called, and this function is only called once. Therefore, the logic for decrypting and restoring the SO can be implemented in JNI_OnLoad.

[0003] Android-customized SO hardening offers high security, but its applicability and compatibility are low. The decryption processing in JNI_OnLoad restricts the SO to be called only in the Java layer and does not support C interfaces. In addition, because all the contents of the SO are hidden, the exported functions are not restored before the loading is complete, so the hardened SO cannot be used as a dependency of other SOs. Summary of the Invention

[0004] The main objective of this invention is to provide a method, device, storage medium, and apparatus for loading hardened ELF files, aiming to solve the problem of how to improve the compatibility of loading hardened ELF files.

[0005] To achieve the above objectives, the present invention provides a method for loading a hardened ELF file, the method comprising the following steps:

[0006] When a loading request for a hardened ELF file is received, a preset initialization function is called based on the dynamic link library interface information in the hardened ELF file.

[0007] The decryption function and relocation information are obtained based on the preset initialization function;

[0008] The hardened ELF file is decrypted using the decryption function to obtain the decrypted ELF file;

[0009] The decrypted ELF file is relocated according to the relocation information in order to load the file.

[0010] Optionally, when a loading request for a hardened ELF file is obtained, calling a preset initialization function based on the dynamic link library interface information in the hardened ELF file includes:

[0011] When a loading request for a hardened ELF file is received, the file type of the hardened ELF file is determined;

[0012] When the file type of the hardened ELF file is an executable file, the start function is used as the preset initialization function, and the start function is called according to the dynamic link library interface information in the hardened ELF file;

[0013] When the file type of the hardened ELF file is a dynamic link library file, the init function is used as the preset initialization function, and the init function is called according to the dynamic link library interface information in the hardened ELF file.

[0014] Optionally, before obtaining the decryption function based on the preset initialization function, the method further includes:

[0015] Obtain the function address of the preset initialization function;

[0016] Adjust the function address to the jump address of the decryption function;

[0017] The step of obtaining the decryption function based on the preset initialization function includes:

[0018] The decryption function is obtained based on the jump address of the preset initialization function.

[0019] Optionally, the hardened ELF file includes executable code functions;

[0020] Before calling the preset initialization function based on the dynamic link library interface information in the hardened ELF file, the method further includes:

[0021] The dynamic link library interface information of the hardened ELF file is set to the executable code function, and the executable code function is set to the fill function;

[0022] Set the fill function to the preset initialization function.

[0023] Optionally, the hardened ELF file includes exported symbol information;

[0024] Before obtaining relocation information according to the preset initialization function, the method further includes:

[0025] Set the exported symbol information of the hardened ELF file to a preset initialization function;

[0026] The preset initialization function obtains relocation information, including:

[0027] The exported symbol information of the hardened ELF file is obtained according to the preset initialization function;

[0028] The derived symbol information is parsed to obtain relocation information.

[0029] Optionally, before calling the preset initialization function based on the dynamic link library interface information in the hardened ELF file when a loading request for the hardened ELF file is obtained, the method further includes:

[0030] Obtain the ELF file to be hardened;

[0031] Determine the preset reserved data and corresponding reserved area information in the ELF file to be reinforced; write the preset reserved data and corresponding reserved area information into the shell code to generate the shell file;

[0032] Obtain the decryption function and relocation information in the ELF file to be hardened, point the decryption function and relocation information to a preset initialization function, and obtain the dynamic link library interface information according to the preset initialization function;

[0033] The data and code portions of the ELF file to be hardened are encrypted using a decryption function to obtain encrypted data.

[0034] A hardened ELF file is generated based on the shell file, dynamic link library interface information, and encrypted data.

[0035] Optionally, before encrypting the data and code portions of the ELF file to be hardened according to the decryption function to obtain the encrypted data, the method further includes:

[0036] The original data in the ELF file to be hardened is analyzed based on the dynamic link library interface information to determine whether the original data in the ELF file to be hardened contains data associated with the dynamic link library interface information.

[0037] When the original data in the ELF file to be hardened does not contain data associated with the dynamic link library interface information, the data that does not contain data associated with the dynamic link library interface information is taken as the data part.

[0038] Furthermore, to achieve the above objectives, the present invention also proposes a loading device for hardened ELF files, the loading device for hardened ELF files comprising:

[0039] The calling module is used to call a preset initialization function based on the dynamic link library interface information in the hardened ELF file when a loading request for the hardened ELF file is obtained;

[0040] The determination module is used to obtain the decryption function and relocation information based on the preset initialization function;

[0041] The decryption module is used to decrypt the hardened ELF file according to the decryption function to obtain the decrypted ELF file;

[0042] The relocation module is used to relocate the decrypted ELF file according to the relocation information in order to load the file.

[0043] Furthermore, to achieve the above objectives, the present invention also proposes a loading device for hardened ELF files, the loading device for hardened ELF files comprising: a memory, a processor, and a loading program for hardened ELF files stored on the memory and running on the processor, wherein when the loading program for hardened ELF files is executed by the processor, it implements the steps of the loading method for hardened ELF files as described above.

[0044] In addition, to achieve the above objectives, the present invention also proposes a storage medium storing a loading program for hardened ELF files, wherein when the loading program for hardened ELF files is executed by a processor, it implements the steps of the loading method for hardened ELF files as described above.

[0045] The technical solution provided by this invention, upon receiving a loading request for a hardened ELF file, calls a preset initialization function based on the dynamic link library interface information in the hardened ELF file; obtains a decryption function and relocation information based on the preset initialization function; decrypts the hardened ELF file using the decryption function to obtain a decrypted ELF file; and relocates the decrypted ELF file based on the relocation information to achieve file loading. This solution utilizes dynamic link library interface information on the hardened ELF file, calls the preset initialization function through the dynamic link library interface information to obtain the decryption function and relocation information, and achieves loading of the hardened ELF file. This avoids calling the JNI_OnLoad function on the Android platform, enabling loading of hardened ELF files on all platforms and improving the compatibility of loading hardened ELF files. Attached Figure Description

[0046] Figure 1 This is a schematic diagram of the structure of the loading device for the hardened ELF file of the hardware operating environment involved in the embodiments of the present invention;

[0047] Figure 2 This is a flowchart illustrating the first embodiment of the method for loading ELF files to strengthen according to the present invention;

[0048] Figure 3 This invention provides an embodiment of the method for strengthening the loading of ELF files, which includes an ELF file format.

[0049] Figure 4 This is a schematic diagram of the ELF file loading process according to an embodiment of the ELF file loading method of the present invention;

[0050] Figure 5 This is a flowchart illustrating the second embodiment of the method for loading ELF files to strengthen according to the present invention;

[0051] Figure 6 This is a schematic diagram of the execution restoration process of an embodiment of the method for loading ELF files to strengthen according to the present invention;

[0052] Figure 7 This is a flowchart illustrating the third embodiment of the method for loading ELF files to strengthen according to the present invention;

[0053] Figure 8 This is a schematic diagram of the hardening process of an embodiment of the loading method for hardening ELF files according to the present invention;

[0054] Figure 9 This is a structural block diagram of the first embodiment of the loading device for strengthening ELF files according to the present invention.

[0055] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0056] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0057] The main technical terms involved in the embodiments of this application include:

[0058] Shellcode is a piece of code executed to exploit software vulnerabilities. It is hexadecimal machine code and gets its name from the fact that it often allows attackers to gain a shell (or "shell") in the process. Shellcode is often written in machine language. It can be inserted into a register after a buffer overflow, allowing the CPU to execute arbitrary commands from the attacker.

[0059] ELF is a file format consisting of four parts: the ELF header, the program header table, sections, and the section header table. In reality, a file may not contain all the content, and their positions may not be arranged as shown. Only the position of the ELF header is fixed; the position, size, and other information of the other parts are determined by the values ​​in the ELF header.

[0060] The .so file format, or Executable and Linkable Format (ELF) file format, is a unified format for executable files, shared library files, and object files under Linux.

[0061] Linker loads dynamic link libraries and executable files into memory.

[0062] SO hardening refers to encrypting specified sections in an SO file to strengthen the SO file and thus ensure its security.

[0063] Redirection refers to the process of transforming a program's logical address space into its actual physical address space in memory.

[0064] Reference Figure 1 , Figure 1 This is a schematic diagram of the device structure for loading ELF files to harden the hardware operating environment involved in the embodiments of the present invention.

[0065] like Figure 1 As shown, the loading device for the hardened ELF file may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen, and optionally, the user interface 1003 may also include a standard wired interface and a wireless interface. In this invention, the wired interface of the user interface 1003 may be a Universal Serial Bus (USB) interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed random access memory (RAM); it may also be stable memory, such as non-volatile memory, specifically a disk storage device. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0066] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the loading device for hardened ELF files and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0067] like Figure 1 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a loader for hardened ELF files.

[0068] exist Figure 1In the hardened ELF file loading device shown, the network interface 1004 is mainly used to connect to the backend server and communicate with the backend server; the user interface 1003 is mainly used to connect to peripherals; the hardened ELF file loading device calls the hardened ELF file loading program stored in the memory 1005 through the processor 1001 and executes the hardened ELF file loading method provided in this embodiment of the invention.

[0069] Based on the above hardware structure, an embodiment of the loading method for strengthening ELF files according to the present invention is proposed.

[0070] Reference Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the loading method for strengthening ELF files according to the present invention.

[0071] In the first embodiment, the method for loading the hardened ELF file includes the following steps:

[0072] Step S10: When a loading request for the hardened ELF file is obtained, a preset initialization function is called according to the dynamic link library interface information in the hardened ELF file.

[0073] It should be noted that the execution subject in this embodiment is the loading device for hardening ELF files, but it can also be other devices that can achieve the same or similar functions. This embodiment does not limit this. In this embodiment, the loading device for hardening ELF files is used as an example for explanation.

[0074] In this embodiment, it is mainly applied to loading hardened ELF files. Hardening an ELF file involves encrypting the ELF file to obtain a more secure hardened ELF file, such as... Figure 3The ELF file format shown includes a linker view and an execution view. The ELF Header contains Section and Program Headers, both of which record the types and information of various fields within the file. The linker view observes the ELF structure from the perspective of sections. During execution, it does not depend on the data structure of sections. However, the default compiled ELF file has finely divided sections. Under Linux, you can view the information of each section using `readELF -S filename`. The table below lists some key section information. Table 1 below shows the structure description of the ELF file linker view. For example, `text` represents the executable code, `dynamic` represents a dynamic table used to find fields needed by the linker during execution, and `got` and `got.plt` represent relocation addresses, with the specific address and relocation method marked in `.rel.dyn` and `.rel.plt`. The execution view is the structure used during runtime and analyzes the ELF structure from the perspective of the loaded segment. Table 2 below shows the structure description of the ELF file execution view. For example, `PT_LOAD` represents the address mapping relationship loaded into memory and permissions, etc.

[0075]

[0076] Table 1

[0077]

[0078]

[0079] Table 2

[0080] It is understood that the ELF file in this embodiment may include .so files and executable files, and may also be files of other formats. This embodiment does not limit this. In this embodiment, .so files and executable files are used as examples for explanation. The loading process of .so and executable files is almost the same. The following uses the loading process of .so as an example to introduce how ELF is loaded into memory. Figure 4 The diagram below shows the ELF file loading process, and Table 3 shows the function call descriptions. Calling `do_dlopen` loads the dynamic link library; calling `find_library` checks if the dynamic link library is already loaded in memory; if not, subsequent functions are executed; calling `load_library` loads the dynamic link library; calling `loadSegment` loads the file region specified by `PT_LOAD` into memory; calling `prelink` reads the dynamic node; calling `linkImage` performs relocation; and calling `callConstructors` starts calling the `init` function in the `.so` file. Table 3 shows:

[0081]

[0082] The specific loading process is as follows: During loading, relocation is performed to ensure that all function calls and variable accesses can be executed correctly. Since the relative positions of code and data in the compiled .so and executable files are related, the principle of restoring the .so after hardening is that the relative offsets of code and data cannot be modified. Furthermore, since memory alignment differs across systems, the restored memory location is generally the same as the normally loaded location. Therefore, the safest approach is not to modify the starting position and length of each PT_LOAD. If necessary, the only thing that can be modified is the length of the last PT_LOAD.

[0083] Therefore, during the hardening process, preset field information in the ELF file to be hardened can also be obtained. The preset field information is PT_LOAD. Hardening is performed according to the starting position and length in the preset field information to obtain the hardened ELF file, thereby ensuring that the data information in PT_LOAD is not modified and that the position in memory and the loading position are aligned during loading, thus achieving loading accuracy.

[0084] When the system linker loads, it reads and saves some field contents from the dynamic field into memory. To ensure compatibility with this data, the dynamic field must retain some data, and the dynamic field location cannot be modified. Otherwise, if data overwrites the dynamic field during restoration, it may cause unpredictable errors.

[0085] In this embodiment, during the hardening process, field information in the dynamic table can also be obtained, the field information in the dynamic table can be hardened, and some data of the field information in the dynamic table can be retained, thereby ensuring that the hardened ELF file is consistent with the restored ELF file when loaded.

[0086] It is understood that the loading request for the hardened ELF file can be generated when the user performs ELF file operations, or it can be generated through other means. This embodiment does not impose any restrictions on this. The dynamic link library interface information can be the dynamic link library libdepend.so, or it can be in other forms. This embodiment does not impose any restrictions on this. When the hardened ELF file is an executable file, the default initialization function is the start function; when the hardened ELF file is a dynamic link library file, the default initialization function is the init function.

[0087] Step S20: Obtain the decryption function and relocation information according to the preset initialization function.

[0088] It should be noted that the preset initialization function has calling logic for the decryption function and relocation information. The decryption function is a function that restores the hardened ELF file, and the relocation information is a mapping relationship that transforms the logical address space of the restored ELF file into the actual physical address in memory.

[0089] Since the decryption function contains relocation logic, writing it to a file in the form of shellcode is quite difficult. If the shellcode is too long, it may affect the ptload size and cause compatibility issues on some platforms. It is advisable to compile the logic into a separate dynamic link library libdepend.so and call the decryption function in libdepend.so to restore the .so file.

[0090] In this embodiment, the shellcode is established to call the start function or the init function, and the decryption function and relocation information are obtained through the start function or the init function.

[0091] Step S30: Decrypt the hardened ELF file according to the decryption function to obtain the decrypted ELF file.

[0092] In the specific implementation, since the hardened ELF file is an encrypted ELF file, when loading the hardened ELF file, it is necessary to decrypt the hardened ELF file through a decryption function to obtain the decrypted ELF file, that is, to realize the restoration of the hardened ELF file, thereby ensuring that the hardened ELF file can be loaded normally.

[0093] Step S40: Relocate the decrypted ELF file according to the relocation information to load the file.

[0094] It is understandable that if the .so is loaded directly, and the relocation information is found in other .so, then all the content of the original .so can be encrypted. It is only necessary to implement relocation and overwrite the memory of the .so in init.

[0095] If a .so file is loaded as a dependency by other .so files, the loading process will not perform decryption during relocation. Therefore, the hardened .so file needs to retain all relevant information about exported symbols. As for imported symbols, you can implement your own relocation method to perform relocation and restoration.

[0096] This embodiment, through the above-described scheme, calls a preset initialization function based on the dynamic link library interface information in the hardened ELF file when a loading request for the hardened ELF file is received; obtains a decryption function and relocation information based on the preset initialization function; decrypts the hardened ELF file using the decryption function to obtain a decrypted ELF file; and relocates the decrypted ELF file based on the relocation information to achieve file loading. Thus, by providing dynamic link library interface information on the hardened ELF file and calling the preset initialization function through the dynamic link library interface information to obtain the decryption function and relocation information, the hardened ELF file can be loaded. This avoids calling the JNI_OnLoad function on the Android platform, enabling the loading of hardened ELF files on all platforms and improving the compatibility of loading hardened ELF files.

[0097] Reference Figure 5 , Figure 5 This is a flowchart illustrating the second embodiment of the method for loading ELF files to strengthen according to the present invention. Based on the above... Figure 2 The first embodiment shown presents a second embodiment of the loading method for strengthening ELF files according to the present invention.

[0098] In the second embodiment, step S10 includes:

[0099] Step S101: When a loading request for a hardened ELF file is received, the file type of the hardened ELF file is determined.

[0100] In this embodiment, in order to improve the compatibility of hardened ELF files and enable loading processing for various hardened ELF files, different preset initialization functions are used for loading processing for different hardened ELF files.

[0101] In the specific implementation, the file type of the hardened ELF file is determined. The file type can be an executable file, a dynamic link library file, or other forms of hardened ELF files. This embodiment does not limit this. In this embodiment, an executable file or a dynamic link library file is used as an example for explanation.

[0102] Step S102: When the file type of the hardened ELF file is an executable file, the start function is used as a preset initialization function, and the start function is called according to the dynamic link library interface information in the hardened ELF file.

[0103] In this embodiment, the start function is the execution function of the executable file, which means it is a preset initialization function. Since the executable file needs to call the start function to start execution when it is being recorded, the call to the start function is realized through the dynamic link library interface information.

[0104] Step S103: When the file type of the hardened ELF file is a dynamic link library file, the init function is used as the preset initialization function, and the init function is called according to the dynamic link library interface information in the hardened ELF file.

[0105] In this embodiment, the init function is the execution function of the dynamic link library file, which means it is a preset initialization function. Since the dynamic link library file needs to call the init function to start execution when it is being recorded, the init function is called through the dynamic link library interface information.

[0106] In one embodiment, prior to step S20, the method further includes:

[0107] Obtain the function address of the preset initialization function; adjust the function address to the jump address of the decryption function; obtaining the decryption function based on the preset initialization function includes: obtaining the decryption function based on the jump address of the preset initialization function.

[0108] In this embodiment, the executable file and dynamic link library have a fixed execution flow during loading. The executable file starts execution from start by default, while the dynamic link library executes the init function by default. Since the addresses of these two functions are specified as the jump addresses of the decryption function during hardening, the decryption function will definitely be executed after the ELF is loaded, thereby realizing the acquisition of the decryption function.

[0109] In one embodiment, the hardened ELF file includes executable code functions; prior to step S10, the method further includes:

[0110] The dynamic link library interface information of the hardened ELF file is set to the executable code function, the executable code function is set to the fill function, and the fill function is set to the preset initialization function.

[0111] It should be noted that the execution code function can be a GOT function. Since the hardened ELF file contains a GOT function, the GOT function is pointed to the padding function, and the padding function is pointed to the preset initialization function, thereby obtaining the preset initialization function through the padding function. The padding function can be a shellcode function, or other forms of padding function. This embodiment does not limit this. In this embodiment, the shellcode function is used as an example for explanation.

[0112] In the specific implementation, the execution code function is pointed to the padding function, and the padding function is used to bridge the execution code function and the preset initialization function. In this way, the preset initialization function can be obtained through the dynamic link library interface information, and the logic of obtaining the decryption function and relocation can be realized. This avoids directly obtaining the decryption function and relocation information when restoring the hardened ELF file, which would be detrimental to data security.

[0113] In one embodiment, the hardened ELF file includes exported symbol information;

[0114] Before step S10, the method further includes:

[0115] The exported symbol information of the hardened ELF file is directed to a preset initialization function.

[0116] In this embodiment, the exported symbol information is generated based on the symbol table, string table, relocation table information, and dynamic node information. It can also be generated based on other parameters. This embodiment does not limit this. In this embodiment, the symbol table, string table, relocation table information, and dynamic node information are used as examples for explanation.

[0117] The preset initialization function obtains relocation information, including: obtaining the exported symbol information of the hardened ELF file according to the preset initialization function; and parsing the exported symbol information to obtain relocation information.

[0118] In the specific implementation, the redirection logic can be obtained based on the exported symbol information. Specifically, the corresponding redirection logic is searched in a preset logic mapping table based on the exported symbol information. That is, the exported symbol information is parsed to obtain relocation information. For example, the logic of the decryption function is as follows: the .so or executable file loads normally and executes shellcode. The shellcode jumps to the decryption function start_xx, obtains the decryption parameters, merges the encrypted data, and performs decryption. Based on the restoration information, the data in the original .so is restored, and the restored data is relocated. If it is an .so file, it returns directly to the end. If it is an executable file, it jumps to the address indicated by start and executes start normally. Figure 6 The diagram shows the execution restoration process.

[0119] This embodiment, through the above-described scheme, requires implementing a linker process to harden more ELF file information. The relocation information in the original ELF file is hidden through dynamic link library interface information, and a custom relocation is performed after loading via the init call. By collecting the symbol table, string table, relocation table information, and dynamic nodes in the ELF file and reorganizing them into a recognizable structure, the relocation results are parsed in memory and restored to memory, but the symbol table, string table, relocation table information, and dynamic node information are not restored. Thus, even if loaded into memory, the analyst cannot directly know the names of these relocated functions and variables, increasing the difficulty of analysis.

[0120] Reference Figure 7 , Figure 7 This is a flowchart illustrating a third embodiment of the loading method for hardening ELF files according to the present invention. The third embodiment of the loading method for hardening ELF files according to the present invention is proposed based on the first embodiment or the second embodiment. In this embodiment, the description is based on the first embodiment.

[0121] In the third embodiment, before step S10, the method further includes:

[0122] Step S104: Obtain the ELF file to be reinforced.

[0123] It should be noted that the ELF file to be hardened is an ELF file, that is, the ELF file that needs to be hardened, such as... Figure 8 The diagram shows the reinforcement process.

[0124] Step S105: Determine the preset reserved data and corresponding reserved area information in the ELF file to be reinforced.

[0125] In this embodiment, the preset reserved data includes ELF header, phdr, symtab, strtab, hash table, and dynamic field data, and may also include other data. This embodiment does not limit this. Specifically, necessary data is used as preset reserved data, and other data is encrypted to ensure that as much data as possible is encrypted, thereby improving the security of data reinforcement.

[0126] Step S106: Write the preset reserved data and the corresponding reserved area information into the shell code to generate a shell file.

[0127] It should be noted that the content of the .so file is placed as data into the shell code. The shell is compiled into a separate .so file and the data of the .so file is released into memory, thereby enabling the loading of the .so file.

[0128] In its implementation, the hardening process follows three basic principles: the file must be able to load normally into memory before and after hardening, and it must be compatible with the system linker, which requires preserving exported symbols. The decryption and relocation functions reside in a dependent .so file (libdepend.so), and decryption and relocation are not performed directly on the shell. Ultimately, the shell only sees exported symbols and the logic for jumping to the decryption code; other data is invisible, thus ensuring the security of the hardened ELF file during the loading process.

[0129] Step S107: Obtain the decryption function and relocation information in the ELF file to be hardened, point the decryption function and relocation information to a preset initialization function, and obtain the dynamic link library interface information according to the preset initialization function.

[0130] The specific hardening process is as follows: Read the ELF file, obtain the reserved data and the area where the reserved data is located, write it into the shell, add the dependency on libdepend.so in the dynamic field according to the ELF format, add the decryption function (assuming the function name is start_xx) information to the symbol table, string table and GOT table, and write the corresponding shellcode according to the platform type of ELF. If it is a .so file, add init pointing to the shellcode address in dynamic. If it is an executable file, write the shellcode address into the entry field of the ELF header.

[0131] Step S108: Encrypt the data and code portions of the ELF file to be hardened using the decryption function to obtain encrypted data.

[0132] The encrypted data is merged and encrypted again. Based on the reserved area, the fillable area is calculated and the encrypted data is filled into the fillable file area to minimize the file size. After adding the necessary section information, the hardening is completed.

[0133] Step S109: Generate a hardened ELF file based on the shell file, dynamic link library interface information, and encrypted data.

[0134] In this embodiment, the hardened file effectively hides imported functions. Even if the memory is dumped, it's impossible to directly determine which other functions or variables in the shared objects (SOs) the function calls. Finally, the implementation of libdpend.so can also quickly implement other additional functionalities, thereby improving the flexibility of the hardening process.

[0135] In one embodiment, before encrypting the data portion and code portion of the ELF file to be hardened according to the decryption function to obtain encrypted data, the method further includes: analyzing the original data in the ELF file to be hardened according to the dynamic link library interface information to determine whether the original data in the ELF file to be hardened contains data associated with the dynamic link library interface information; when the original data in the ELF file to be hardened does not contain data associated with the dynamic link library interface information, the data that does not contain data associated with the dynamic link library interface information is taken as the data portion.

[0136] In this embodiment, in order to ensure the smooth progress of the loading process while encrypting as much data as possible during the encryption process, it is necessary to leave the data associated with the dynamic link library interface information unencrypted. This ensures that all independent data is encrypted, thereby hiding as much data in the ELF file as possible while meeting compatibility requirements and preventing the original ELF file from being backed up during runtime.

[0137] In one embodiment, before generating the hardened ELF file based on the shell file, dynamic link library interface information, and encrypted data, the method further includes: obtaining a fillable area based on the reserved area information; filling the fillable area with the encrypted data to obtain fill data; the step of generating the hardened ELF file based on the shell file, dynamic link library interface information, and encrypted data includes: generating the hardened ELF file based on the shell file, dynamic link library interface information, and fill data.

[0138] It should be noted that when hardening an ELF file, in order to store the encrypted data, it is necessary to set a reserved area information. The reserved area information can be used to obtain the fill area, and then the encrypted data is filled into the fillable area to obtain the fill data. This ensures that the fill area can be filled with encrypted data, and avoids data overflow due to insufficient fill area to fill the encrypted data, thereby improving the accuracy of ELF file hardening.

[0139] In one embodiment, the relocation information includes loading mode information, and step S40 includes:

[0140] The target loading mode is determined based on the loading mode information; the relocation timing or the search range of the relocation symbol is obtained based on the target loading mode; the decrypted ELF file is relocated based on the relocation timing or the search range of the relocation symbol.

[0141] It should be noted that the target loading mode includes RTLD_NOW mode, RTLD_LAZY mode, RTLD_LOCAL mode, and RTLD_GLOBAL mode, and may also include other loading modes. This embodiment does not limit this. Among them, RTLD_NOW mode indicates that it affects the relocation timing. After dlopen, all relocations must be performed. RTLD_LAZY mode indicates that it affects the relocation timing. After dlopen, the data in the plt_got table is not relocated, but relocation is performed during execution. RTLD_LOCAL mode indicates that it affects the search range of relocation symbols. It only searches in the current .so and dependent .so. RTLD_GLOBAL mode indicates that it affects the search range of relocation symbols. It searches in the current .so, dependent .so, and .so loaded by RTLD_GLOBAL mode, as shown in the loading mode description table in Table 4.

[0142]

[0143]

[0144] Table 4

[0145] Understandably, dynamic link libraries (DLLs) are of type DYN. ELF executables exist in two formats. By default, the type obtained by direct compilation is EXEC. If the parameter -pie--fPIE is added during compilation, an executable of type DYN will be generated. The location of an EXEC file in memory is fixed. Because the address is fixed, the address of some instructions is also fixed. These instructions are called position-dependent code. During loading, except for some referenced function variables, almost no relocation is needed. DYN, on the other hand, is loaded into random memory. The addresses in the instructions are all relative addresses or indirect addresses. If necessary, some address relocation may occur. This type of code is called position-independent code.

[0146] For executable files, regardless of the file format, the program can run normally as long as the data in memory is relocated according to the relocation rules. However, for dynamic link libraries, it is necessary to distinguish some loading rules. There are four loading modes for dynamic link libraries, two of which affect the timing of relocation and two of which affect the symbol lookup range. Therefore, different relocation methods can be implemented by identifying the loading modes.

[0147] In this embodiment, the improved ELF file hardening scheme is well-compatible with hardening both .so and executable files. Executable files can be hardened normally for both EXEC and DYN types. .so files can be loaded normally and can be loaded as DT_NEEDED. Furthermore, the improved scheme supports RTLD_LAZY and RTLD_GLOBAL modes.

[0148] In one embodiment, the method for determining the target loading mode based on the loading mode information further includes:

[0149] Determine whether the loading mode information contains a preset field; if the dynamic table in the hardened ELF file contains a preset field, determine the target loading mode based on the preset field.

[0150] In this embodiment, the preset field can be the DT_PLTGOT field, or other fields; this embodiment does not impose any restrictions on this.

[0151] In the specific implementation, if the loading of a .so file under Linux supports the RTLD_LAZY mode, the DYNAMIC segment will contain a DT_PLTGOT field. The first three values ​​of this field store three addresses: the second address is the return value handle of dlopen, and the third address is the address of the lazy-loaded function. This address will be filled in during relocation in RTLD_LAZY mode, and will default to 0 in RTLD_NOW mode. Since this address is related to the implementation of libdl.so, custom-implemented linkers cannot obtain and use this address. It is necessary to reimplement the loading method and fill it in to achieve compatibility with different loading modes.

[0152] In one embodiment, after relocating the decrypted ELF file according to the relocation information, the method further includes:

[0153] If the decrypted ELF file is an executable file, then jump to the startup function and execute the executable file through the startup function; if the file type of the decrypted ELF file is a dynamic link library file, then return to the termination function and terminate the dynamic link library file through the termination function.

[0154] In this embodiment, the startup function can be the start function or other functions, and this embodiment does not impose any restrictions on this. The ending function can be the end function or other functions, and this embodiment does not impose any restrictions on this. After loading is complete, if it is an .so file, it returns to the end directly. If it is an executable file, it jumps to the address indicated by start and executes start normally.

[0155] This embodiment uses the above-described scheme to identify the loading mode by recognizing preset fields, thereby enabling redirection under different loading modes and improving compatibility with different loading modes.

[0156] Furthermore, this embodiment of the invention also proposes a storage medium storing a loading program for a hardened ELF file. When the loading program for the hardened ELF file is executed by a processor, it implements the steps of the terminal network access method described above.

[0157] Since this storage medium adopts all the technical solutions of all the above embodiments, it has at least all the beneficial effects brought about by the technical solutions of the above embodiments, which will not be repeated here.

[0158] In addition, refer to Figure 9 The present invention also proposes a loading device for hardened ELF files, the loading device for hardened ELF files comprising:

[0159] Module 10 is used to call a preset initialization function based on the dynamic link library interface information in the hardened ELF file when a loading request for the hardened ELF file is obtained.

[0160] In this embodiment, it is mainly applied to loading hardened ELF files. Hardening an ELF file involves encrypting the ELF file to obtain a more secure hardened ELF file, such as... Figure 3 The ELF file format shown includes a linked view and an execution view. The ELF Header contains Section and Program Headers, both of which record the types and information of various fields within the file. The linked view observes the ELF structure from the perspective of sections; the execution process does not depend on the data structure of the sections. However, the default compiled ELF file has a finer division of sections. Under Linux, you can view the information of each section using `readELF -S filename`. The table below lists some key section information, such as... Figure 4 The diagram shown illustrates the structure of the ELF file link view. For example, `text` represents executable code, `dynamic` represents a dynamic table used to find fields needed by the linker during execution, and `got` and `got.plt` represent relocation addresses, with specific addresses and relocation methods marked in `.rel.dyn` and `.rel.plt`. The execution view is the structure used during runtime and analyzes the ELF structure from the perspective of the loading segment. Figure 5 The diagram shown illustrates the structure of the ELF file execution view, including details such as the address mapping relationship (PT_LOAD) for loading into memory and permissions.

[0161] It is understood that the ELF file in this embodiment may include .so files and executable files, and may also be files of other formats. This embodiment does not limit this. In this embodiment, .so files and executable files are used as examples for explanation. The loading process of .so and executable files is almost the same. The following uses the loading process of .so as an example to introduce how ELF is loaded into memory. Figure 6 The diagram shown illustrates the ELF file loading process and, as well as... Figure 7 The diagram illustrates the function calls, where `do_dlopen` loads the dynamic link library, `find_library` checks if the dynamic link library is already loaded in memory (if not), and executes subsequent functions, `load_library` loads the dynamic link library, `loadSegment` loads the file region specified by `PT_LOAD` into memory, `prelink` reads the dynamic node, `linkImage` performs relocation, and `callConstructors` initiates the init function in the .so file.

[0162] The specific loading process is as follows: During loading, relocation is performed to ensure that all function calls and variable accesses can be executed correctly. Since the relative positions of code and data in the compiled .so and executable files are related, the principle of restoring the .so after hardening is that the relative offsets of code and data cannot be modified. Furthermore, since memory alignment differs across systems, the restored memory location is generally the same as the normally loaded location. Therefore, the safest approach is not to modify the starting position and length of each PT_LOAD. If necessary, the only thing that can be modified is the length of the last PT_LOAD.

[0163] Therefore, during the hardening process, preset field information in the ELF file to be hardened can also be obtained. The preset field information is PT_LOAD. Hardening is performed according to the starting position and length in the preset field information to obtain the hardened ELF file, thereby ensuring that the data information in PT_LOAD is not modified and that the position in memory and the loading position are aligned during loading, thus achieving loading accuracy.

[0164] When the system linker loads, it reads and saves some field contents from the dynamic field into memory. To ensure compatibility with this data, the dynamic field must retain some data, and the dynamic field location cannot be modified. Otherwise, if data overwrites the dynamic field during restoration, it may cause unpredictable errors.

[0165] In this embodiment, during the hardening process, field information in the dynamic table can also be obtained, the field information in the dynamic table can be hardened, and some data of the field information in the dynamic table can be retained, thereby ensuring that the hardened ELF file is consistent with the restored ELF file when loaded.

[0166] It is understood that the loading request for the hardened ELF file can be generated when the user performs ELF file operations, or it can be generated through other means. This embodiment does not impose any restrictions on this. The dynamic link library interface information can be the dynamic link library libdepend.so, or it can be in other forms. This embodiment does not impose any restrictions on this. When the hardened ELF file is an executable file, the default initialization function is the start function; when the hardened ELF file is a dynamic link library file, the default initialization function is the init function.

[0167] The determination module 20 is used to obtain the decryption function and relocation information according to the preset initialization function.

[0168] It should be noted that the preset initialization function has calling logic for the decryption function and relocation information. The decryption function is a function that restores the hardened ELF file, and the relocation information is a mapping relationship that transforms the logical address space of the restored ELF file into the actual physical address in memory.

[0169] Since the decryption function contains relocation logic, writing it to a file in the form of shellcode is quite difficult. If the shellcode is too long, it may affect the ptload size and cause compatibility issues on some platforms. It is advisable to compile the logic into a separate dynamic link library libdepend.so and call the decryption function in libdepend.so to restore the .so file.

[0170] In this embodiment, the shellcode is established to call the start function or the init function, and the decryption function and relocation information are obtained through the start function or the init function.

[0171] The decryption module 30 is used to decrypt the hardened ELF file according to the decryption function to obtain the decrypted ELF file.

[0172] In the specific implementation, since the hardened ELF file is an encrypted ELF file, when loading the hardened ELF file, it is necessary to decrypt the hardened ELF file through a decryption function to obtain the decrypted ELF file, that is, to realize the restoration of the hardened ELF file, thereby ensuring that the hardened ELF file can be loaded normally.

[0173] The relocation module 40 is used to relocate the decrypted ELF file according to the relocation information in order to load the file.

[0174] It is understandable that if the .so is loaded directly, and the relocation information is found in other .so, then all the content of the original .so can be encrypted. It is only necessary to implement relocation and overwrite the memory of the .so in init.

[0175] If a .so file is loaded as a dependency by other .so files, the loading process will not perform decryption during relocation. Therefore, the hardened .so file needs to retain all relevant information about exported symbols. As for imported symbols, you can implement your own relocation method to perform relocation and restoration.

[0176] This embodiment, through the above-described scheme, calls a preset initialization function based on the dynamic link library interface information in the hardened ELF file when a loading request for the hardened ELF file is received; obtains a decryption function and relocation information based on the preset initialization function; decrypts the hardened ELF file using the decryption function to obtain a decrypted ELF file; and relocates the decrypted ELF file based on the relocation information to achieve file loading. Thus, by providing dynamic link library interface information on the hardened ELF file and calling the preset initialization function through the dynamic link library interface information to obtain the decryption function and relocation information, the hardened ELF file can be loaded. This avoids calling the JNI_OnLoad function on the Android platform, enabling the loading of hardened ELF files on all platforms and improving the compatibility of loading hardened ELF files.

[0177] The loading device for strengthening ELF files described in this invention adopts all the technical solutions of all the above embodiments, and therefore has at least all the beneficial effects brought about by the technical solutions of the above embodiments, which will not be repeated here.

[0178] The above are merely preferred embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for loading hardened ELF files, characterized in that, The method for loading the hardened ELF file includes the following steps: When a loading request for a hardened ELF file is received, a preset initialization function is called based on the dynamic link library interface information in the hardened ELF file. The decryption function and relocation information are obtained according to the preset initialization function. The shellcode and the call logic of the start function or init function are established. The decryption function and relocation information are obtained through the start function or init function. The relocation information is the mapping relationship that realizes the transformation of the logical address space of the ELF file after the hardened ELF file is restored into the actual physical address in memory. The hardened ELF file is decrypted using the decryption function to obtain the decrypted ELF file; The decrypted ELF file is relocated according to the relocation information in order to load the file.

2. The loading method for hardened ELF files as described in claim 1, characterized in that, When a loading request for a hardened ELF file is received, a preset initialization function is called based on the dynamic link library interface information in the hardened ELF file, including: When a loading request for a hardened ELF file is received, the file type of the hardened ELF file is determined; When the file type of the hardened ELF file is an executable file, the start function is used as the preset initialization function, and the start function is called according to the dynamic link library interface information in the hardened ELF file; When the file type of the hardened ELF file is a dynamic link library file, the init function is used as the preset initialization function, and the init function is called according to the dynamic link library interface information in the hardened ELF file.

3. The loading method for hardened ELF files as described in claim 1, characterized in that, Before obtaining the decryption function based on the preset initialization function, the method further includes: Obtain the function address of the preset initialization function; Adjust the function address to the jump address of the decryption function; The step of obtaining the decryption function based on the preset initialization function includes: The decryption function is obtained based on the jump address of the preset initialization function.

4. The loading method for hardened ELF files as described in any one of claims 1 to 3, characterized in that, The hardened ELF file includes executable code functions; Before calling the preset initialization function based on the dynamic link library interface information in the hardened ELF file, the method further includes: The dynamic link library interface information of the hardened ELF file is set to the executable code function, and the executable code function is set to the fill function; Set the fill function to the preset initialization function.

5. The method for loading a hardened ELF file as described in any one of claims 1 to 3, characterized in that, The hardened ELF file includes exported symbol information; Before obtaining relocation information according to the preset initialization function, the method further includes: Set the exported symbol information of the hardened ELF file to a preset initialization function; The preset initialization function obtains relocation information, including: The exported symbol information of the hardened ELF file is obtained according to the preset initialization function; The derived symbol information is parsed to obtain relocation information.

6. The method for loading a hardened ELF file as described in any one of claims 1 to 3, characterized in that, Before calling the preset initialization function based on the dynamic link library interface information in the hardened ELF file when a loading request for the hardened ELF file is obtained, the method further includes: Obtain the ELF file to be hardened; Determine the preset reserved data and corresponding reserved area information in the ELF file to be reinforced; Write the preset reserved data and the corresponding reserved area information into the shell code to generate a shell file; Obtain the decryption function and relocation information in the ELF file to be hardened, point the decryption function and relocation information to a preset initialization function, and obtain the dynamic link library interface information according to the preset initialization function; The data and code portions of the ELF file to be hardened are encrypted using a decryption function to obtain encrypted data. A hardened ELF file is generated based on the shell file, dynamic link library interface information, and encrypted data.

7. The loading method for hardened ELF files as described in claim 6, characterized in that, Before encrypting the data and code portions of the ELF file to be hardened according to the decryption function to obtain the encrypted data, the method further includes: The original data in the ELF file to be hardened is analyzed based on the dynamic link library interface information to determine whether the original data in the ELF file to be hardened contains data associated with the dynamic link library interface information. When the original data in the ELF file to be hardened does not contain data associated with the dynamic link library interface information, the data that does not contain data associated with the dynamic link library interface information is taken as the data part.

8. The method for loading a hardened ELF file as described in claim 6, wherein before generating the hardened ELF file based on the shell file, dynamic link library interface information, and encrypted data, the method further includes: The fillable area is obtained based on the reserved area information; The encrypted data is filled into the fillable area to obtain the filled data; The step of generating a hardened ELF file based on the shell file, dynamic link library interface information, and encrypted data includes: A hardened ELF file is generated based on the shell file, dynamic link library interface information, and filler data.

9. The loading method for a hardened ELF file as described in any one of claims 1 to 3, wherein the relocation information includes loading mode information; The step of relocating the decrypted ELF file according to the relocation information includes: Determine the target loading mode based on the loading mode information; The relocation timing or the search range of the relocation symbol is obtained based on the target loading mode; The decrypted ELF file is relocated according to the relocation timing or the search range of the relocation symbol.

10. The loading method for hardened ELF files as described in claim 9, wherein determining the target loading mode based on the loading mode information includes: Determine whether the loading mode information contains a preset field; When the dynamic table in the hardened ELF file contains preset fields, the target loading mode is determined based on the preset fields.

11. The method for loading a hardened ELF file as described in any one of claims 1 to 3, wherein after relocating the decrypted ELF file according to the relocation information, the method further includes: If the decrypted ELF file is an executable file, then the system jumps to the startup function and executes the executable file through the startup function. If the decrypted ELF file is a dynamic link library file, then return to the termination function to end the dynamic link library file.

12. A loading device for hardening ELF files, characterized in that, The loading device for the hardened ELF file includes: The calling module is used to call a preset initialization function based on the dynamic link library interface information in the hardened ELF file when a loading request for the hardened ELF file is obtained; The determination module is used to obtain the decryption function and relocation information according to the preset initialization function. The module establishes the calling logic between the shellcode and the start function or the init function. The decryption function and relocation information are obtained through the start function or the init function. The relocation information is a mapping relationship that transforms the logical address space of the restored ELF file into the actual physical address in memory. The decryption module is used to decrypt the hardened ELF file according to the decryption function to obtain the decrypted ELF file; The relocation module is used to relocate the decrypted ELF file according to the relocation information in order to load the file.

13. The loading device for hardened ELF files as described in claim 12, wherein the calling module is further configured to determine the file type of the hardened ELF file when a loading request for a hardened ELF file is received; When the file type of the hardened ELF file is an executable file, the start function is used as the preset initialization function, and the start function is called according to the dynamic link library interface information in the hardened ELF file; When the file type of the hardened ELF file is a dynamic link library file, the init function is used as the preset initialization function, and the init function is called according to the dynamic link library interface information in the hardened ELF file.

14. The loading device for hardened ELF files as described in claim 12, further comprising: Jump module; The jump module is used to obtain the function address of the preset initialization function; Adjust the function address to the jump address of the decryption function.

15. The loading apparatus for a hardened ELF file as described in any one of claims 12 to 14, wherein the hardened ELF file includes executable code functions; The calling module is also used to direct the executable code function of the hardened ELF file to the padding function; Set the fill function to the preset initialization function.

16. The loading apparatus for a hardened ELF file as described in any one of claims 12 to 14, wherein the hardened ELF file includes exported symbol information; The relocation module is also used to point the exported symbol information of the hardened ELF file to a preset initialization function.

17. The loading device for hardened ELF files as described in any one of claims 12 to 14, wherein the loading device for hardened ELF files further comprises: Reinforcement module; The reinforcement module is used to obtain the ELF file to be reinforced; Determine the preset reserved data and corresponding reserved area information in the ELF file to be reinforced; Write the preset reserved data and the corresponding reserved area information into the shell code to generate a shell file; Obtain the decryption function and relocation information in the ELF file to be hardened, point the decryption function and relocation information to a preset initialization function, and obtain the dynamic link library interface information according to the preset initialization function; The data and code portions of the ELF file to be hardened are encrypted using a decryption function to obtain encrypted data. A hardened ELF file is generated based on the shell file, dynamic link library interface information, and encrypted data.

18. The loading device for hardening ELF files as described in claim 17, wherein the hardening module is further configured to analyze the original data in the ELF file to be hardened based on the dynamic link library interface information, so as to determine whether the original data in the ELF file to be hardened contains data associated with the dynamic link library interface information; When the original data in the ELF file to be hardened does not contain data associated with the dynamic link library interface information, the data that does not contain data associated with the dynamic link library interface information is taken as the data part.

19. The loading device for hardening ELF files as described in claim 17, wherein the hardening module is further configured to obtain a fillable area based on the reserved area information; The encrypted data is filled into the fillable area to obtain the filled data.

20. The loading device for hardened ELF files as described in any one of claims 12 to 14, wherein the relocation information includes loading mode information; The relocation module is further configured to determine the target loading mode based on the loading mode information; The relocation timing or the search range of the relocation symbol is obtained based on the target loading mode; The decrypted ELF file is relocated according to the relocation timing or the search range of the relocation symbol.

21. The loading device for hardening ELF files as described in claim 20, wherein the relocation module is further configured to determine whether a preset field is stored in the loading mode information; When the dynamic table in the hardened ELF file contains preset fields, the target loading mode is determined based on the preset fields.

22. The loading device for hardened ELF files as described in any one of claims 12 to 14, wherein the loading device for hardened ELF files further comprises: Execution module; The execution module is configured to, when the decrypted ELF file is an executable file, jump to the startup function and execute the executable file through the startup function; If the decrypted ELF file is a dynamic link library file, then return to the termination function to end the dynamic link library file.

23. A loading device for hardened ELF files, characterized in that, The loading device for the hardened ELF file includes: a memory, a processor, and a loading program for the hardened ELF file stored on the memory and running on the processor. When the loading program for the hardened ELF file is executed by the processor, it implements the steps of the loading method for the hardened ELF file as described in any one of claims 1 to 11.

24. A storage medium, characterized in that, The storage medium stores a loading program for hardened ELF files, which, when executed by a processor, implements the steps of the loading method for hardened ELF files as described in any one of claims 1 to 11.

Images