CN117763538B - Dynamic link library injection method, device and computer readable medium - Google Patents

Abstract

A method, device and computer-readable medium for injecting a dynamic link library are provided. A method for injecting a dynamic link library is characterized by comprising: obtaining a UEFI startup file that has been solidified into a storage device; and injecting a dynamic link library using the UEFI startup file.

Description

Dynamic link library injection method, device and computer readable medium

Technical Field

The present invention relates to a method, device and computer-readable medium for injecting a dynamic link library (DLL). Specifically, the present invention relates to injecting a dynamic link library into a process so that the injected dynamic link library will not be closed and can be permanently resident in a computer system.

Background Art

Dynamic link library is a shared library implementation used to implement the concept of shared libraries in operating systems such as Windows and OS/2. Dynamic link library injection is a technique that allows dynamic link library files to be loaded into a target process and the code in it to be executed. There are many forms of dynamic link library injection, including asynchronous procedure call (APC) injection, message injection, registry injection, remote thread injection, input method injection, etc.

The above conventional injection methods have the disadvantages of easily exposing the injected dynamic link library, which may cause it to be quickly terminated or closed or even deleted, and it is not easy to achieve persistent residence. For example, remote thread injection is implemented in user mode, and its injection process may be discovered by security software, so it may be intercepted and cause injection failure. In addition, since this injection method exists in user mode, it cannot be injected into high-privilege processes, for example, it cannot be injected into services.exe, lsass.exe, smss.exe and other processes. In addition, remote thread injection cannot achieve persistent residence. In addition, if the file source of the dynamic link library is deleted, the dynamic link library disappears completely. From the user side, this will cause a loss of connection with the server, resulting in the inability to track the status of the user's product. For example, for a computing device such as a computer, after the driver of a hardware such as a graphics card is installed in the computer, a corresponding manager will exist in the computer. However, the manager may be abnormally closed or uninstalled, which will cause the computer to lose connection with the server, making it impossible for the server to collect data such as the status information of the graphics card. This loss of connection will also hinder the management of the graphics card and the repair of vulnerabilities.

Unified Extensible Firmware Interface (UEFI) is used to define the software interface between the operating system and the system firmware as an alternative to BIOS. UEFI is responsible for the power-on self-test (POST), contacting the operating system, and providing an interface between the operating system and the hardware. Shellcode is a piece of machine code (binary code) used to exploit software vulnerabilities. It is commonly used in the field of computer security, especially in penetration testing, vulnerability exploitation, and malware development.

Summary of the invention

According to one aspect of the present disclosure, a method for injecting a dynamic link library is provided, characterized in that it includes: obtaining a UEFI startup file that has been solidified in a storage device; and using the UEFI startup file to perform the injection of the dynamic link library. Through this method, the functions for injection can be implemented in the UEFI startup file that has been solidified in the storage device, thereby providing protection at the source of the file, because the UEFI startup file is not easily damaged. In addition, using the UEFI startup file to perform the injection of the dynamic link library enables the injection to be performed in the kernel state, thereby overcoming the shortcomings of the injection method in the user state described above.

In one aspect, the method further includes: linking the UEFI boot file and the firmware of the storage device into an image file; and fixing the image file into the storage device. Through this method, the firmware of the storage device further provides hardware firmware protection at the source of the file, ensuring the security of the source. In addition, linking the UEFI boot file and the firmware of the storage device into one file allows the computer to directly load this file at startup, thereby achieving fast startup and efficient operation.

In one aspect, the curing includes upgrading the image file to the storage device by means of a firmware upgrade interface of the storage device. Through this method, the UEFI boot file can be unbound and accessed only on hardware that has undergone a firmware upgrade. In this way, access rights to the UEFI boot file can be controlled, thereby improving the security of injection.

In one aspect, using the UEFI boot file to perform dynamic link library injection includes: running the UEFI boot file to perform the boot work and enter the operating system kernel environment; using the UEFI boot file to load the driver program in the operating system kernel environment; using the driver program loaded by the UEFI boot file operation to bury process monitoring to monitor the creation of a specified process; and in response to the creation of the specified process, using the driver program loaded by the UEFI boot file operation to inject the dynamic link library into the specified process. Through this method, the dynamic link library can be injected into the specified process in the operating system kernel environment, thereby overcoming the shortcomings of the injection method in user mode described above.

In one aspect, loading a driver using the UEFI boot file in the operating system kernel environment includes: extracting the driver from the shell code data area; allocating a section of memory in the memory pool of the operating system kernel environment that can accommodate the driver after memory alignment; copying the driver to the allocated memory; repairing the relocation table entry and import table entry of the driver; creating a driver object, obtaining the entry point of the driver; initializing the driver object; and calling the entry point of the driver to perform secondary initialization on the driver object. Through this method, extracting the driver from the shell code data area increases the security of the driver and reduces the risk of being detected and identified. Through this method, memory alignment is allocated to the driver, and then the driver is copied to the allocated memory and the relocation table entry and import table entry of the driver are repaired, ensuring that the driver can be correctly linked and executed.

In one aspect, using the driver loaded by the UEFI boot file operation to embed process monitoring to monitor the creation of a specified process includes: creating a device object with a random name during the initialization of the driver; and registering a process notification callback function of the driver to monitor the creation of the specified process. By registering the process notification callback function of the driver by this method, the process creation and destruction events in the operating system kernel environment can be monitored, so that necessary operations can be performed on the process before it runs, such as injecting a dynamic link library.

