Hot patch injection method, hot patching method and apparatus

Abstract

This disclosure provides a hot patching injection method applied to a running target process, comprising: identifying a target thread in the target process that is in an interruptible, lock-free state; modifying a first execution environment of the target thread to a second execution environment; wherein the first execution environment is the current execution environment of the target thread, and the second execution environment is used to redirect the execution flow of the target thread to a dynamic library loading interface within the target process; and controlling the target thread to initiate the loading of a hot patching tool library through the dynamic library loading interface. This disclosure also provides a hot patching method, an electronic device, a computer-readable storage medium, and a computer program product. This disclosure enables the injection of hot patching tools without restarting the process, giving the process hot patching functionality, and thus allowing the use of hot patches to fix security vulnerabilities and faults without restarting the process.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a hot patch injection method, a hot patching method and apparatus. Background Technology

[0002] Some applications, during their initial development, did not anticipate the potential need for hot patching, or there was no such requirement at the time, and therefore did not embed hot patching tools upon release. If security vulnerabilities or faults are subsequently discovered that need fixing, but the already running processes cannot be restarted, a predicament will ensue. Summary of the Invention

[0003] This disclosure provides a hot patch injection method, a hot patching method, and an apparatus.

[0004] In a first aspect, embodiments of this disclosure provide a hot patch injection method applied to a running target process, comprising: identifying a target thread in the target process that is in an interruptible, lock-free state; modifying a first execution environment of the target thread to a second execution environment; wherein the first execution environment is the current execution environment of the target thread, and the second execution environment is used to redirect the execution flow of the target thread to a dynamic library loading interface within the target process; and controlling the target thread to start loading a hot patch tool library through the dynamic library loading interface.

[0005] Secondly, embodiments of this disclosure provide a hot patching method, comprising: responding to a hot patching instruction; invoking a hot patching tool library injected by any of the above hot patching injection methods to repair a running target process.

[0006] Thirdly, the disclosed embodiments provide an electronic device, which includes a memory and a processor; the memory stores a computer program that can be executed by the processor, and when the computer program is executed by the processor, it implements the hot patch injection method or the hot patching method described in any one of the preceding embodiments.

[0007] Fourthly, the disclosed embodiments provide a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the method for injecting a hot patch as described in any of the preceding claims, or a method for hot patching.

[0008] Fifthly, the disclosed embodiments provide a computer program product comprising a computer program that, when executed by a processor, implements the hot patch injection method or the hot patching method described in any of the preceding embodiments.

[0009] This disclosure enables the injection of hot patching tools without restarting the process, thus equipping the process with hot patching capabilities. This allows hot patches to be used to fix security vulnerabilities and faults without restarting the process. Attached Figure Description

[0010] In the accompanying drawings of the embodiments disclosed herein:

[0011] Figure 1 This is a flowchart illustrating the steps of the hot patch injection method provided in the embodiments of this disclosure;

[0012] Figure 2 A flowchart illustrating the steps of another hot patch injection method provided in this embodiment of the disclosure;

[0013] Figure 3 A flowchart illustrating the steps of another hot patch injection method provided in this embodiment of the disclosure;

[0014] Figure 4 A flowchart illustrating the steps of identifying a target thread in an interruptible, lock-free state within the target process in the hot patch injection method provided in this embodiment of the disclosure.

[0015] Figure 5 A flowchart illustrating the steps of saving and building the execution environment in the hot patch injection method provided in this embodiment of the disclosure;

[0016] Figure 6 The flowchart of the steps for controlling dynamic library loading and completing detection in the hot patch injection method provided in this embodiment of the disclosure;

[0017] Figure 7 A flowchart illustrating the steps of restoring and cleaning the execution environment in the hot patch injection method provided in this embodiment of the disclosure;

[0018] Figure 8 A flowchart illustrating the steps of a hot patch injection method provided in another embodiment of this disclosure;

[0019] Figure 9 This is a flowchart illustrating the steps of a hot patching method provided in an embodiment of the present disclosure;

[0020] Figure 10 This is a block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions of this disclosure, a hot patch injection method, hot patching method and apparatus provided by the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings.

[0022] The present disclosure will be described more fully below with reference to the accompanying drawings; however, the embodiments shown may be embodied in different forms, and the present disclosure should not be construed as limited to the embodiments set forth below. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will enable those skilled in the art to fully understand the scope of the disclosure.

[0023] The accompanying drawings of the embodiments disclosed herein are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the detailed embodiments to explain this disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the description of the detailed embodiments with reference to the accompanying drawings.

[0024] This disclosure may be described with reference to plan and / or cross-sectional views using the ideal schematic diagrams of this disclosure. Therefore, the example illustrations may be modified according to manufacturing techniques and / or tolerances.

[0025] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0026] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the disclosure. The term "and / or" as used in this disclosure includes any and all combinations of one or more of the associated enumerated entries. The singular forms "a" and "the" as used in this disclosure are also intended to include the plural forms, unless the context clearly indicates otherwise. The term "comprising" as used in this disclosure specifies the presence of the stated feature, integral, step, operation, element, and / or component, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, components, and / or groups thereof.

