A thermal patch processing method and device

Abstract

The present invention discloses a hot patch processing method and device, and relates to the field of computer technology. A specific implementation of the method includes: in response to a hot patch request, determining a target process corresponding to the hot patch request; injecting a target patch file corresponding to the hot patch request into the target process, and storing the first file information of the target patch file into a management module in the target process; running the target patch file according to the first file information and the second file information of one or more historical patch files stored in the management module to debug the component corresponding to the target process. This implementation enables the process to support the coexistence of multiple patch files at the same time, thereby facilitating the reflection of the relationship between multiple repair processes.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a hot patch processing method and device. Background Art

[0002] As the time required to fix program vulnerabilities becomes shorter and shorter, hot patching technology comes into being. In the current hot patching technology, only one patch module can exist in a process. When multiple patch files need to be injected into a process, the patch files that previously existed in the process need to be uninstalled before the new patch files can be re-injected into the process.

[0003] In the process of implementing the present invention, the inventors found that there are at least the following problems in the prior art:

[0004] Multiple functional modules in a process may have multiple repair processes respectively. Currently, only one patch file can exist in a process at the same time, which makes it difficult to reflect the relationship between multiple repair processes and is inconvenient to manage functional modules. Summary of the invention

[0005] In view of this, an embodiment of the present invention provides a hot patch processing method and device, which injects a management module by adding memory space in the process, and records the file information of multiple patch files through the management module, so that multiple patch files can coexist in the process at the same time. Therefore, when running a patch file, the target patch file can be run according to the similarities and differences between the first file information corresponding to it and the second file information corresponding to the historical patch file, so as to facilitate the reflection of the relationship between multiple repair processes, and then facilitate the management of multiple functional modules in the process.

[0006] To achieve the above objective, according to one aspect of an embodiment of the present invention, a thermal patch processing method is provided.

[0007] A hot patch processing method according to an embodiment of the present invention includes: in response to a hot patch request, determining a target process corresponding to the hot patch request;

[0008] Injecting a target patch file corresponding to the hot patch request into the target process, and storing first file information of the target patch file into a management module in the target process;

[0009] The target patch file is run according to the first file information and the second file information of one or more historical patch files stored in the management module to debug the component corresponding to the target process.

[0010] Optionally, the first file information includes: a first function address and a first injection time of one or more functions to be debugged, and the second file information includes: a second function address and a second injection time of one or more debugged functions corresponding to each of the historical patch files; and running the target patch file according to the first file information and the second file information includes:

[0011] Determining, from the second file information according to the first injection time and the second injection time, second function addresses corresponding to the first function addresses of the one or more functions to be debugged;

[0012] According to the determined running result of the historical patch file corresponding to the second function address, the target patch file is run to debug the function to be debugged.

[0013] Optionally, a second function address which is the same as the function to be debugged and has the smallest time difference between the second injection time and the first injection time is determined as the second function address corresponding to the first function address.

[0014] Optionally, after running the target patch file, the method further includes:

[0015] For any of the historical patch files, execute:

[0016] Determine whether all second function addresses included in the second file information corresponding to the historical patch file have corresponding target second function addresses; wherein the second injection time corresponding to the target second function address is later than the second injection time corresponding to the historical patch file;

[0017] If yes, the second file information corresponding to the historical patch file is deleted from the management module.

[0018] Optionally, before injecting the first patch file corresponding to the patch request into the target process, the method further includes:

[0019] Determining whether a management module exists in the target process;

[0020] If not, when the virtual space of the target process is larger than the target patch file, a management module is injected into the virtual space of the target process.

[0021] Optionally, the method further comprises:

[0022] After the target patch file is executed, deleting the target patch file from the target process;

[0023] When the number of patch files in the target process is zero, the management module is deleted.

[0024] Optionally, before injecting the target patch file corresponding to the patch request into the target process, the method further includes:

[0025] It is determined that the target patch file is consistent with the operating environment of the target process.

[0026] To achieve the above objective, according to another aspect of an embodiment of the present invention, a thermal patch processing device is provided.

[0027] A thermal patch processing device according to an embodiment of the present invention includes:

[0028] A process determination module, configured to determine, in response to a hot patch request, a target process corresponding to the hot patch request;

[0029] A file injection module, used for injecting a target patch file corresponding to the hot patch request into the target process, and storing first file information of the target patch file into a management module in the target process;

[0030] The patch running module is used to run the target patch file according to the first file information and the second file information of one or more historical patch files stored in the management module to debug the component corresponding to the target process.

[0031] To achieve the above objective, according to another aspect of an embodiment of the present invention, a thermal patch-processed electronic device is provided.

[0032] An electronic device for hot patch processing according to an embodiment of the present invention comprises: one or more processors; a storage device for storing one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors implement a hot patch processing method according to an embodiment of the present invention.

[0033] To achieve the above objective, according to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided.

[0034] A computer-readable storage medium according to an embodiment of the present invention stores a computer program, and when the program is executed by a processor, a hot patch processing method according to an embodiment of the present invention is implemented.

[0035] An embodiment of the above invention has the following advantages or beneficial effects: by adding memory space to the process to inject the management module, and recording the file information of multiple patch files through the management module, the process can support the coexistence of multiple patch files at the same time. Therefore, when running the patch file, the target patch file can be run according to the similarities and differences between the first file information corresponding to it and the second file information corresponding to the historical patch file, so as to facilitate the reflection of the relationship between multiple repair processes, and then facilitate the management of multiple functional modules in the process.

[0036] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with the specific implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0038] Figure 1 is a schematic diagram of main steps of a thermal patch processing method according to an embodiment of the present invention;

[0039] Figure 2 is a schematic diagram of main modules of a thermal patch processing device according to an embodiment of the present invention;

[0040] Figure 3 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;

[0041] Figure 4 It is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0042] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0043] It should be pointed out that the embodiments of the present invention and the technical features therein may be combined with each other without conflict.

[0044] With the rapid development of the Internet industry, the time between a program vulnerability and being exploited by an attack is getting shorter and shorter, and the time required to patch is getting shorter and shorter. Fixing vulnerabilities means upgrading the software and restarting the program, but some cloud architecture basic programs such as openswitch and qemu and other core components must run for a long time. At this time, the method of patching vulnerabilities can use libcare hot patch technology. However, the current hot patch technology can only have one patch file in the process space, and cannot allow multiple patch files to exist in the process at the same time. If you need to load a new patch file, you must first uninstall the patch file that existed in the process before. Then, each time a new patch file is run, the previous repair results will be fully overwritten, and the corresponding functional modules will be repaired again according to the new patch file. However, different patch files may repair the same functional module or multiple modules with associations. Therefore, the current method of only having one patch file at the same time in the process is difficult to reflect the relationship between multiple repair processes and is not convenient for managing multiple functional modules. Among them, libcare is an open source process hot patch solution, openswitch is an open source virtual switch that supports openflow, and qemu is an open source simulation processor, which often cooperates with kvm to provide iaas cloud host solutions.

[0045] In order to solve the above technical problems, an embodiment of the present invention provides a thermal patch processing method. Figure 1 Schematic diagram of main steps of a thermal patch processing method according to an embodiment of the present invention.

[0046] like Figure 1 As shown, a hot patch processing method according to an embodiment of the present invention mainly includes the following steps:

[0047] Step S101: In response to a hot patch request, determining a target process corresponding to the hot patch request.

[0048] When hot patching is needed to debug or repair a process, Libcare can determine the target process to be debugged or repaired. There may be multiple vulnerabilities in the target process that need to be repaired, which means that multiple functions need to be debugged.

[0049] Step S102: injecting a target patch file corresponding to the hot patch request into the target process, and storing first file information of the target patch file into a management module in the target process.

