Hot patch implementation method and system based on program defect dynamic detection and redirection replacement

Abstract

The invention discloses a hot patch implementation method and system based on program defect dynamic detection and redirection replacement, and belongs to the technical field of computer software security. According to the method, a dynamic addressing technology for a fault code in a memory space during terminal operation is adopted, a fault code address is positioned by aggregating process memory mapping and byte code signature information, code loading is processed in combination with a memory patch fragmentation injection mechanism, so that isolation and independence of patches are realized, a patch instance in a memory state is obtained, and the service life of the patch is prolonged. A hot patch execution model based on dynamic redirection replacement is constructed, and a complete execution context is aggregated by backing up and reusing an original instruction. Compared with a traditional shutdown updating or static patch tool, the method can more comprehensively adapt to different platforms, the problems of repair failure and service interruption caused by dependence on a fixed address and a specific environment in a traditional method are solved, and the repair precision and the system availability are improved.

Description

Technical Field

[0001] This invention belongs to the field of computer software security technology, specifically relating to a hot patching method and system based on dynamic detection and redirection replacement of program defects. Background Technology

[0002] With the convergence of cloud computing, the Internet of Things (IoT), and big data technologies, information technology infrastructure is evolving into a complex mega-system comprised of massive computing devices, high-speed networks, and diverse applications—the computing network (CNN). Within this network, from cloud data centers to edge computing nodes and billions of terminal devices, the number, variety, and logical complexity of running software programs are enormous. This complexity makes software defects and security vulnerabilities unavoidable inherent risks. Traditional vulnerability remediation methods primarily rely on a shutdown update model, which involves stopping services, installing patches, and restarting services to fix defects, completely separating the remediation process from business operations. However, in real-world CNN scenarios, there is close business collaboration and data flow between nodes. The shutdown of one node can trigger a chain reaction, leading to the interruption of the entire service chain. Ignoring this service interruption effect may cause traditional remediation models to underestimate operational risks, resulting in significant economic losses and potential security problems for enterprises.

[0003] Online non-interference repair technology, as a core component of network operations and maintenance, can repair vulnerabilities without interrupting services by analyzing the runtime state of programs, thus supporting high system availability. With the development of underlying system technologies, technologies such as Dynamic Binary Instrumentation (DBI) and Runtime Code Modification (RCM) have demonstrated advantages in system maintenance and emergency response due to their powerful runtime intervention capabilities: DBI enables fine-grained monitoring and analysis of program instruction flows, while RCM can directly modify code logic in memory. Compared to traditional downtime update methods, these methods show significant advantages in ensuring high service availability.

[0004] However, existing hot patching technologies still have significant limitations. On the one hand, most hot patching tools are deeply tied to specific operating systems and CPU architectures, making them unsuitable for heterogeneous environments. For example, the Linux kernel's kpatch cannot be used on Windows servers, and patches designed for the x86 platform cannot run directly on ARM embedded devices. In heterogeneous computing and networking environments, this means that a separate patching tool and process needs to be maintained for each platform combination, the complexity and workload of which even exceed traditional methods.

[0005] On the other hand, while some technologies achieve single-point repair, they lack a unified patch description format and a centralized distribution management system, making it difficult to cope with the large-scale deployment needs of massive nodes. Furthermore, some simple memory modification methods lack protection for the integrity of the execution context, easily disrupting program logic and leading to repair failures or program crashes; their robustness fails to meet production environment requirements. In recent years, although some research has attempted to use virtualization or container technology to achieve rapid updates, this is not true hot patching; it is essentially a restart, failing to achieve zero interruption and suffering from state loss issues. These shortcomings result in poor performance of existing technologies in cross-platform compatibility, large-scale deployment, and repair reliability in computing networks, making it difficult to meet the high availability, high security, and high automation operation and maintenance requirements of actual computing network services. Summary of the Invention

[0006] In response to the problems mentioned in the background art, this invention proposes a hot patching method and system based on dynamic detection and redirection replacement of program defects, which enables online repair of software defects without stopping program execution.

[0007] Technical Solution: To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0008] A hot patching method based on dynamic detection and redirection replacement of program defects includes the following steps:

[0009] Step 1: Detect runtime defects through a dynamic monitoring mechanism: When the target program is running, its key behaviors are monitored through a dynamic monitoring mechanism, and a structured defect feature library is built to define and match program defects.

[0010] Step 2, Dynamic addressing of fault codes based on bytecode signature: When the monitored behavior matches an entry in the defect signature library, the precise address of the fault code segment is dynamically scanned and located in the memory space of the target program based on the bytecode signature provided in the library.

[0011] Step 3: Cross-platform patch code fragment injection: Based on the CPU architecture of the target node, select the corresponding pre-compiled patch binary fragment, allocate a safe memory region in the virtual address space of the target process, and inject the patch fragment into it;

[0012] Step 4, Trampoline-based lossless execution flow redirection: At the entry point of the fault code, the instructions are atomically backed up and replaced, the program execution flow is redirected to the injected patch code, and the trampoline mechanism is used to ensure that the original execution flow can be returned to without loss after the patch is completed;

[0013] Step 5: Build a distributed hot patch management and verification system: In a massive heterogeneous computing network environment, deploy a central control node and agent nodes to achieve unified distribution of patch strategies, status monitoring, and verification of repair effects.

[0014] Preferably, in step 1, the specific implementation process is as follows:

