Kernel injection method, code execution method, system and device for process entry

Abstract

The application discloses a process entry kernel injection method, a code execution method, a system and equipment. The method comprises the following steps: a daemon device receives notification information, and obtains process information of an injected process according to the notification information, and determines a process handle of the injected process according to the process information; the daemon device obtains an original instruction memory of the injected process according to the process handle; the daemon device modifies the original instruction memory according to the process handle to obtain a target instruction memory, wherein the target instruction memory stores target code, and the target code comprises: callback instructions, which are used for calling back to the original instruction memory after the target code is executed; and the daemon device restores a main thread of the injected process according to a preset thread handle, and executes the target code through the main thread. The embodiment of the method provides a more stable and more compatible injection code mode.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a kernel injection method, code execution method, system, and device for process entry points. Background Technology

[0002] In related technologies, multiple application processes typically run on a terminal system, each performing different functions. In cases of unconditional code injection into the Windows kernel, multiple similar injection methods often coexist, leading to compatibility issues. Summary of the Invention

[0003] This invention aims to at least solve one of the technical problems existing in the prior art. To this end, this invention proposes a kernel injection method, code execution method, system, and device for process entry points, providing a more stable and more compatible code injection method.

[0004] A kernel injection method for a process entry point according to a first aspect embodiment of the present invention includes:

[0005] The guardian device receives a notification message, obtains the process information of the injected process based on the notification message, and determines the process handle of the injected process based on the process information.

[0006] The guardian device obtains the original instruction memory of the injected process based on the process handle;

[0007] The guardian device modifies the original instruction memory according to the process handle to obtain the target instruction memory. The target instruction memory stores the target code, which includes a callback instruction. The callback instruction is used to return to the original instruction memory after the target code is executed.

[0008] The guardian device restores the main thread of the injected process according to a preset thread handle, and executes the target code through the main thread.

[0009] The kernel injection method for process entry points according to embodiments of the present invention has at least the following beneficial effects:

[0010] The system receives notification information via a guardian device, retrieves the process information of the injected process based on the notification, and determines the process handle of the injected process. It then obtains the original instruction memory of the injected process based on the process handle. The guardian device modifies the original instruction memory according to the process handle to obtain the target instruction memory, which stores the target code. The target code includes callback instructions, which are used to redirect back to the original instruction memory after the target code is executed. Finally, the main thread of the injected process is restored according to a preset thread handle, and the target code is executed through the main thread. Therefore, this method provides a more stable and compatible code injection approach.

[0011] According to some embodiments of this application, before the guardian device receives the notification information and obtains the process information of the injected process based on the notification information, the method further includes:

[0012] The daemon driver registers and loads callback functions to monitor the process file of the initial process;

[0013] If the process file is a preset file, the guardian driver determines the injected process from the initial process and records the process information of the injected process;

[0014] The guardian driver sends a notification to the guardian device based on the process information and then enters a waiting state.

[0015] According to some embodiments of this application, after the guardian device receives notification information and obtains the process information of the injected process based on the notification information, the method further includes:

[0016] The guardian device provides feedback on the guardian driver response information based on the process information.

[0017] According to some embodiments of this application, the guardian device feeds back the guardian driver response information based on the process information, including:

[0018] The guardian device locates the thread handle of the injected process based on the thread identifier of the process information;

[0019] The guardian device suspends the main thread based on the thread handle and obtains the suspension information;

[0020] The guardian device feeds back the response information to the guardian driver based on the suspension information.

[0021] According to some embodiments of this application, the guardian device modifies the original instruction memory according to the process handle to obtain the target instruction memory, including:

[0022] The guardian device allocates virtual memory space to the target code according to the thread handle, and determines the assembly instruction memory according to the address information of the virtual memory space;

[0023] The guardian device replaces the original instruction memory with the assembly instruction memory and writes the target code into the assembly instruction memory to obtain the target instruction memory.

[0024] According to some embodiments of this application, the guardian device allocates virtual memory space to the target code based on the thread handle, and determines the assembly instruction memory based on the address information of the virtual memory space, including:

[0025] The guardian device calculates the target code to obtain the code data value of the target code;

[0026] The guardian device allocates a virtual memory space of the same size as the code data value to the target code according to the thread handle;

[0027] The guardian device determines the assembly instruction memory based on the address information of the virtual memory space.