[0027] Unless otherwise specified, all terms used in this disclosure (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in common dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined in this disclosure. This disclosure is not limited to the embodiments shown in the accompanying drawings, which are illustrative in nature and not intended to be restrictive.

[0028] Technical Terminology Explanation

[0029] Unless otherwise specified in this disclosure, the following technical terms shall be interpreted as follows:

[0030] 1. Process

[0031] In an operating system, a process is the basic unit of program execution. It not only represents a running instance of code but also serves as the core carrier of system resource management. When a user launches an application (such as a text editor or browser), the operating system creates an independent process environment for it. This process involves operations such as allocating virtual address space (ensuring process memory isolation), initializing file descriptor tables (managing open files or network connections), and setting security contexts (such as Linux's UID / GID permission control). Each process acts like a sandbox, possessing its own dedicated view of resources. This isolation mechanism ensures stability (a single process crash will not affect other processes) and provides a foundation for multitasking.

[0032] 2. Thread

[0033] A thread is a lightweight unit of execution within a process and the smallest unit of CPU scheduling. Unlike processes, threads do not have independent resource spaces; instead, they share the code segment, heap memory, and data segment of their parent process. This makes communication and data sharing between threads more efficient. However, each thread still needs to maintain its own execution state, including an independent stack space (for storing local variables and function call chains) and register context (such as the program counter and status register), to ensure that threads can concurrently execute different code paths.

[0034] 3. The relationship between operating system, process, and thread

[0035] The operating system is the manager of processes and threads. It allocates independent virtual address spaces, file descriptors, security permissions, and other resources to each process, ensuring isolation between processes. The operating system uses a process scheduler (such as Linux's CFS or Windows' scheduler) to determine which process / thread gets a CPU time slice, enabling multitasking concurrency. Simultaneously, the operating system provides inter-process communication (IPC) mechanisms (such as pipes, shared memory, and message queues) and thread synchronization tools (such as mutexes and semaphores).

[0036] A process is the basic unit of resource allocation. Each process has its own independent memory space and system resources, and the crash of one process will not directly affect other processes (for example, a browser and a music player are two independent processes).

[0037] Threads are the basic unit of CPU scheduling. Threads share the memory and resources (code segment, heap, data segment) of the process to which they belong, but have their own independent stack and register context. Thread switching does not require switching memory space, and the overhead is much lower than process switching (for example, web servers use multiple threads to handle multiple requests at the same time).

[0038] Simply put, an operating system manages multiple processes, a process contains one or more threads, and a thread actually uses the CPU to execute instructions.

[0039] For example, an operating system can run a browser, an IDE (Integrated Development Environment), and a music player simultaneously; an IDE process may contain a UI rendering thread and a code analysis thread, and the operating system scheduler directly allocates CPU time slices to the threads.

[0040] 4. Hot Patching

[0041] Hot patching is a dynamic code fix technique that allows developers to update running program logic in real time without restarting processes or services. Its core principle is to redirect execution flow to the new fix by modifying machine instructions in the process's memory, such as replacing code segments in the target function or inserting jump instructions (like `jmp`). Hot patching is particularly important in high-availability systems, such as databases, financial trading systems, or online services, because traditional restart operations can lead to service interruptions or data loss.

[0042] 5. User-mode programs

[0043] User-mode programs are applications that run in the user mode of the operating system. They cannot directly access hardware or execute privileged instructions and must request kernel services through interfaces provided by the operating system (such as system calls). For example, browsers (Chrome / Firefox), text editors, and games are all user-mode programs.

[0044] The operating mechanism of user-mode programs includes:

[0045] (1) Process creation

[0046] Users launch programs via Shell or GUI → the operating system creates processes and allocates resources such as virtual memory and file descriptors. Program code is then loaded from disk into user-mode memory space.

[0047] (2) Execution process

[0048] The CPU executes user-mode code (such as calculations and logical judgments).

[0049] When a user-mode program executes an operation that requires access to hardware or system resources (such as sending a network request, reading or writing a file, or allocating memory), because these operations involve privileged instructions, the program cannot complete them directly in user mode. At this point, the system call mechanism comes into play, acting as a bridge between user mode and kernel mode.

[0050] (3) Resource access

[0051] All hardware access (such as graphics card rendering and printing files) is implemented through the driver interface provided by the kernel.

[0052] In some related technologies, user-mode program hot patching technology mainly has two technical routes:

[0053] Route 1: The hot patching tool is embedded as a module (dynamic library) into the program being patched. Since the hot patching tool and the program's business code are in the same process, they can directly access and modify the memory of the process being patched, resulting in high patching performance and minimal impact on the program.

[0054] Route Two: The hot patching tool exists as a standalone program. During the patching operation, the execution of each thread in the process is paused first, and then the memory of the process being patched is accessed and modified through system call interfaces. Because the hot patching operation requires frequent reading of data from the program being patched through system calls, it results in frequent switching between kernel mode and user mode, leading to poor performance. The long pause in program execution has a significant impact on performance-sensitive programs, and may cause the program to malfunction after the patching operation is completed.

[0055] Because the performance of hot patching operations is crucial to the stability of the patched processes, most hot patching tools in the industry currently adopt Technology Route 1. However, Technology Route 1 has a significant limitation: for some historically released versions of programs, because they were not designed with hot patching support in mind or there was no such requirement at the time, these historical versions do not have embedded hot patching tools. Therefore, it is impossible to hot patch existing processes running on these historical versions without restarting. An alternative is to use Technology Route 2 to support hot patching of these processes. The problem with this approach is that it requires maintaining two hot patching schemes simultaneously: using Technology Route 1 to support hot patching of newer versions of processes, and using Technology Route 2 to support hot patching of historical versions of processes. This increases operational costs and also carries the risk that hot patching Technology Route 2 may affect the normal operation of performance-sensitive processes.

[0056] Firstly, referring to Figure 1 This disclosure provides a hot patching injection method applied to a running target process, specifically targeting hot patching technology for Linux user-space software in ELF (Executable and Linkable Format) format. More specifically, it provides a technique for hot patching existing processes started from historical versions that did not originally support hot patching operations. The method includes:

[0057] Step 110: Identify the target thread in the target process that is in an interruptible, lock-free state.

[0058] The target process can be a running user-mode program, and the process associated with the user-mode program is the target process.

[0059] The target thread is a specific thread used to carry out hot patch injection operations. In this embodiment, the target thread is an interruptible, lock-free target thread. Specifically, a thread in the target process whose current execution state does not hold critical lock resources, such as file locks or memory manager locks, and whose execution flow can be safely interrupted, modified, and redirected. "Safe" means that interrupting, modifying, and redirecting the execution flow of this thread will not lead to deadlock or program crash.

[0060] In the embodiments of this disclosure, the interruptible lock-free state of the target thread can correspond to the stage when the thread is executing a "safe state function". This step searches for and determines a thread within the running target process that meets the "interruptible lock-free state" condition, ensuring the safety of subsequent operations.

[0061] Safe state functions: Because processes like `dlopen` involve opening files and allocating memory, file locks and memory manager locks are acquired. Therefore, the current thread executing `dlopen` must not hold these locks; otherwise, a deadlock will occur. If a thread is currently in a function that will never hold file locks or memory manager locks, then that function is called a safe state function, and calls to the `dlopen` function can be safely inserted.

[0062] By analyzing the source code of the standard C library in various mainstream versions, we can obtain:

[0063] poll, ppoll, sleep, nanosleep, usleep, select, waitpid

[0064] These functions are safety state functions.

[0065] Step 120: Modify the first execution environment of the target thread to a second execution environment; wherein, the first execution environment is the current execution environment of the target thread, and the second execution environment is used to redirect the execution flow of the target thread to the dynamic library loading interface inside the target process.

[0066] In one embodiment of this disclosure, the first execution environment can be the original running context state of the target thread before it is identified and interrupted, mainly including its associated register states, such as general-purpose registers, status registers, program counter PC, stack frame registers, etc.

[0067] The second execution environment can be a new runtime context temporarily constructed for the target thread to implement hot-patching toolkit injection. This environment is modified to direct the execution flow of the target thread to the dynamic library loading function within the target process.

[0068] It can be seen that the main purpose of this step is to modify the execution environment, modify the current execution environment (first execution environment) of the identified target thread, and modify the target of the modification to the preset second execution environment. This involves adjusting the register state so that the thread's program counter (PC) points to the dynamic library loading interface inside the target process.

[0069] Step 130: Control the target thread to start loading the hot patching tool library through the dynamic library loading interface.

[0070] The purpose of this step is to restore the execution of the target thread in the modified execution environment. Since its program counter (PC) has been modified, the thread's execution flow will be redirected to the dynamic library loading interface. By controlling this thread to perform the loading operation, the specified hot-patch utility library (e.g., libpatch.so) is loaded into the target process's memory space.

[0071] The dynamic library loading interface refers to a function interface provided by the operating system or standard library that allows a program to dynamically load shared libraries at runtime. Examples include the dlopen() function in Linux, the LoadLibrary() API in Windows, or the module loader call interface in a microkernel system. It is understood that this disclosure does not limit the form of the dynamic library loading interface.

[0072] A hot patching tool library is a dynamic link library file containing the core hot patching functionality code. It needs to be injected into the target process's memory address space to provide hot patching capabilities. Examples include libpatch.so in a Linux environment, as well as a Windows DLL dynamic link library or eBPF bytecode from a custom loader. It is understood that this disclosure does not limit the scope of the hot patching tool library.

[0073] It can be seen from steps 110, 120, and 130 above that:

[0074] This disclosed embodiment hijacks the control flow of a thread in a safe execution state within a target process. Through external control means (typically a debugging interface such as ptrace), the target process is paused, and a thread (interruptible and lock-free) that will not cause problems due to interruption and execution of external code is found. Then, like a debugger, the register state of this thread is directly modified, forcing it to call a dynamic library loading interface, such as the dlopen function. The call to the dlopen function occurs within the address space of the target process, thus the loaded hot-patching utility library becomes part of the target process, enabling direct access to the target process's memory and calling its internal functions, thereby gaining the ability to perform hot-patching operations.

[0075] In simple terms, this embodiment of the disclosure uses a thread of the target process that is in an interruptible and lock-free state as a carrier. By modifying the execution context of the thread, it deviates from the original execution path and instead executes the dynamic library loading function provided by the target process, thus injecting the external hot patch tool library into the target process.

[0076] Reference Figure 2 This disclosure provides a hot patch injection method applied to a running target process, comprising:

[0077] Step 210: Identify the target thread in the target process that is in an interruptible, lock-free state;

[0078] Step 220: Modify the first execution environment of the target thread to a second execution environment; wherein, the first execution environment is the current execution environment of the target thread, and the second execution environment is used to redirect the execution flow of the target thread to the dynamic library loading interface inside the target process;

[0079] Step 230: Control the target thread to start loading the hot patching tool library through the dynamic library loading interface;

[0080] Step 240: In response to the hot patching tool library being successfully loaded into the memory address space of the target process, return to the preset trap address;

[0081] Step 250: After capturing the exception triggered by accessing the trap address, instruct the hot patching tool library to complete loading.

[0082] It can be seen that the difference between this embodiment and the previous embodiment lies in the addition of steps 240 and 250. Since steps 210 to 230 correspond to steps 110 to 130 in the previous embodiment, they will not be repeated here; relevant details can be compared with each other, referring to the foregoing description. Steps 240 and 250 will be further explained below.

[0083] Based on steps 210 to 230, this embodiment adds a step of reliably determining the completion status of the dynamic library loading operation.

[0084] In modifying the second execution environment of the target thread, not only is an interface pointing to the hot patching tool library calling function set, but after the hot patching tool library is successfully loaded into the memory address space of the target process, the return address is set to a preset "trap address". The trap address is a pre-set memory address that is designed to trigger an operating system-level exception or signal when accessed, such as an invalid memory address or an address containing illegal instructions.

[0085] In other words, after the target thread finishes executing the hot patching utility library call function, it will attempt to return to this trap address. Because the trap address is designed to cause an exception, the external control program can catch this exception. Catching the exception triggered by accessing this trap address means that the target thread has finished executing the hot patching utility library call function, thus reliably indicating that the loading process of the hot patching utility library has been completed.

[0086] As can be seen, this embodiment utilizes function calling conventions and exception handling mechanisms: in a normal function call, the caller pushes the return address onto the stack or saves it in a specific register, and after the called function completes execution, it jumps back to that return address to continue execution. This embodiment intentionally sets the "return address" to an illegal trap address before the hot patching tool library calls the function. When the hot patching tool library attempts to return after the function call, it accesses this trap address, triggering an exception that can be caught externally. By waiting for and catching this specific exception, the external program can accurately know when the hot patching tool library has finished loading and executing.

[0087] Clearly, steps 240 and 250 solve the problem of how to reliably determine whether a function injected and executed in another process context has completed, avoiding potential race conditions and errors caused by polling or other uncertain methods. A reliable load completion indication is a prerequisite for restoring the original state of the target thread and releasing control, ensuring the stability of the entire injection process.

[0088] Reference Figure 3 , Figure 3 This disclosure provides a hot patch injection method applied to a running target process, comprising:

[0089] Step 310: Identify the target thread in the target process that is in an interruptible, lock-free state;

[0090] Step 315: Save the first execution environment;

[0091] Step 320: Modify the first execution environment of the target thread to the second execution environment; wherein, the first execution environment is the current execution environment of the target thread, and the second execution environment is used to redirect the execution flow of the target thread to the dynamic library loading interface inside the target process;

[0092] Step 330: Control the target thread to start loading the hot patching tool library through the dynamic library loading interface;

[0093] Step 340: In response to the hot patching tool library being successfully loaded into the memory address space of the target process, return to the preset trap address;

[0094] Step 350: After capturing the exception triggered by accessing the trap address, instruct the hot patching tool library to complete loading;

[0095] Step 355: Switch the second execution environment of the target thread to the first execution environment, so that the execution flow of the target thread returns to the execution environment before the modification, and release the control connection of the target thread.

[0096] In this embodiment, steps 310 to 330 correspond to steps 110 to 130 in the previous embodiment, so they will not be repeated here. Relevant parts can be compared with each other and referred to the above description.

[0097] In this embodiment, steps 340 to 350 correspond to steps 240 to 250 in the previous embodiment, so they will not be repeated here. Relevant parts can be compared with each other and referred to the above description.

[0098] It can be seen that this embodiment adds operations corresponding to steps 315 and 355. These two steps will be further explained below.

[0099] After performing step 310 in this embodiment, that is, after identifying the target thread in the target process that is in an interruptible and lock-free state, the operation of saving the first execution environment is also included. To be precise, before modifying the execution environment of the target thread, the current complete register state of the thread is read and stored, including general-purpose registers, status registers, PC, stack frame registers, etc.

[0100] Furthermore, after step 350 is executed, i.e., after the operation instructing the hot patching tool library to complete loading is completed, step 355 is also included: switching the second execution environment of the target thread to the first execution environment, causing the execution flow of the target thread to return to the execution environment before modification, and releasing the control connection of the target process. In other words, after the hot patching tool library is loaded, the current register state of the target thread is restored to the previously saved state of the first execution environment, and control over the target process is released, allowing the target process and its threads to resume normal and autonomous operation.

[0101] This embodiment of the disclosure, by adding steps 315 and 355, ensures that the interference of the hot patch injection operation on the target thread is temporary and recoverable. By saving the original state of the thread before the operation and fully restoring it after the operation is successful, the target thread can seamlessly return from the injection operation as if it had never been interrupted, continuing to execute its original business logic from the point of interruption. This is like first "freezing" the thread, letting it perform a special task (loading a library), and then "unfreezing" it and sending it back to its original position after the task is completed; releasing the control connection returns control to the target process, ends the debugging or control state, and restores its normal operating performance and behavior. This embodiment improves the security, stability, and non-intrusiveness of the hot patch injection process, ensuring smooth and imperceptible hot patching.

[0102] In one embodiment of this disclosure, prior to identifying the target thread in the target process that is in an interruptible, lock-free state, such as in step 110, step 210, or step 310, a system-level process control connection with the target process is further included.

[0103] More specifically, a system-level process control connection is a control relationship established between the external control program and the target process using low-level mechanisms provided by the operating system. This connection grants the external control program the ability to perform deep operations on the target process. These deep operation capabilities include: suspending the execution of all threads within the target process, granting the target process read / write permissions to its memory / registers, and intercepting the process's system-level calls.

[0104] For example, based on Linux, a process control connection with the process is established through the ptrace interface;

[0105] For example, based on Windows, a process control connection with the process is established through the DebugActiveProcess interface;

[0106] For example, based on embedded systems, a process control connection with the process is established through the Custom Debug API interface.

[0107] Specifically, pausing the execution of all threads within the target process involves using a system-level control connection to temporarily halt the execution of the current instruction stream by all threads within the target process. This is done to check thread states and modify the environment in a relatively static state.

[0108] Granting read / write permissions to the target process's memory / registers allows for the acquisition of read and modify capabilities within the target process's address space and the CPU register contents of its individual threads via a system-level control connection. This forms the basis for operations such as modifying the execution environment and saving / restoring state.

[0109] The interception of system-level calls by the process involves using a system-level control connection to enable system calls initiated by the target process to be captured and processed by an external control program, rather than being directly submitted to the operating system kernel.

[0110] It is understood that the embodiments disclosed herein utilize the low-level capabilities provided by the operating system for debugging and monitoring purposes. By establishing a system-level control connection, the external program (hot patch injection tool) becomes the "tracer" of the target process, gaining powerful control: it can pause all threads, ensuring that the state of the target process is relatively fixed when checking thread states and modifying the environment, thereby avoiding race conditions; read and write permissions to memory and registers are direct means to achieve operations such as "saving the first execution environment", "modifying the second execution environment", and reading the return value of hot patch call functions; establishing this control connection lays the technical foundation for subsequent fine-grained, low-level operations within the target process, and is the first step in realizing a general method of "safely and reliably inserting function calls in the context of the patched process", thus enabling successful injection of the hot patch tool library.

[0111] Reference Figure 4 , Figure 4 This invention discloses a method for injecting hot patches, which includes a flowchart illustrating the process of identifying a target thread in an interruptible, lock-free state within the target process.

[0112] After establishing a system-level process control connection and pausing all threads of the target process, it is necessary to safely select a thread for the injection operation. This embodiment uses a method based on the thread's current execution position (PC) and a preset safe interval. Specifically, it includes the following steps:

[0113] Step 410: Confirm that all threads included in the target process are paused.

[0114] This is a prerequisite for accurately obtaining thread states (such as PC values) subsequently. After the steps in the foregoing embodiments successfully establish a system-level process control connection with the target process, for example, after the ptrace(PTRACE_ATTACH,...) operation succeeds, all threads of the target process are typically automatically paused. This step in the embodiments of this disclosure is an explicit confirmation of this state.

[0115] In practical implementation, the state of each thread can be checked by reading the State field of the state file to determine if it is in a paused state. Although PTRACE_ATTACH typically guarantees a pause, explicit checking increases robustness and ensures that stable register and memory states are obtained. This step further ensures that the execution flow of the target process is frozen during thread state checks, avoiding state judgment errors caused by race conditions.

[0116] Step 420: Scan the program execution point of the current execution flow of each thread;

[0117] This step aims to obtain the memory address of the instruction being executed by each thread in the target process at the moment it is paused. This address is the thread's program counter (PC) value.

[0118] For each thread of the target process, a system-level process control interface, such as calling ptrace in Linux, is used to read the register set of that thread. From the read register structure regs, the register value corresponding to the program counter (PC) is extracted. Of course, the PC register name is different for different processor architectures, and the reading process will differ, but this disclosure does not limit this.

[0119] This step provides accurate information for determining the current execution position of each thread, providing a basis for subsequent safety assessments.

[0120] Step 430: Poll the program execution point of each thread. If the program execution point of the currently polled thread is within a safe range, confirm that the currently polled thread is the target thread. The safe range is the memory address range corresponding to the interruptible lock-free execution flow.

[0121] In one embodiment of this disclosure, the step may include the following steps:

[0122] (1) Function to query security status

[0123] First, it is necessary to determine the safe zone of the target process.

[0124] For example, a safe interval can be determined by querying a safe state function in the target process; and by determining the safe interval of the target process based on the starting address and size of the safe state function.

[0125] This step is used to determine which specific address ranges in the target process's memory space are considered "safe," meaning that when a thread executes to these addresses, it is believed that it will not hold critical locks that conflict with resources (such as file locks and memory allocation locks) required for dynamic library loading (such as dlopen) operations.

[0126] By parsing the symbol tables of the dynamic libraries and executables already loaded in the target process, or by utilizing debugging information, the loading addresses and corresponding code sizes of a predefined set of "safe state functions" in the target process's virtual address space can be found.

[0127] The security state functions are determined based on analysis and experience of the behavior of common library functions (such as wait functions in the standard C library), which typically release or do not hold critical locks during execution. Examples of security state functions include, but are not limited to, poll, ppoll, sleep, nanosleep, usleep, select, and waitpid. Other functions can be flexibly added through configuration files. If a configured security function is not found in the target process, the corresponding security interval is ignored, or the injection attempt is terminated based on a strategy.

[0128] (2) Determine the safe zone

[0129] The code segment address ranges (from the starting address to the starting address + size) of all the retrieved safe state functions are collected to form one or more non-contiguous memory address ranges. The sum of these ranges constitutes the "safe range" described in this embodiment.

[0130] Determining the safe zone of the target process provides a clear and verifiable range definition for judging whether a thread is in an interruptible, lock-free state, and is an important step in implementing secure injection.

[0131] (3) Poll each thread and identify the target thread.

[0132] This step checks the PC value of each thread obtained in step 420 one by one to determine whether the PC value of any thread falls within any address range of the safe interval determined above (3).

[0133] More specifically, iterate through all thread IDs of the target process. For each thread, obtain its PC value and compare it with the safe range. The safe range may consist of multiple non-contiguous address ranges; check if the PC value falls within any of these ranges. If the thread's PC value falls within any address range of the safe range, then the thread is identified as the "target thread" for this injection operation. Typically, the first thread that meets the criteria is selected as the target thread. Once the target thread is determined, the polling can be stopped, and subsequent steps can be performed.

[0134] It is understandable that this allows for the quick and accurate identification of threads that are currently in a safe state and eligible for injection operations, thus avoiding operations on threads that are not suitable for interruption.

[0135] Two points need to be added:

[0136] First, when the current program execution point of all threads is outside the safe zone, resume the execution of each thread in the target process; and after waiting for an agreed time interval, re-execute the operation of the target thread in the target process that is in an interruptible and lock-free state.

[0137] In other words, this disclosure embodiment includes a retry mechanism. For example, if the target thread is not found, a system-level process control interface is invoked, for example, in a Linux environment:

[0138] Call ptrace(PTRACE_CONT,target_pid,0,0) or ptrace(PTRACE_CONT,-1,0,0)

[0139] Resume execution of all threads in the target process, depending on the method and scope of the attach.

[0140] Then, the external injection tool pauses its own execution for a preset "agreed time interval" (e.g., tens to hundreds of milliseconds to avoid missing the brief function execution moment).

[0141] After the waiting time ends, return to step 410 (if you detached before, you need to reattach) or step 420 (if you keep attaching and pause all threads), pause the threads again, scan the PC, and repeat the above process.

[0142] Second, when the current program execution point of all threads is outside the safe zone, the execution of each thread in the target process is resumed; and after waiting for an agreed time interval, the operation of the target thread in the target process that is in an interruptible and lock-free state is re-executed.

[0143] In other words, this disclosed embodiment includes a failure exit mechanism, specifically setting a maximum allowed number of retries, a "preset threshold." Each retrieval accumulates the number of attempts. If, after the accumulated number of attempts reaches or exceeds the preset threshold, the target thread within the safe zone is still not identified, the injection attempt is deemed a failure. At this point, it is necessary to release the control connection to the target process, for example, by calling:

[0144] ptrace(PTRACE_DETACH, target_pid) or ptrace(PTRACE_CONT, target_pid, 0, 0) detach after recovery.

[0145] It then returns a failure result to the caller.

[0146] The above operations indicate that if, after traversing all threads, no thread's program counter (PC) is found to be within the safe zone, it means that the current moment is not suitable for injection. In this case, the target process cannot be paused indefinitely; measures need to be taken to allow the target process to continue running for a period of time, hoping that the thread state will change and enter the safe zone. Simultaneously, an exit mechanism needs to be set to prevent infinite waiting.

[0147] The retry and failure exit mechanisms described above strike a balance between security and availability. They ensure injection only at safe times while avoiding disruption to normal business operations caused by prolonged pauses in the target process. Robust retry and timeout (threshold exceeding) exit mechanisms enhance the method's practicality.

[0148] Through the above steps, this embodiment achieves the ability to safely and accurately identify target threads suitable for hot patching tool library injection operations in complex multi-threaded environments by checking whether the program execution point of a thread is located within a safe interval composed of safe state functions.

[0149] The following is a further explanation of the saving of the first execution environment and the construction of the second execution environment in a hot patch injection method according to an embodiment of the present disclosure.

[0150] Reference Figure 5 , Figure 5 This is a flowchart illustrating the steps involved in saving and building the execution environment in this embodiment of the disclosure, including the following steps:

[0151] Step 510, save the first execution environment

[0152] As described above, after identifying a safe target thread in an interruptible, lock-free state, it is necessary to prepare for the execution of a dynamic library loading interface (such as dlopen) call within the thread's context (i.e., utilizing its current process space and partial state). This primarily involves saving the first execution environment, as addressed in the preceding embodiments, for example, as explained in step 315. Further explanation follows.

[0153] The purpose of saving the first execution environment is to record the current state information of the target thread completely and accurately before modifying its execution state (such as register values ​​and stack contents). Thus, after the injection operation (dynamic library loading) is completed, the target thread can be restored to its original state before it was interrupted, so that it can seamlessly continue to execute its interrupted task.

[0154] As mentioned above, the first execution environment mainly consists of the set of CPU registers at the moment the target thread is suspended. These registers include, but are not limited to:

[0155] General purpose registers are used to store data or addresses.

[0156] The program counter (PC) points to the address of the next instruction to be executed.

[0157] The stack pointer register SP points to the top of the current thread's stack.

[0158] The stack frame register FP points to the base address of the current function's stack frame, as well as status registers (such as flag registers, which reflect the status of the calculation results and control the CPU operating mode, etc.).

[0159] In one embodiment, the data is saved via a system-level process control interface.

[0160] For example, calling it under Linux:

[0161] ptrace(PTRACE_GETREGS,target_thread_id,NT_PRSTATUS,®s_struct)

[0162] Read the current register state of the target thread and store these register values ​​in the memory of the external injection tool process.

[0163] It can be seen that saving the first execution environment provides the necessary data foundation to ensure that the target thread can safely and correctly restore its original execution flow after the injection operation is completed.

[0164] Step 520: Construct the second execution environment

[0165] In one embodiment of this disclosure, the second execution environment may include: a list of input parameters for functions called by the dynamic library loading interface, and the value of the program counter pointing to the execution flow of the target thread of the dynamic library loading interface. More preferably, a trap address may also be used as a parameter in the second execution environment, wherein the trap address includes: a preset illegal memory address, or a preset memory address for executing an illegal instruction.

[0166] The purpose of constructing a second execution environment is to forge a function call to a dynamic library loading interface (such as the dlopen function in the standard C library) by modifying its registers and stack contents within the context in which the target thread is suspended. This includes setting function parameters, directing the thread's execution entry point to the target function, and specifically designing a "return" mechanism that can be captured by external tools after the function execution is complete.

[0167] More specifically, in one embodiment, constructing the second execution environment may include:

[0168] Prepare function parameters: Based on the ABI (Application Binary Interface) specification of the target processor architecture, prepare the parameters to be passed to the dynamic library loading interface (such as dlopen(const char *filename, int flags)), including the path string of the hot patch utility library file to be loaded (such as libpatch.so) and the loading flags (such as RTLD_NOW|RTLD_GLOBAL). These are explained below:

[0169] (1) Store string: Write the file path string of the hot patching tool library (such as " / path / to / libpatch.so") into a writable memory area in the virtual address space of the target process. This memory can be the original writable stack memory of the target process, or a new memory area requested or mapped in the target process by an external injection tool through ptrace (for example, by modifying the memory mapping of the target process).

[0170] (2) Setting Parameter Registers / Stack: According to the ABI specification, the address of the string and the load flag are set as parameters into the corresponding registers (e.g., on x86-64, the address of the first parameter is placed in rdi, and the integer of the second parameter is placed in rsi; on AArch64, the first parameter is placed in x0, and the second parameter is placed in x1) or pushed onto the target thread's stack.

[0171] (3) Set the Program Counter (PC): Obtain the starting address of the dynamic library loading interface (such as the dlopen function) in the target process. This address can be obtained by resolving the symbol table of the target process. Modify the PC register value in the first execution environment saved by the target thread to the starting address of the dlopen function. For example, on x86-64, modify regs.rip = dlopen_addr;

[0172] (4) Setting the Return Address (Trap Address): According to the ABI specification, after a function call completes, execution typically jumps to the return address saved on the stack to continue. To trigger an externally catchable event when dlopen completes, its return address is set to a special "trap address." This trap address is a pre-defined address that, when accessed or executed, will trigger an operating system-level exception. Optional trap addresses include:

[0173] Preset illegal memory addresses: For example, address 0 (a NULL pointer) or any other address located in a reserved or unmapped region of the operating system. In many operating systems, accessing address 0 will trigger a segmentation fault (SIGSEGV).

[0174] Preset memory address for executing illegal instructions: Find or allocate a small space in the executable memory region of the target process, write a machine code that will cause the CPU to generate an illegal instruction exception (SIGILL) into it, and then set the address of this space as the trap address.

[0175] Write this trap address to the location on the target thread's stack where the function return address is stored.

[0176] A second execution environment is constructed, applying the modified register states and stack contents to the target thread. This creates a "fake" function call environment without modifying the target process's own code, allowing the target thread to execute the dynamic library loading operation as expected upon resumption of runtime. The trap address design provides external tools with a reliable signal that the call has ended without requiring active communication from the target process.

[0177] Through the above steps, the original execution environment of the target thread is saved, and a second execution environment, constructed for loading dynamic libraries, is established in the context of the target thread.

[0178] After the execution environment of the target thread has been constructed as described above, i.e., after the construction of the second execution environment has been completed, the next step is to trigger the target thread to execute a fake dynamic library loading interface call (e.g., steps 130, 230, and 330 in the aforementioned embodiments), and externally monitor its execution process and completion status (e.g., steps 340 and 350 in the aforementioned embodiments). The following will elaborate on triggering the target thread to execute the fake dynamic library loading interface call and further externally monitoring its execution process and completion status.

[0179] Reference Figure 6 , Figure 6 The flowchart illustrating the steps of controlling and completing the detection of dynamic library loading in the hot patch injection method of this disclosure embodiment includes the following steps:

[0180] Step 610: Control the target thread to load the hot patching tool library through the dynamic library loading interface.

[0181] This step aims to restore the target thread's execution. Since its PC has been modified to the starting address of the dynamic library loading interface, the thread will immediately jump to that address and begin executing functions such as dlopen after restoration.

[0182] In one embodiment, a system-level process control interface is used, for example, called under Linux:

[0183] ptrace(PTRACE_CONT,target_thread_id,0,0)) resumes execution of the target thread.

[0184] Thus, the process of injecting the hot patching tool library into the target process was officially initiated, and the designated thread in the target process began to execute the tasks arranged by the external tool.

[0185] Step 620: Wait for the dynamic library to load and complete.

[0186] More specifically, in response to the hot patching tool library being successfully loaded into the memory address space of the target process, it returns to the preset trap address. In this step, after starting step 610, the external injection tool itself enters a waiting state until the state of the tracked target thread changes, especially when it completes the injected function call and attempts to return, triggering an exception.

[0187] In this step, a blocking system call is invoked, waiting for any state change in the target thread (such as stopping, terminating, receiving a signal, etc.). When the target thread finishes executing the dynamic library loading interface (such as dlopen) and attempts to jump based on the return address on the stack, a CPU exception is triggered because the return address is set to a trap address (an illegal address or an address containing an illegal instruction). The operating system kernel catches this exception and sends a signal (e.g., SIGSEGV for segmentation fault, SIGILL for illegal instruction) to the external injection tool that is tracking it, causing the waitpid call to return and indicating that the target thread has stopped and received a signal.

[0188] As can be seen, the embodiments of this disclosure implement a mechanism for synchronization with the target thread. External tools do not need to know the internal execution time of the dlopen function; they only need to wait for the exception signal that is naturally triggered after its execution to detect the end of the call.

[0189] Step 630: Capture the exception and verify the completion status

[0190] After capturing an exception triggered by the trap address, the hot patching tool library is instructed to complete loading. More specifically, instructing the hot patching tool library to complete loading after capturing an exception triggered by the trap address includes: in response to the exception, obtaining the program counter value of the current execution point of the target thread; and if the program counter value is the same as the trap address that triggered the exception, instructing the hot patching tool library to complete loading.

[0191] In other words, after capturing the abnormal signal of the target thread, it is necessary to further verify that the abnormality is indeed caused by returning to the preset trap address, rather than other unrelated abnormalities occurring in the target process itself.

[0192] For example, in one embodiment, after waitpid returns and indicates that the target thread stopped due to a signal, it is necessary to read the current register state of the target thread again. From the read registers, the program counter (PC) value at the time the exception occurred in the target thread is extracted. This obtained PC value is then precisely compared with the previously set preset trap address. If the obtained PC value exactly matches the trap address, it can be highly certain that the exception was caused by the dlopen function attempting to return to the trap address after execution, thus determining that the dynamic library loading interface has completed execution. If the PC value does not match the trap address, it is possible that other exceptions have occurred in the target process; in this case, the injection operation may fail, and error handling is required.

[0193] This embodiment provides a reliable completion status judgment standard that eliminates the possibility of false alarms by comparing the precise execution location when the anomaly occurs with the preset trap address, thus ensuring the accuracy of the injection process control.

[0194] Step 640: Determine the success status of the injection operation.

[0195] Based on the exception verification in step 630, determine whether the hot patching tool library has been successfully loaded.

[0196] Through steps 610-640 above, the target thread was successfully controlled to execute the dynamic library loading interface. The completion status of the loading operation was reliably detected by verifying the exception triggered by the trap address and its location, and its return value was obtained, thereby determining whether the hot patch tool library was successfully injected.

[0197] After successfully confirming that the dynamic library loading interface (such as dlopen) has been executed and the hot patching tool library has been loaded, the target thread needs to be restored to its original state before it was interrupted, and the external injection tool's control over the target process needs to be removed so that it can resume normal and independent operation.

[0198] In one embodiment of this disclosure, reference is made to Figure 7 This may include the following steps:

[0199] Step 710: Restore the original execution environment of the target thread.

[0200] In this step, the second execution environment of the target thread is switched to the first execution environment, so that the execution flow of the target thread returns to the execution environment before the modification.

[0201] This step aims to reapply the original register state saved by the target thread to that thread, causing its program's execution point (PC) to return to the address before the interruption, and the stack pointer and other parameters to their original values. Thus, when the thread resumes execution, it will continue executing its original sequence of instructions from the point where it was suspended, as if the injection operation had never occurred.

[0202] In practice, the system-level process control interface is used to write the previously saved register values ​​representing the target thread's "first execution environment" back to the target thread's current register set. Obviously, this will overwrite the values ​​of PC, SP, parameter registers, etc., that were modified to build the second execution environment.

[0203] This step ensures that the target thread can smoothly and safely return to its original task. This guarantees that the hot patch injection operation has no side effects on the target process and does not disrupt its original execution logic.

[0204] Step 720: Remove control connection to the target process

[0205] The purpose of this step is to allow the external injection tool to relinquish its debugging control over the target process. The target process will then be managed and scheduled by the operating system's normal scheduler, freed from the intervention of the external tool.

[0206] In practice, the `detach` operation of the system-level process control interface can be invoked. This operation removes the tracking relationship between the external injection tool process and the target process / thread. For example, if the entire process is attached to via `PTRACE_ATTACH` and all threads are paused, and all threads need to be resumed after injection, the typical approach is to resume the target thread, detach it, and then resume the execution of other threads. After the `detach` operation returns, the target process will be completely taken over by the operating system scheduler and continue to run normally.

[0207] This step marks the successful completion of the hot patching tool library injection process and the removal of external control. The target process resumes its fully independent running state, and the hot patching tool library loaded inside will wait for the appropriate time to execute the actual patching logic (usually starting in the initialization function when the library is loaded).

[0208] Through the above steps, the target thread was successfully restored to its original state, and the external injection tool released control of the target process, completing the final work of the entire hot patching tool library injection process.

[0209] Reference Figure 8 This is a flowchart illustrating the steps of a hot patch injection method provided in another embodiment of this disclosure. The steps include:

[0210] S1: Locate the starting address of the function (target function) that the patched process needs to call.

[0211] In this embodiment, it is necessary to find the starting address of the dlopen function. If the address of the dlopen function is not found, the process jumps to step thirteen and ends.

[0212] S2: Query the starting address and size of each security state function in the patched process.

[0213] Because it's necessary to ensure the target thread is in a safe state function before inserting a call to the target function within its context, otherwise deadlocks and other problems may occur. In this embodiment, since the `dlopen` function may acquire locks, to ensure safe calls to `dlopen`, the default configured safe state functions are: `poll`, `ppoll`, `sleep`, `nanosleep`, `usleep`, `select`, and `waitpid`. Other functions can be added as safe state functions through configuration files according to business scenarios. Therefore, it's necessary to find the starting address and size of these safe state functions to subsequently determine whether a thread is in a certain safe state function. If the starting address of a safe function is not found, proceed to step thirteen, and the process ends.

[0214] S3: attach to the patched process

[0215] If the attach process fails, jump to S13 and the process ends.

[0216] S4: Pause all threads in the patched process and get the current PC of each thread.

[0217] S5: Locate the target thread that is in a certain safe state function.

[0218] Find the first thread whose current PC is in any safe state function as the target thread; if no such thread is found, resume the execution of each thread. If the maximum number of attempts has not been reached, wait for a period of time and then jump back to step four to try again. Otherwise, detach each thread and jump to step thirteen, and the process ends; otherwise, execute step six.

[0219] S6: Detach other threads and save the target thread's current register state.

[0220] It is necessary to save the current register state of the target thread so that execution of the target thread can be resumed after the inserted function has finished executing. The current register state that needs to be saved specifically includes: all general-purpose registers, all status registers, the program counter (PC), and the stack frame register.

[0221] S7: Constructing the context for executing functions

[0222] This step is crucial and requires constructing the context environment for calling the target function according to the normal function call process. Specifically, it includes the following:

[0223] (1) Extend the stack on the target thread's current stack to store the return address and parameters. For example, for the x8664 architecture, the example code is as follows:

[0224] ptrace(PTRACE_GETREGSET,pid,NT_PRSTATUS,®s);

[0225] regs.sp = regs.rsp;

[0226] regs.sp-=128;

[0227] regs.sp&=~15;

[0228] ptrace(PTRACE_POKETEXT,pid,(long)regs.sp,libname);

[0229] (2) Set the parameter list to be passed to the target function according to the ABI specification of the current processor platform. For this embodiment, it is necessary to set the parameter list to be passed to the dlopen function, including two parameters: file name and load flag. For example, for the x8664 architecture, the example code is as follows:

[0230] regs.rdi=sp+offsetof_libname;

[0231] regs.rsi=RTLD_NOW|RTLD_GLOBAL;

[0232] (3) Set the current pc to the starting address of the target function. In this embodiment, the pc is set to the starting address of the dlopen function. For example, for the x8664 architecture, the example code is as follows:

[0233] regs.rip = dlopen_addr;

[0234] ptrace(PTRACE_SETREGSET,pid,NT_PRSTATUS,®s);

[0235] (4) Set the return address to 0 so that it can be used to determine whether the called function has finished executing. For example, for the x8664 architecture, the example code is as follows:

[0236] return_addr = 0;

[0237] regs.sp-=8;

[0238] ptrace(PTRACE_POKETEXT,pid,(long)regs.sp,&return_addr);

[0239] S8: Resume execution of the target thread.

[0240] Since the current program counter (PC) of the target thread is set to the starting address of the target function, the target thread will jump to the target function to continue execution after resuming execution. In this embodiment, the target thread will start executing the dlopen function.

[0241] S9: Wait for the target thread to finish executing the target function.

[0242] The execution of the target thread was interrupted by a call to the target function. It's essential to know when the target thread finishes executing the target function in order to both detect the execution result and restore the target thread to its pre-interruption state, thus enabling its normal operation. The specific method is as follows:

[0243] Use waitpid to wait for the target thread's state change. Since step seven sets the return address to 0, the target will return to address 0 after execution and generate an exception. Therefore, it is only necessary to obtain the PC value at the time of the exception and determine whether the target has successfully completed execution based on whether it is 0. In this embodiment, if the PC is 0 when the target thread generates an exception, it indicates that the dlopen function has completed execution.

[0244] S10: Obtain the return value after the target function has finished executing.

[0245] After the target function is executed, the return value can be obtained by reading the register that stores the return value according to the ABI specification of the processor platform. In this embodiment, the return value of dlopen is obtained for subsequent judgment of the execution result.

[0246] S11: Restore the previously saved register state of the target thread.

[0247] S12: Detach the target thread and resume its execution.

[0248] Since S11 restores the register state of the target thread when it was interrupted, the target thread will continue running from the point of interruption after execution resumes.

[0249] S13: Returns the result of the entire operation.

[0250] Based on the return type of the target function and the return value obtained in S10, the system determines whether the target function execution result is correct, and the entire process ends. In this embodiment, if the return value is not empty, it indicates that the dlopen function has executed successfully, the hot patching tool dynamic library has been successfully injected into the patched process, and hot patching operations can be performed on the patched process subsequently; otherwise, it returns failure.

[0251] On the other hand, this disclosure also discloses a hot-patching method, referring to... Figure 9 The method includes:

[0252] Step 910, responding to the hot patch command from the operations and maintenance personnel;

[0253] The entire hot patching process is usually initiated by personnel responsible for system maintenance or software operation and maintenance who issue a command to apply a hot patch to a specific running process through some management interface (such as command-line tools, graphical interfaces, or automated operation and maintenance platforms).

[0254] The instruction typically includes identification information of the target process that needs to be patched (e.g., process ID or process name) and the patch file to be applied (which may contain a hot patching library and the actual patch data). The hot patching management system or utility program receives this instruction and prepares to execute subsequent steps.

[0255] Step 920: Invoke the hot patch tool library injected by the aforementioned hot patch injection method to repair the running target process.

[0256] This step aims to implement the hot patch injection method described above. A pre-compiled utility library (such as libpatch.so) containing the actual hot patching logic is injected into the specified target process, granting this capability to existing processes that did not originally support in-process hot patching. Once the hot patching utility library (such as libpatch.so) is successfully injected and loaded into the target process, the library can be used to perform actual vulnerability fixes or feature updates within the target process.

[0257] The initialization function of the loaded hot patching library (libpatch.so), or functions further called by it, will be responsible for executing the specific patch application logic. This may include:

[0258] Parsing patch data: Hot patching libraries may contain or read files containing specific patch information, which indicates which functions need to be replaced, which data needs to be modified, etc.

[0259] Locate the target function / data: Locate the entry address of the original function (such as the vulnerable function) that needs to be fixed or the address of the data that needs to be modified in the address space of the target process.

[0260] Applying patches: Modifying the execution flow or data of a target process using various in-process hot-patching techniques. For example, modifying the entry instruction of the original function to hook it into the fixed new function code provided by a hot-patching toolkit. This can be achieved by directly modifying instructions (such as writing jump instructions) or modifying the GOT / PLT table of the dynamic linker. Alternatively, it can be done by directly modifying data in the target process's memory.

[0261] The injection method for hot patching is general and supports various specific in-process hot patching implementations. For example, it can be function hook-based patching, data patching, or even more complex control flow hijacking. The core lies in the injection method's ability to execute arbitrary code within the target process; the specific patching logic is implemented by the injected hot patching utility library. If needed, the injected hot patching utility library can also include patch unloading logic, such as restoring modified function entries or data upon receiving an unload command.

[0262] As can be seen, the embodiments of this disclosure complete the repair of internal defects or the enhancement of functions without interrupting the target process's business, solve the problem that existing processes of historical versions cannot be patched online, and improve the availability and security of the system.

[0263] The embodiments disclosed herein enable online repair of running historical versions of processes that do not originally support hot patching, requiring only the maintenance of a single technical solution based on in-process hot patching to cover both new and old versions.

[0264] It should be noted that the above embodiments are merely illustrative of this disclosure and not intended to limit it. Those skilled in the art will understand that modifications or substitutions can be made to the above embodiments without departing from the principles and spirit of this application, and such modifications or substitutions should fall within the protection scope of this application. For example, the specific system calls (such as ptrace) and register names described in this application are examples based on the Linux system and a specific processor architecture. For target processes running on other operating systems or processor architectures, those skilled in the art can select or determine equivalent system calls, memory access methods, and register operations according to the corresponding system interfaces and ABI specifications to implement the technical solutions of this application. The list of security state functions is exemplary and can be added to, deleted from, or adjusted according to actual needs and the characteristics of the target process.

[0265] Thirdly, the disclosed embodiments provide an electronic device, with reference to Figure 10 It includes a memory and a processor; the memory stores a computer program that can be executed by the processor, and when the computer program is executed by the processor, it implements the hot patch injection method or the hot patching method described in any one of the preceding claims.

[0266] Fourthly, the disclosed embodiments provide a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the method for injecting a hot patch as described in any of the preceding claims, or a method for hot patching.

[0267] Fifthly, the disclosed embodiments provide a computer program product comprising a computer program that, when executed by a processor, implements the hot patch injection method or the hot patching method described in any of the preceding embodiments.

[0268] Among them, the processor is a device with data processing capabilities, including but not limited to the central processing unit (CPU); the memory is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read-write interface) is connected between the processor and the memory, enabling information exchange between the memory and the processor, including but not limited to the data bus (Bus).