[0015] Step 1.1: During the execution of the target program, based on the dynamic monitoring mechanism, API hook technology is used to monitor the calls, memory accesses and function return values ​​of key API functions by modifying the import address table of the operating system.

[0016] Step 1.2: Construct a structured defect feature library, where each entry contains a defect ID, triggering conditions, and risk level;

[0017] Step 1.3: When the monitoring data meets any of the triggering conditions in the feature library, it is determined that a defect has been detected, and the corresponding defect ID is obtained.

[0018] Preferably, in step 2, the specific implementation process is as follows:

[0019] Step 2.1: Obtain the bytecode signature corresponding to the defect ID from the defect feature library. This signature is a sequence of N consecutive machine codes at the entry point of the fault code.

[0020] Step 2.2: Perform a sliding window scan within the code segment memory region of the target process to match bytecode signatures and determine the starting virtual address of the fault code;

[0021] Step 2.3: Calculate the precise memory address of the fault code.

[0022] Preferably, in step 3, the specific implementation process is as follows:

[0023] Step 3.1: From the patch knowledge base, select the corresponding pre-compiled patch binary fragment based on the CPU instruction set architecture of the target node;

[0024] The patch knowledge base stores native machine code versions for multiple mainstream CPU instruction set architectures in advance for the same patch logic;

[0025] Step 3.2: In the virtual address space of the target process, allocate a memory page with read, write, and execute permissions through a system call;

[0026] Step 3.3: Write the patch binary fragment into the memory page and handle the relative address relocation to ensure the independence of the patch code.

[0027] Preferably, in step 4, the specific implementation process is as follows:

[0028] Step 4.1: At the fault code entry point, atomically back up the original M-byte instruction;

[0029] Step 4.2: Construct a trampoline code snippet, the contents of which are: the backup of the original M-byte instruction, and an instruction to jump back to the subsequent position of the original process;

[0030] Step 4.3: Atomically replace the M-byte instruction at the fault code entry point with an instruction that directly jumps to the patch code entry point;

[0031] Step 4.4: After the patch code is executed, jump to the trampoline code. After the backup instruction is executed, verify whether the critical status register or memory value meets the expectations. If it does, jump back to the original process; otherwise, trigger exception handling.

[0032] Preferably, in step 5, the specific implementation process is as follows:

[0033] Step 5.1: Construct a distributed system consisting of a central control node and multiple agent nodes. The central node is responsible for maintaining and distributing the patch knowledge base, while the agent nodes are deployed on various terminals of the heterogeneous computing network.

[0034] Step 5.2: The proxy node maintains communication with the central node through a heartbeat mechanism, regularly reports the node status and the list of applied patches, and actively pulls the latest patch policy.

[0035] Step 5.3: Define key performance indicators, including average repair time, defined as the average time from the detection of a defect to the completion of repair; repair success rate, defined as the ratio of the number of successfully repaired nodes to the total number of nodes; and performance overhead, defined as the peak increment of the target program's CPU utilization during the repair period.

[0036] As a preferred option, the specific implementation process in step 5.3 is as follows:

[0037] The mean repair time is calculated as follows:

[0038] ;

[0039] Where MTTR represents the average repair time, and N represents the total number of repair events. This represents the timestamp of the i-th defect detection. This represents the timestamp when the i-th repair was completed;

[0040] Repair Success Rate (RSR) measures the proportion of defects that are successfully repaired out of a total number of repair events. Its calculation formula can be expressed as:

[0041] ;

[0042] in, Indicates the number of defect events that were successfully fixed; This represents the total number of defect events that need to be fixed.

[0043] Performance overhead (PO) is used to measure the impact of patch application or dynamic monitoring on the performance of a target system. It can be calculated by comparing key performance indicators before and after patch application, and its calculation formula can be expressed as:

[0044] ;

[0045] in, This indicates the program execution time after applying a patch or enabling monitoring mechanisms. This represents the baseline execution time when no patches are applied or monitoring mechanisms are enabled.

[0046] A hot patching system based on dynamic detection and redirection replacement of program defects, implementing the hot patching method based on dynamic detection and redirection replacement of program defects as described above, includes a dynamic monitoring module, a dynamic addressing module, a patch injection module, and an execution flow redirection module;

[0047] Dynamic monitoring module: responsible for monitoring the key behaviors of the target program during runtime through instrumentation or hooking techniques, and matching program defects based on a structured defect feature library;

[0048] Dynamic addressing module: When the monitored behavior matches an entry in the defect signature library, it is responsible for dynamically scanning and locating the precise address of the faulty code segment in the target program's memory space based on the bytecode signature provided in the library;

[0049] Patch injection module: Responsible for selecting the corresponding pre-compiled patch binary fragment based on the CPU architecture of the target node, allocating a safe memory region in the virtual address space of the target process, and injecting the patch fragment into it;

[0050] The execution flow redirection module is responsible for atomically backing up and replacing instructions at the entry point of the fault code, redirecting the program execution flow to the injected patch code, and ensuring that the original execution flow can be returned to without loss after the patch is completed through a trampoline mechanism.

[0051] Beneficial effects: Compared with the prior art, the present invention has the following advantages:

[0052] (1) This invention takes monitoring, addressing, injection and redirection as the core elements, and integrates dynamic monitoring mechanism and trampoline redirection mechanism to capture program runtime context and memory code structure at the same time, thereby solving the service interruption problem caused by traditional shutdown update mode and improving system availability.