[0050] In one embodiment of the present invention, before executing step S102, it may also include: determining whether a management module exists in the target process; if not, when the virtual space of the target process is larger than the target patch file, injecting the management module into the virtual space of the target process.

[0051] Here, a memory segment is added to the target process, similar to the dynamic segment in the dynamic executable file, to store the management module. The management module is used to record the information list of the patch files currently injected into the target process. After the patch file is run, the patch file information can be deleted accordingly. When the last patch file in the process is deleted, this memory segment can be deleted, that is, the management module is deleted together.

[0052] Specifically, after Libcare determines the target process, such as after the Attach process (pause process), it can first query whether there is a management module in the target process space. If it exists, the first file information of the target patch file is stored in the management module, and the first file information may include the loaded patch file name, injection address and injection time, etc. Among them, the injection address may include the first function address of the function to be debugged. If there is no management module in the target process, it is queried whether the virtual space of the target process meets the conditions for injecting the target patch file and the management module, that is, it is determined whether there is space in the virtual address of the target process to store the entire patch file and the management module. In one embodiment of the present invention, the management module can be injected into the virtual space of the target process when the virtual space of the target process is larger than the target patch file to be injected. In order to ensure that the target process has sufficient space to store the patch file after the management module is injected, the patch file can also be injected into the target process first, and then the management module can be injected. Therefore, if the management module is injected successfully, it means that the virtual space of the target process meets the conditions for injecting the management module.

[0053] After the patch file is successfully injected, the file information corresponding to the patch file in the management module is updated. It is understandable that if the management module exists in the target process before the target patch file is injected, then the management module stores the second file information of the historical patch file that existed in the target process before the target patch file was injected. Then, after the target patch file is injected, the first file information of the target patch file is added to the management module accordingly.

[0054] Step S103: running the target patch file according to the first file information and the second file information of one or more historical patch files stored in the management module to debug the component corresponding to the target process.

[0055] In one embodiment of the present invention, the file information stored in the management module may include a patch file name, an injection address, an injection time, etc. Among them, the injection address may include a function address. Specifically, the first file information in the management module may include: the first function address and the first injection time of one or more functions to be debugged; the second file information may include: the second function address and the second injection time of one or more debugged functions corresponding to each of the historical patch files. It can be understood that the historical patch file is a patch file that has been injected into the target process before the target patch file is injected. Based on this, the specific implementation of step S103 may include: according to the first injection time and the second injection time, respectively determining the second function address corresponding to the first function address of the one or more functions to be debugged from the second file information; according to the running result of the historical patch file corresponding to the determined second function address, running the target patch file to debug the function to be debugged.

[0056] In one embodiment of the present invention, the second function address corresponding to the first function address is: the second function address that is the same as the function to be debugged and has the smallest time difference between the second injection time and the first injection time of the first function address. For example, the target patch file includes the first function addresses A1 and A2 corresponding to the functions A1 and A2 to be debugged in function module A, and the first function address B1 corresponding to the function B1 to be debugged in function module B. The management module includes the second file information V1 corresponding to the historical patch file V1 and the second file information V2 corresponding to the historical patch file V2, wherein the second file information V1 includes the second function addresses A1' and A2' corresponding to the functions A1 and A2 in function module A, respectively, and the second file information V2 includes the second function address B1' corresponding to the function B in function module B.

[0057] Then, the second function address corresponding to the first function address A1 is A1', the second function address corresponding to the first function address A2 is A2', and the second address corresponding to the first function address B1 is B1'. When running the target patch file, the target patch file can be run based on the running results of the historical patch files V1 and V2, that is, based on the debugging results of the historical patch files V1 and V2 on the functions A1, A2 and B1, thereby debugging the functions A1, A2 and B1 by running the patch files on the basis of V1 and V2.