In one aspect, in response to the creation of the designated process, the driver loaded by the UEFI boot file operation is used to inject the dynamic link library into the interior of the designated process, including: registering the callback function of the driver to attach to the designated process; opening the created device object in the callback function of the driver; storing the device handle, interrupt vector number and random token in the user state shell code in the driver; allocating a readable, writable and executable memory from the virtual address space of the designated process in the callback function of the driver; writing the designated shell code and the dynamic link library into the readable, writable and executable memory in a memory copy manner; replacing the original entry point of the designated process with the entry point of the dynamic link library; using the address of the entry point of the dynamic link library as a parameter to update the translation back buffer of the central processing unit to clear the translation back buffer; and releasing the driver from attaching to the designated process. Through this method, it can be ensured that the dynamic link library is safely and correctly injected into the desired designated process in the operating system kernel environment without affecting the subsequent operation of the designated process. In addition, through this method, programs in user mode can use device handles, interrupt vector numbers and random tokens to communicate with the driver, that is, perform two-way verification, further improving the security of communication between the hardware device driver and the user end.

In one aspect, the method further includes initializing the dynamic link library through the shell code after the dynamic link library is injected, including: the shell code obtains the initial execution right of the specified process to perform the earliest initialization; the shell code performs the relocation work of the dynamic link library based on the entry point of the dynamic link library; the dynamic link library performs its own initialization and returns to the shell code after completion; and the shell code returns to the original entry point of the specified process, so as to start initializing the specified process. Through this method, it can be ensured that the injected dynamic link library is initialized and takes effect safely and correctly, and that the specified process injected into the dynamic link library is subsequently initialized and runs safely and correctly.

According to one aspect of the present disclosure, a dynamic link library injection device is provided, characterized in that it includes: a startup file acquisition module, used to obtain a UEFI startup file that has been solidified into a storage device; and an injection module, used to perform dynamic link library injection using the UEFI startup file.

In one aspect, the device further includes: a linking module, configured to link a UEFI boot file and a firmware of the storage device into an image file; and a curing module, configured to curate the image file into the storage device.

In one aspect, the flashing includes upgrading the image file to the storage device via a firmware upgrade interface of the storage device.

In one aspect, the injection module uses the UEFI startup file to perform injection of the dynamic link library, including: running the UEFI startup file to perform startup work and enter the operating system kernel environment; using the UEFI startup file to load a driver program in the operating system kernel environment; using the driver program loaded by the UEFI startup file operation to embed process monitoring to monitor the creation of a specified process; and in response to the creation of the specified process, using the driver program loaded by the UEFI startup file operation to inject the dynamic link library into the interior of the specified process.

In one aspect, the injection module uses the UEFI boot file to load the driver in the operating system kernel environment, including: extracting the driver from the shell code data area; allocating a section of memory in the memory pool of the operating system kernel environment that can accommodate the driver after memory alignment; copying the driver to the allocated memory; repairing the relocation table entries and import table entries of the driver; creating a driver object and obtaining the entry point of the driver; initializing the driver object; and calling the entry point of the driver to perform secondary initialization on the driver object.

In one aspect, the injection module uses the driver loaded by the UEFI boot file operation to embed process monitoring to monitor the creation of a specified process, including: creating a device object with a random name during the driver initialization process; and registering the driver's process notification callback function to monitor the creation of the specified process.

In one aspect, the injection module responds to the creation of the designated process, and utilizes the driver loaded by the UEFI startup file operation to inject the dynamic link library into the interior of the designated process, including: registering the callback function of the driver to attach to the designated process; opening the created device object in the callback function of the driver; storing the device handle, interrupt vector number and random token in the user-mode shell code in the driver; allocating a readable, writable and executable memory from the virtual address space of the designated process in the callback function of the driver; writing the designated shell code and the dynamic link library into the readable, writable and executable memory in a memory copy manner; replacing the original entry point of the designated process with the entry point of the dynamic link library; using the address of the entry point of the dynamic link library as a parameter to update the translation lookaside buffer of the central processing unit to clear the translation lookaside buffer; and releasing the driver from attaching to the designated process.

In one aspect, the device also includes an initialization module, which is used to initialize the dynamic link library through the shell code after the dynamic link library is injected, including: the shell code obtains the initial execution right of the specified process to perform the earliest initialization; the shell code performs the relocation of the dynamic link library based on the entry point of the dynamic link library; the dynamic link library performs its own initialization and returns to the shell code after completion; and the shell code returns to the original entry point of the specified process to start initializing the specified process.

According to one aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to call the instructions stored in the memory to execute the above method.

According to one aspect of the present disclosure, a computer readable medium having instructions stored thereon is provided, wherein when the instructions are executed, the computing device is caused to perform the method described according to the present disclosure.

Through the present disclosure, the dynamic link library can be protected and safely injected into the desired process. The injection according to the present disclosure is protected from the source of the file, such as hardware firmware, and the dynamic link library can be injected into the system process in the kernel environment, so that it cannot be forcibly terminated or closed. Therefore, the injection according to the present disclosure effectively solves the problem of the user terminal losing connection with the server due to the abnormal uninstallation of the hardware device manager such as the graphics card.

BRIEF DESCRIPTION OF THE DRAWINGS

Specific exemplary embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, the present disclosure may be implemented in many different forms and should not be construed as being limited to the embodiments set forth herein; rather, these embodiments are provided to make the disclosure comprehensive and complete and will fully convey the scope of the present disclosure to those skilled in the art. The terms used in the detailed description of specific exemplary embodiments shown in the accompanying drawings are not intended to be limiting of the present disclosure. In the accompanying drawings, like numbers refer to like parts.