[0053] (2) Based on a platform-independent patch description language and local adapter, this invention separates the intent and implementation of cross-platform patches and unifies them into a standardized strategy that can be interpreted and executed by heterogeneous node agents. Subsequently, through bytecode signature positioning and cross-platform binary injection, the compatibility and accuracy of patches on different CPU architectures and operating systems are ensured, thereby improving the success rate of repair.

[0054] (3) In this invention, the hot patching system is finally deployed in the agent mode on each node of the massive heterogeneous computing network. The patching strategy is uniformly distributed, the status is monitored and the effect is quantified through the central control node. The event flow of the program is connected, the repair instructions and status reports are output according to the unified standard, and the version, indicators and logs are recorded to meet the requirements of operation and maintenance management for process traceability and effect quantification. Attached Figure Description

[0055] Figure 1 This is an overall flowchart of the method of the present invention. Detailed Implementation

[0056] The present invention will be further illustrated below with reference to specific embodiments. These embodiments are implemented based on the technical solutions of the present invention, and it should be understood that these embodiments are only used to illustrate the present invention and are not intended to limit the scope of the present invention.

[0057] Example 1

[0058] like Figure 1 As shown, the hot patching method for dynamic detection and redirection replacement of program defects provided in this embodiment adopts dynamic addressing technology for fault codes in the terminal runtime memory space. It locates the fault code address by aggregating process memory mapping and bytecode signature information, and combines the memory patch fragmentation injection mechanism to handle code loading, so as to achieve the isolation and independence of the patch, obtain the memory-state patch instance, and construct a hot patch execution model based on dynamic redirection replacement. This model includes a custom trampoline mechanism, which aggregates the complete execution context by backing up and reusing the original instructions.

[0059] like Figure 1 As shown, the specific steps are as follows:

[0060] Step 1: Detect runtime defects through a dynamic monitoring mechanism: When the target program is running, its key behaviors are monitored through a dynamic monitoring mechanism, and a structured defect feature library is built to define and match program defects.

[0061] Step 1.1: During the execution of the target program, based on the dynamic monitoring mechanism, API hook technology is used to monitor the calls, memory accesses and function return values ​​of key API functions by modifying the import address table of the operating system.

[0062] Step 1.2: Construct a structured defect feature library, where each entry contains a defect ID, triggering conditions, and risk level;

[0063] Step 1.3: When the monitoring data meets any triggering condition in the feature library, it is determined that a defect has been detected, and the corresponding defect ID is obtained;

[0064] The triggering condition is a logical expression, specifically a Boolean expression in this embodiment.

[0065] For example, the `if (input_length > buffer_size) AND (source == 'network') thentrigger` is used to describe the triggering logic for defects. It means that when the length of the monitored input data (input_length) exceeds the buffer capacity (buffer_size) allocated by the program, and the input data comes from the network (source is network), the behavior is considered to meet the predefined defect triggering conditions in the feature library, thereby triggering defect detection and obtaining the corresponding defect ID.

[0066] In this embodiment, the dynamic monitoring mechanism can be implemented using binary instrumentation technology, inserting probe code at the entry points of key functions or basic blocks in the target program to collect runtime information. Specifically, the instrumentation locations are preferably key function entry points, sensitive API call points, or basic block boundaries, so as to collect runtime information related to defect determination in real time during program execution, such as input data length, buffer size, data source, and function call context.

[0067] During implementation, the target program is first subjected to binary parsing to construct its control flow graph (CFG) and identify functions or basic blocks related to the defect feature library. Then, probe instructions are inserted at selected instrumentation locations. These probes are triggered during program execution to read key variables in registers or memory and transmit the collected runtime information to the monitoring module or store it in the log buffer. Finally, the monitoring module evaluates predefined Boolean trigger conditions based on the collected data. When the conditions are met, defect determination is triggered and the corresponding defect ID is associated.

[0068] For example, its core instrumentation logic can be represented by the following pseudocode:

[0069] on_enter(function f):

[0070] input_length = read_runtime_value(INPUT_LEN)

[0071] buffer_size = read_runtime_value(BUF_SIZE)

[0072] source = read_runtime_value(INPUT_SOURCE)

[0073] if (input_length > buffer_size) and (source == NETWORK):

[0074] report_defect(defect_id);

[0075] Here, `on_enter(function f)` represents the probe inserted at the function entry point, `read_runtime_value` is used to obtain runtime state information, and `report_defect` is used to report the detection results to the defect detection module. Through this method, binary instrumentation technology can achieve fine-grained perception of runtime behavior while maintaining the original program functionality and execution flow largely unchanged, providing reliable data support for subsequent defect detection and analysis.

[0076] In this embodiment, the dynamic monitoring mechanism can also be implemented using API hook technology. This involves modifying the operating system's import address table or using debug registers to intercept calls to the target API function. The API hook implementation by modifying the target program's import address table involves the following steps: First, the executable file format of the target program is parsed to locate its import address table and identify the API function entries related to the monitoring target. Then, the addresses that originally pointed to system API functions are replaced with custom hook function addresses. When the program runs and calls the corresponding API, the control flow first enters the hook function. This hook function collects runtime information before or after calling the original API, such as function parameters, input data length, buffer pointers and their sizes, and the source of the call. Finally, the hook function transfers control to the original API function to ensure the normal execution of the program's original functions. Alternatively, the processor's debug registers or breakpoint mechanism can be used to set execution breakpoints at the entry point of the target API function. When the program executes the API, a debug exception is triggered. The monitoring module obtains the function context and parameter information during exception handling and resumes program execution after completing the monitoring logic. This method does not require direct modification of the program's memory structure and is suitable for operating environments with high stability requirements.