[0028] A code execution method according to a second aspect embodiment of the present invention includes:

[0029] The target code injected by the kernel injection method at the process entry point as described in the first aspect of the present invention is executed;

[0030] Execute the target code in the target instruction memory;

[0031] The callback instruction in the target code is redirected to the original instruction memory.

[0032] A kernel injection system for process entry points according to a third aspect embodiment of this application includes:

[0033] The receiving module is used to receive notification information from the guardian device, obtain the process information of the injected process based on the notification information, and determine the process handle of the injected process based on the process information.

[0034] The acquisition module is used by the guardian device to acquire the original instruction memory of the injected process based on the process handle;

[0035] A replacement module is used by the guardian device to modify the original instruction memory according to the process handle to obtain a target instruction memory. The target instruction memory stores target code, and the target code includes a callback instruction, which is used to call back to the original instruction memory after the target code is executed.

[0036] The recovery module is used by the guardian device to restore the main thread of the injected process according to a preset thread handle, and to execute the target code through the main thread.

[0037] A kernel injection device for a process entry point according to a fourth aspect embodiment of this application includes:

[0038] At least one memory;

[0039] At least one processor;

[0040] At least one program;

[0041] The program is stored in memory, and the processor executes the at least one program to achieve:

[0042] Such as the kernel injection method for the process entry point of the first aspect of the present invention.

[0043] According to a fifth aspect embodiment of this application, a storage medium stores executable instructions that can be executed by a computer to cause the computer to perform a kernel injection method for a process entry point as described in the first aspect of this invention.

[0044] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0045] The present invention will be further described below with reference to the accompanying drawings and embodiments, wherein:

[0046] Figure 1 A first detailed flowchart of the kernel injection method for process entry points provided by the present invention;

[0047] Figure 2 for Figure 1 A second detailed flowchart illustrating the kernel injection method for the process entry point, prior to step S100.

[0048] Figure 3 for Figure 1 A third detailed flowchart illustrating the kernel injection method for the process entry point, following step S100.

[0049] Figure 4 for Figure 1 A detailed flowchart of step S300;

[0050] Figure 5 for Figure 4 A detailed flowchart of step S310. Detailed Implementation

[0051] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0052] In the description of this invention, it should be understood that the orientation descriptions, such as up, down, front, back, left, right, etc., are based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.

[0053] In the description of this invention, "several" means one or more, "multiple" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0054] In the description of this invention, unless otherwise explicitly defined, terms such as "set up," "install," and "connect" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this invention in conjunction with the specific content of the technical solution.

[0055] In the description of this invention, the terms "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0056] First, let's analyze some of the terms used in this application:

[0057] Instruction memory: In the embodiments of this application, it is an EIP or RIP register, which is used to store the address of the instruction to be read by the CPU. The CPU reads the instruction to be executed through the EIP or RIP register.

[0058] Unconditional injection based on kernel instruction memory (EIP / RIP): When a process starts, process code or shellcode that loads a dynamic link library (DLL) is written into its address space, modifying its initial instruction memory (EIP / RIP) so that when its import table is initialized, it is forced to load a dynamic link library (DLL) and execute the specified code in its address space.

[0059] The guardian device suspends the injected process, writes process code that loads the shellcode of the dynamic link library into the process space, modifies the instruction memory (EIP) (RIP) of the injected process, and then resumes the injected process to allow it to continue execution.

[0060] The daemon driver synchronously notifies the injected process of the daemon device to load the ntdll event.

[0061] Target code: In the embodiments of this application, it refers to the target code, which also refers to the process code (shellcode) that loads the dynamic link library. The logic of this code is to call LoadbraryW or other similar system functions to load the injected dynamic link library (DLL), and then jump back to the initial instruction memory (EIP / RIP) address, thereby transparently executing the process code (shellcode).

[0062] Kernel file: In some embodiments of this application, this refers to ntdll.dll, which is an important module of the Windows system and serves as the entry point from ring 3 (application layer) to ring 0 (driver layer). In 64-bit systems, the kernel files are located in C:\Windows\System32 and C:\Windows\SysWOW64 in the system directory, and ntdll.dll is loaded every time a process starts.

[0063] This disclosure provides a kernel injection method, code execution method, system, and device for process entry points. The specific implementation is illustrated in the following embodiments. First, the kernel injection method for process entry points in this disclosure is described.