[0058] After running the target patch file, the file information in the management module can be deleted accordingly. Specifically, in one embodiment of the present invention, after running the target patch file, for any of the historical patch files, the following can be performed: determining whether all the second function addresses included in the second file information corresponding to the historical patch file have corresponding target second function addresses; wherein the second injection time corresponding to the target second function address is later than the second injection time corresponding to the historical patch file; if so, deleting the second file information corresponding to the historical patch file from the management module.

[0059] It is understandable that after the first file information corresponding to the target patch file is stored in the management module, the first file information can also be used as the second file information, and the first function address in the first file information can also be used as the second function address. Still taking the debugging of function module A and function module B as an example, after running the target patch file, the second function addresses A1' and A2' in the second file information V1 both have corresponding target second function addresses (A1 and A2), which means that the second function addresses A1' and A2' in the second file information V1 both have corresponding patch versions. At this time, there is no need to retain the second file information V1 in the management module, so the second file information V1 can be deleted from the management module. Similarly, after running the target patch file, the second function address B1' in the second file information V2 also has a corresponding target second function address (B1), and the second file information V2 in the management module can also be deleted. In this way, the file information in the management module can be effectively managed, avoiding the problem of too much data being searched when running the target patch file due to too much file information stored in the management module, and improving the running efficiency of the target patch file.

[0060] In addition, in one embodiment of the present invention, after the target patch file is executed, the target patch file is deleted from the target process; when the number of patch files in the target process is zero, the management module is deleted.

[0061] In this embodiment, each time a patch file is run to completion, the completed patch file can be deleted from the target process to avoid too many patch files in the target process. Then, after the latest injected target patch file is run, the target patch file is also deleted from the target process. If other patch files injected before the target patch file have also been run to completion, the number of patch files in the target process is zero. At this time, the management module can be deleted, and the file information in the management module is also deleted. When it is necessary to inject a patch file into the target process again, the management module can be injected into the target process again to record the file information of the patch file through the management module.

[0062] In addition, before running the target patch file, it can also include determining that the target patch file is consistent with the operating environment of the target process. Here, the build ID consistency test can be used to determine that the address space of the target patch file is basically consistent with that of the target process. Among them, the build ID can be calculated by a secure hash algorithm (such as sha-2) for the target patch file, that is, the build ID can be the sha-2 calculated value of the target patch file, thereby proving the uniqueness of the code segment and data segment of this file. Then determine whether the build ID is consistent with the build ID of the target process, thereby determining whether the address space of the target patch file is consistent with that of the target process, thereby ensuring the safe operation of the target patch file.

[0063] According to a hot patch processing method of an embodiment of the present invention, it can be seen that by adding memory space to the process to inject a management module, and recording the file information of multiple patch files through the management module, multiple patch files can be supported to coexist in the process at the same time. Therefore, when running a patch file, the target patch file can be run according to the similarities and differences between the first file information corresponding to it and the second file information corresponding to the historical patch file, so as to facilitate the reflection of the relationship between multiple repair processes, and then facilitate the management of multiple functional modules in the process.

[0064] Figure 2 Schematic diagram of main modules of a thermal patch processing device according to an embodiment of the present invention.

[0065] like Figure 2 As shown, a thermal patch processing device 200 according to an embodiment of the present invention includes:

[0066] The process determination module 201 is used to determine a target process corresponding to the hot patch request in response to the hot patch request;

[0067] A file injection module 202, configured to inject a target patch file corresponding to the hot patch request into the target process, and store first file information of the target patch file into a management module in the target process;

[0068] The patch running module 203 is used to run the target patch file according to the first file information and the second file information of one or more historical patch files stored in the management module to debug the component corresponding to the target process.

[0069] In one embodiment of the present invention, the first file information includes: a first function address and a first injection time of one or more functions to be debugged, and the second file information includes: a second function address and a second injection time of one or more debugged functions corresponding to each of the historical patch files;