[0077] In this embodiment, the dynamic monitoring mechanism can also be implemented through a hardware performance monitoring unit. This unit configures the CPU's Performance Management Unit (PMU) to count specific events (such as branch prediction failures and cache misses). When the counter exceeds a threshold, defect analysis is triggered. The PMU is a hardware-level monitoring module provided by the CPU, capable of counting specific events occurring during program execution with almost no additional overhead. These events include the number of branch prediction failures, cache misses, instruction execution counts, and abnormal jump behaviors. In practice, the monitoring module first selects hardware event types related to defect behavior based on predefined monitoring strategies in the defect feature library. It then configures the CPU's PMU through the operating system or underlying interface, assigning corresponding performance counters to the selected events. Subsequently, during the target program's execution, the PMU automatically increments the event count without modifying the program instruction flow. The monitoring module periodically or at specific times reads the current value of the performance counters and compares it with a pre-set threshold. When the value of one or more counters exceeds the corresponding threshold, the program's execution behavior is considered to deviate from the normal mode, triggering the defect analysis process. The module then determines the possible defect type or defect ID based on the current execution context.

[0078] Step 2, Dynamic addressing of fault codes based on bytecode signature: When the monitored behavior matches an entry in the defect signature library, the precise address of the fault code segment is dynamically scanned and located in the memory space of the target program based on the bytecode signature provided in the library.

[0079] Step 2.1: Obtain the bytecode signature corresponding to the defect ID from the defect feature library. This signature is a sequence of N consecutive machine codes at the entry point of the fault code.

[0080] In this embodiment, the bytecode signature is an inherent feature information pre-built and stored by the defect feature library during the offline phase. Specifically, during the construction of the defect feature library, static analysis, disassembly, or dynamic debugging are performed on the target program or its corresponding function for confirmed defect types or historical defect samples to accurately determine the entry point of the faulty code segment. Subsequently, a sequence of N bytes of machine code is continuously extracted from the entry point as the bytecode signature used to identify the faulty code segment, where N is a pre-set signature length used to achieve a balance between uniqueness and matching stability. In some implementations, to improve the applicability of the signature under different operating environments or load addresses, the extracted machine code sequence can be regularized, for example, by masking bytes related to specific addresses or immediate values, retaining only opcodes and key instruction patterns. The finally generated bytecode signature is associated with the corresponding defect ID and stored in the defect feature library for scanning and matching in the target program's memory space at runtime, thereby achieving dynamic addressing of the faulty code segment.

[0081] Step 2.2: Perform a sliding window scan within the code segment memory region of the target process to match bytecode signatures and determine the starting virtual address of the fault code.

[0082] First, the base address of the executable module of the target process in memory and the start and end addresses of the code segment are obtained to limit the scanning range. Then, starting from the start address of the code segment, N consecutive bytes are extracted using a sliding window method, and compared with the corresponding bytecode signature in the defect signature library. During the matching process, environment-related bytes in the signature (such as immediate values ​​or address offsets) can be ignored to enhance the robustness of the matching. When the byte sequence in the window completely matches the signature or meets the regularized matching conditions, the start address of the current window is recorded, which means that the starting virtual address of the faulty code segment has been found. Finally, the address is returned to the dynamic monitoring module for subsequent fault analysis or defect handling.

[0083] Step 2.3: Calculate the precise memory address of the fault code;

[0084] Specifically: Address = ModuleBaseAddress + Offset.

[0085] Here, ModuleBaseAddress represents the base address in memory of the module containing the faulty code in the target process, and Offset represents the starting offset within the module's code segment when the bytecode signature matches successfully. By adding the module base address and the offset, the virtual address Address of the faulty code in the current process's address space can be obtained. This address corresponds to the entry point of the faulty code segment and can be used for subsequent dynamic analysis or defect handling.

[0086] Step 3: Cross-platform patch code fragment injection: Based on the CPU architecture of the target node, select the corresponding pre-compiled patch binary fragment, allocate a safe memory region in the virtual address space of the target process, and inject the patch fragment into it;

[0087] Step 3.1: From the patch knowledge base, select the corresponding pre-compiled patch binary fragment based on the CPU instruction set architecture (ISA) of the target node;

[0088] To address the instruction set differences across different hardware architectures (such as x86 and ARM), the patch knowledge base pre-stores native machine code versions for various mainstream CPU instruction set architectures, such as patch_x86_64.bin and patch_aarch64.bin, for the same patch logic. The agent selects one based on its own platform, thereby achieving cross-platform compatibility.

[0089] Step 3.2: In the virtual address space of the target process, allocate a memory page with read, write, and execute (RWX) permissions through system calls (such as mmap in Linux or VirtualAlloc in Windows);

[0090] Specifically, within the target process's virtual address space, a memory region with read, write, and execute (RWX) permissions can be allocated via system calls provided by the operating system. On Linux platforms, the mmap system call can be used, specifying the starting address (usually NULL to allow the kernel to choose automatically), the required size (usually aligned to the system page size, such as 4KB or 8KB), permission flags PROT_READ | PROT_WRITE | PROT_EXEC, and mapping types MAP_ANONYMOUS | MAP_PRIVATE. On Windows platforms, the VirtualAlloc function can be used, specifying the allocation size (usually an integer multiple of the system page size) and allocation type MEM_COMMIT | MEM_COMMIT. MEM_RESERVE and the protection attribute PAGE_EXECUTE_READWRITE; the allocated memory page size is generally aligned with the operating system page size to ensure the efficiency and security of memory management, usually 4KB or 8KB, but multiple contiguous pages can be requested as needed to store more data or instrumentation code; this memory page is then used to store dynamically generated probe code or temporary buffers for runtime execution or data exchange, thereby enabling dynamic monitoring and analysis of the target process while ensuring executability and security.