FIG. 1 is a flow chart showing a method for injecting a dynamic link library according to an embodiment of the present disclosure.

FIG. 2 is a flow chart showing a method for performing injection of a dynamic link library using a UEFI startup file according to another embodiment of the present disclosure.

FIG. 3 is a schematic diagram showing the injection of a dynamic link library during the startup process of a Windows operating system according to another embodiment of the present disclosure.

FIG. 4 is a block diagram showing a device for injecting a dynamic link library according to another embodiment of the present disclosure.

FIG. 5 is a block diagram illustrating a computing device according to an embodiment of the present disclosure.

DETAILED DESCRIPTION

In order to make the purpose, technical solution and advantages of the present disclosure more clear, the technical solution of the present disclosure is further described below with reference to the accompanying drawings and examples. It should be further understood that the term "comprising" used in this specification means the presence of the stated features, steps, operations, parts and/or components, but does not exclude the presence or addition of one or more other features, steps, operations, parts, components and/or groups thereof.

FIG. 1 is a flow chart showing a method 100 for injecting a dynamic link library according to an embodiment of the present disclosure.

As shown in Figure 1, at step 102, a UEFI boot file that has been solidified into a storage device is obtained. The UEFI boot file may include all boot functions for starting a computing device such as a computer, which includes a boot program and other necessary boot information of an operating system of a computing device such as a computer. In one embodiment, the UEFI boot file may include all functions implemented according to the present disclosure, such as all functions related to injecting a dynamic link library. The storage device may include various types of storage devices for storing code and data, such as a hard disk (e.g., a solid-state hard disk, etc.), a removable storage device (e.g., a USB flash drive, an SD card, a CF card, an external hard drive, etc.), an optical disk (e.g., a CD-ROM, a DVD-ROM, and a Blu-ray disc, etc.), a tape storage device, and the like. In the present disclosure, the UEFI boot file can preferably be fixed to one or more of the following storage devices: a hard disk, especially in a system partition of the hard disk or an Extensible Firmware Interface (EFI) system partition; a removable storage device, in which the UEFI boot file can also be fixed, so that it can be connected to a computer to realize booting from the removable storage device; an optical disk, in which the UEFI boot file can also be fixed, for example, to make a UEFI boot optical disk or an installation optical disk, so that the computer can boot from the optical disk and load the UEFI boot file. In this way, the various functions implemented according to the present disclosure can be effectively protected, because the data and code embodying these functions can all be implemented in the UEFI boot file that has been fixed to the above-mentioned non-volatile storage device, and such a UEFI boot file is difficult to be destroyed and tampered with.

In one example, the UEFI boot file that has been solidified into the storage device can be obtained by the following operations: entering the UEFI setting interface after the computer is powered on; and navigating to the boot order (Boot Order) or similar options in the boot (Boot) or similar options in the UEFI setting interface, so that the UEFI boot file can be found and obtained accordingly.

Alternatively or additionally, in one embodiment, the UEFI boot file and the firmware of the storage device can be linked into an image file, and the image file can be fixed to the storage device. The firmware of the storage device is a software for managing hardware devices, which contains the driver and other necessary information of the hardware device. The image file contains an image that completely copies or backs up a specific system, application or data, such as a read-only memory (ROM) file, a BIN (Binary) file, an ISO file, an IMG (Image) file, and the like. The read-only memory file is used to store a mirror or backup of the read-only memory in the computer system. In one example, the UEFI boot file and the firmware of the storage device can be linked into a read-only memory file, and the read-only memory file can be fixed to the storage device. For example, the UEFI boot file and the firmware of the storage device can be linked together as a read-only memory file by a dedicated imaging tool, a read-only memory copy device or an emulator, and the read-only memory file can be fixed to the storage device by burning. Alternatively, the read-only memory file can be stored in the storage device by direct copying. Since the read-only memory file is read-only and cannot be modified or deleted, the UEFI boot file including all functions according to the present disclosure is further protected by hardware firmware through the linking and solidification as described above, thereby ensuring the security of the file source. In addition, linking the UEFI boot file and the firmware of the storage device into one file allows the computer to directly load this file when it starts, thereby achieving fast startup and efficient operation.

Alternatively or additionally, the UEFI boot file and the firmware of the storage device may be solidified as a whole into the storage device in the following ways: file system, storing the UEFI boot file and the firmware of the storage device as files in the file system of the storage device; embedding the UEFI boot file and the firmware of the storage device into the installation medium of the operating system, so that when the operating system is installed, the UEFI boot file and the firmware of the storage device can be written into the storage device together; special partition, creating a special partition to store the UEFI boot file and the firmware of the storage device, and so on.

Alternatively or additionally, the curing includes upgrading the image file to the storage device by means of a firmware upgrade interface of the storage device. Through this method, the UEFI startup file can be unbound and accessed only on hardware that has undergone a firmware upgrade. In this way, access rights to the UEFI startup file can be controlled, thereby further improving the security of the injection according to the present disclosure.

Alternatively or additionally, in an embodiment in which the UEFI boot file and the firmware of the storage device are linked into a read-only memory file, the UEFI boot file solidified in the storage device can be obtained by the following operations: after the computer is powered on, the read-only memory file of the storage device is started and initialized; the UEFI and/or BIOS (basic input and output system) detects the UEFI partition of the storage device to search for the UEFI boot file; the firmware of the storage device receives the search request, reads the UEFI boot file from the read-only memory file, and returns it to the memory area specified by the UEFI and/or BIOS.

