Data processing method and device, storage medium and electronic equipment

Abstract

The invention discloses a data processing method and device, a storage medium and electronic equipment. The method comprises the following steps: when a target process needs to load a dynamic link library, determining a variable identifier corresponding to a target thread local storage variable needing to be accessed by a patch function and an initial position of an assembly code according to a code snippet associated with the patch function; according to the variable identifier, searching whether target relocation information with the variable identifier exists in the executable file, and if the target relocation information is not searched, modifying an assembly code corresponding to the local storage variable of the same-name thread according to the target offset to obtain a target assembly code; and replacing the initial assembly code with the target assembly code, modifying the relocation type of the local storage variable of the target thread to be relocation forbidding, and updating and loading the dynamic link library. According to the method and the device, the technical problem of patch function loading failure caused by different addressing modes of thread local storage variables in a conventional dynamic mode and a local executable mode is solved.

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular to a data processing method and device, a storage medium, and an electronic device. Background Art

[0002] Currently, in existing dynamic link libraries, thread local storage variables are usually relocated through a global offset table. When the dynamic link library is loaded into memory, the address of the thread local storage variable will be filled into the global offset table, and the program accesses the thread local storage variable through the global offset table when running.

[0003] However, when the patch function in the dynamic link library uses the conventional dynamic mode to address the thread local storage variables, and the thread local storage variables are addressed in the local executable mode in the executable file, the patch function fails to load due to the lack of relocation information in the local executable mode. That is, there is a technical problem in the related art that the patch function fails to load due to the different addressing methods of thread local storage variables in the conventional dynamic mode and the local executable mode.

[0004] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0005] The embodiments of the present application provide a data processing method and device, a storage medium and an electronic device to at least solve the technical problem of patch function loading failure caused by the different addressing methods of thread local storage variables in conventional dynamic mode and local executable mode.

[0006] According to one aspect of an embodiment of the present application, a data processing method is provided, comprising: when a target process needs to load a dynamic link library, determining a variable identifier and a starting position of a corresponding assembly code corresponding to a target thread local storage variable that the patch function needs to access according to a code snippet associated with a patch function, wherein the dynamic link library includes the patch function; searching whether there is target relocation information with the variable identifier in an executable file, and when the target relocation information is not found, determining that the access mode of the target thread local storage variable is a local executable mode; when the access mode of the target thread local storage variable is the local executable mode, determining a thread local storage variable with the same name as the variable identifier in the executable file according to the variable identifier, and a target offset of the thread local storage variable with the same name; modifying the assembly code corresponding to the thread local storage variable with the same name according to the target offset to obtain a target assembly code; replacing the initial assembly code corresponding to the starting position with the target assembly code, and modifying the relocation type of the target thread local storage variable to prohibiting relocation, and updating and loading the dynamic link library.

[0007] According to another aspect of an embodiment of the present application, a data processing device is also provided, including: a determination module, for determining, when a target process needs to load a dynamic link library, a variable identifier corresponding to a target thread local storage variable that the patch function needs to access and a starting position of a corresponding assembly code according to a code fragment associated with a patch function, wherein the dynamic link library includes the patch function; a search module, for searching whether there is target relocation information with the variable identifier in an executable file, and determining that the access mode of the target thread local storage variable is a local executable mode if the target relocation information is not found; an execution module, for determining, when the access mode of the target thread local storage variable is the local executable mode, a thread local storage variable with the variable identifier and a target offset of the thread local storage variable with the same name in the executable file according to the variable identifier; a modification module, for modifying the assembly code corresponding to the thread local storage variable with the same name according to the target offset to obtain a target assembly code; and a replacement module, for replacing the initial assembly code corresponding to the starting position with the target assembly code, and modifying the relocation type of the target thread local storage variable to prohibiting relocation, and updating and loading the dynamic link library.

[0008] Optionally, the device is used to determine the variable identifier corresponding to the target thread local storage variable that the patch function needs to access and the starting position of the corresponding assembly code according to the code snippet associated with the patch function in the following manner: traverse the memory corresponding to the dynamic link library to search for the code snippet, wherein the first part of bytes of the code snippet is in a preset format, and the code snippet includes the first part of bytes; determine the variable identifier and the starting position based on the relocation table corresponding to the code snippet and the dynamic link library.

[0009] Optionally, the device is used to determine the variable identifier and the starting position based on the relocation table corresponding to the code snippet and the dynamic link library in the following manner, including: determining a first offset value between the code snippet and the register based on the second part of bytes of the code snippet, wherein the code snippet includes the second part of bytes; obtaining the address of the next operation instruction of the register; and determining the variable identifier and the starting position in the relocation table based on the sum of the first offset value and the address.

[0010] Optionally, the device is used to search whether there is target relocation information with the variable identifier in the executable file in the following manner, and if the target relocation information is not found, determine that the access mode of the target thread local storage variable is the local executable mode: obtain symbol information of the executable file; if the symbol information is of a preset type, determine that the executable file includes the target thread local storage variable; search whether there is the target relocation information with the variable identifier in the executable file; if the target relocation information is not found, determine that the access mode of the target thread local storage variable is the local executable mode.

[0011] Optionally, the device is used to determine, in the executable file, a thread local storage variable with the same name and the variable identifier and a target offset of the thread local storage variable with the same name according to the variable identifier when the access mode of the target thread local storage variable is the local executable mode in the following manner: when the access mode of the target thread local storage variable is the local executable mode, determine, in the executable file, a thread local storage variable with the same name and the variable identifier according to the variable identifier; obtain a second offset of the thread local storage variable with the same name in the thread local storage space and an alignment size of the thread local storage space; and determine the target offset according to the second offset and the alignment size.

[0012] Optionally, the device is used to determine the target offset according to the second offset and the alignment size in the following manner: determine a third offset corresponding to the last thread local storage variable in the thread local storage space; determine the sum of the third offset and the alignment size as a pointer offset; and determine the difference between the second offset and the pointer offset as the target offset.

[0013] Optionally, the device is used to modify the assembly code corresponding to the thread local storage variable with the same name according to the target offset to obtain the target assembly code: obtain the assembly code corresponding to the thread local storage variable with the same name, wherein the assembly code corresponding to the thread local storage variable with the same name includes at least 4 bytes; modify the last 4 bytes of the assembly code corresponding to the thread local storage variable with the same name according to the target offset to obtain the target assembly code.

[0014] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the above-mentioned data processing method when running.

[0015] According to another aspect of the embodiments of the present application, a computer program product or a computer program is provided, the computer program product or the computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the above data processing method.

[0016] According to another aspect of the embodiments of the present application, there is also provided an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the data processing method through the computer program.

[0017] In an embodiment of the present application, when a target process needs to load a dynamic link library, a variable identifier corresponding to a target thread local storage variable that a patch function needs to access and a starting position of a corresponding assembly code are determined according to a code snippet associated with the patch function, wherein the dynamic link library includes the patch function; searching for target relocation information with a variable identifier in an executable file, and determining that an access mode of the target thread local storage variable is a local executable mode if no target relocation information is found; and determining, in a case where the access mode of the target thread local storage variable is a local executable mode, in a case where the access mode of the target thread local storage variable is a local executable mode, determining a thread with the same name as the variable identifier in the executable file according to the variable identifier. Local storage variables, and target offsets of thread-local storage variables with the same name; modifying the assembly code corresponding to the thread-local storage variable with the same name according to the target offset to obtain the target assembly code; using the target assembly code to replace the initial assembly code corresponding to the starting position, and modifying the relocation type of the target thread-local storage variable to prohibit relocation, updating and loading the dynamic link library, thereby releasing the relocation dependency of the target thread-local storage variable in the patch function, allowing the patch function to be successfully loaded, and further solving the technical problem of the failure of patch function loading due to the different addressing methods of thread-local storage variables in the conventional dynamic mode and the local executable mode. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0019] Figure 1 is a schematic diagram of an application environment of an optional data processing method according to an embodiment of the present application;

[0020] Figure 2 is a flowchart of an optional data processing method according to an embodiment of the present application;

[0021] Figure 3 is a schematic diagram of an optional data processing method according to an embodiment of the present application;

[0022] Figure 4 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0023] Figure 5 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0024] Figure 6 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0025] Figure 7 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0026] Figure 8 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0027] Fig. 9 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0028] Fig.10 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0029] Fig.11 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0030] Fig.12 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0031] Fig.13 is a schematic structural diagram of an optional data processing device according to an embodiment of the present application;

[0032] Fig.14 is a schematic diagram of the structure of an optional data processing product according to an embodiment of the present application;

[0033] Fig.15 It is a schematic diagram of the structure of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

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

[0035] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0036] The present application is described below in conjunction with embodiments:

[0037] According to one aspect of an embodiment of the present application, a data processing method is provided. Optionally, in this embodiment, the data processing method can be applied to Figure 1 In the hardware environment composed of the server 101 and the terminal device 103 shown in FIG. Figure 1As shown, the server 101 is connected to the terminal device 103 via a network, and can be used to provide services for the terminal device or the application installed on the terminal device. The application 107 can be a video application, an instant messaging application, a browser application, an educational application, a game application, etc. A database 105 may be set up on the server or independently of the server to provide data storage services for the server 101, for example, a game data storage server. The above-mentioned network may include, but is not limited to, a wired network and a wireless network, wherein the wired network includes, a local area network, a metropolitan area network and a wide area network; the wireless network includes, Bluetooth, WIFI and other networks that implement wireless communication; the terminal device 103 may be a terminal configured with an application, and may include, but is not limited to, at least one of the following: a mobile phone (such as an Android phone, an iOS phone, etc.), a laptop computer, a tablet computer, a PDA, a MID (Mobile Internet Devices), a PAD, a desktop computer, a smart TV, an intelligent voice interaction device, a smart home appliance, a vehicle-mounted terminal, an aircraft, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a mixed reality (MR) terminal and other computer devices; the above-mentioned server may be a single server, a server cluster consisting of multiple servers, or a cloud server.

[0038] Combination Figure 1 As shown, the above data processing method can be executed by an electronic device, which can be a terminal device or a server. The above data processing method can be implemented by the terminal device or the server respectively, or by the terminal device and the server together.

[0039] The above is only an example and is not specifically limited in this embodiment.

[0040] Optionally, as an optional implementation, as Figure 2 As shown, the method for processing the above data includes:

[0041] S202, when the target process needs to load a dynamic link library, determining a variable identifier corresponding to a target thread local storage variable that the patch function needs to access and a starting position of a corresponding assembly code according to a code snippet associated with the patch function, wherein the dynamic link library includes the patch function;

[0042] Optionally, in an embodiment of the present application, the target process may be understood as an instance of a program running in a computer, which may include but is not limited to program code, data, and execution status, etc. Each process has an independent memory space, and multiple processes may run simultaneously without affecting each other. The dynamic link library refers to a library file containing code and data that can be dynamically loaded by a program at runtime, which can be shared by multiple programs and can be updated or replaced while the program is running without recompiling or restarting the program. The patch function refers to a defect repair function, which means a function that repairs erroneous logic and implements normal functions. The defect function here refers to a function with erroneous logic running in the target process.

[0043] Exemplarily, it may include but is not limited to replacing the instructions of the defective function with the instructions of the patch function when the target process is running, so as to ensure that the target process can run normally.

[0044] It should be noted that the above-mentioned dynamic link library may include but is not limited to pre-compiled functions, variables, classes or other code fragments, and this application does not limit the compilation process.

[0045] In an exemplary embodiment, it is assumed that there is a target process A that is running and executing business functions. At this time, a dynamic link library B containing a patch function can be loaded to repair an erroneous logic in the target process A. Once the dynamic link library B is successfully loaded into the target process A, the patch file can be used to dynamically load the patched process, read the patch function information implemented in the patch file, and search for a function with the same name among all functions that can be used by the patched process according to the name of the patch function. If a function with the same name is found, it means that the function with the same name is the function that needs to be patched; then, modify the assembly instruction at the function address entry of the function to be patched in the patched process, and modify the assembly instruction content to: jump to the address of the function with the same name implemented in the patch dynamic link library, thereby realizing the repair of the erroneous logic. In other words, even if the target process A is running, the erroneous logic can be repaired by loading the dynamic link library without stopping the operation of the target process A.

[0046] Optionally, in an embodiment of the present application, the above-mentioned code snippet may be located in the above-mentioned dynamic link library, the above-mentioned target thread local storage variable refers to a TLS (Thread Local Storage) variable, the above-mentioned variable identifier may include but is not limited to the variable name of the target thread local storage variable, and the above-mentioned dynamic link library may include the assembly code corresponding to the target thread local storage variable.

[0047] It should be noted that Thread Local Storage (TLS) is a thread-level storage mechanism that allows each thread in a process to have its own private variables at runtime. The target thread local storage variables can only be accessed by the corresponding thread and will not be shared by other threads. That is, the target thread local storage variables are thread private variables and will not be open to the target process. Global variables accessed by any thread in the target process are all in the same memory space.

[0048] In an exemplary embodiment, Figure 3 is a schematic diagram of an optional data processing method according to an embodiment of the present application, such as Figure 3 As shown, taking the target process in the X86-64-bit CPU (central processing unit) as an example, it includes but is not limited to:

[0049] S302, start;

[0050] S304, traversing the program code of the dynamic link library;

[0051] S306, determine whether there is a code segment in the program code where bytes 0 to 1 are 0x66 0x48 and bytes 8 to 10 are 0x66 0x66 0x48, if yes, execute S308, if not, execute S314;

[0052] S308, determine whether the offset value of the 4th to 7th bytes relative to rip in little endian order is within the range of the GOT table after adding the offset value to the rip value, wherein rip refers to the instruction pointer register in the x86 architecture, which is used to store the memory address of the currently executed instruction. During the program execution, rip will be continuously updated to the address of the next instruction to be executed. The GOT (Global Offset Table) table is a table for storing variable offset addresses, which is used to store variable addresses in dynamic link libraries. The variables here may include but are not limited to global variables, TLS variables, etc. If so, execute S310, if not, execute S314;

[0053] S310, determine whether the offset value of the 4th to 7th bytes relative to rip in little endian plus the rip value is consistent with the "offset" field in the relocation table of type R_X86_64_DTPMOD64 (64-bit data pointer module relocation of x86_64 architecture), if yes, execute S312, if not, execute S314;

[0054] Among them, taking X86-64 bit CPU as an example, the function __tls_get_addr is called through a pointer parameter pointing to an object of type tls_index, and the access address of the corresponding TLS variable (the above-mentioned target thread local storage variable) in the current thread can be calculated. The function __tls_get_addr is expressed as "extern void*__tls_get_addr(tls_index*ti)", where the type tls_index is defined as follows:

[0055]

[0056]

[0057] When the linker links, the two members ti_module and ti_offset of the tls_index structure allocated to each TLS variable are stored in the GOT table (Global Offset Table), where the member ti_module is associated with the relocation type R_X86_64_DTPMOD64 of the TLS variable, and the member ti_offset is associated with the relocation type R_X86_64_DTPOFF64 of the TLS variable. ti_module is an index pointing to the TLS module, which is used to find the corresponding TLS variable in the TLS module; and ti_offset is the offset of the TLS variable in the TLS module, which is used to calculate the access address of the TLS variable in the current thread.

[0058] For example, the dynamic link library libtest.so in ELF (executable and link) format can be used to see the relocation information in the dynamic link library through the readelf-rlibtest.so command. Among them, the R_X86_64_DTPMOD64 type offset address of the TLS variable t_flg is 0x000000200fd0, indicating that the ti_module information of the t_flg variable is stored in the GOT table at 0x000000200fd0, and the R_X86_64_DTPOFF64 type offset address of the TLS variable t_flg is 0x000000200fd8, indicating that the ti_offset information of the t_flg variable is stored in the GOT table at 0x000000200fd8.

[0059] S312, determining the variable identifier and binary assembly code position of the TLS variable (target thread local storage variable) operated by the current code segment, that is, the above-mentioned starting position;

[0060] S314, end.