[0070] The patch running module 203 is used to determine the second function addresses corresponding to the first function addresses of the one or more functions to be debugged from the second file information according to the first injection time and the second injection time; and run the target patch file according to the running result of the historical patch file corresponding to the determined second function address to debug the function to be debugged.

[0071] In one embodiment of the present invention, the patch running module 203 is used to determine a second function address which is the same as the function to be debugged and has the smallest time difference between the second injection time and the first injection time as the second function address corresponding to the first function address.

[0072] In one embodiment of the present invention, the patch running module 203 is used to execute, for any of the historical patch files after running the target patch file: determining whether all second function addresses included in the second file information corresponding to the historical patch file have corresponding target second function addresses; wherein the second injection time corresponding to the target second function address is later than the second injection time corresponding to the historical patch file; if so, deleting the second file information corresponding to the historical patch file from the management module.

[0073] In one embodiment of the present invention, the file injection module 202 is used to determine whether there is a management module in the target process before injecting the first patch file corresponding to the patch request into the target process; if not, when the virtual space of the target process is larger than the target patch file, the management module is injected into the virtual space of the target process.

[0074] In one embodiment of the present invention, the patch running module 203 is further used to delete the target patch file from the target process after the target patch file is run; and to delete the management module when the number of patch files in the target process is zero.

[0075] In one embodiment of the present invention, the file injection module 202 is further used to determine whether the target patch file corresponding to the patch request is consistent with the operating environment of the target process before injecting the target patch file into the target process.

[0076] According to a hot patch processing device of an embodiment of the present invention, it can be seen that by adding memory space to the process to inject a management module, and recording the file information of multiple patch files through the management module, multiple patch files can be supported to coexist in the process at the same time. Therefore, when running a patch file, the target patch file can be run according to the similarities and differences between the first file information corresponding to it and the second file information corresponding to the historical patch file, so as to facilitate the reflection of the relationship between multiple repair processes, and then facilitate the management of multiple functional modules in the process.

[0077] Figure 3 An exemplary system architecture 300 is shown to which a hot patch processing method or a hot patch processing device according to an embodiment of the present invention can be applied.

[0078] like Figure 3 As shown, the system architecture 300 may include terminal devices 301, 302, 303, a network 304 and a server 305. The network 304 is used to provide a medium for communication links between the terminal devices 301, 302, 303 and the server 305. The network 304 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0079] Users can use terminal devices 301, 302, 303 to interact with server 305 through network 304 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 301, 302, 303, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0080] The terminal devices 301 , 302 , and 303 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers, etc.

[0081] Server 305 may be a server that provides various services, such as a backend management server that provides support for shopping websites browsed by users using terminal devices 301, 302, and 303. The backend management server may analyze and process received data such as product information query requests, and feed back the processing results to the terminal device.

[0082] It should be noted that the hot patch processing method provided in the embodiment of the present invention is generally executed by the server 305 , and accordingly, the hot patch processing device is generally disposed in the server 305 .

[0083] It should be understood that Figure 3 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0084] Reference below Figure 4 , which shows a schematic diagram of the structure of a computer system 400 of a terminal device suitable for implementing an embodiment of the present invention. Figure 4 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0085] like Figure 4 As shown, the computer system 400 includes a central processing unit (CPU) 401, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 402 or a program loaded from a storage part 408 into a random access memory (RAM) 403. In the RAM 403, various programs and data required for the operation of the system 400 are also stored. The CPU 401, the ROM 402, and the RAM 403 are connected to each other via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

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

[0087] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 409, and / or installed from the removable medium 411. When the computer program is executed by the central processing unit (CPU) 401, the above-mentioned functions defined in the system of the present invention are executed.

[0088] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0089] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0090] The modules involved in the embodiments of the present invention may be implemented by software or hardware. The modules described may also be set in a processor, for example, it may be described as: a processor includes a process determination module, a file injection module and a patch running module. The names of these modules do not constitute a limitation on the modules themselves in some cases, for example, the file injection module may also be described as a "module for injecting a target patch file into a target process".