[0064] like Figure 1 As shown, it is a schematic diagram of the implementation process of the kernel injection method for the process entry point provided in the embodiment of this application. The kernel injection method for the process entry point may include, but is not limited to, steps S100 to S400.

[0065] S100, the guardian device receives the notification information, obtains the process information of the injected process based on the notification information, and determines the process handle of the injected process based on the process information.

[0066] S200, the guardian device obtains the raw instruction memory of the injected process based on the process handle;

[0067] S300, the guardian device modifies the original instruction memory according to the process handle to obtain the target instruction memory. The target instruction memory stores the target code, which includes callback instructions. The callback instructions are used to return to the original instruction memory after the target code is executed.

[0068] S400: The guardian device restores the main thread of the injected process according to the preset thread handle, and executes the target code through the main thread.

[0069] In some embodiments, reference Figure 2 As shown, before executing step S100, the kernel injection method for the process entry point may also include, but is not limited to, steps S101 to S103.

[0070] S101, the daemon driver registers and loads callback functions to monitor the process file of the initial process;

[0071] S102, If the process file is a preset file, the daemon driver determines the injected process from the initial process and records the process information of the injected process.

[0072] S103, the guardian driver sends a notification message to the guardian device based on the process information and enters a waiting state.

[0073] In step S101 of some embodiments, the daemon driver registers a loading callback function to monitor the process file of the initial process. It can be understood that the daemon driver will register a process module loading callback function at startup to monitor the kernel status of the initial process and determine whether the process file of the initial process has loaded the kernel file.

[0074] It should be noted that the loading callback function registered by the daemon driver can be a process module loading callback function, which is used in the kernel to monitor the loading of the injected process module.

[0075] In step S102 of some embodiments, after executing step S101 (registering and loading the callback function to monitor the process file of the initial process), if the process file is a preset file, the daemon driver determines the injected process from the initial processes and records the process information of the injected process. It can be understood that if the process files of multiple monitored initial processes are preset files, the daemon driver considers the initial process corresponding to that kernel file to be the injected process, and can determine the injected process from the initial processes through a marking and filtering method, while simultaneously recording the process information of the injected process.

[0076] Furthermore, process information includes at least one of the following: process identifier, thread identifier, and whether it is a Windows 64 process.

[0077] In some embodiments, the default file is ntdll.dll.

[0078] In step S103 of some embodiments, after executing step S102 (if the process file is a preset kernel file), the daemon driver determines the injected process from the initial process, records the process information of the injected process, sends a notification message to the daemon device based on the process information, and enters a waiting state until the daemon device has completed all its work, the daemon process sends feedback to the daemon driver, and then the waiting state is released. It can be understood that after the daemon driver records the process information of the injected process, it sends a notification message to the daemon device based on the recorded process information, and then the daemon driver is in a waiting state. Alternatively, it can be understood that after the daemon driver sends the notification message to the daemon device, it suspends the daemon driver.

[0079] It should be noted that the notification message is the guardian driver informing the guardian device that it has recorded the process information of the injected process, entered a suspended state, and is waiting for the guardian device to respond to the guardian driver, while simultaneously sending the process information to the guardian device.

[0080] In step S100 of some embodiments, after step S103 is completed, whereby the guardian driver sends a notification message to the guardian device based on the process information and enters a waiting state, the guardian device receives the notification message, obtains the process information of the injected process based on the notification message, and determines the process handle of the injected process based on the process information. It can be understood that after the guardian driver sends a notification message to the guardian device and enters a waiting state, the guardian device receives the notification message sent by the guardian driver, obtains the process information of the injected process based on the notification message sent by the guardian driver, and then determines the process handle of the injected process based on the process information.

[0081] It should be noted that in some embodiments of this application, the process handle can be: a process opened by a function (OpenProcess), a process with access permission operation (PROCESS_VM_OPERATION), or a process written to (PROCESS_VM_WRITE).

[0082] In some embodiments, after the guardian device receives notification information in step S100, obtains the process information of the injected process based on the notification information, and determines the process handle of the injected process based on the process information, the kernel injection method for the process entry point may also include, but is not limited to, the steps of the guardian device feeding back guardian driver response information based on the process information, and the guardian driver releasing the waiting state based on the response information. It is understood that the guardian device receives notification information sent by the guardian driver and feeds back guardian driver response information based on the process information in the received notification information.