[0061] For example, Figure 4 It is a schematic diagram of another optional data processing method according to an embodiment of the present application. There is a dynamic link library libtest.so in ELF format. The relocation information in the dynamic link library can be seen by the readelf-rlibtest.so command. Figure 4 As shown, the R_X86_64_DTPMOD64 type offset address of the target thread local storage variable t_flg is 0x000000200fd0, indicating that the ti_module information of the t_flg variable is stored in the GOT table at the position of 0x000000200fd0, and the R_X86_64_DTPOFF64 type offset address of the target thread local storage variable t_flg is 0x000000200fd8, indicating that the ti_offset information of the t_flg variable is stored in the GOT table at the position of 0x000000200fd8 (the GOT table (Global Offset Table) is a table for storing variable offset addresses, which is used to store the addresses of various variables in the dynamic library.

[0062] Furthermore, there is a difference of 8 bytes from 0x000000200fd0 to 0x000000200fd8, and the length of the ti_module member is 8 bytes. Therefore, the 16-byte continuous space starting from the address 0x000000200fd0 in the GOT table is used to store the tls_index information of the t_flg variable. When implementing the assembly code, you can first find the address 0x000000200fd0 and store it in the register rdi that passes the first function parameter, and then call the __tls_get_addr function to get the access address of the target thread local storage variable t_flg in the current thread. Then, the compiled binary assembly code with a length of 16 bytes is implemented as follows:

[0063] 8e5:66 48 8d 3d e3 06 20 00data16 lea 0x2006e3(%rip),%rdi#200fd0<_DYNAMIC+0x210>;

[0064] 8ed:66 66 48e8 bb fe ff ff data16 data16 callq 7b0<__tls_get_addr@plt>;

[0065] 8f5: ...

[0066] Among them, the first two bytes of the first line 0x66 0x48 are fixed to represent the prefix, 0x8d 0x3d 0xe3 0x06 0x200x00 implements the function of lea 0x2006e3 (%rip), %rdi, and the 4 bytes starting from the 4th byte 0xe3 0x06 0x20 0x00 are 0x2006e3 in little endian. When calling the first line, rip represents the address of the next instruction 0x8ed, 0x2006e3+0x8ed=0x200fd0, which is exactly the address of the variable t_flg storing ti_offset information in the GOT table. The first three bytes of the second line 0x66 0x660x48 are fixed to represent the prefix, followed by e8 bb fe ff ff implements the function of calling the __tls_get_addr interface. Therefore, the code segment of the dynamic link library libtest.so is traversed in the ELF format. If there is a code segment with the first two bytes of 0x660x48, the 8th to 10th bytes (starting from 0) are 0x66 0x66 0x48, and the 4th to 7th bytes (starting from 0) are the offset value relative to rip in little endian (0x2006e3) plus the rip value (for example, 0x8ed), the sum of which is 0x200fd0. Look it up in the relocation table of type R_X86_64_DTPMOD64. If the Offset field value (0x200fd0) is consistent with the value of a thread local storage variable of a certain item in the relocation table (0x200fd0 of t_flg), it can be determined that the variable identifier operated in the code segment is t_flg and the starting position of the binary assembly code is 0x8e5.

[0067] S204, searching whether there is target relocation information with a variable identifier in the executable file, and if no target relocation information is found, determining that the access mode of the target thread local storage variable is a local executable mode;

[0068] Optionally, in the embodiment of the present application, the target relocation information may include but is not limited to: Figure 4 As shown, it includes the index of the target thread local storage variable, the offset of the target thread local storage variable, the storage address of the target thread local storage variable, etc.

[0069] It should be noted that the above-mentioned local executable mode refers to: through the definition of TLS variables (the above-mentioned thread-local storage variables of the same name) and strict limitation of usage scenarios, the local executable mode (abbreviated as LE) is optimized. This mode can only reference TLS variables defined in executable files. When linking, the linker can calculate the relative offset of each TLS variable relative to the thread control block (TCB) pointer. When addressing, it can directly find the thread control block (TCB) pointer, and add this offset value to find the address of the TLS variable without relocation. The most common application scenario of LE mode is the use of TLS variables defined in executable files by functions compiled in a static linking manner.

[0070] For example, Figure 5 is a schematic diagram of another optional data processing method according to an embodiment of the present application, such as Figure 5 As shown, Thread 1 and Thread 2 both have their own Thread Local Storage (TLS) space for TLS variables at runtime. The corresponding TLS variable Thread Local Storage space can only be accessed by the thread to which it belongs and will not be shared by other threads. When the linker is linking, the memory space of each thread variable and Thread Control Block (TCB) is arranged.

[0071] For example, in the thread local storage space, the offset of TLS variable 1 is 0 and the length is 4, the offset of TLS variable 2 is 4 and the length is 4, the offset of TLS variable N is 28 and the length is 4, and the offset of the TCB pointer is 32 (0x20). When actually accessing the TLS variable, first get the address of the TCB pointer, add the relative offset, and you can get the address of the TLS variable, and then access the TLS variable.

[0072] For another example, the address of the TCB pointer of thread 1 is 0x40020. If TLS variable 1 needs to be accessed, the offset of TLS variable 1 is calculated to be 0–0x20=-0x20, and the address of TLS variable 1 can be calculated to be 0x40020-0x20=0x40000.

[0073] In an exemplary embodiment, Figure 6 is a schematic diagram of another optional data processing method according to an embodiment of the present application, such as Figure 6 As shown, whether the access mode of the target thread local storage variable is the local executable mode may be determined by, but is not limited to, the following methods:

[0074] S602, start;

[0075] S604, parse the executable file in ELF format to obtain symbol information, and determine whether the type of the symbol information is STT_TLS. If the variable identifier type is STT_TLS, it indicates that the variable identifier is a TLS variable (the above-mentioned target thread local storage variable);

[0076] S606, determine whether the symbol information indicates a local storage variable of the target thread, and search the relocation information for a variable identifier with the same name according to the variable identifier name. If not, execute S608; if so, execute S610;

[0077] S608, determining that the target thread local storage variable is used in the local executable mode;

[0078] S610: Determine that the target thread local storage variable is not used in the local executable mode, and end.

[0079] In yet another exemplary embodiment, Figure 7 is a schematic diagram of another optional data processing method according to an embodiment of the present application, such as Figure 7 As shown, the variable identification information of the executable file is parsed according to the ELF format. If the variable identification is STT_TLS, it indicates that the variable identification is a TLS variable (the above-mentioned target thread local storage variable). The relocation table corresponding to the executable file is searched according to the variable identification name of the TLS variable. If there is no relocation information with the same name (such as Figure 7 If a thread-local storage variable of the same name is found, it means that the local executable mode in the executable file uses the TLS variable.

[0080] For example, Figure 8 is a schematic diagram of another optional data processing method according to an embodiment of the present application, such as Figure 8 As shown, the relocation information is checked through "readelf -r executable file name". For example, after confirming that t_InSoflg is the TLS variable of the executable file process_a, enter "readelf -r process_a" to search for the TLS variable from the output relocation information. No information with the same name is found, indicating that the TLS variable t_InSoflg is used in local executable mode.

[0081] S206, when the access mode of the target thread local storage variable is the local executable mode, determining the thread local storage variable with the same name as the variable identifier in the executable file according to the variable identifier, and the target offset of the thread local storage variable with the same name;

[0082] Optionally, in an embodiment of the present application, the above-mentioned thread local storage variable with the same name refers to a variable having the same variable identifier as the above-mentioned target thread local storage variable, and the thread local storage variable with the same name is defined in the above-mentioned thread local storage variable with the same name, and the above-mentioned target offset may include but is not limited to being determined by the offset of the thread local storage variable with the same name in the thread local storage space and the offset of the last TLS variable in the thread local storage space.

[0083] Exemplarily, the starting position is 0x8e5 of the code segment, and the 16 bytes starting from 0x8e5 are (66 48 8d 3de3 06 20 00 66 66 48e8 bb fe ff ff). According to the variable identifier t_flg, it is determined that there is a thread local storage variable with the same name in the executable file. The variable identifier is also t_flg. The thread local storage variable t_flg with the same name uses the local executable mode in the executable file.

[0084] Furthermore, through the variable identifier t_flg in the ELF file format execution file (process_a), it is determined that the offset of the thread local storage variable t_flg with the same name in the thread local storage space is 8, and the offset of the last TLS variable in the thread local storage space in the entire executable file is 8 and the length is 4. It is obtained that the TLS variable is aligned according to 4 bytes. Therefore, the above target offset value is 8+4=12.

[0085] S208, modifying the assembly code corresponding to the thread local storage variable with the same name according to the target offset to obtain the target assembly code;

[0086] S210, using the target assembly code to replace the initial assembly code corresponding to the starting position, and modifying the relocation type of the target thread local storage variable to prohibit relocation, and updating and loading the dynamic link library.

[0087] Optionally, in an embodiment of the present application, the target assembly code is used to execute the functionality of the patch function.

[0088] In an exemplary embodiment, the offset 8 of the thread local storage variable with the same name minus the offset 12 of the TCB (thread block) pointer can be obtained as 8-12=-4, which is represented by the hexadecimal complement code as fc ff ff ff.

[0089] Furthermore, the target offset value is used to replace the last four bytes of the binary assembly code 64 48 8b 04 25 00 00 00 00 48 8d 80f8ff ff ff (the last four bytes f8 ff ff ff are the offset value) used in the local executable mode to generate the binary assembly code 64 48 8b 04 25 00 00 0000 48 8d 80fc ff ff ff used in the local executable mode of the TLS variable t_flg. Thus, the 16-byte LE mode uses the assembly code of the t_flg variable to replace the starting position 0x8e5 in the dynamic link library, thereby updating the dynamic link library. Then, the dynamic link library can be successfully loaded in the above target process.

[0090] Optionally, in an embodiment of the present application, the above-mentioned target assembly code and initial assembly code can implement the same or different business functions, and the present application does not limit this.

[0091] Exemplarily, taking X86-64-bit CPU as an example, the above relocation types may include but are not limited to R_X86_64_DTPMOD64, R_X86_64_DTPOFF64, R_X86_64_RELATIVE types, etc.

[0092] In an exemplary embodiment, Fig. 9 is a schematic diagram of another optional data processing method according to an embodiment of the present application, in which the relocation type in the target thread local storage variable is modified to the R_X86_64_RELATIVE type, so that the operating system does not relocate t_InSoflg, and then successfully loads the dynamic link library libhotpatchtest.so. The target thread local storage variable of the modified dynamic link library is as follows Fig. 9 shown.

[0093] In yet another exemplary embodiment, Fig.10 is a schematic diagram of another optional data processing method according to an embodiment of the present application, such as Fig.10 As shown, the patch file is dynamically loaded by the patched process in a dynamic loading manner, the patch function information implemented in the patch file is read, and the function with the same name is searched among all the functions used by the patched process according to the function name. If it is found, it is the function that needs to be patched, and the function that needs to be patched in the patched process is modified (such as Fig.10 The assembly instruction at the address entry of func A) shown in the figure is modified to jump to the address of the function with the same name implemented in the patch dynamic link library, so as to replace the patched function with the patch function and repair the function defect problem.

[0094] Exemplarily, the data processing method proposed in this application can be applied to the hot patch loading process. Fig.11 is a schematic diagram of another optional data processing method according to an embodiment of the present application, such as Fig.11 As shown, including but not limited to:

[0095] S1102, start;

[0096] S1104, determining a variable identifier of a target thread local storage variable and a starting position of a binary assembly code according to a code snippet associated with the patch function;

[0097] S1106, determine whether the target thread local storage variable uses the local executable mode in the executable file, if so, execute S1108, if not, execute S1116.

[0098] S1108, searching for a thread local storage variable with the same name as the target thread local storage variable in the executable file in the ELF file format according to the variable identifier (for example, obtaining it by using the readelf -s executable file name method), and determining the offset of the thread local storage variable with the same name in the thread local storage space;

[0099] S1110, determining the offset of the TCB (thread block) pointer according to the offset and length of the last TLS variable (thread local storage variable with the same name) in the executable file and the number of aligned bytes;

[0100] S1112, subtract the offset of the TCB pointer from the offset of the thread local storage variable with the same name to obtain the offset of the TLS variable relative to the TCB pointer (the above-mentioned target offset), use the offset value to replace the last four bytes of the binary assembly code 64 48 8b 04 25 00 00 00 00 48 8d80f8 ff ff ff for accessing the LE mode TLS variable (the last four bytes f8 ff ffff are the offset value), and generate the local executable mode assembly code of the corresponding TLS variable (the above-mentioned target assembly code);

[0101] S1114, starting from the starting position of the binary assembly code corresponding to the target thread local storage variable, the binary assembly code corresponding to the original target thread local storage variable is replaced with the 16-byte local executable mode assembly code in the dynamic link library;

[0102] S1116, end.

[0103] According to the embodiment of the present application, when the target process needs to load a dynamic link library, the variable identifier corresponding to the target thread local storage variable that the patch function needs to access and the starting position of the corresponding assembly code are determined according to the code fragment associated with the patch function, wherein the dynamic link library includes the patch function; searching whether there is target relocation information with the variable identifier in the executable file, and when the target relocation information is not found, determining that the access mode of the target thread local storage variable is the local executable mode; when the access mode of the target thread local storage variable is the local executable mode, determining in the executable file according to the variable identifier the thread with the same name having the variable identifier Local storage variables, and target offsets of thread-local storage variables with the same name; modifying the assembly code corresponding to the thread-local storage variable with the same name according to the target offset to obtain the target assembly code; using the target assembly code to replace the initial assembly code corresponding to the starting position, and modifying the relocation type of the target thread-local storage variable to prohibit relocation, updating and loading the dynamic link library, thereby releasing the relocation dependency of the target thread-local storage variable in the patch function, allowing the patch function to be successfully loaded, and further solving the technical problem of the failure of patch function loading due to the different addressing methods of thread-local storage variables in the conventional dynamic mode and the local executable mode.

[0104] As an optional solution, the above-mentioned method of determining the variable identifier corresponding to the target thread local storage variable that the patch function needs to access and the starting position of the corresponding assembly code based on the code snippet associated with the patch function includes: traversing the memory corresponding to the dynamic link library to search for the code snippet, wherein the first part of bytes of the code snippet is in a preset format, and the code snippet includes the first part of bytes; determining the variable identifier and the starting position based on the relocation table corresponding to the code snippet and the dynamic link library.

[0105] Optionally, in an embodiment of the present application, the above-mentioned relocation table refers to a data structure used to record the addresses and offsets of instructions, variables, functions, etc. that need to be relocated when the program is loaded. The above-mentioned preset format can be flexibly set and the present application does not limit this.

[0106] Exemplarily, the memory corresponding to the dynamic link library is traversed to obtain the location and storage status of each function, variable and other related data structures in the dynamic link library in the memory, and then the corresponding code segment in the memory is obtained. The code segment can be as follows: Figure 4 shown.

[0107] Further, in Figure 4In the example shown, the difference between 0x000000200fd0 and 0x000000200fd8 is 8 bytes, which is the length of the ti_module member. Therefore, the 16-byte continuous space starting from the address 0x000000200fd0 in the GOT table is used to store the tls_index information of the t_flg variable. When implementing the assembly code, find the address 0x000000200fd0 and store it in the register rdi that passes the first function parameter. Then call the __tls_get_addr function to get the access address of the TLS variable t_flg in the current thread.

[0108] The following is a sample of the 16-byte binary assembly code that is compiled:

[0109] 8e5:66 48 8d 3d e3 06 20 00data16 lea 0x2006e3(%rip),%rdi#200fd0<_DYNAMIC+0x210>;

[0110] 8ed:66 66 48e8 bb fe ff ff data16 data16 callq 7b0<__tls_get_addr@plt>;

[0111] 8f5: ...

[0112] Among them, the first two bytes of the first line 0x66 0x48 are fixed to represent the prefix, 0x8d 0x3d 0xe3 0x06 0x200x00 implements the function of lea 0x2006e3 (%rip), %rdi, and the 4 bytes starting from the 4th byte 0xe3 0x06 0x20 0x00 are 0x2006e3 in little endian order. When calling this line, rip represents the address of the next instruction 0x8ed, 0x2006e3+0x8ed=0x200fd0, which is exactly the address of the variable t_flg storing ti_offset information in the GOT table. The first three bytes of the second line 0x66 0x66 0x48 are fixed to represent the prefix, and e8 bb fe ff ff implements the function of calling the __tls_get_addr interface.

[0113] Further, the code segment of the dynamic link library libtest.so is traversed according to the ELF format. If there is a code segment whose 0th to 1st bytes are 0x66 0x48 and whose 8th to 10th bytes are 0x66 0x66 0x48, the above first part of bytes is determined as the 0th to 1st bytes and the 8th to 10th bytes of the code segment. The above preset format indicates that the 0th to 1st bytes in the code segment are 0x66 0x48 and the 8th to 10th bytes are 0x66 0x66 0x48.

[0114] As an optional scheme, the above-mentioned determining the above-mentioned variable identifier and the above-mentioned starting position based on the relocation table corresponding to the above-mentioned code snippet and the above-mentioned dynamic link library includes: determining the first offset value between the register and the above-mentioned code snippet according to the second part of bytes of the above-mentioned code snippet, wherein the above-mentioned code snippet includes the above-mentioned second part of bytes; obtaining the address of the next operation instruction of the above-mentioned register; determining the above-mentioned variable identifier and the above-mentioned starting position in the above-mentioned relocation table according to the sum of the above-mentioned first offset value and the above-mentioned address.

[0115] Optionally, in an embodiment of the present application, the first part of bytes and the second part of bytes may be flexibly set. Specifically, they may be related to the system, hardware device, central processing unit, etc. where the process is located, and the present application does not limit this.

[0116] Exemplarily, the above little endian means that the low-order bytes of the data are arranged at the low address of the memory, and the high-order bytes are arranged at the high address of the memory, and "8e5: 66 48 8d 3d e3 06 20 00data16lea 0x2006e3 (%rip), %rdi#200fd0<_DYNAMIC+0x210>;8ed:66 66 48e8bb fe ff ff data16 data16callq 7b0<__tls_get_addr@plt>;8f5:..." is used as an example, where the 4 bytes starting from the 4th byte are 0xe3 0x06 0x20 0x00 is the second part of bytes mentioned above, that is: 0x2006e3. When this line of instructions is called, rip represents the address 0x8ed of the next instruction. The sum of 0x2006e3 and 0x8ed is 0x200fd0, which is the address of the target thread local storage variable storing ti_offset (offset) information in the GOT table. Among them, 0x2006e3 is the first offset value mentioned above, and "0x2006e3" is the above address.

[0117] Furthermore, a search is performed in the relocation table of type R_X86_64_DTPMOD64 to determine whether the sum of the first offset value and the address (0x200fd0) exists. If the offset field value (0x200fd0) is consistent with the value of a TLS variable in the relocation table (0x200fd0 of t_flg), it can be determined that the variable identifier is t_flg and the starting position is 0x8e5.

[0118] As an optional solution, the above-mentioned searching whether there is target relocation information with the above-mentioned variable identifier in the executable file, and determining that the access mode of the above-mentioned target thread local storage variable is the local executable mode when the above-mentioned target relocation information is not found, includes: obtaining symbol information of the above-mentioned executable file; when the above-mentioned symbol information is of a preset type, determining that the above-mentioned executable file includes the above-mentioned target thread local storage variable; searching whether there is the above-mentioned target relocation information with the above-mentioned variable identifier in the above-mentioned executable file; when the above-mentioned target relocation information is not found, determining that the access mode of the above-mentioned target thread local storage variable is the above-mentioned local executable mode.

[0119] Optionally, in an embodiment of the present application, the above-mentioned symbol information refers to the names, addresses and other related information of identifiers such as functions and variables stored in the executable file.

[0120] For example, Fig.12 is a schematic diagram of another optional data processing method according to an embodiment of the present application, such as Fig.12 As shown, assuming that there is an executable file, first obtain the symbol information corresponding to the executable file to determine whether it contains the target thread local storage variable. Assuming that a symbol named t_flg is found, which is the STT_TLS preset type, it can be determined that the executable file contains the target thread local storage variable.

[0121] Further, it is checked whether there is target relocation information with the t_flg variable identifier in the executable file. If so, it can be determined that the access mode of the target thread local storage variable is the relocation mode. If the target relocation information is not found, it can be determined that the access mode of the target thread local storage variable is the local executable mode. That is, by searching the symbol information, the relocation information and the preset type, it is possible to determine the access mode of the above-mentioned target thread local storage variable and whether the target thread local storage variable is included in the executable file.

[0122] As an optional solution, when the access mode of the target thread local storage variable is the local executable mode, determining the thread local storage variable with the same name having the variable identifier in the executable file according to the variable identifier, and the target offset of the thread local storage variable with the same name, includes: when the access mode of the target thread local storage variable is the local executable mode, determining the thread local storage variable with the same name having the variable identifier in the executable file according to the variable identifier; obtaining the second offset of the thread local storage variable with the same name in the thread local storage space and the alignment size of the thread local storage space; and determining the target offset according to the second offset and the alignment size.

[0123] As an optional solution, determining the target offset based on the second offset and the alignment size includes: determining a third offset corresponding to the last thread local storage variable in the thread local storage space; determining the sum of the third offset and the alignment size as a pointer offset; and determining the difference between the second offset and the pointer offset as the target offset.

[0124] Optionally, in an embodiment of the present application, the second offset refers to the offset position of the thread-local storage variable with the same name in the thread-local storage space, which can be understood as the offset of the thread-local storage variable with the same name relative to the starting position of the thread-local storage space; the third offset refers to the offset position of the last thread-local storage variable in the thread-local storage space, which can be understood as the offset of the last thread-local storage variable relative to the starting position of the thread-local storage space.

[0125] Optionally, in an embodiment of the present application, the alignment size of the thread-local storage space can be understood as that the starting address of the data in the thread-local storage space needs to be aligned according to a certain byte alignment rule. The alignment size may include but is not limited to the byte size of the largest data type in the storage space, so as to ensure that the data in the storage space can be stored according to the correct byte alignment rule, thereby achieving the purpose of improving the efficiency of memory access and reducing memory access time.

[0126] In an exemplary embodiment, assuming that there is a target thread local storage variable with a variable identifier of "myVar", in the local executable mode in the executable file, it is necessary to determine the thread local storage variable with the variable identifier of the same name. First, search the symbol table of the variable name "myVar" in the executable file to find the corresponding thread local storage variable with the same name. Assume that the address of the thread local storage variable with the same name corresponding to "myVar" is 0x1000, the alignment size is 8, the second offset is 100, and the third offset corresponding to the last thread local storage variable in the thread local storage space is 200.

[0127] Further, the pointer offset is calculated as 200 (third offset)+8 (alignment size)=208, and the target offset is obtained as 100 (second offset)-208 (pointer offset)=-108.

[0128] As an optional solution, the above-mentioned modifying the assembly code corresponding to the above-mentioned thread local storage variable with the same name according to the above-mentioned target offset to obtain the target assembly code includes: obtaining the assembly code corresponding to the above-mentioned thread local storage variable with the same name, wherein the assembly code corresponding to the above-mentioned thread local storage variable with the same name includes at least 4 bytes; modifying the last 4 bytes of the assembly code corresponding to the above-mentioned thread local storage variable with the same name according to the above-mentioned target offset to obtain the above-mentioned target assembly code.

[0129] In an exemplary embodiment, assuming that the assembly code corresponding to the thread local storage variable with the same name is "64 488b 04 25 00 00 00 00 48 8d 80ff ff ff ff", and the target offset is "f8 ff ff ff", the last four bytes of the assembly code are replaced by the above target offset to generate the above target assembly code, which is expressed as "64 48 8b 0425 00 00 00 00 48 8d 80f8 ff ff ff", specifically: the first 9 bytes "64 48 8b 04 25 00 00 0000" indicate that the address of the TCB pointer is obtained by using the fs register to store the address, and the next 6 bytes "48 8d 80f8 ff ff ff" represent the offset value represented by the little endian complement, and the address of the TCB pointer is added to obtain the address of the specific TLS variable.

[0130] For example, if there is a TLS variable with an offset value of 4 relative to the TCB pointer, the last four bytes can be modified to obtain the above target assembly code represented as "64 48 8b 04 25 00 00 0000 48 8d 80 04 00 0000".

[0131] Exemplarily, the data processing method proposed in the present application can be applied to the process of hot patch loading implementation. Specifically, the relocation addressing method of the TLS (thread local storage) thread variable in the GD mode (conventional dynamic mode) in the dynamic link library is defined in the LE mode (local executable mode) in the executable file, thereby removing the dependency on the relocation of the TLS variable in the patch function, so that the function patch using the TLS variable is successfully loaded.

[0132] In an exemplary embodiment, under the premise that the device is not restarted by hot patching technology, the instructions of the defective function are replaced by instructions for repairing the defective function during the process running, so as to repair the defective function. The defective function refers to a function with erroneous logic running in the process, and the defective repair function can also be understood as a patch function, which means a function that repairs the erroneous logic and realizes the normal function. First, the terms appearing in the embodiments of the present application are explained:

[0133] General Dynamic (GD): TLS variables (the above-mentioned target thread-local storage variables) need to be constructed to create a separate space for each thread, and different threads access different TLS variables in different memory spaces; the most common access method for TLS variables is General Dynamic (GD), which passes two parameters, the module ID and TLS block offset, determined when the dynamic linker runs relocation, to the __tls_get_addr function, which calculates the access address of the corresponding TLS variable in the current thread. The most common application of GD mode is the use of TLS variables by functions in dynamic link libraries.

[0134] It should be noted that since LE mode does not require relocation, and GD mode addressing relies on the module ID and TLS block offset used for relocation, the TLS variables in GD mode cannot be relocated and addressed in LE mode. For example, the TLS variable t_flg in GD mode cannot be relocated and addressed in LE mode, which means that if the TLS variable t_flg is used in the patch function func_a, if func_a is compiled into a dynamic link library, the patch function func_a in the dynamic link library uses the GD mode to address the TLS variable t_flg, and t_flg is defined in the executable file, and the executable file uses the LE method compiled in a static link mode to address t_flg, resulting in t_flg having no relocation information. That is, in the related art, there is a technical problem that the TLS variable t_flg used in the patch function func_a using the GD mode to address cannot be relocated and addressed because the LE mode t_flg defined in the executable file has no relocation information, resulting in the failure of patch loading.

[0135] Specifically, the embodiments of the present application may include but are not limited to:

[0136] S1, determine the method of using TLS variable name for the function in the dynamic link library:

[0137] Traverse the code segment, according to the matching conditions: bytes 0 to 1 are 0x66 0x48, bytes 8 to 10 are 0x660x66 0x48, bytes 4 to 7 are the offset values ​​relative to rip in little endian, and after adding the rip value, determine whether it is within the range of the GOT table. If it is within the range of the GOT table, take its value and search it in the relocation table of type R_X86_64_DTPMOD64. If the Offset field value is consistent, the variable name information and the location of the binary assembly code of the TLS variable that needs to be obtained in the current code segment can be matched.

[0138] In an exemplary embodiment, taking an X86-64-bit CPU (central processing unit) as an example, the function __tls_get_addr is called with a pointer parameter pointing to an object of type tls_index, and the access address of the corresponding TLS variable in the current thread can be calculated:

[0139] extern void*__tls_get_addr(tls_index*ti);

[0140] Among them, the tls_index type is defined as follows:

[0141]

[0142] It means that when the linker is linking, the two members ti_module and ti_offset of the tls_index structure allocated to each TLS variable are stored in the GOT table (Global Offset Table), where the member ti_module is associated with the relocation type R_X86_64_DTPMOD64 of the TLS variable, and the member ti_offset is associated with the relocation type R_X86_64_DTPOFF64 of the TLS variable.

[0143] S2, determining the access method of the local executable (abbreviated as LE) mode TLS variable, which may include but is not limited to:

[0144] Through the definition of TLS variables and strict limitation of usage scenarios, for example, the use of TLS variables defined in executable files by functions compiled in static linking mode is optimized to the local executable mode (Local Executable, abbreviated as LE). This mode can only use TLS variables defined in executable files. The linker can calculate the relative offset of each TLS variable relative to the thread control block (TCB) pointer. When addressing, it directly queries the thread control block (TCB) pointer and adds this offset value to determine the address of the TLS variable for access without relocation.

[0145] In an exemplary embodiment, taking the X86-64-bit CPU compilation product as an example, the information of each TLS variable defined in the executable file can be seen through "readelf -s executable file (such as process_a)", such as Figure 7As shown, the value in the fourth column Type item is TLS, indicating that the variable is a TLS variable. The value in the eighth column Name item is the TLS variable name. The value in the third column Size item is the length in bytes occupied by the TLS variable. The value in the second column Value item is the offset of each TLS variable in the thread local storage space. For example, the offset of the TLS variable t_flg2 in the thread local storage space is 4, and the length is 4.

[0146] For example, in an X86-64-bit CPU, the fs register (a special-purpose register used to store the address of a thread control block (TCB) pointer) can be used to store the address of a TCB pointer. If a TLS variable needs to be accessed, first obtain the value of the fs register to obtain the address of the TCB pointer, then obtain the offset of the TLS variable in the thread local storage space and the offset of the TCB pointer, calculate the offset difference, and add the value of the TCB pointer to the offset difference to obtain the address of the TLS variable, thereby accessing the corresponding content of the TLS variable.

[0147] The 16-byte binary assembly code compiled to access the TLS variable t_flg2 is as follows:

[0148] 400ce2: 64 48 8b 04 25 00 00 00 00mov%fs: 0x0, %rax;

[0149] 400ceb: 48 8d 80f8 ff ff ff lea-0x8(%rax),%rax;

[0150] Among them, the first line of instruction 64 48 8b 04 25 00 00 00 00 means to obtain the TCB pointer address stored in the fs register and store it in the rax register. The offset of the t_flg2 variable in the thread local storage space is 4. The offset of the last TLS variable t_flg in the thread local storage space of the entire executable file is 8 and the length is 4. The TLS variable is aligned to 4 bytes. Therefore, the offset of the TCB pointer is 8+4=12.

[0151] Furthermore, we can calculate that the offset from the t_flg2 variable to the TCB pointer is 4-12=-8, and the instruction 48 8d 80f8 ff ff ff in the second line of the assembly code subtracts 8 from the TCB pointer address stored in the rax register (the last four bytes of the instruction f8 ff ff ff represent the value of -8 represented by the complement code), and then stores it back in the rax register to obtain the address of the t_flg2 variable, which can be used to access the t_flg2 variable.

[0152] S3, determining whether the TLS variable in LE mode is used in the executable file, may include but is not limited to:

[0153] First, parse the symbol information of the executable file according to the ELF format. If the symbol type is STT_TLS, it indicates that the symbol is a TLS variable. Search the relocation table corresponding to the executable file according to the symbol name of the TLS variable. If there is no relocation information with the same name, it means that the LE mode in the executable file uses the TLS variable.

[0154] For another example, check the relocation information through "readelf -r executable file name". For example, after confirming that t_InSoflg is the TLS variable of the executable file process_a, enter "readelf -rprocess_a" to search for the TLS variable in the output relocation information. No information with the same name is found, indicating that the TLS variable t_InSoflg is used in LE mode.

[0155] S4, since the length of the binary assembly code compiled by accessing TLS variables in GD mode and LE mode is the same as 16 bytes, the TLS variables in the dynamic link library can be switched from GD mode to LE mode, which can include but is not limited to:

[0156] S4-1, according to S2 "the method of determining the TLS variable name used by the function in the dynamic link library", obtain the variable name and the starting position of the binary assembly code;

[0157] S4-2, judging whether the TLS variable in the executable file uses the LE mode according to S3 "a method for determining whether the variable name uses the LE mode in the TLS variable in the executable file";

[0158] S4-3, if the TLS variable does not use LE mode in the executable file, it means that there is relocation information in the dynamic link library and there is no need to switch to LE mode;

[0159] S4-4, if it is LE mode, search for a TLS variable with the same name in the executable file in the ELF file format according to the variable name (for example, obtain it using the "readelf -s executable file name method" instruction), and determine the offset of the TLS variable in the thread local storage space;

[0160] S4-5, determine the offset of the TCB pointer based on the offset and length of the last TLS variable and the number of aligned bytes;

[0161] S4-6, subtract the offset of the TCB pointer from the offset of the TLS variable to get the target offset of the TLS variable relative to the TCB pointer. The target offset value replaces the last four bytes of the binary assembly code 64 48 8b 04 25 00 0000 00 48 8d 80f8 ff ff ff for accessing the TLS variable in LE mode (the last four bytes f8 ff ff ff are the offset value), and generates the corresponding binary assembly code of the LE mode of the TLS variable;

[0162] S4-7, replace the starting position of the binary assembly code obtained from the 16-byte LE mode assembly code of "the method for determining the function using the TLS variable name in the dynamic link library" to achieve the purpose of changing the GD mode using the TLS variable in the dynamic library to the LE mode using the TLS variable.

[0163] Exemplarily, according to the “method for determining the TLS variable name used by a function in a dynamic link library”, the 16 bytes (66 48 8d 3d e3 0620 00 66 66 48e8 bb feff ff) starting from the code segment 0x8e5 in the dynamic link library libtest.so are the TLS variable t_flg used in the GD mode. According to the variable name t_flg, the “method for determining whether the TLS variable in the executable file uses the LE mode” is used to determine that the variable t_flg uses the LE mode in the executable file. Through the variable name t_flg in the ELF file format executable file (process_a), it is determined that the offset of the t_flg variable in the thread local storage space is 8. Furthermore, the offset of the last TLS variable t_flg in the thread local storage space in the entire executable file is 8, and the length is 4. It is obtained that the TLS variable is aligned according to 4 bytes. Therefore, the offset of the TCB pointer is 8+4=12.

[0164] Furthermore, the offset 8 of the TLS variable t_flg minus the offset 12 of the TCB pointer can be used to obtain the target offset value of the TLS variable t_flg relative to the TCB pointer, which is 8-12=-4, and the hexadecimal complement is fc ff ff ff. The target offset value is used to replace the last four bytes of the binary assembly code 64 48 8b 04 25 00 00 00 00 48 8d 80f8ff ff ff for LE mode TLS variable access (the last four bytes f8 ff ff ff are the offset value), and the binary assembly code 64 48 8b 04 25 00 00 00 00 48 8d 80fc ff ff used in LE mode of the TLS variable t_flg is generated. ff, replace the 16-byte assembly code of the LE mode using the t_flg variable starting from the code segment 0x8e5 in libtest.so, and you can change the GD mode using the t_flg variable in the dynamic link library libtest.so to the LE mode using the t_flg variable.

[0165] In an exemplary embodiment, the steps of creating a patch file by the data processing method proposed in this application may include but are not limited to:

[0166] S1, a patch function (a function for repairing a defect) is compiled into a dynamic link library in a manner of a dynamic link library with the same name as the patched function (defective function).

[0167] S2, according to the above S4 "Method for switching TLS variables in dynamic link library from GD mode to LE mode", the TLS variables used in the code segment of the function in the dynamic link library are switched from GD mode to LE mode;

[0168] S3, the TLS variables in the dynamic link library are switched from GD mode to LE mode, and the R_X86_64_DTPMOD64 and R_X86_64_DTPOFF64 types in the relocation information are changed to R_X86_64_RELATIVE types to indicate that the operating system does not need to relocate the TLS variables. Otherwise, the operating system will still search according to the relocation type, resulting in failure to load the dynamic link library.

[0169] For example, after modifying the TLS variable t_InSoflg in libhotpatchtest.so (dynamic link library) from GD mode to LE mode, the relocation information is obtained through the instruction "readelf -r libhotpatchtest.so". In the relocation information, the type of t_InSoflg is still R_X86_64_DTPMOD64 and R_X86_64_DTPOFF64. After dynamically loading the libhotpatchtest.so, the operating system still searches for the t_InSoflg variable according to the relocation type, resulting in a loading failure. Therefore, the relocation type in t_InSoflg is modified to R_X86_64_RELATIVE type, so that the operating system will not relocate t_InSoflg, and then successfully load the dynamic link library libhotpatchtest.so. The modified relocation information of the dynamic link library is as follows: Fig. 9 shown.

[0170] Optionally, in the embodiments of the present application, it may include but is not limited to:

[0171] S1, the patch function is compiled into a dynamic link library in the form of a dynamic link library with the same name as the patched function, and the code segment of the patch file in the form of a dynamic link library is traversed in the ELF format. According to the matching conditions: the 0th to 1st bytes are 0x66 0x48, the 8th to 10th bytes are 0x66 0x66 0x48, and the 4th to 7th bytes are the offset value of the little endian rip plus the rip value within the range of the GOT table, and its value is searched in the relocation table of the R_X86_64_DTPMOD64 type. If the Offset field value is consistent, the variable name and the location of the binary assembly code of the TLS variable that needs to be obtained in the current code segment can be matched to determine, and the symbol information is searched in the ELF format executable file according to the variable name to see if it is STT_TLS. If so, the relocation information is searched to see if there is a variable with the same name. Otherwise, it means that the variable is used in LE mode in the executable file, and the TLS variable needs to be switched from GD mode to LE mode in the dynamic link state library;

[0172] S2, according to the TLS variable name that needs to be switched, search for the TLS variable with the same name in the executable file in the ELF file format, obtain the offset of the TLS variable in the thread local storage space, determine the offset of the TCB pointer according to the offset and length of the last TLS variable in the executable file and the number of aligned bytes, subtract the offset of the TCB pointer from the offset of the TLS variable to obtain the offset of the TLS variable relative to the TCB pointer, and replace the last four bytes of the binary assembly code 64 48 8b0425 00 00 00 00 48 8d 80f8 ff ff ff of the LE mode TLS variable access with its value, generate the corresponding LE mode binary assembly code of the TLS variable, replace the 16-byte LE mode assembly code from the starting position of the GD mode binary assembly code, and complete the switching of the TLS variable from the GD mode to the LE mode in the dynamic link state library;

[0173] S3, when the GD mode in the dynamic link library is successfully switched to the TLS variable in the LE mode, the relocation type of the TLS variable in the relocation information is changed from R_X86_64_DTPMOD64 and R_X86_64_DTPOFF64 to R_X86_64_RELATIVE, and the patch file is made. Finally, the patch file is dynamically loaded by the patched process in a dynamic loading manner, and the patch function information implemented in the patch file is read. According to the function name, the function with the same name is searched in all functions used by the patched process. If it is found, it is the function that needs to be patched. The assembly instruction at the function address entry of the function to be patched in the patched process is modified, and the assembly instruction content is modified to jump to the address of the function with the same name implemented in the patch dynamic link library, thereby realizing the relocation addressing method of the TLS thread variable in the GD mode in the dynamic link library and the TLS variable in the LE mode defined in the executable file.

[0174] It is understandable that in the specific implementation of this application, related data such as user information is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0175] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0176] According to another aspect of the embodiment of the present application, a data processing device for implementing the above-mentioned data processing method is also provided. Fig.13 As shown, the device comprises:

[0177] A determination module 1302 is used to determine, when the target process needs to load a dynamic link library, a variable identifier corresponding to a target thread local storage variable that the patch function needs to access and a starting position of a corresponding assembly code according to a code fragment associated with the patch function, wherein the dynamic link library includes the patch function;

[0178] A search module 1304 is used to search whether there is target relocation information with a variable identifier in the executable file, and if the target relocation information is not found, determine that the access mode of the target thread local storage variable is a local executable mode;

[0179] An execution module 1306 is used to determine, in the executable file, a thread local storage variable with the same name as the variable identifier and a target offset of the thread local storage variable with the same name according to the variable identifier when the access mode of the target thread local storage variable is the local executable mode;

[0180] A modification module 1308, used to modify the assembly code corresponding to the thread local storage variable with the same name according to the target offset to obtain the target assembly code;

[0181] The replacement module 1310 is used to replace the initial assembly code corresponding to the starting position with the target assembly code, modify the relocation type of the target thread local storage variable to prohibit relocation, and update and load the dynamic link library.

[0182] As an optional solution, the device is used to determine the variable identifier corresponding to the target thread local storage variable that the patch function needs to access and the starting position of the corresponding assembly code based on the code snippet associated with the patch function in the following manner: traverse the memory corresponding to the dynamic link library to search for the code snippet, wherein the first part of bytes of the code snippet is in a preset format, and the code snippet includes the first part of bytes; determine the variable identifier and the starting position based on the relocation table corresponding to the code snippet and the dynamic link library.