[0269] Those skilled in the art will understand that all or some of the steps, systems, and devices disclosed above, as functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0270] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be executed by several physical components working together.

[0271] Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit (CPU), digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technique for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH) or other disk storage; read-only optical disc (CD-ROM), digital versatile disc (DVD) or other optical disc storage; magnetic cartridges, magnetic tapes, disk storage or other magnetic storage; and any other media that can be used to store desired information and can be accessed by a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0272] This disclosure has disclosed exemplary embodiments, and although specific terminology has been used, it is for general illustrative purposes only and should not be construed as limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A hot-patching injection method, applied to a running target process, comprising: Identify the target thread in the target process that is in an interruptible, lock-free state; The first execution environment of the target thread is modified to a second execution environment; wherein, the first execution environment is the current execution environment of the target thread, and the second execution environment is used to redirect the execution flow of the target thread to the dynamic library loading interface inside the target process; Control the target thread to start loading the hot patching tool library through the dynamic library loading interface; The identification of target threads in the target process that are in an interruptible, lock-free state includes: Confirm that all threads included in the target process are paused; Scan the program execution point of the current execution flow of each thread; The program execution point of each thread is polled, and if the program execution point of the currently polled thread is within a safe range, the currently polled thread is identified as the target thread; wherein, the safe range is the memory address range corresponding to the interruptible lock-free execution flow.