At step 104, the injection of the dynamic link library is performed using the UEFI boot file. As described above, in one embodiment, the UEFI boot file obtained may include all functions implemented according to the present disclosure, such as all functions related to the injection of the dynamic link library. In this way, after the computer is powered on and UEFI performs the initialization of the computer operating system to enter the operating system kernel environment, the injection of the dynamic link library can be performed in the operating system kernel environment. In other words, in this embodiment, the injection of the dynamic link library according to the present disclosure can be performed in the kernel state, so that the injection process will not be intercepted by the security software and cause the injection failure, and the dynamic link library can be injected into a high privileged process (for example, services.exe, lsass.exe, smss.exe and other processes), so that it can be permanently resident in the operating system. Accordingly, the user end using the injected dynamic link library can communicate with the server persistently, so that the status of the user product can be tracked persistently.

The method of using a UEFI startup file to perform dynamic link library injection will be further described below in conjunction with Figure 2. Figure 2 is a flow chart showing a method 200 of using a UEFI startup file to perform dynamic link library injection according to another embodiment of the present disclosure.

As shown in FIG2 , at step 202, the UEFI startup file is run to perform the startup work and enter the operating system kernel environment. The UEFI startup file can be obtained in the manner described above. After obtaining the UEFI startup file, the UEFI can perform a series of initialization operations for the operating system to enter the operating system kernel environment. For example, in an embodiment of the Windows operating system, one or more of the following modules in its kernel environment may be initialized: EFIDXE, which is the EFI driver execution environment (Driver Execution Environment, or DXE); the loader module Loader.efi, which reads system startup data from the BCDedit database (which is a database developed by Microsoft) when executed; the monitoring module EfiMonitor.efi, which is used to enable monitoring of system startup; the Bootmgrfw.efi module, which is used to execute a normal boot process; the WinPE module, which is a lightweight operating system environment for deploying, maintaining and restoring the Windows operating system; the EFIBootService module, which is the EFI boot server, which includes event services, memory management services, various protocol services, etc.; the BootMgr module, which is used to manage startup operations and load the operating system; the Winload.efi module, which is used to load the kernel (ntoskrnl.exe) and other necessary system files of the Windows operating system; the EFI Runtime Service (EFI Runtime Service). Services) module, which is used to interact with the firmware when the operating system is running; Ntkrnlmp.exe module, which contains the core components and functions of the operating system and is responsible for managing and controlling various resources and operations of the computer; Hardware Abstraction Layer (Hal) module, which is located between the operating system kernel and the hardware and provides an abstract and unified access interface to the hardware, etc., as shown in Figure 3. In the process of initializing these modules in the kernel environment, various messages generated during system startup can be monitored and intercepted through message processing mechanisms such as hooks, and program modification methods such as patches can be used to control the initialization process of the operating system kernel environment.

At step 204, the driver is loaded using the UEFI boot file in the operating system kernel environment. The driver is a program for controlling a hardware device, which can interact with the hardware device to achieve control of the hardware device. For example, according to the present disclosure, in an example where the hardware device is a graphics card, the driver corresponding to the graphics card can be a kernel mode display driver (KMD) of the graphics card, which directly interacts with the graphics card hardware and provides an access interface to the graphics card function. When the operating system kernel environment is established, the driver can be loaded and linked to the hardware device to achieve control of the hardware device. Loading the driver may include initializing and configuring the driver. The initialization operation may include setting driver parameters, allocating memory, registering callback functions, etc. A callback function is a function that is passed as a parameter to another function and is called after the function is executed. According to the present disclosure, initialization and configuration of the driver is performed according to the functions implemented in the UEFI boot file. Specifically, the UEFI boot file including the functions according to the present disclosure can control the initialization of the driver, such as allocating the desired size of memory and registering a specific callback function to achieve the desired operation, such as dynamic link library injection, etc.

Alternatively or additionally, using the UEFI boot file to load the driver may include extracting the driver from the shell code data area. This means that the driver can be pre-stored in the shell code data area, so the driver does not need to be stored in a storage device in plain text, which increases the security of the driver. In addition, by embedding the driver in the shell code data area, the driver can be provided with cross-platform or cross-architecture support. Shell code is an executable code for a specific platform and architecture. By loading and executing the shell code, the same driver can be run on different operating systems or architectures. Using the UEFI boot file to load the driver may also include allocating a section of memory that can accommodate the driver after memory alignment in the memory pool of the operating system kernel environment. In this way, the driver can be stored in the memory pool of the operating system kernel environment, so that the driver has higher performance and controllability, thereby achieving efficient control of hardware devices. Using the UEFI boot file to load the driver may also include copying the driver to the allocated memory. In one example, the driver can be copied to the memory region by region according to 4k alignment, that is, partition loading of a portable executable file (Portable Executable, abbreviated PE) is performed. 4K alignment is a memory alignment method that can improve the efficiency of memory access and thus improve computer performance. Specifically, 4K alignment is to align data in multiples of 4K bytes. For example, if the starting address of the data is 0x1000, then according to the 4K alignment method, the starting address of the data should be a multiple of 0x1000, that is, 0x1000, 0x2000, 0x3000, etc.

