A linking method, device and medium for preventing dynamic link library hijacking

Abstract

The embodiment of the present application discloses a linking method, device and medium for preventing dynamic link library hijacking, which belongs to the field of computer software technology and solves the problem that the existing dynamic link library detection and defense methods are difficult to deal with when facing complex attacks such as advanced persistent threats. The main program source code is compiled to generate a relocation file; the connector is called to link the relocation file with the dynamic link library through implicit linking to generate an executable file; the dynamic link library is encrypted with a private key, and the public key corresponding to the private key is stored in the custom segment of the executable file; the executable file is run, and the dynamic link library file is determined based on the link and loaded; the loaded dynamic link library file is decrypted based on the public key in the executable file, and the loading of the dynamic link library file is completed when the decryption is successful.

Description

Technical Field

[0001] The present application relates to the field of computer software technology, and in particular to a linking method, device and medium for preventing dynamic link library hijacking. Background Art

[0002] In the development and application of computer software and systems, Dynamic Link Library (DLL), as an important modular programming technology, is widely used to achieve code reuse, resource sharing and reduce memory usage.

[0003] However, with the increasing complexity of network environments and the continuous development of hacker technology, the security issues of DLL files have become increasingly prominent. Attackers can hijack or tamper with DLL files through various means to control the execution process of programs, steal sensitive information or destroy system stability.

[0004] Dynamic link library hijacking is a way to exploit security vulnerabilities. In Linux, the dynamic linker is responsible for parsing and loading the shared libraries required by the program when the program is running. The dynamic linker searches for shared library files in a certain order, which includes environment variables, system configuration, standard paths, etc. An attacker can place a malicious shared library at the front of the search path by modifying environment variables, system configuration files, or exploiting other system vulnerabilities, so that it is loaded first. When a program tries to load a shared library, if the malicious shared library already exists and is loaded first, the program will call the function in the malicious shared library instead of the normal shared library function.

[0005] Traditional methods to prevent DLL hijacking mainly focus on runtime detection and defense, which often have problems such as delayed response and limited protection range. Especially in the face of complex attacks such as advanced persistent threats, existing detection and defense methods are often difficult to deal with effectively. Summary of the invention

[0006] The embodiments of the present application provide a link method, device and medium for preventing dynamic link library hijacking, which are used to solve the following technical problems: when facing complex attacks such as advanced persistent threats, it is difficult to effectively respond due to the lag of existing detection and defense methods.

[0007] The present application embodiment adopts the following technical solutions:

[0008] The embodiment of the present application provides a linking method for preventing dynamic link library hijacking. The method includes compiling the source code of the main program to generate a relocation file; calling a connector to link the relocation file with the dynamic link library through an implicit linking method to generate an executable file; encrypting the dynamic link library with a private key, and storing the public key corresponding to the private key in a custom segment of the executable file; running the executable file, determining the dynamic link library file based on the link and loading it; decrypting the loaded dynamic link library file based on the public key in the executable file, and completing the loading of the dynamic link library file if the decryption is successful.

[0009] The embodiment of the present application uses a private key to encrypt the dynamic link library file during the linking phase of software compilation, that is, before the program generates an executable file, and stores the corresponding public key in the executable file, thereby ensuring that the dynamic link library file is pure and has not been tampered with before deployment. Subsequently, when the program is running, the loader decrypts the dynamic link library using the public key stored in the executable file. If the decryption is successful, it means that the file has not been modified. If the decryption fails, it means that the file has been tampered with, thereby quickly identifying and preventing any potential hijacking or tampering. The system's defense capabilities and response speed against complex network attacks are improved, thereby effectively preventing the dynamic link library file from being maliciously hijacked or tampered with.

[0010] In one implementation of the present application, the main program source code is compiled to generate a relocation file, which specifically includes: reading a target file and merging the symbol table in the target file into a global symbol table; allocating a memory address to each symbol in the global symbol table, and modifying the reference address corresponding to each symbol based on the allocated memory address; and generating a relocation file based on the modified memory address corresponding to the target file and the global symbol table.