[0091] Step 3.3: Write the patch binary fragment into the memory page and handle the relative address relocation to ensure the independence of the patch code.

[0092] Specifically, when a patch binary fragment is copied from its original location (original base address) during compilation or generation to a newly allocated memory page, it may contain relative address references based on the original location (such as relative jump instructions, function calls, data references, etc.). Without relocation, the patch code will encounter jump errors or data access exceptions when executed at the new address. To ensure the independence of the patch code, all relative addresses need to be adjusted. The basic calculation formula is as follows:

[0093] RelocatedAddress=OriginalAddress+(NewBaseAddress-OriginalBaseAddress);

[0094] In this context, `OriginalAddress` is the target address (offset calculated from the original base address) of the relative reference in the patch binary, `OriginalBaseAddress` is the base address assumed during patch generation, `NewBaseAddress` is the starting address of the actually allocated memory page, and `RelocatedAddress` is the correct target address when executed in the new memory page. In practice, the instruction stream of the patch binary can be traversed or a relocation table can be used (if a relocation table was generated during patch compilation) to correct each instruction or data reference containing a relative address according to the above formula. This method allows the patch binary fragment to execute independently and correctly in the newly allocated memory page without relying on its original load address, thus ensuring the reliability and security of dynamic injection.

[0095] Step 4, Trampoline-based lossless execution flow redirection: At the entry point of the fault code, the instructions are atomically backed up and replaced, the program execution flow is redirected to the injected patch code, and the trampoline mechanism is used to ensure that the original execution flow can be returned to without loss after the patch is completed;

[0096] Step 4.1: At the fault code entry point, atomically back up the original M-byte instruction, where M is the byte length of the platform jump instruction;

[0097] Step 4.2: Construct a trampoline code snippet, the contents of which are: the backup of the original M-byte instruction, and an instruction to jump back to the subsequent position of the original process;

[0098] Step 4.3: Atomically replace the M-byte instruction at the fault code entry point with an instruction that directly jumps to the patch code entry point;

[0099] The specific machine code of the instruction that jumps to the patch code entry point is dynamically generated by the local adapter deployed on the target node based on the current CPU architecture. For example, it generates a JMP instruction (e.g., JMP [Patch_Entry_Address]) under the x86_64 architecture; and a B or BR instruction under the aarch64 architecture to ensure the correctness of the redirection operation on different hardware.

[0100] Step 4.4: After the patch code is executed, jump to the trampoline code. After the backup instruction is executed, verify whether the critical status register or memory value meets the expectations. If it does, jump back to the original process; otherwise, trigger exception handling.

[0101] Specifically, after the patch code finishes execution and jumps to the trampoline code, the system first restores and executes the instructions that were overridden in the original code. At the same time, it performs consistency checks on key states that are closely related to the correct execution of the program. Key states include, but are not limited to, general-purpose registers, stack pointers, instruction pointers, flag registers, and key memory units related to the patch logic. The verification method is to compare the current register value or memory content with the baseline or expected value saved before the patch execution to determine whether predefined constraints are met, such as whether the registers remain unchanged, whether the stack pointer is within a legal range, and whether the key memory data has not been illegally tampered with. If the verification result shows that the key states meet expectations, the trampoline code controls the execution flow to seamlessly jump back to the next instruction position of the original program flow to ensure the continuity of program behavior. Conversely, if an abnormal register or memory state is found, an exception handling process is triggered. Exception handling may include recording exception context information, reporting defects or exception types, rolling back the executed patch operations, terminating the current patch execution, or interrupting the execution of the target process when necessary to prevent the abnormal state from spreading further, thereby improving the security and stability of system operation.

[0102] Step 5: Construct a distributed hot patch management and verification system: In a massive heterogeneous computing network environment, deploy a central control node and agent nodes to achieve unified distribution of patch strategies, status monitoring, and verification of repair effects.

[0103] Step 5.1: Construct a distributed system consisting of a central control node and multiple agent nodes. The central node is responsible for maintaining and distributing the patch knowledge base, while the agent nodes are deployed on various terminals of the heterogeneous computing network.

[0104] Step 5.2: The proxy node maintains communication with the central node through a heartbeat mechanism, regularly reports the node status and the list of applied patches, and actively pulls the latest patch policy.

[0105] Specifically, proxy nodes periodically send heartbeat messages to the central node. These messages contain information such as the node identifier, current running status, a list of applied patches, and an optional timestamp or version number. This allows the central node to monitor the health status and patch application progress of each node in real time. The heartbeat message sending frequency can be set via the parameter `T_heartbeat`, for example, sending it every fixed number of seconds to ensure timely status updates while avoiding excessive network overhead. Upon receiving a heartbeat message, the central node can return a response indicating whether there are any new patch policies to fetch. The entire process can be abstracted into the following loop logic:

[0106] while (node_running):

[0107] wait(T_heartbeat)

[0108] heartbeat_msg = construct_heartbeat(node_id, status, applied_patches, timestamp)

[0109] send_to_central(heartbeat_msg)

[0110] response = receive_from_central(timeout)

[0111] if response.contains_new_patch:

[0112] pull_and_apply_patch(response.patch_info);

[0113] Here, `construct_heartbeat` is the heartbeat message construction function; `send_to_central` and `receive_from_central` represent network sending and receiving operations, respectively; `node_running` represents the proxy node's running identifier, used to control whether the heartbeat and patch detection loop continues to execute; `T_heartbeat` is a preset heartbeat period parameter, used to control the time interval at which the proxy node sends status update messages to the central control node; `heartbeat_msg` represents the heartbeat message data packet generated by the proxy node, used to report the current running status and patch application information to the central node; `node_id` represents the identifier information used to uniquely identify the proxy node; `status` represents the current running status information of the proxy node, used by the central node to determine the node's health; `applied_patches` represents the set of patch identifiers that the proxy node has successfully deployed; `timestamp` represents the heartbeat message generation timestamp, used to assist the central node in performing status synchronization and timing analysis; `response` represents the feedback information from the central node to the proxy node's heartbeat request; `pull_and_apply_patch` represents the operation process of the proxy node performing patch pulling and dynamic loading based on patch information; and `response.patch_info` represents the patch-related information that the central node instructs the proxy node to pull.

[0114] If no response is received from the central node within the timeout period, the proxy node can resend the heartbeat or record the communication anomaly according to the retry policy. Through this mechanism, the proxy node can maintain continuous and reliable communication with the central node, realize node status reporting and patch policy synchronization, without the need for complex mathematical calculation formulas, but can ensure the real-time performance and robustness of communication by parameterizing the heartbeat frequency, the number of timeout retries and message format.

[0115] Step 5.3: Define key performance indicators, including average repair time, defined as the average time from the detection of a defect to the completion of repair; repair success rate, defined as the ratio of the number of successfully repaired nodes to the total number of nodes; and performance overhead, defined as the peak increment of the target program's CPU utilization during the repair period.

[0116] The Mean Time To Repair (MTTR) is calculated as follows:

[0117]

[0118] Where N represents the total number of repair events, This represents the timestamp of the i-th defect detection. This represents the timestamp when the i-th repair was completed.

[0119] Repair Success Rate (RSR) measures the proportion of defects that are successfully repaired out of a total number of repair events. Its calculation formula can be expressed as:

[0120]

[0121] in, Indicates the number of defect events that were successfully fixed; This represents the total number of defect events that need to be fixed (including successes and failures).

[0122] Performance overhead (PO) measures the impact of patch application or dynamic monitoring on the performance of a target system. It is calculated by comparing key performance indicators (such as execution time, CPU utilization, and memory usage) before and after patch application. Taking execution time as an example, its calculation formula can be expressed as:

[0123]

[0124] in, This indicates the program execution time after applying a patch or enabling monitoring mechanisms. This represents the baseline execution time when no patches are applied or monitoring mechanisms are enabled.

[0125] The method of this invention is applied to massive heterogeneous computing network environments, which include terminal devices with at least two different CPU instruction set architectures (such as x86_64, aarch64).

[0126] In this embodiment, the hot patching system is a complete repair architecture formed by the collaborative work of the dynamic monitoring mechanism produced in step 1, the dynamic addressing engine in step 2, the patch injection module in step 3, and the execution flow redirector in step 4 within the proxy node. It can be described as an integrated model of monitoring, addressing, injection, and redirection. Steps 1-4 can be regarded as the core execution process of single-point repair, and step 5 is an extension of distributed management and large-scale deployment based on this.

[0127] Example 2

[0128] This embodiment also provides a hot patching system based on dynamic detection and redirection replacement of program defects, including:

[0129] The dynamic monitoring module is configured to monitor the key behaviors of the target program during runtime using instrumentation or hooking techniques, and to match program defects against a structured defect signature library.

[0130] The dynamic addressing module is configured to dynamically scan and locate the precise address of the faulty code segment in the target program's memory space based on the bytecode signature provided in the defect signature library when the monitored behavior matches an entry in the defect signature library.

[0131] The patch injection module is configured to select the corresponding pre-compiled patch binary fragment based on the CPU architecture of the target node, allocate a safe memory region in the virtual address space of the target process, and inject the patch fragment into it;

[0132] The execution flow redirection module is configured to atomically back up and replace instructions at the fault code entry point, redirect the program execution flow to the injected patch code, and ensure that the original execution flow can be returned to without loss after the patch is executed through a trampoline mechanism.

[0133] To verify the effectiveness of the present invention, the following experiment was conducted in this embodiment.

[0134] The experimental platform for this embodiment is as follows: In this embodiment, a hot patching experiment is conducted on an Nginx server with a CVE-2017-7529 vulnerability in a simulated massive heterogeneous computing network environment. The experimental environment consists of two standard commercial rack servers to simulate a real data center environment.

[0135] The specific configuration of the experimental environment is as follows:

[0136] Physical servers: Two standard 1U or 2U rack-mount servers, each equipped with an Intel Xeon Silver series CPU (such as Xeon Silver 4210R) and 64GB DDR4 memory, providing ample computing resources.

[0137] Virtual machine cluster: On the physical servers described above, deploy the following virtualization platforms via VMware vSphere or KVM: 10 Ubuntu 20.04 x86_64 virtual machines; 5 Ubuntu 20.04 aarch64 virtual machines emulated via QEMU; and 5 Windows Server 2019 x86_64 virtual machines.

[0138] Target application: Deploy Nginx version 1.12.2, which is vulnerable to CVE-2017-7529 (Nginx directory traversal vulnerability), on all 20 virtual machine nodes, and run a static website service. At the same time, use the wrk tool to continuously send HTTP requests to simulate business load.