[0183] As an optional solution, the device is used to determine the variable identifier and the starting position based on the relocation table corresponding to the code fragment and the dynamic link library in the following manner, including: determining a first offset value between the code fragment and the register based on the second part of bytes of the code fragment, wherein the code fragment includes the second part of bytes; obtaining the address of the next operation instruction of the register; and determining the variable identifier and the starting position in the relocation table based on the sum of the first offset value and the address.

[0184] As an optional solution, the device is used to search whether there is target relocation information with a variable identifier in the executable file in the following manner, and if the target relocation information is not found, determine that the access mode of the target thread local storage variable is the local executable mode: obtain symbol information of the executable file; if the symbol information is of a preset type, determine that the executable file includes the target thread local storage variable; search whether there is target relocation information with a variable identifier in the executable file; if the target relocation information is not found, determine that the access mode of the target thread local storage variable is the local executable mode.

[0185] As an optional solution, the device is used to determine, in a case where the access mode of the target thread local storage variable is the local executable mode, a thread local storage variable with the same name having a variable identifier in an executable file and a target offset of the thread local storage variable with the same name according to the variable identifier in the following manner: in a case where the access mode of the target thread local storage variable is the local executable mode, determine, in the executable file, a thread local storage variable with the same name having the variable identifier according to the variable identifier; obtain a second offset of the thread local storage variable with the same name in the thread local storage space and an alignment size of the thread local storage space; and determine the target offset according to the second offset and the alignment size.