Further, using the UEFI boot file to load the driver can also include repairing the relocation table entries and import table entries of the driver. In the above example of partition loading of PE files, after the driver is loaded into the kernel memory, the relocation items and import table entries in the PE file need to be repaired to ensure that the driver can be correctly linked and executed. Using the UEFI boot file to load the driver can also include creating a driver object and obtaining the entry point of the driver. The driver object is an instance of a driver, which contains the status and properties of the driver. The entry point of the driver refers to the main function of the driver, which is the execution entry of the driver. After the driver is loaded into the kernel memory, it is necessary to create a driver object and obtain the entry point of the driver so that the operating system can call the main function of the driver to achieve control of the hardware device. Using the UEFI boot file to load the driver can also include initializing the driver object. The process of initializing the driver object can include setting the parameters of the driver object, allocating memory, registering callback functions, etc. Using the UEFI boot file to load the driver can also include calling the entry point of the driver and performing secondary initialization on the driver object. Performing secondary initialization on the driver object can further configure and initialize the device object to implement additional functions, such as registering additional callback functions, allocating resources, establishing communication channels, etc. This is because some initialization steps need to be performed after the device object is created.

At step 206, the driver loaded by the UEFI boot file operation is used to embed process monitoring to monitor the creation of the specified process. According to the present disclosure, the specified process can be any process that can be injected with a dynamic link library, such as an application process, a system process, a service process, etc. In particular, in one embodiment, the dynamic link library can be injected into system processes such as services.exe, lsass.exe, and smss.exe. By injecting the dynamic link library into the system process, it cannot be forcibly terminated or closed, thereby avoiding the problem of losing connection with the client and the server.

Alternatively or additionally, the embedded process monitoring may also include creating a device object with a random name during the initialization process of the driver. When creating a device object, a device object with a random name may be created for it. In one example, a specific name may also be specified for the device object, but the present disclosure is not limited thereto. The embedded process monitoring may also include registering a process notification callback function of the driver to monitor the creation of the specified process. By registering the process notification callback function of the driver, the process creation and destruction events in the operating system kernel environment may be monitored, so that necessary operations may be performed on the process before it runs, such as injecting a dynamic link library into a specified process. Optionally, the embedded process monitoring may also include registering interrupt handling, so that the driver provides an interrupt handling function to the operating system for handling specific interrupt events. In this way, in certain specific cases where dynamic link library injection is associated with an interrupt handler, the corresponding input event may be intercepted by registering an interrupt handling function, and custom operations may be performed in the dynamic link library.

At step 208, in response to the creation of the specified process, the driver loaded by the UEFI boot file operation is used to inject the dynamic link library into the inside of the specified process. According to the present disclosure, various methods can be used to inject the dynamic link library into the process under the kernel environment, including but not limited to: kernel module loading (Kernel Module Loading), under the kernel environment, dynamic link library injection can be achieved by loading a custom kernel module, the kernel module can contain custom code and data, and custom operations can be performed in the context of the specified process; kernel hook (Kernel Hooking), by setting a hook in the system function of the specified process, function calls can be intercepted and redirected to custom code; and kernel driver injection (Kernel Driver Injection), by loading the driver in the kernel environment and registering the corresponding callback function, it is associated with the specified process, and the custom code can be executed in the context of the specified process to achieve dynamic link library injection, as further described below.

Alternatively or additionally, injecting the dynamic link library into the specified process may include registering a callback function of the driver to attach to the specified process. In this operation, a callback object may be created and a callback function may be registered during the initialization process of the driver, and then the creation of the specified process may be waited for. In this process, it is not necessary to know the information of the specified process. When the specified process is created, the system will call the callback function registered by the driver to respond to the process creation event. Injecting the dynamic link library into the specified process may also include opening the created device object in the callback function of the driver. In the callback function, the driver may open the device object created by itself and perform some necessary operations, such as reading data, writing data, updating status, etc. Injecting the dynamic link library into the specified process may also include storing the device handle, interrupt vector number and random token in the user state shell code in the driver. Through this operation, when in user mode, the program in user mode can use the above-mentioned device handle, interrupt vector number and random token to communicate with the driver, that is, two-way verification for the communication can be performed to improve security.

Injecting the dynamic link library into the specified process may also include allocating a readable, writable and executable memory from the virtual address space of the specified process in the callback function of the driver. The virtual address space is a piece of memory space allocated by the operating system for each process, which is used to store information such as code, data and stack. It should be noted that the driver can allocate a readable, writable and executable memory from the high-end address of the virtual address space of the specified process by calling the ZwAllocateVirtualMemory function to ensure that the allocated memory can be accessed by the specified process. ZwAllocateVirtualMemory is a function in the Windows kernel that is used to allocate a segment of memory in the virtual address space of the specified process. Injecting the dynamic link library into the specified process may also include writing the specified shell code and the dynamic link library into the readable, writable and executable memory in a memory copy manner. The segment of memory allocated from the virtual address space of the specified process is also called the user mode memory of the specified process, which is only visible and operated in the user mode of the specified process. The user mode memory of each process is isolated from each other. Various functions (such as WriteProcessMemory) can be used to write the shell code and the dynamic link library into the allocated memory of the specified process. For example, the binary data of the shell code may be first written to the beginning of the memory, and then the binary data of the dynamic link library may be written to an appropriate location of the memory, usually a location after the shell code.