[0139] Central control node: A separate virtual machine that deploys a patch knowledge base and management server for unified patch distribution strategies.

[0140] Patch Agent: Deploy the patch agent of this invention on each target node. The agent will automatically identify the node's OS and CPU architecture and load the corresponding local adapter.

[0141] The evaluation metrics for this embodiment are as follows:

[0142] (1) Repair success rate: This is the ratio of the number of successfully repaired nodes to the total number of nodes. The higher the value, the better the performance. Success_Rate = (Success_Node_Count / Total_Node_Count) 100%.

[0143] (2) Exploitation blocking rate: This is the ratio of successfully blocked perturbations to the total number of perturbations. The higher the value, the better the performance. Block_Rate = (Blocked_Attacks / Total_Attacks) 100%.

[0144] (3) Average repair delay: the average time from the detection of a defect to the completion of repair. The smaller the value, the better the performance.

[0145] (4) Service interruption time: This is the total duration of business request failures during the repair process. The smaller the value, the better the performance. Downtime = 0ms (ideal value).

[0146] Among them, Success_Node_Count is the number of nodes successfully repaired; Total_Node_Count is the total number of nodes; Blocked_Attacks is the number of perturbations successfully blocked; and Total_Attacks is the total number of perturbations.

[0147] Table 1 shows the experimental environment configuration for this experiment, as detailed below:

[0148] Table 1 Experimental environment configuration for this experiment

[0149]

[0150] Table 2 evaluates the repair effectiveness of the hot patching method based on the present invention in the heterogeneous environment shown in Table 1, as follows:

[0151] Table 2. Evaluation of the repair effect of the hot patching method of the present invention

[0152]

[0153] Experimental Results Analysis: The experimental results show that the method of this invention achieved a 100% repair success rate and vulnerability blocking rate on all 20 heterogeneous nodes, demonstrating its strong cross-platform compatibility. The average repair latency is only 85ms, and the service interruption time is 0ms, fully demonstrating the core value of its hot patching. The performance overhead is extremely low, with almost no impact on business operations, indicating that this method is feasible for deployment in a production environment.

[0154] Table 3 shows a performance comparison between the technology of this invention and the traditional shutdown update method, as detailed below:

[0155] Table 3 Performance Comparison between the Invention Technology and Traditional Methods

[0156]

[0157] Table 3 above presents a performance analysis comparison. Compared to traditional methods, this invention improves single-node repair efficiency by more than 56 times and achieves a qualitative leap in service availability from minute-level interruptions to zero interruptions. In large-scale scenarios, traditional manual operation modes are no longer feasible, while the automated deployment capability of this invention enables the repair of all nodes within 5 seconds, representing a revolutionary improvement in operational capabilities.

[0158] The technical solution of this invention is mainly based on three core elements: cross-platform compatibility, uninterrupted operation, and automation. First, based on a platform-independent patch description language and local adapter, the intent and implementation of the patch are separated and unified into a standardized strategy that can be interpreted and executed by heterogeneous nodes. Then, through bytecode signature positioning and cross-platform binary injection, the compatibility and accuracy of the patch on different CPU architectures and operating systems are ensured. In the repair phase, an integrated process of monitoring, addressing, injection, and redirection is adopted. First, the dynamic monitoring mechanism discovers the problem in real time, then the addressing engine accurately locates it, the injection module securely deploys it, and finally, the trampoline mechanism achieves lossless replacement to ensure business continuity. In the evaluation phase, key indicators such as MTTR and success rate are quantified to support its performance advantages with data. Finally, the hot patching system is deployed in agent mode on various nodes of a massive heterogeneous computing network. The central control node realizes the unified distribution of patch strategies, status monitoring, and effect quantification. It is connected to the program runtime event stream, outputs repair instructions and status reports according to a unified standard, and records version, indicators, and logs to meet the requirements of operation and maintenance management for process traceability and effect quantification.

[0159] This invention integrates dynamic addressing and fragmented injection, while simultaneously capturing the complex environment of massive heterogeneous computing networks, such as the dynamic states of nodes and programs running under different operating systems and CPU architectures. Compared with traditional shutdown updates or static patching tools, it can more comprehensively adapt to different platforms, solve the problem of repair failure and business interruption caused by the reliance on fixed addresses and specific environments in traditional methods, and improve the accuracy of repair and system availability.

[0160] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A hot patching method based on dynamic detection and redirection replacement of program defects, characterized in that: Includes the following steps: Step 1: Detect runtime defects through a dynamic monitoring mechanism: When the target program is running, its key behaviors are monitored through a dynamic monitoring mechanism, and a structured defect feature library is built to define and match program defects. Step 2, Dynamic addressing of fault codes based on bytecode signature: When the monitored behavior matches an entry in the defect signature library, the precise address of the fault code segment is dynamically scanned and located in the memory space of the target program based on the bytecode signature provided in the library. Step 3, Cross-platform patch code fragment injection: Based on the CPU architecture of the target node, select the corresponding pre-compiled patch binary fragment, allocate a safe memory region in the virtual address space of the target process, and inject the patch fragment into it; Step 4: Trampoline-based lossless execution flow redirection: At the entry point of the fault code, the instructions are atomically backed up and replaced, the program execution flow is redirected to the injected patch code, and the trampoline mechanism is used to ensure that the original execution flow can be returned to without loss after the patch is completed. Step 5: Build a distributed hot patch management and verification system: In a massive heterogeneous computing network environment, deploy a central control node and agent nodes to achieve unified distribution of patch strategies, status monitoring, and verification of repair effects.