[0011] In one implementation of the present application, after the symbol tables in the target files are merged into a global symbol table, the method further includes: obtaining error information output by the linker, and determining symbol undefined information and symbol conflict information based on the error information; if it is symbol undefined information, querying the symbol definition corresponding to the undefined symbol in the library file and other target files to add the queried symbol definition to the global symbol table; if it is symbol conflict information, determining the conflicting symbols, and calling the automatic naming tool to rename the conflicting symbols; wherein the renaming includes at least one of adding a prefix, adding a suffix, and adding a unique identifier; the renamed symbol name is globally detected, and when the detection result is that there is no conflict, determining that the renaming is successful.

[0012] In one implementation of the present application, an executable file is run, and a dynamic link library file is determined based on a link and loaded, specifically including: running the executable file, determining a library file in the dynamic link library based on a link relationship corresponding to the executable file; parsing the executable and linkable ELF file headers corresponding to the library file to obtain export symbols and relocations; determining an offset based on the export symbol, determining a relocated entry address based on the relocation, and determining an actual address corresponding to the dynamic link library based on the offset and the relocated entry address; and loading the dynamic link library file based on the actual address.

[0013] In one implementation of the present application, a loaded dynamic link library file is decrypted based on a public key in an executable file, specifically including: determining that the loaded dynamic link library file is in an encrypted state; obtaining a public key in a custom segment of the executable file; decrypting a symmetric key stored in the dynamic link library file based on the public key, and decrypting data in the dynamic link library file based on the decrypted symmetric key; performing an integrity check on the decrypted data, and mapping the data to memory if the check is correct.

[0014] In one implementation of the present application, a symmetric key stored in a dynamic link library file is decrypted based on a public key, and data in the dynamic link library file is decrypted based on the decrypted symmetric key, specifically including: decrypting a symmetric key stored in a dynamic link library file based on a public key to obtain multiple decrypted symmetric keys; wherein the multiple decrypted symmetric keys are respectively provided with a unique identifier; querying a preset identifier comparison table to determine encrypted data and an encryption method that match the unique identifier; responding to a decryption instruction to determine the type of data to be decrypted, and determining the data to be decrypted based on the data type; matching the encrypted data with the data to be decrypted, and decrypting the data to be decrypted based on the matching result and the encryption method.

[0015] In one implementation of the present application, before decrypting the loaded dynamic link library file based on the public key in the executable file, the method also includes: obtaining the current system actual occupancy parameter value, comparing the system actual occupancy parameter value with the preset reference parameter value, and determining the time adjustment area based on the comparison result; wherein the system actual occupancy parameter includes at least one of CPU usage and memory occupancy; based on the time adjustment area, adjusting the first time parameter value to obtain the second time parameter value; based on the decryption parameter and the preset decryption time prediction model, obtaining the decryption prediction time; wherein the decryption parameter includes at least one of the decryption method, the dynamic link library size and the remaining available resource size; comparing the decryption prediction time with the second time parameter value, and when the comparison result meets the requirements, decrypting the dynamic link library file.

[0016] In one implementation of the present application, after decrypting the loaded dynamic link library file based on the public key in the executable file, the method also includes: generating error information in the event of a decryption failure; wherein the error information includes at least one of the cause of the decryption failure, the decryption time, and an error code; the cause of the decryption failure includes at least one of a key error, data corruption, and a decryption timeout; generating a decryption log based on the error information; periodically checking the decryption log, and determining the error frequency based on the detection result; prioritizing different error information based on the error frequency, and repairing the error information based on the ranking.

[0017] An embodiment of the present application provides a link device for preventing dynamic link library hijacking, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can: compile the main program source code to generate a relocation file; call a connector to link the relocation file with the dynamic link library by implicit linking to generate an executable file; encrypt the dynamic link library with a private key, and store the public key corresponding to the private key in a custom segment of the executable file; run the executable file, determine the dynamic link library file based on the link and load it; decrypt the loaded dynamic link library file based on the public key in the executable file, and complete the loading of the dynamic link library file if the decryption is successful.