Injecting the dynamic link library into the specified process may also include replacing the original entry point of the specified process with the entry point of the dynamic link library. Through this operation, it can be ensured that the written data (for example, the injected dynamic link library) can be accessed by the specified process, so that the injected dynamic link library is initialized before the specified process is initialized. Injecting the dynamic link library into the specified process may also include using the address of the entry point of the dynamic link library as a parameter to update the translation lookaside buffer of the central processing unit to clear the translation lookaside buffer. Translation lookaside buffer (TLB) is a high-speed cache for storing the mapping relationship between virtual addresses and physical addresses. When the CPU accesses the memory, the memory management unit (MMU) will first search the physical address corresponding to the virtual address in the translation lookaside buffer. If there is no hit in the translation lookaside buffer, it is necessary to query the page table to obtain the physical address. Using the address of the new entry point as a parameter to update the translation lookaside buffer can invalidate the translation lookaside buffer to clear it, which can prevent the memory management unit of the CPU from hitting the physical address in the original translation lookaside buffer when fetching instructions. After clearing, when the CPU fetches instructions, the memory management unit does not hit, thereby forcing the CPU to refresh the query page table or segment table to reload the new physical memory for the injected dynamic link library. Injecting the dynamic link library into the specified process can also include de-pending the driver to the specified process. By de-pending, the operations that have been performed (for example, injection, hook, etc.) are removed from the specified process, and the specified process is restored to the original state. For example, de-pending can include closing or releasing the handle of the specified process, releasing the memory allocated from the specified process, etc.

Alternatively or additionally, after the dynamic link library is injected, the dynamic link library can be initialized by the shell code. For example, after the specified process is created by monitoring as described above, the dynamic link library is initialized. Initializing the dynamic link library by the shell code may include: the shell code obtains the initial execution right of the specified process to perform the earliest initialization. In this operation, the shell code can obtain the handle of the specified process for subsequent operations; and allocate memory in the specified process for loading and executing the dynamic link library or other initialization code. Initializing the dynamic link library by the shell code may also include: the shell code performs the relocation of the dynamic link library based on the entry point of the dynamic link library. Relocation refers to adjusting the address reference in the dynamic link library according to the actual memory layout before loading the dynamic link library into the memory and starting to execute, so as to ensure that the code and data can correctly access the memory location they need. The relocation operation may include loading the dynamic link library into the memory, parsing the import table of the dynamic link library, performing relocation processing, etc. It should be noted that the relocation operation can be performed by the function used inside the operating system, so there is no need to repair the export table of the dynamic link library. Initializing the dynamic link library through the shell code can also include: the dynamic link library performs its own initialization and returns the shell code after completion. For example, the initialization of the dynamic link library itself can be performed by calling the DllMain function of the Windows operating system, so that it can take effect and be called and used by other programs. In addition, during the initialization process of the dynamic link library, the data injected by the driver can be saved for use in other functions of the dynamic link library. For example, the injected data can be copied to a global variable in the DllMain function for later use. The data injected here can include handles or object references in the operating system or application program, configuration information, etc. Initializing the dynamic link library through the shell code can also include: the shell code returns to the original entry point of the specified process, so that the specified process starts to be initialized. When the dynamic link library is initialized, the shell code returns to the original entry point of the specified process and continues to perform subsequent operations of the specified process to initialize the specified process.

After the process described above is completed, the injected dynamic link library becomes effective, so that it can be called and used by other programs. Specifically, the dynamic link library can provide some functions or data, and after it becomes effective, other programs can implement the desired functions by calling these functions or data in the dynamic link library. For example, the injected dynamic link library can be used to protect the graphics card driver, and the effectiveness of the injected dynamic link library enables the graphics card driver to implement one or more of the following functions: the user-side program can use the device handle or interrupt vector stored in the user mode shell code as described above, for example, to use a random token to perform two-way authentication with the graphics card driver to improve security; perform online upgrades on the graphics card firmware; call the graphics card driver to execute various performance strategies, thereby performing various performance optimizations on the graphics card (for example, adjusting the operating frequency, voltage, fan speed and other parameters of the graphics card); and collect error logs associated with the graphics card and/or the graphics card driver for logging and/or server upload. It should be understood that the graphics card is used as an example here only, and the injected dynamic link library can implement one or more of the above functions for any suitable hardware device.

FIG. 3 is a schematic diagram showing the injection of a dynamic link library during the startup process of a Windows operating system according to another embodiment of the present disclosure.

As shown in FIG3 , the UEFI boot file and the hard disk firmware can be linked together and burned into the hard disk firmware in the various ways described above. After a computing device such as a computer is powered on, the UEFI boot file is returned from the hard disk firmware to obtain a UEFI boot file including various functions according to the present disclosure. After obtaining the UEFI boot file, the UEFI can perform a series of initialization operations for the operating system to enter the operating system kernel environment. For example, in the embodiment of the Windows operating system shown in FIG3 , one or more modules in its kernel environment can be initialized, as described above with respect to FIG2 .

When the initialization operation of the operating system proceeds to loading the driver, the dynamic link library injection operation according to the present disclosure can be performed as described above. As shown in Figure 3, by injecting the dynamic link library into the specified process in the process of loading the driver in the kernel environment, after the injected dynamic link library takes effect, the graphics manager in the user mode can call the dynamic link library to implement various functions. Specifically, the graphics manager can send an interrupt trigger to the CPU to initiate interaction with the driver. In response, the CPU can initiate interrupt processing to the driver so that the driver and the graphics manager can communicate and interact, such as implementing the various functions described above.