[0186] As an optional solution, the device is used to determine the target offset according to the second offset and the alignment size in the following manner: determine the third offset corresponding to the last thread local storage variable in the thread local storage space; determine the sum of the third offset and the alignment size as the pointer offset; and determine the difference between the second offset and the pointer offset as the target offset.

[0187] As an optional solution, the device is used to modify the assembly code corresponding to the thread local storage variable with the same name according to the target offset to obtain the target assembly code: obtain the assembly code corresponding to the thread local storage variable with the same name, wherein the assembly code corresponding to the thread local storage variable with the same name includes at least 4 bytes; modify the last 4 bytes of the assembly code corresponding to the thread local storage variable with the same name according to the target offset to obtain the target assembly code.

[0188] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0189] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0190] According to one aspect of the present application, a computer program product is provided. The computer program product includes a computer program.

[0191] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0192] Fig.14 The structure block diagram of a computer system for implementing an electronic device according to an embodiment of the present application is schematically shown.

[0193] It should be noted that Fig.14 The computer system 1400 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0194] like Fig.14 As shown, the computer system 1400 includes a central processing unit 1401 (CPU), which can perform various appropriate actions and processes according to the program stored in the read-only memory 1402 (ROM) or the program loaded from the storage part 1408 to the random access memory 1403 (RAM). Various programs and data required for system operation are also stored in the random access memory 1403. The central processing unit 1401, the read-only memory 1402 and the random access memory 1403 are connected to each other through a bus 1404. An input / output interface 1405 (Input / Output interface, i.e., I / O interface) is also connected to the bus 1404.