[0018] A non-volatile computer storage medium provided in an embodiment of the present application stores computer executable instructions, wherein the computer executable instructions are configured to: compile a main program source code to generate a relocation file; call a connector to link the relocation file with a dynamic link library by implicit linking to generate an executable file; encrypt the dynamic link library with a private key, and store the public key corresponding to the private key in a custom segment of the executable file; run the executable file, determine the dynamic link library file based on the link, and load it; decrypt the loaded dynamic link library file based on the public key in the executable file, and complete the loading of the dynamic link library file if the decryption is successful.

[0019] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects: the embodiments of the present application use a private key to encrypt the dynamic link library file during the linking phase of software compilation, that is, before the program generates an executable file, and store the corresponding public key in the executable file, thereby ensuring the purity and non-tampering state of the dynamic link library file before deployment. Subsequently, when the program is running, the loader decrypts the dynamic link library using the public key stored in the executable file. If the decryption is successful, it means that the file has not been modified. If the decryption fails, it means that the file has been tampered with, thereby quickly identifying and preventing any potential hijacking or tampering. The system's defense capabilities and response speed against complex network attacks are improved, thereby effectively preventing DLL files from being maliciously hijacked or tampered with. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative labor. In the drawings:

[0021] Figure 1 A flow chart of a linking method for preventing dynamic link library hijacking provided in an embodiment of the present application;

[0022] Figure 2 A schematic diagram of a link implementation example for preventing dynamic link library hijacking provided in an embodiment of the present application;

[0023] Figure 3 A schematic diagram of the structure of a link device for preventing dynamic link library hijacking provided in an embodiment of the present application.

[0024] Reference numerals:

[0025] 200: a link device for preventing dynamic link library hijacking, 201: a processor, 202: a memory. DETAILED DESCRIPTION

[0026] Embodiments of the present application provide a linking method, device, and medium for preventing dynamic link library hijacking.

[0027] In order to enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of them. Based on the embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this application.

[0028] The technical solution proposed in the embodiment of the present invention is described in detail below with reference to the accompanying drawings.

[0029] Figure 1 A flowchart of a linking method for preventing dynamic link library hijacking provided in an embodiment of the present application is shown in FIG. Figure 1 As shown, the linking method for preventing dynamic link library hijacking includes the following steps:

[0030] Step 101: compile the main program source code to generate a relocation file.

[0031] In one embodiment of the present application, the target file is read, and the symbol table in the target file is merged into a global symbol table. Memory addresses are allocated to each symbol in the global symbol table, and the reference address corresponding to each symbol is modified based on the allocated memory address. Based on the modified memory address corresponding to the target file and the global symbol table, a relocation file is generated.

[0032] Specifically, there are two types of links: static linking and dynamic linking. Static linking is done at compile time, and the linker copies the codes of all functions and variables used in the program from the corresponding target file or static library to the final executable file. Dynamic linking is done when the program is running. The operating system loads the required dynamic library into memory when the program is running, and associates the function calls in the program with the function implementations in the dynamic library. The specific steps are as follows:

[0033] Read input files: The linker first reads all the object files and library files that need to be linked.

[0034] Symbol table merging: The linker merges the symbol tables in all object files into a global symbol table.

[0035] Symbol resolution: The linker traverses the global symbol table to resolve the dependencies between symbols. For each unresolved symbol reference, the linker looks for the corresponding symbol definition in the library file or other target file.

[0036] Address assignment: The linker assigns memory addresses to all symbol definitions. These addresses are the actual addresses that the program will use when it runs.

[0037] Relocation: The linker modifies the addresses of all symbol references so that they point to the newly allocated memory addresses, including modifying the jump instructions, function call instructions, and data access instructions in the code.

[0038] Merge segments: The linker merges the code segments, data segments, etc. in all target files into a whole to form the final executable file or library file.

[0039] Generate output file: After the linker completes the above steps, it generates the final executable file or library file. This file contains all the code and data of the program, as well as the necessary metadata (such as relocation information, symbol table, etc.) so that it can be loaded and executed at runtime.