FIG4 is a block diagram showing a dynamic link library injection device according to another embodiment of the present disclosure. Referring to FIG4, a block diagram 400 of a dynamic link library injection device according to an embodiment of the present disclosure is shown. As shown in FIG4, the device 400 may include a boot file acquisition module 402 and an injection module 404. Specifically, the boot file acquisition module 402 is used to acquire a UEFI boot file that has been solidified into a storage device. The UEFI boot file solidified into the storage device may include all functions implemented according to the present disclosure, such as all functions related to injecting a dynamic link library. The injection module 404 is used to perform the injection of the dynamic link library using the UEFI boot file. In one embodiment, the injection module 404 can be used to: run the UEFI boot file to perform the startup work and enter the operating system kernel environment; load the driver using the UEFI boot file in the operating system kernel environment; use the UEFI boot file to operate the loaded driver to bury the process monitoring to monitor the creation of the specified process; and in response to the creation of the specified process, use the UEFI boot file to operate the loaded driver to inject the dynamic link library into the inside of the specified process. In another embodiment, the injection module 404 can be used to extract the driver from the shell code data area; allocate a section of memory in the memory pool of the operating system kernel environment that can accommodate the driver after memory alignment; copy the driver to the allocated memory; repair the relocation table entry and import table entry of the driver; create a driver object, obtain the entry point of the driver; initialize the driver object; and call the entry point of the driver to perform secondary initialization on the driver object. In another embodiment, the injection module 404 can be used to create a device object with a random name during the driver initialization process; and register the driver's process notification callback function to monitor the creation of a specified process. In another embodiment, the injection module 404 can be used to register the callback function of the driver to attach to the specified process; open the created device object in the callback function of the driver; store the device handle, interrupt vector number and random token in the user-mode shell code in the driver; allocate a readable, writable and executable memory from the virtual address space of the specified process in the callback function of the driver; write the specified shell code and dynamic link library into the readable, writable and executable memory in a memory copy manner; replace the original entry point of the specified process with the entry point of the dynamic link library; use the address of the entry point of the dynamic link library as a parameter to update the translation backup buffer of the central processing unit to clear the translation backup buffer; and release the driver from attaching to the specified process. In addition, the injection module 404 can perform injection using the UEFI boot file according to any method described above for performing injection of the dynamic link library, which will not be repeated here.

Alternatively or additionally, the device 400 may further include: a linking module, configured to link the UEFI boot file and the firmware of the storage device into an image file; and a curing module, configured to curate the image file into the storage device. Similarly, the linking module and the curing module may perform the above operations according to any of the methods described above, which will not be described in detail herein.

Alternatively or additionally, the device 400 may also include an initialization module for initializing the dynamic link library through a shell code after the dynamic link library is injected. After the dynamic link library is initialized, it can take effect, so that it can be called and used by other programs. In one embodiment, the initialization module initializing the dynamic link library through the shell code may include: the shell code obtains the initial execution right of the specified process to perform the earliest initialization; the shell code performs the relocation of the dynamic link library based on the entry point of the dynamic link library; the dynamic link library performs its own initialization and returns the shell code after completion; and the shell code returns to the original entry point of the specified process, so that the specified process begins to be initialized. Similarly, the initialization module can perform the above operations according to any method described above, which will not be repeated here.

It should be understood that, in various embodiments, the apparatus 400 may be used to perform the steps of any method as described above.

Additionally or alternatively, the above-mentioned method, universal docking module, service platform or third-party platform of the present disclosure can be implemented on one or more computers or servers or similar devices using computer processors, memory units, storage devices, computer software and other components. A high-level block diagram of such a computer or server is shown in FIG5. Here, computers, servers or other devices including processors are collectively referred to as computing devices. The computing device 502 includes a processor 504, which controls the operation of the computer 502 by executing computer program instructions that define the overall operation. The computer program instructions can be stored in a storage device 512 (e.g., a disk) and loaded into a memory 510 when the computer program instructions need to be executed. Therefore, the steps of the method with reference to FIG1 and FIG2 can be defined by computer program instructions stored in a memory 510 and/or a storage device 512, and controlled by a processor 504 that executes the computer program instructions. The computing device 502 also includes one or more network interfaces 506 for communicating with other devices via a network. The computing device 502 also includes other input/output devices 508 (e.g., a display, keyboard, mouse, speakers, buttons, etc.) that enable a user to interact with the computer 502. Those skilled in the art will recognize that an actual computer implementation may also include other components, and that FIG5 is a high-level representation of some components of such a computer for purposes of illustration.

The storage device 512 and the memory 510 each include a tangible, non-transitory computer-readable storage medium. The storage device 512 and the memory 510 may each include a high-speed random access memory, such as a dynamic random access memory (DRAM), a static random access memory (SRAM), a double data rate synchronous dynamic random access memory (DDR RAM), or other random access solid-state memory devices, and may include non-volatile memory, such as one or more magnetic disk storage devices (such as internal hard disks and removable disks), magneto-optical disk storage devices, optical disk storage devices, flash memory devices, semiconductor memory devices (such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)), compact disk read-only memory (CD-ROM), digital versatile disk read-only memory (DVD-ROM) disks, or other non-volatile solid-state storage devices.

In another embodiment, the above method, universal docking module, service platform or third-party platform can be implemented in a network-based cloud computing system. In such a network-based cloud computing system, the server communicates with one or more client computers via a network. The client computer can communicate with the server, for example, via a web browser application resident on and running on the client computer. The client computer can store data on the server and access the data via the network. The client computer can transmit data requests or online service requests to the server via the network. The server can implement the requested service and provide the data to (one or more) client computers. The server can also transmit data adapted to enable the client computer to implement a specified function (e.g., implement calculations, display specified data on the screen, etc.). Some steps of the above method can be implemented by a server or by other computers/processors in a network-based cloud computing system. Some steps of the above method can be implemented locally by a client computer in a network-based cloud computing system. The steps of the above method can be implemented in any combination by one or more devices in a network-based cloud computing system or by a local client computer.