[0195] The following components are connected to the input / output interface 1405: an input section 1406 including a keyboard, a mouse, etc.; an output section 1407 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1408 including a hard disk, etc.; and a communication section 1409 including a network interface card such as a LAN card, a modem, etc. The communication section 1409 performs communication processing via a network such as the Internet. A drive 1410 is also connected to the input / output interface 1405 as needed. A removable medium 1411, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1410 as needed so that a computer program read therefrom is installed into the storage section 1408 as needed.

[0196] In particular, according to an embodiment of the present application, the process described in each method flow chart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer readable medium, and the computer program contains a program code for executing the method shown in the flow chart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 1409, and / or installed from the removable medium 1411. When the computer program is executed by the central processor 1401, various functions defined in the system of the present application are executed.

[0197] In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 1409, and / or installed from the removable medium 1411. When the computer program is executed by the central processor 1401, various functions provided by the embodiments of the present application are performed.

[0198] According to another aspect of the embodiment of the present application, an electronic device for implementing the above data processing method is also provided. The electronic device may be Figure 1 The terminal device or server shown in the figure. This embodiment is described by taking the electronic device as a terminal device as an example. Fig.13 As shown, the electronic device includes a memory 1302 and a processor 1304. The memory 1302 stores a computer program, and the processor 1304 is configured to execute the steps in any of the above method embodiments through the computer program.