[0040] In one embodiment of the present application, the error information output by the linker is obtained, and the symbol undefined information and the symbol conflict information are determined based on the error information. If it is symbol undefined information, the symbol definition corresponding to the undefined symbol is queried in the library file and other target files, and the queried symbol definition is added to the global symbol table. If it is symbol conflict information, the conflicting symbol is determined, and the automatic naming tool is called to rename the conflicting symbol; wherein the renaming includes at least one of adding a prefix, adding a suffix, and adding a unique identifier. The renamed symbol name is globally detected, and when the detection result is that there is no conflict, it is determined that the renaming is successful.

[0041] Specifically, the linker is responsible for merging multiple compiled object files and library files into an executable file or library file. In this process, the linker needs to resolve the symbol reference problem, that is, to ensure that each symbol, such as function name, variable name, is correctly defined and there is no conflict.

[0042] Furthermore, when the linker tries to resolve a symbol reference, but cannot find the definition of the symbol in all input object files and library files, it reports a symbol undefined error. That is, the necessary source file or library file is missing, or the definition in the source file is not correctly compiled into the object file. Identify all undefined symbols from the linker's error output, search for the definitions of these symbols in other object files, check whether the library files containing the definitions of these symbols are missing, and if missing library files are found, make sure to include these libraries during the link process. If they are defined in other object files, reorganize the order of compilation and linking, or adjust the compiler settings to ensure that the symbols are exported.

[0043] Furthermore, when the linker finds multiple different definitions, usually from different object files or libraries, for the same symbol, a symbol conflict error is reported. This can be caused by including duplicate library files, multiple files defining the same global symbol without using namespaces or prefixes correctly, etc. All conflicting symbols are identified from the linker's error output, and each conflicting symbol is renamed using an automatic naming tool. The renaming strategy can include adding a prefix, suffix, unique identifier, or a combination of these. After the renaming is completed, global detection is performed again to ensure that there are no new conflicts.

[0044] Step 102: Call the connector to link the relocation file with the dynamic link library in an implicit linking manner to generate an executable file.

[0045] In one embodiment of the present application, a linker combines the object files and any required static or dynamic libraries into one executable file.

[0046] Specifically, in the case of implicit linking, the linker handles references to dynamic link libraries and inserts some metadata into the executable file that tells the operating system which dynamic libraries need to be loaded when the program starts. Dynamic link libraries are usually accompanied by an import library, which contains stubs of symbolic references to functions and data in the dynamic link library. During the linking process, the linker uses these import libraries to resolve references to functions in the dynamic link library and generates corresponding import tables in the executable file. Dynamic link information is usually contained in the metadata section of the executable file, which tells the dynamic linker which shared libraries need to be loaded when the program is running. When the executable file is loaded into memory and ready to be executed, the dynamic linker loads the required dynamic libraries based on the information in the executable file. Function calls in the program are redirected to the actual functions in the dynamic library.

[0047] Step 103: encrypt the dynamic link library with a private key, and store the public key corresponding to the private key in the custom segment of the executable file.

[0048] In one embodiment of the present application, the dynamic link library is encrypted using a private key, and the public key is stored in a custom segment in the generated executable file.

[0049] Specifically, an encryption algorithm is used to encrypt the entire dynamic link library file or a key part of the dynamic link library. The private key is used to encrypt the symmetric key, and the encrypted symmetric key is stored in a custom segment of the executable file. The public key is stored in the custom segment of the executable file so that the symmetric key can be decrypted by the public key at runtime.

[0050] Step 104: Run the executable file, determine the dynamic link library file based on the link, and load it.

[0051] In one embodiment of the present application, an executable file is run, and a library file in a dynamic link library is determined based on the link relationship corresponding to the executable file. The executable and linkable ELF file header corresponding to the library file is parsed to obtain export symbols and relocation. When relocation is needed, an offset is determined according to the export symbol, and an entry address to be relocated is determined according to relocation. Based on the offset and the entry address to be relocated, the actual address corresponding to the dynamic link library is determined. Loading of the dynamic link library file is performed based on the actual address.