[0083] It should be noted that the response information can be understood as: the guardian device feeding back to the guardian driver the reception status of the process information it has received from the guardian driver.

[0084] In some embodiments, reference Figure 3 As shown, the step guardian device may provide feedback on guardian driver response information based on process information, including but not limited to steps S110 to S130.

[0085] S110, the guardian device finds the thread handle of the injected process based on the thread identifier of the process information;

[0086] S120, the guardian device suspends the main thread based on the thread handle and obtains the suspension information;

[0087] S130, the guardian device provides feedback on the guardian driver response information based on the suspension information.

[0088] In step S110 of some embodiments, after the guardian device receives notification information and obtains the process information of the injected process according to the notification information, and determines the process handle of the injected process according to the process information, the guardian device finds the thread handle of the injected process according to the thread identifier in the process information. It can be understood that the guardian device finds the thread handle of the main thread of the injected process according to the thread identifier in the process information, and uses this to suspend the main thread.

[0089] It should be noted that the thread handle includes multiple functions. In some embodiments of this application, it may include: a function to open a thread (OpenThread), a function to suspend / resume the execution of a thread (SuspendThread / ResumeThread), a function to get the thread content (GetThreadContext), and a function to set the thread content (SetThreadContext).

[0090] In step S120 of some embodiments, after the guardian device finds the thread handle of the injected process based on the thread identifier of the process information in step S110, the guardian device suspends the main thread based on the thread handle and obtains suspension information. It can be understood that the guardian device suspends the main thread of the injected process based on the thread handle obtained in step S110 and obtains suspension information indicating that the main thread is suspended.

[0091] In step S130 of some embodiments, after executing step S120 where the daemon suspends the main thread based on the thread handle and obtains suspension information, the daemon sends back daemon driver response information based on the suspension information. It can be understood that the daemon sending back daemon driver response information based on the suspension information of the main thread being suspended obtained in step S120 further implies that the daemon has received the process information sent by the daemon driver and has used this process information to respond to the daemon driver.

[0092] In step S200 of some embodiments, after step S130 is completed, the guardian device provides feedback on the guardian driver response information based on the suspension information, and the guardian driver releases the waiting state based on the response information. Then, the guardian device obtains the original instruction memory of the injected process based on the process handle. This can be understood as the guardian device obtaining the original instruction memory corresponding to the injected process based on the process handle after the main thread of the injected process is suspended. Alternatively, it can be understood that the guardian device obtains the original instruction memory of the main thread of the injected process based on the thread handle obtained in step S110.

[0093] It should be noted that the injected process is the initial process that has already loaded the kernel file. It has only one thread, and this thread is the main thread. Suspending the injected process can also be understood as suspending the main thread of the injected process.

[0094] In step S300 of some embodiments, after the daemon device obtains the original instruction memory of the injected process according to the process handle in step S200, the daemon device modifies the original instruction memory according to the process handle to obtain the target instruction memory. The target instruction memory stores the target code, which includes a callback instruction used to return to the original instruction memory after the target code is executed. It can be understood that the daemon device modifying the original instruction memory according to the process handle to obtain the target instruction memory can specifically be as follows: the daemon device allocates virtual memory space for the target code according to the thread handle, determines the assembly instruction memory according to the address information of the virtual memory space, replaces the original instruction memory with the assembly instruction memory, and writes the target code into the assembly instruction memory to obtain the target instruction memory.

[0095] It should be noted that the target code is stored in the target instruction memory, and the target code also includes callback instructions. After the target code is finished, the callback instructions will be used to return to the original instruction memory.

[0096] In some embodiments, reference Figure 4 As shown, step S300 may also include, but is not limited to, steps S310 to S320.

[0097] S310, the guardian device allocates virtual memory space to the target code according to the thread handle, and determines the assembly instruction memory according to the address information of the virtual memory space;

[0098] S320, the guardian device replaces the original instruction memory with the assembly instruction memory and writes the target code into the assembly instruction memory to obtain the target instruction memory.