The embodiment of the present disclosure also provides a computer-readable storage medium, on which computer program instructions are stored, and when the computer program instructions are executed by a processor, the above method is implemented. The computer-readable storage medium can be a volatile or non-volatile computer-readable storage medium.

An embodiment of the present disclosure further proposes an electronic device, comprising: a processor; and a memory for storing instructions executable by the processor; wherein the processor is configured to call the instructions stored in the memory to execute the above method.

The embodiments of the present disclosure also provide a computer program product, including a computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code. When the computer-readable code runs in a processor of an electronic device, the processor in the electronic device executes the above method.

The electronic device may be provided as a terminal, a server, or a device in other forms.

It should be appreciated that certain features of the disclosure described in the context of separate embodiments for clarity may also be provided in combination in a single embodiment. Conversely, various features of the disclosure described in the context of a single embodiment for simplicity may also be provided individually or in any suitable sub-combination or as appropriate in any other described embodiment of the disclosure. Certain features described in the context of various embodiments should not be considered essential features of those embodiments unless the embodiment is ineffective without those elements.

Although the present disclosure has been described in conjunction with the specific embodiments of the present disclosure, it is obvious that many substitutions, modifications and changes will be obvious to those skilled in the art. Therefore, it is intended to cover all such substitutions, modifications and changes that fall within the spirit and broad scope of the appended claims.

All publications, patents, and patent applications mentioned in this specification are incorporated herein by reference in their entirety to the same extent as if each individual publication, patent, or patent application was specifically and particularly indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this disclosure should not be construed as allowing such reference to be used as prior art in the present disclosure. Where section headings are used, they should not be construed as necessarily limiting.

Claims (10)

1. A method for injecting a dynamic link library, characterized by comprising: Obtaining the UEFI boot file that has been solidified into the storage device; and Utilizing the UEFI startup file to perform dynamic link library injection includes: Run the UEFI startup file to perform startup work and enter the operating system kernel environment; Loading a driver using the UEFI boot file in the operating system kernel environment; Using the driver loaded by the UEFI boot file operation to embed process monitoring to monitor the creation of a specified process; and In response to the creation of the designated process, the loaded driver is operated using the UEFI boot file to inject the dynamic link library into the designated process. 2. The method for injecting a dynamic link library according to claim 1, characterized in that the method further comprises: Linking the UEFI boot file and the firmware of the storage device into an image file; and The image file is fixed to the storage device. 3. The dynamic link library injection method according to claim 2, wherein the curing comprises upgrading the image file to the storage device by means of a firmware upgrade interface of the storage device. 4. The method for injecting a dynamic link library according to claim 1, wherein loading a driver using the UEFI boot file under the operating system kernel environment comprises: Extracting the driver from the shell code data area; Allocate a section of memory in the memory pool of the operating system kernel environment that can accommodate the driver program after memory alignment; Copying the driver into the allocated memory; Repairing the relocation table entries and import table entries of the driver; Create a driver object and obtain the entry point of the driver program; Initializing the driver object; and The entry point of the driver is called to perform secondary initialization on the driver object. 5. The method for injecting a dynamic link library according to claim 1, wherein the step of using the driver loaded by the UEFI boot file operation to embed a process monitor to monitor the creation of a specified process comprises: Creating randomly named device objects during initialization of the driver; and Registering a process notification callback function of the driver to monitor the creation of the specified process. 6. The method for injecting a dynamic link library according to claim 5, wherein in response to the creation of the designated process, using the driver loaded by the UEFI startup file operation to inject the dynamic link library into the interior of the designated process comprises: Registering a callback function of the driver to attach to the specified process; Open the created device object in the callback function of the driver; In the driver, the device handle, the interrupt vector number and the random token are stored in the user-mode shell code; In the callback function of the driver, a section of readable, writable and executable memory is allocated from the virtual address space of the designated process; Writing the specified shell code and the dynamic link library into the readable, writable and executable memory in a memory copying manner; Replacing the original entry point of the specified process with the entry point of the dynamic link library; Using the address of the entry point of the dynamic link library as a parameter, updating the translation lookaside buffer of the central processing unit to clear the translation lookaside buffer; and The driver is released from the specified process. 7. The method for injecting a dynamic link library according to claim 6, further comprising initializing the dynamic link library by the shell code after injecting the dynamic link library, comprising: The shell code obtains the initial execution right of the designated process to perform the earliest initialization; The shell code performs relocation of the dynamic link library based on the entry point of the dynamic link library; The dynamic link library performs its own initialization and returns the shell code after completion; and The shell code returns to the original entry point of the designated process so as to start initializing the designated process. 8. A dynamic link library injection device, characterized in that it comprises: A boot file acquisition module, used to acquire the UEFI boot file that has been solidified into the storage device; and An injection module, used to perform injection of a dynamic link library using the UEFI startup file, includes: Run the UEFI startup file to perform startup work and enter the operating system kernel environment; Loading a driver using the UEFI boot file in the operating system kernel environment; Using the driver loaded by the UEFI boot file operation to embed process monitoring to monitor the creation of a specified process; and In response to the creation of the designated process, the loaded driver is operated using the UEFI boot file to inject the dynamic link library into the designated process. 9. An electronic device, comprising: processor; a memory for storing processor-executable instructions; The processor is configured to call the instructions stored in the memory to execute the method described in any one of claims 1 to 7. 10. A computer readable medium having stored thereon instructions which, when executed, cause a computing device to perform the method of any one of claims 1 to 7.