[0052] Specifically, when an executable file is loaded into memory, its dynamic linker checks the file's dynamic segment, which contains information about the shared libraries that the program depends on. Each shared library is an executable and linkable ELF (Executable and Linkable Format) file. When a shared library is loaded, its ELF file header is parsed to obtain information about the file type, architecture, section layout, etc.

[0053] In ELF, exported symbols are usually associated with their offsets in the shared library. If the shared library needs to be relocated, the dynamic linker uses the relocation table to fix the symbol address. The dynamic linker resolves the corrected symbols into actual memory addresses to load the dynamic link library file.

[0054] Step 105: decrypt the loaded dynamic link library file based on the public key in the executable file, and complete the loading of the dynamic link library file when the decryption is successful.

[0055] In one embodiment of the present application, the actual system occupancy parameter value is obtained, the actual system occupancy parameter value is compared with the preset reference parameter value, and the time adjustment area is determined based on the comparison result; wherein the actual system occupancy parameter includes at least one of CPU usage and memory occupancy. Based on the time adjustment area, the first time parameter value is adjusted to obtain the second time parameter value. Based on the decryption parameter and the preset decryption time prediction model, the decryption prediction time is obtained; wherein the decryption parameter includes at least one of the decryption method, the dynamic link library size, and the remaining available resource size. The decryption prediction time is compared with the second time parameter value, and when the comparison result meets the requirements, the dynamic link library file is decrypted.

[0056] Specifically, monitor and record the current resource usage, including but not limited to CPU usage, memory occupancy, etc. These parameters reflect the current load status of the system. Compare the current actual occupancy parameter value with the preset reference parameter value. For example, if the preset CPU usage reference value does not exceed 80%, and the memory usage reference value does not exceed 90%, then the current system status (CPU 70%, memory 85%) is within an acceptable range. Based on the comparison results, evaluate whether the current performance is sufficient to support the upcoming decryption operation, and determine a time adjustment area accordingly. For example, if the system determines that the current load is high, it will estimate that the decryption operation will take longer, so the originally planned first time parameter value (for example, the estimated decryption time is 10 seconds) is adjusted to a longer second time parameter value (for example, adjusted to 15 seconds) to leave buffer time.

[0057] Furthermore, decryption-related parameters, such as decryption mode, dynamic link library size, remaining available resource size, etc., and a preset decryption time prediction model are used to estimate the time required for the decryption operation. The preset decryption time prediction model in the embodiment of the present application is obtained based on historical data training, and can consider the influence of different factors on the decryption time. The training process is to use the obtained decryption-related parameter samples as input samples, and the decryption time corresponding to the input samples as output samples, and train the preset neural network model to obtain the decryption time prediction model.

[0058] Further, the predicted decryption time is compared with the second time parameter value determined previously to determine whether there is enough time to complete the decryption operation. If the second time parameter value is 15 seconds and the predicted decryption time is 8 seconds, then the comparison result meets the requirements and the system has enough time to complete the decryption operation. If the comparison result meets the requirements, the decryption operation is performed to decrypt the dynamic link library file.

[0059] In one embodiment of the present application, it is determined that the loaded dynamic link library file is in an encrypted state. A public key is obtained in a custom segment of the executable file. The symmetric key stored in the dynamic link library file is decrypted based on the public key, and the data in the dynamic link library file is decrypted based on the decrypted symmetric key. The decrypted data is integrity checked, and the data is mapped to the memory if the check is correct.

[0060] Specifically, the executable file is run, and the dynamic link library is searched and loaded according to the runtime search path. The loader verifies the dynamic link library and decrypts it using the public key to verify whether the file has been tampered with. If the decryption is normal, the dynamic link library continues to be loaded. If the decryption is wrong, an error message is generated and the loading of the dynamic link library is stopped.

[0061] In one embodiment of the present application, the symmetric key stored in the dynamic link library file is decrypted based on the public key to obtain multiple decrypted symmetric keys; wherein the multiple decrypted symmetric keys are respectively provided with unique identifiers. A query is performed in the preset identifier comparison table to determine the encrypted data and encryption method that match the unique identifier. In response to the decryption instruction, the data type to be decrypted is determined, and the data to be decrypted is determined based on the data type. The encrypted data is matched with the data to be decrypted, and the data to be decrypted is decrypted based on the matching result and the encryption method.