[0099] In step S310 of some embodiments, the daemon allocates virtual memory space to the target code based on the thread handle, and determines the assembly instruction memory based on the address information of the virtual memory space. It can be understood that the specific execution steps of the daemon allocating virtual memory space to the target code based on the thread handle obtained in step S110, and determining the assembly instruction memory based on the address information of the virtual memory space, can be as follows: the daemon first calculates the target code to obtain the code data value of the target code, then allocates a virtual memory space of the same size as the code data value to the target code based on the thread handle, and then determines the assembly instruction memory based on the address information of the virtual memory space.

[0100] In step S320 of some embodiments, after executing step S310, where the daemon allocates virtual memory space for the target code based on the thread handle and determines the assembly instruction memory based on the address information of the virtual memory space, the daemon replaces the original instruction memory with the assembly instruction memory and writes the target code into the assembly instruction memory to obtain the target instruction memory. It can be understood that the daemon replaces the original instruction memory with the assembly instruction memory, and then writes the target code into the assembly instruction memory; the assembly instruction memory after the code is written is the target instruction memory.

[0101] In some embodiments, reference Figure 5 As shown, step S310 may also include, but is not limited to, steps S311 to S313.

[0102] S311, the guardian device calculates the target code to obtain the code data value of the target code;

[0103] S312, the guardian device allocates virtual memory space of the same size as the code data value to the target code according to the thread handle;

[0104] S313, the guardian device determines the assembly instruction memory based on the address information of the virtual memory space.

[0105] In step S311 of some embodiments, the guardian device calculates the target code to obtain the code data value of the target code. It can be understood that the guardian device calculates the data size of the target code to be injected into the target instruction memory, which is the code data value of the target code.

[0106] In step S312 of some embodiments, after the guardian device calculates the target code and obtains the code data value of the target code in step S311, the guardian device allocates a virtual memory space of the same size as the code data value to the target code based on the thread handle. It can be understood that the guardian device allocates a virtual memory space sufficient to accommodate the target code based on the thread handle obtained in step S110 and the code data value of the target code obtained in step S311, and the size of this virtual memory space is at least the code data value of the target code calculated in step S311.

[0107] In step S313 of some embodiments, after the daemon allocates a virtual memory space of the same size as the code data value to the target code according to the thread handle in step S312, the daemon determines the assembly instruction memory based on the address information of the virtual memory space. It can be understood that the daemon uses the starting address of the virtual memory space allocated in step S312, which is sufficient to accommodate the target code, as the new assembly instruction memory for the injected process; that is, it determines the assembly instruction memory based on the address information of the virtual memory space.

[0108] In step S400 of some embodiments, after the guardian device determines the assembly instruction memory based on the address information of the virtual memory space in step S313, the guardian device restores the main thread of the injected process according to the preset thread handle, and executes the target code through the main thread. It can be understood that the guardian device restores the main thread of the injected process according to the thread handle obtained in step S110, thereby enabling the execution of the target code through the main thread.

[0109] This embodiment has at least the following beneficial effects: First, when loading the process module, the import table is fully initialized. After the import table is fully initialized, the entry function of the injected process is executed, which is equivalent to executing the main function. Since the original instruction memory has been replaced by the target instruction memory, the target code is executed directly. Since the final callback instruction of the target code is to call back to the original instruction memory (the main function of the injected process).

[0110] In addition, embodiments of this application also provide a code execution method, including:

[0111] The target code injected by the kernel injection method at the process entry point as described in the above embodiments of the present invention;

[0112] Execute the target code in the target instruction memory;

[0113] The callback instruction in the target code is redirected to the original instruction memory.

[0114] In addition, embodiments of this application also provide a kernel injection system for process entry points, including:

[0115] The receiving module is used to guard the device to receive notification information, obtain the process information of the injected process based on the notification information, and determine the process handle of the injected process based on the process information.

[0116] The acquisition module is used by the guardian device to obtain the raw instruction memory of the injected process based on the process handle;

[0117] The replacement module is used to protect the device by modifying the original instruction memory according to the process handle to obtain the target instruction memory. The target instruction memory stores the target code, which includes callback instructions. The callback instructions are used to return to the original instruction memory after the target code is executed.

[0118] The recovery module is used by the guardian device to restore the main thread of the injected process according to the preset thread handle, and execute the target code through the main thread.

[0119] The specific implementation of the kernel injection system for the process entry point in this embodiment is basically the same as the specific implementation of the kernel injection method for the process entry point described above, and will not be repeated here.

[0120] In addition, embodiments of this application also provide a kernel injection device for process entry points, including:

[0121] At least one memory;

[0122] At least one processor;

[0123] At least one program;

[0124] The program is stored in memory, and the processor executes the at least one program to achieve:

[0125] The kernel injection method for the process entry point in the above embodiments of the present invention.

[0126] In addition, embodiments of this application also provide that the storage medium stores executable instructions that can be executed by a computer.

[0127] Memory, as a non-transitory storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0128] The embodiments described in this disclosure are for the purpose of more clearly illustrating the technical solutions of this disclosure and do not constitute a limitation on the technical solutions provided by this disclosure. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by this disclosure are also applicable to similar technical problems.

[0129] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0131] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0132] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0133] The preferred embodiments of the present disclosure have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present disclosure. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and spirit of the present disclosure shall be within the scope of the claims of the present disclosure.

Claims

1. A kernel injection method for process entry points, characterized in that, include: The daemon driver registers and loads callback functions to monitor the process file of the initial process; If the process file is a preset file, the guardian driver determines the injected process from the initial process and records the process information of the injected process; The guardian driver sends a notification message to the guardian device based on the process information and then enters a waiting state. The guardian device receives a notification message, obtains the process information of the injected process based on the notification message, and determines the process handle of the injected process based on the process information. The guardian device obtains the original instruction memory of the injected process based on the process handle; The guardian device modifies the original instruction memory according to the process handle to obtain the target instruction memory. The target instruction memory stores the target code, which includes a callback instruction. The callback instruction is used to return to the original instruction memory after the target code is executed. The guardian device restores the main thread of the injected process according to a preset thread handle, and executes the target code through the main thread; The guardian device modifies the original instruction memory according to the process handle to obtain the target instruction memory, including: The guardian device allocates virtual memory space to the target code according to the thread handle, and determines the assembly instruction memory according to the address information of the virtual memory space; The guardian device replaces the original instruction memory with the assembly instruction memory and writes the target code into the assembly instruction memory to obtain the target instruction memory; The guardian device allocates virtual memory space to the target code based on the thread handle, and determines the assembly instruction memory based on the address information of the virtual memory space, including: The guardian device calculates the target code to obtain the code data value of the target code; The guardian device allocates a virtual memory space of the same size as the code data value to the target code according to the thread handle; The guardian device determines the assembly instruction memory based on the address information of the virtual memory space.

2. The kernel injection method for process entry points according to claim 1, characterized in that, After the guardian device receives the notification information and obtains the process information of the injected process based on the notification information, the kernel injection method for the process entry point further includes: The guardian device feeds back the guardian driver response information based on the process information.

3. The kernel injection method for process entry points according to claim 2, characterized in that, The guardian device feeds back the guardian driver response information based on the process information, including: The guardian device locates the thread handle of the injected process based on the thread identifier of the process information; The guardian device suspends the main thread based on the thread handle and obtains the suspension information; The guardian device feeds back the response information to the guardian driver based on the suspension information.

4. A code execution method, characterized in that, The code execution method is used to execute the target code injected by the kernel injection method at the process entry point as described in any one of claims 1 to 3; Execute the target code in the target instruction memory; The callback instruction in the target code is redirected to the original instruction memory.

5. A kernel injection system for process entry points, characterized in that, The system is applied to the kernel injection method for the process entry point as described in any one of claims 1 to 3, including: The receiving module is used to receive notification information from the guardian device, obtain the process information of the injected process based on the notification information, and determine the process handle of the injected process based on the process information. The acquisition module is used by the guardian device to acquire the original instruction memory of the injected process based on the process handle; A replacement module is used by the guardian device to modify the original instruction memory according to the process handle to obtain a target instruction memory. The target instruction memory stores target code, and the target code includes a callback instruction, which is used to call back to the original instruction memory after the target code is executed. The recovery module is used by the guardian device to restore the main thread of the injected process according to a preset thread handle, and to execute the target code through the main thread.

6. A kernel injection device for a process entry point, characterized in that, include: At least one memory; At least one processor; At least one program; The program is stored in memory, and the processor executes the at least one program to achieve the following: The kernel injection method for process entry points as described in any one of claims 1 to 3.

7. A storage medium, characterized in that, The storage medium stores executable instructions that can be executed by a computer, causing the computer to perform the following: The kernel injection method for process entry points as described in any one of claims 1 to 3.

Images