[0199] Optionally, in this embodiment, the electronic device may be located in at least one network device among a plurality of network devices of a computer network.

[0200] Optionally, in this embodiment, the above-mentioned processor can be configured to execute the methods in each embodiment of the present application through a computer program.

[0201] Alternatively, a person skilled in the art may understand that: Fig.15 The structure shown is for illustration only. Fig.15 The structure of the electronic device is not limited. Fig.15 More or fewer components (such as network interfaces, etc.) as shown in, or with Fig.15 Different configurations are shown.

[0202] Among them, the memory 1502 can be used to store software programs and modules, such as the program instructions / modules corresponding to the data processing method and device in the embodiments of the present application. The processor 1504 executes various functional applications and data processing by running the software programs and modules stored in the memory 1502, that is, realizing the above-mentioned data processing method. The memory 1502 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 1502 may further include a memory remotely located relative to the processor 1504, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Among them, the memory 1502 can be specifically, but not limited to, used to store information such as dynamic link libraries and executable files. As an example, such as Fig.15 As shown, the memory 1502 may include, but is not limited to, the determination module 1302, the search module 1304, the execution module 1306, the modification module 1308, and the replacement module 1310 in the data processing device. In addition, other module units in the data processing device may also be included but are not limited to, which will not be repeated in this example.

[0203] Optionally, the transmission device 1506 is used to receive or send data via a network. Specific examples of the above-mentioned network may include a wired network and a wireless network. In one example, the transmission device 1506 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices and routers via a network cable so as to communicate with the Internet or a local area network. In one example, the transmission device 1506 is a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0204] In addition, the electronic device further includes: a display 1508 for displaying the dynamic link library and executable files; and a connection bus 1510 for connecting various module components in the electronic device.

[0205] In other embodiments, the terminal device or server may be a node in a distributed system, wherein the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting the multiple nodes through network communication. The nodes may form a peer-to-peer network, and any form of computing device, such as a server, terminal or other electronic device, may become a node in the blockchain system by joining the peer-to-peer network.

[0206] According to one aspect of the present application, a computer-readable storage medium is provided, and a processor of an electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the data processing method provided in various optional implementations of the above-mentioned data processing aspects.

[0207] Optionally, in this embodiment, the above-mentioned computer-readable storage medium can be configured to store data for executing the methods in various embodiments of the present application.

[0208] Optionally, in this embodiment, a person of ordinary skill in the art may understand that all or part of the steps in the various methods of the above embodiments may be completed by instructing hardware related to the terminal device through a program, and the program may be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.

[0209] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0210] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for one or more electronic devices to execute all or part of the steps of the methods described in each embodiment of the present application.

[0211] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0212] In the several embodiments provided in the present application, it should be understood that the disclosed application can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0213] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0214] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0215] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A data processing method, characterized in that: include: In the case where the target process needs to load a dynamic link library, determining a variable identifier corresponding to a target thread local storage variable that the patch function needs to access and a starting position of a corresponding assembly code according to a code fragment associated with the patch function, wherein the dynamic link library includes the patch function; Searching whether there is target relocation information with the variable identifier in the executable file, and if the target relocation information is not found, determining that the access mode of the target thread local storage variable is a local executable mode; In a case where the access mode of the target thread local storage variable is the local executable mode, determining a thread local storage variable with the same name as the variable identifier in the executable file according to the variable identifier, and a target offset of the thread local storage variable with the same name; Modify the assembly code corresponding to the thread local storage variable with the same name according to the target offset to obtain the target assembly code; The target assembly code is used to replace the initial assembly code corresponding to the starting position, and the relocation type of the target thread local storage variable is modified to prohibit relocation, and the dynamic link library is updated and loaded.

2. The method according to claim 1, characterized in that: The step of determining, according to the code snippet associated with the patch function, a variable identifier corresponding to a target thread local storage variable that the patch function needs to access and a starting position of a corresponding assembly code includes: Traversing the memory corresponding to the dynamic link library to search for the code snippet, wherein the first part of bytes of the code snippet is in a preset format, and the code snippet includes the first part of bytes; The variable identifier and the starting position are determined based on the relocation table corresponding to the code fragment and the dynamic link library.

3. The method according to claim 2, characterized in that The determining the variable identifier and the starting position based on the relocation table corresponding to the code fragment and the dynamic link library includes: Determine a first offset value between the register and a second portion of bytes of the code fragment, wherein the code fragment includes the second portion of bytes; Obtaining the address of the next operation instruction of the register; The variable identifier and the starting position are determined in the relocation table according to the sum of the first offset value and the address.

4. The method according to claim 1, characterized in that: The searching whether there is target relocation information with the variable identifier in the executable file, and if the target relocation information is not found, determining that the access mode of the target thread local storage variable is a local executable mode, comprises: Obtaining symbol information of the executable file; In a case where the symbol information is of a preset type, determining that the executable file includes the target thread local storage variable; Searching in the executable file whether the target relocation information having the variable identifier exists; When the target relocation information is not found, it is determined that the access mode of the target thread local storage variable is the local executable mode.

5. The method according to claim 1, characterized in that When the access mode of the target thread local storage variable is the local executable mode, determining the thread local storage variable with the same name as the variable identifier in the executable file according to the variable identifier, and the target offset of the thread local storage variable with the same name, includes: In a case where the access mode of the target thread local storage variable is the local executable mode, determining a thread local storage variable with the same name as the variable identifier in the executable file according to the variable identifier; Obtaining a second offset of the thread local storage variable with the same name in the thread local storage space and an alignment size of the thread local storage space; The target offset is determined based on the second offset and the alignment size.

6. The method according to claim 5, characterized in that The determining the target offset according to the second offset and the alignment size comprises: Determine a third offset corresponding to the last thread local storage variable in the thread local storage space; Determine the sum of the third offset and the alignment size as a pointer offset; The difference between the second offset and the pointer offset is determined as the target offset.

7. The method according to claim 1, characterized in that The step of modifying the assembly code corresponding to the thread local storage variable with the same name according to the target offset to obtain the target assembly code includes: Obtaining the assembly code corresponding to the thread local storage variable with the same name, wherein the assembly code corresponding to the thread local storage variable with the same name includes at least 4 bytes; The last 4 bytes of the assembly code corresponding to the thread local storage variable with the same name are modified according to the target offset to obtain the target assembly code.

8. A data processing device, characterized in that: include: a determination module, for determining, when a target process needs to load a dynamic link library, a variable identifier corresponding to a target thread local storage variable that the patch function needs to access and a starting position of a corresponding assembly code according to a code fragment associated with the patch function, wherein the dynamic link library includes the patch function; A search module, used for searching whether there is target relocation information with the variable identifier in the executable file, and determining that the access mode of the target thread local storage variable is a local executable mode when the target relocation information is not found; an execution module, configured to determine, in the executable file, a thread local storage variable with the same name as the variable identifier and a target offset of the thread local storage variable with the same name according to the variable identifier, when the access mode of the target thread local storage variable is the local executable mode; A modification module, used for modifying the assembly code corresponding to the thread local storage variable with the same name according to the target offset to obtain a target assembly code; The replacement module is used to replace the initial assembly code corresponding to the starting position with the target assembly code, and to modify the relocation type of the target thread local storage variable to prohibit relocation, and to update and load the dynamic link library.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored computer program, wherein the computer program can be executed by an electronic device to perform the method described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method described in any one of claims 1 to 7 are implemented.

11. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 7 through the computer program.

Images