[0062] Specifically, multiple symmetric keys are stored in the dynamic link library, and these keys are encrypted by public key encryption technology to protect their security. Each symmetric key has a unique identifier so that it can be identified after decryption. When these symmetric keys need to be accessed, they are decrypted using the corresponding private key. After decryption, multiple symmetric keys in plain text are obtained, each with its unique identifier. In the identifier comparison table preset in the embodiment of the application, the entry that matches the unique identifier of the symmetric key after decryption is searched, and the comparison table records the encrypted data corresponding to each identifier and its encryption method.

[0063] Further, when a decryption instruction is received, the specific data to be decrypted is determined according to the data type specified in the instruction. Based on the data type or identifier, the data to be decrypted is determined, the encrypted data is matched with the data to be decrypted, and it is confirmed that the retrieved encrypted data completely corresponds to the data to be decrypted, and decryption is performed. The data to be decrypted is decrypted using the matching symmetric key and encryption method.

[0064] The embodiment of the present application flexibly manages and uses encryption keys and data stored in a dynamic link library while ensuring data security. By protecting symmetric keys through public key encryption and managing encrypted data and encryption methods through an identifier comparison table, the system can efficiently respond to decryption requests while maintaining data security and manageability.

[0065] In one embodiment of the present application, in the case of decryption failure, an error message is generated; wherein the error message includes at least one of the decryption failure reason, the decryption time, and the error code; the decryption failure reason includes at least one of the key error, data corruption, and decryption timeout. A decryption log is generated based on the error message. The decryption log is regularly tested, and the error frequency is determined based on the test result. Different error messages are prioritized based on the error frequency, and the error messages are repaired based on the ranking.

[0066] Specifically, when a decryption operation fails, an error message is generated so that the user or administrator can quickly locate the problem. The error message should at least include the reason for the decryption failure, the time when the decryption operation was attempted, i.e., the decryption time, and a unique error code for problem tracking and statistics. Possible causes include key errors, i.e., the wrong key was used or the key pair does not match, data corruption, encrypted data was tampered with or corrupted during storage or transmission, and decryption timeout, where the decryption operation exceeded the predetermined time limit, possibly due to insufficient system resources or inefficient algorithms.

[0067] Furthermore, the error message generated each time a decryption fails will be recorded in the decryption log. The decryption log is checked regularly (such as daily, weekly, or as required) to analyze the performance and stability of the decryption operation. Based on the detection results of the decryption log, the system can calculate the frequency of each cause of decryption failure. Different error messages are prioritized according to the error frequency. Generally, error messages with higher error frequencies are given higher priorities. Based on the sorting results, appropriate measures are taken to fix the problems represented by these error messages. Repair measures may include updating keys, recovering damaged data, optimizing decryption algorithms, or increasing system resources.

[0068] Figure 2 A schematic diagram of a link implementation example for preventing dynamic link library hijacking provided in an embodiment of the present application is shown in FIG. Figure 2 As shown, taking the Linux system as an example, the source code of the dynamic link library is compiled separately, and the code of the header file is as follows:

[0069] / / fun.h

[0070] #ifndef HAVE_FUN_H

[0071] #define HAVE_FUN_H

[0072] int have_fun();

[0073] #endif

[0074] The source file code is as follows:

[0075] / / fun.cpp

[0076] #include <iostream>

[0077] #include "fun.h"

[0078] int have_fun(){

[0079] std::cout<<"have_fun friends!"< <endl;

[0080] return 0;

[0081] }

[0082] Use the following command to generate a dynamic link library:

[0083] g++ --shared -fPIC -o libfun.so . / fun.cc

[0084] The code of main.cpp that calls the dynamic link library is as follows:

[0085] #include <iostream>

[0086] #include "fun.h"

[0087] int main(){

[0088] have_fun();

[0089] return 0;

[0090] }