[0091] As another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiment; or it may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device includes: in response to a hot patch request, determining a target process corresponding to the hot patch request; injecting a target patch file corresponding to the hot patch request into the target process, and storing the first file information of the target patch file into a management module in the target process; and running the target patch file according to the first file information and the second file information of one or more historical patch files stored in the management module to debug the component corresponding to the target process.

[0092] According to the technical solution of the embodiment of the present invention, by adding memory space to the process to inject a management module, and recording the file information of multiple patch files through the management module, the process can support the coexistence of multiple patch files at the same time. Therefore, when running a patch file, the target patch file can be run according to the similarities and differences between the first file information corresponding to it and the second file information corresponding to the historical patch file, so as to facilitate the reflection of the relationship between multiple repair processes, and then facilitate the management of multiple functional modules in the process.

[0093] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A thermal patch processing method, characterized in that: include: In response to a hot patch request, determining a target process corresponding to the hot patch request; Injecting a target patch file corresponding to the hot patch request into the target process, and storing first file information of the target patch file into a management module in the target process; According to the first file information and second file information of one or more historical patch files stored in the management module, running the target patch file to debug the component corresponding to the target process; The first file information includes: a first function address and a first injection time of one or more functions to be debugged, and the second file information includes: a second function address and a second injection time of one or more debugged functions corresponding to each of the historical patch files; The step of running the target patch file according to the first file information and the second file information includes: Determining, from the second file information according to the first injection time and the second injection time, second function addresses corresponding to the first function addresses of the one or more functions to be debugged; According to the determined running result of the historical patch file corresponding to the second function address, the target patch file is run to debug the function to be debugged.

2. The method according to claim 1, characterized in that: A second function address which is the same as the function to be debugged and has the smallest time difference between the second injection time and the first injection time is determined as the second function address corresponding to the first function address.

3. The method according to claim 1, characterized in that After running the target patch file, the method further includes: For any of the historical patch files, execute: Determine whether all second function addresses included in the second file information corresponding to the historical patch file have corresponding target second function addresses; wherein the second injection time corresponding to the target second function address is later than the second injection time corresponding to the historical patch file; If yes, the second file information corresponding to the historical patch file is deleted from the management module.

4. The method according to claim 1, characterized in that Before injecting the target patch file corresponding to the hot patch request into the target process, the method further includes: Determining whether a management module exists in the target process; If not, when the virtual space of the target process is larger than the target patch file, a management module is injected into the virtual space of the target process.

5. The method according to claim 1, characterized in that Also includes: After the target patch file is executed, deleting the target patch file from the target process; When the number of patch files in the target process is zero, the management module is deleted.

6. The method according to claim 1, characterized in that Before injecting the target patch file corresponding to the patch request into the target process, the method further includes: It is determined that the target patch file is consistent with the operating environment of the target process.

7. A thermal patch processing device, characterized in that: include: A process determination module, configured to determine, in response to a hot patch request, a target process corresponding to the hot patch request; A file injection module, used for injecting a target patch file corresponding to the hot patch request into the target process, and storing first file information of the target patch file into a management module in the target process; a patch running module, configured to run the target patch file according to the first file information and second file information of one or more historical patch files stored in the management module, so as to debug a component corresponding to the target process; The first file information includes: a first function address and a first injection time of one or more functions to be debugged, and the second file information includes: a second function address and a second injection time of one or more debugged functions corresponding to each of the historical patch files; The patch running module is also used for: Determining, from the second file information according to the first injection time and the second injection time, second function addresses corresponding to the first function addresses of the one or more functions to be debugged; According to the determined running result of the historical patch file corresponding to the second function address, the target patch file is run to debug the function to be debugged.

8. An electronic device subjected to thermal patching, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 6.

9. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images