2. The hot patching method based on dynamic detection and redirection replacement of program defects according to claim 1, characterized in that: In step 1, the specific implementation process is as follows: Step 1.1: During the execution of the target program, based on the dynamic monitoring mechanism, API hook technology is used to monitor the calls, memory accesses and function return values ​​of key API functions by modifying the import address table of the operating system. Step 1.2: Construct a structured defect feature library, where each entry contains a defect ID, triggering conditions, and risk level; Step 1.3: When the monitoring data meets any of the triggering conditions in the feature library, it is determined that a defect has been detected, and the corresponding defect ID is obtained.

3. The hot patching method based on dynamic detection and redirection replacement of program defects according to claim 1, characterized in that: In step 2, the specific implementation process is as follows: Step 2.1: Obtain the bytecode signature corresponding to the defect ID from the defect feature library. This signature is a sequence of N consecutive machine codes at the entry point of the fault code. Step 2.2: Perform a sliding window scan within the code segment memory region of the target process to match bytecode signatures and determine the starting virtual address of the fault code; Step 2.3: Calculate the precise memory address of the fault code.

4. The hot patching method based on dynamic detection and redirection replacement of program defects according to claim 1, characterized in that: In step 3, the specific implementation process is as follows: Step 3.1: From the patch knowledge base, select the corresponding pre-compiled patch binary fragment based on the CPU instruction set architecture of the target node; The patch knowledge base stores native machine code versions for multiple mainstream CPU instruction set architectures in advance for the same patch logic; Step 3.2: In the virtual address space of the target process, allocate a memory page with read, write, and execute permissions through a system call; Step 3.3: Write the patch binary fragment into the memory page and handle the relative address relocation to ensure the independence of the patch code.

5. The hot patching method based on dynamic detection and redirection replacement of program defects according to claim 1, characterized in that: In step 4, the specific implementation process is as follows: Step 4.1: At the fault code entry point, atomically back up the original M-byte instruction; Step 4.2: Construct a trampoline code snippet, the contents of which are: the backup of the original M-byte instruction, and an instruction to jump back to the subsequent position of the original process; Step 4.3: Atomically replace the M-byte instruction at the fault code entry point with an instruction that directly jumps to the patch code entry point; Step 4.4: After the patch code is executed, jump to the trampoline code. After the backup instruction is executed, verify whether the critical status register or memory value meets the expectations. If it does, jump back to the original process; otherwise, trigger exception handling.

6. The hot patching method based on dynamic detection and redirection replacement of program defects according to claim 1, characterized in that: In step 5, the specific implementation process is as follows: Step 5.1: Construct a distributed system consisting of a central control node and multiple agent nodes. The central node is responsible for maintaining and distributing the patch knowledge base, while the agent nodes are deployed on various terminals of the heterogeneous computing network. Step 5.2: The proxy node maintains communication with the central node through a heartbeat mechanism, regularly reports the node status and the list of applied patches, and actively pulls the latest patch policy. Step 5.3: Define key performance indicators, including mean time to repair, which is defined as the average time from the detection of a defect to the completion of repair. Repair success rate is defined as the ratio of the number of nodes successfully repaired to the total number of nodes. And performance overhead, defined as the peak increment of the target program's CPU utilization during the repair period.

7. The hot patching method based on dynamic detection and redirection replacement of program defects according to claim 6, characterized in that: The specific implementation process in step 5.3 is as follows: The mean repair time is calculated as follows: ； Where MTTR represents the average repair time, and N represents the total number of repair events. This represents the timestamp of the i-th defect detection. This represents the timestamp when the i-th repair was completed; Repair Success Rate (RSR) measures the proportion of defects that are successfully repaired out of a total number of repair events. Its calculation formula can be expressed as: ； in, Indicates the number of defect events that were successfully fixed; This represents the total number of defect events that need to be fixed. Performance overhead (PO) is used to measure the impact of patch application or dynamic monitoring on the performance of a target system. It can be calculated by comparing key performance indicators before and after patch application, and its calculation formula can be expressed as: ； in, This indicates the program execution time after applying patches or enabling monitoring mechanisms. This indicates the baseline execution time when no patches are applied or monitoring mechanisms are enabled.

8. A hot patching system based on dynamic detection and redirection replacement of program defects, implementing the hot patching method based on dynamic detection and redirection replacement of program defects as described in any one of claims 1 to 7, characterized in that, It includes a dynamic monitoring module, a dynamic addressing module, a patch injection module, and an execution flow redirection module; Dynamic monitoring module: responsible for monitoring the key behaviors of the target program during runtime through instrumentation or hooking techniques, and matching program defects based on a structured defect feature library; Dynamic addressing module: When the monitored behavior matches an entry in the defect signature library, it is responsible for dynamically scanning and locating the precise address of the faulty code segment in the target program's memory space based on the bytecode signature provided in the library; Patch injection module: Responsible for selecting the corresponding pre-compiled patch binary fragment based on the CPU architecture of the target node, allocating a safe memory region in the virtual address space of the target process, and injecting the patch fragment into it; The execution flow redirection module is responsible for atomically backing up and replacing instructions at the entry point of the fault code, redirecting the program execution flow to the injected patch code, and ensuring that the original execution flow can be returned to without loss after the patch is completed through a trampoline mechanism.

Images