[0091] Use the header file fun.h exposed by the dynamic link library to generate a relocatable file from main.cpp.

[0092] g++ -c main.cpp -o main.o

[0093] Use implicit loading to load the main program main.o and the dynamic link library libfun.so to generate an executable file.

[0094] g++ main.o -L. / -lfun -Wl,-rpath=. / -o main

[0095] The above command first uses g++ to compile main.cpp and generate a relocation file. Then, in the linking stage, the linker starts to link the libfun.so dynamic link library. At this time, the private key is used to encrypt libfun.so, and the corresponding public key is stored in the custom segment of the executable file main, and finally an executable file in ELF format is generated.

[0096] When executing an executable file, the dynamic link library generated using implicit loading will be loaded into the memory when the program is executed. At this time, the loader uses the public key in the main program's custom segment to decrypt the dynamic link library. If the decryption is normal, the executable file will continue to be executed. If it fails, the program will be stopped and an error message will be generated.

[0097] Figure 3 A schematic diagram of the structure of a link device for preventing dynamic link library hijacking provided in an embodiment of the present application. Figure 3 As shown, a link device 200 for preventing dynamic link library hijacking includes: at least one processor 201; and a memory 202 communicatively connected to the at least one processor 201; wherein the memory 202 stores instructions executable by the at least one processor 201, and the instructions are executed by the at least one processor 201 so that the at least one processor 201 can: compile the main program source code to generate a relocation file; call the connector to link the relocation file with the dynamic link library by implicit linking to generate an executable file; encrypt the dynamic link library with a private key, and store the public key corresponding to the private key in a custom segment of the executable file; run the executable file, determine the dynamic link library file based on the link and load it; decrypt the loaded dynamic link library file based on the public key in the executable file, and complete the loading of the dynamic link library file if the decryption is successful.

[0098] The embodiment of the present application also provides a non-volatile computer storage medium storing computer executable instructions, wherein the computer executable instructions are configured to: compile a main program source code to generate a relocation file; call a connector to link the relocation file with a dynamic link library by implicit linking to generate an executable file; encrypt the dynamic link library with a private key, and store the public key corresponding to the private key in a custom segment of the executable file; run the executable file, determine the dynamic link library file based on the link, and load it; decrypt the loaded dynamic link library file based on the public key in the executable file, and complete the loading of the dynamic link library file if the decryption is successful.

[0099] Each embodiment in this application is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device, equipment, and non-volatile computer storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0100] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the embodiments of the present application may have various changes and variations. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application.< / iostream> < / iostream>

Claims

1. A linking method for preventing dynamic link library hijacking, characterized in that: The method comprises: Compile the main program source code to generate a relocation file; Calling a connector to link the relocation file with a dynamic link library in an implicit linking manner to generate an executable file; Encrypting the dynamic link library with a private key, and storing a public key corresponding to the private key in a custom segment of the executable file; Running the executable file, determining a dynamic link library file based on the link and loading the dynamic link library file; Decrypting the loaded dynamic link library file based on the public key in the executable file, and completing the loading of the dynamic link library file if the decryption is successful; Before decrypting the loaded dynamic link library file based on the public key in the executable file, the method further includes: Obtaining a current system actual occupancy parameter value, comparing the system actual occupancy parameter value with a preset reference parameter value, and determining a time adjustment area based on the comparison result; wherein the system actual occupancy parameter includes at least one of a CPU usage rate and a memory occupancy rate; Based on the time adjustment area, the first time parameter value is adjusted to obtain a second time parameter value; wherein, if the actual occupancy parameter of the current system is higher, the time adjustment area is added to the first time parameter value to obtain a longer second time parameter value; Using the obtained decryption-related parameter samples as input samples, using the decryption time corresponding to the input samples as output samples, training the preset neural network model to obtain a preset decryption time prediction model; Based on the decryption parameters and the preset decryption time prediction model, the decryption prediction time is obtained; wherein the decryption parameters include at least one of the decryption mode, the size of the dynamic link library, and the size of the remaining available resources; The decryption prediction time is compared with the second time parameter value, and when the comparison result meets the requirements, the dynamic link library file is decrypted; wherein, the comparison result meets the requirements when the decryption prediction time is not greater than the second time parameter value.