2. The method according to claim 1, wherein, After the target thread is controlled to start loading the hot patching tool library through the dynamic library loading interface, the method further includes: In response to the hot patching tool library being successfully loaded into the memory address space of the target process, the process returns to the preset trap address; After capturing the exception triggered by accessing the trap address, the hot patching tool library is instructed to complete loading.

3. The method according to claim 2, wherein, After identifying the target thread in the target process that is in an interruptible, lock-free state, the method further includes saving the first execution environment; and, The instruction indicating that the hot patching tool library has been loaded also includes: Switch the second execution environment of the target thread to the first execution environment, so that the execution flow of the target thread returns to the execution environment before the modification; Release the target thread control connection.

4. The method according to claim 1, wherein, Before identifying the target thread in the target process that is in an interruptible, lock-free state, the method further includes: Establish a system-level process control connection with the target process; The system-level control connection includes: Suspend the execution of each thread in the target process, and grant read and write permissions to the target process's memory / registers.

5. The method according to claim 1, wherein, The safe zone is confirmed in the following way: Query the security status function in the target process; Based on the starting address and size of the security state function, the security interval of the target process is determined.

6. The method according to claim 1, wherein, If the execution points of all threads are outside the safe zone, resume execution of each thread in the target process; and, After waiting for the agreed time interval, the operation of the target thread in the target process that is in an interruptible, lock-free state is re-executed.

7. The method according to claim 1, wherein, The total number of times the target thread has been identified during execution; If the number of executions exceeds a preset threshold and no target thread is identified, the process control connection is terminated.

8. The method according to claim 1, wherein, The first execution environment includes: the current state parameters of each register associated with the target thread; The second execution environment includes: The list of input parameters for the functions called by the dynamic library loading interface; and The program counter value of the execution flow of the target thread that points to the dynamic library loading interface.

9. The method according to claim 8, wherein, The second execution environment also includes the return address and / or parameters of the called function; the return address is the trap address that triggers the exception event; After controlling the target thread to load the hot patching tool library through the dynamic library loading interface, the method further includes: In response to the hot patching tool library being successfully loaded into the address space of the target process, return to the trap address; After capturing the exception triggered based on the trap address, the hot patching tool library is instructed to complete loading.

10. The method according to claim 9, wherein, The trap address includes: A default illegal memory address, or a default memory address where an illegal instruction was executed.

11. The method according to claim 10, wherein, The step of instructing the hot patching tool library to complete loading after capturing an exception triggered based on the trap address includes: In response to the exception, obtain the program counter value of the execution flow of the target thread; If the program counter value is the same as the trap address that triggered the exception, the hot patching tool library is indicated to have finished loading.

12. A method for repairing a target process using hot patching, comprising: Responding to hot patch instructions; The hot patch tool library injected according to the hot patch injection method of any one of claims 1 to 11 is invoked to repair the running target process.

13. An electronic device comprising a memory and a processor; the memory storing a computer program executable by the processor, wherein the computer program, when executed by the processor, implements the hot patch injection method of any one of claims 1 to 11, or the method of repairing a target process using a hot patch as described in claim 12.

14. A computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the method of injecting a hot patch according to any one of claims 1 to 11, or the method of repairing a target process using a hot patch according to claim 12.

15. A computer program product comprising a computer program that, when executed by a processor, implements the hot patch injection method of any one of claims 1 to 11, or the method of repairing a target process using a hot patch as described in claim 12.

Images