2. A linking method for preventing dynamic link library hijacking according to claim 1, characterized in that: The main program source code is compiled to generate a relocation file, specifically including: Read the target file, and merge the symbol tables in the target file into a global symbol table; Allocating memory addresses to the symbols in the global symbol table, and modifying reference addresses corresponding to the symbols based on the allocated memory addresses; The relocation file is generated based on the target file and the modified memory address corresponding to the global symbol table.

3. A linking method for preventing dynamic link library hijacking according to claim 2, characterized in that: After merging the symbol tables in the target file into a global symbol table, the method further comprises: Obtain error information output by the linker, and determine symbol undefined information and symbol conflict information based on the error information; If it is symbol undefined information, query the symbol definition corresponding to the undefined symbol in the library file and other target files, so as to add the queried symbol definition to the global symbol table; If it is symbol conflict information, determine the conflicting symbol, and call the automatic naming tool to rename the conflicting symbol; wherein the renaming includes at least one of adding a prefix, adding a suffix, and adding a unique identifier; The renamed symbol name is globally checked, and if the check result shows that there is no conflict, the renaming is determined to be successful.

4. A linking method for preventing dynamic link library hijacking according to claim 1, characterized in that: The running of the executable file, determining a dynamic link library file based on the link and loading the dynamic link library file specifically includes: Running the executable file, and determining the library file in the dynamic link library based on the link relationship corresponding to the executable file; Parsing the executable and linkable ELF file headers corresponding to the library file to obtain export symbols and relocations; In the case where relocation is required, determining an offset according to the exported symbol, determining a relocated entry address according to the relocation, and determining an actual address corresponding to the dynamic link library based on the offset and the relocated entry address; The dynamic link library file is loaded based on the actual address.

5. A linking method for preventing dynamic link library hijacking according to claim 1, characterized in that: The decrypting the loaded dynamic link library file based on the public key in the executable file specifically includes: Determining that the loaded dynamic link library file is in an encrypted state; Obtaining the public key in a custom section of the executable file; Decrypting the symmetric key stored in the dynamic link library file based on the public key, and decrypting the data in the dynamic link library file based on the decrypted symmetric key; The decrypted data is subjected to an integrity check, and if the check is correct, the data is mapped into the memory.

6. A linking method for preventing dynamic link library hijacking according to claim 5, characterized in that: The decrypting the symmetric key stored in the dynamic link library file based on the public key, and decrypting the data in the dynamic link library file based on the decrypted symmetric key, specifically includes: Decrypting the symmetric key stored in the dynamic link library file based on the public key to obtain multiple decrypted symmetric keys; wherein the multiple decrypted symmetric keys are respectively provided with a unique identifier; Searching in a preset identifier comparison table to determine the encrypted data and encryption method that match the unique identifier; In response to the decryption instruction, determining the type of data to be decrypted, and determining the data to be decrypted based on the type of data; The encrypted data is matched with the data to be decrypted, and based on the matching result and the encryption method, the data to be decrypted is decrypted.

7. A linking method for preventing dynamic link library hijacking according to claim 1, characterized in that: After decrypting the loaded dynamic link library file based on the public key in the executable file, the method further includes: In the case of decryption failure, an error message is generated; wherein the error message includes at least one of the decryption failure reason, the decryption time and the error code; the decryption failure reason includes at least one of the key error, data corruption and decryption timeout; generating a decryption log based on the error information; Regularly testing the decryption log, and determining the error frequency based on the test result; The different error information are prioritized based on the error frequencies, and the error information is repaired based on the priorities.

8. A link device for preventing dynamic link library hijacking, characterized in that: The device comprises a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the device is triggered to execute the method according to any one of claims 1 to 7.

9. A non-volatile computer storage medium storing computer executable instructions, characterized in that: The computer executable instructions can execute the method according to any one of claims 1 to 7.

Images