CN117763538A - Injection method, device and computer readable medium for dynamic link library - Google Patents

Abstract

Injection methods, apparatus, and computer readable media for dynamic link libraries are provided. A method for injecting a dynamic link library, comprising: acquiring a UEFI starting file solidified into a storage device; and executing the injection of the dynamic link library by using the UEFI start file.

Description

Injection method, device and computer readable medium for dynamic link library

Technical Field

The present disclosure relates to a method, apparatus and computer readable medium for injection of a dynamic link library (Dynamic Link Library, abbreviated DLL). In particular, the present disclosure relates to injecting dynamic link libraries into a process such that the injected dynamic link libraries are not closed and can persist in a computer system.

Background

Dynamically linked libraries are one implementation of shared libraries for implementing 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 code therein to be executed. Dynamic link library injection takes many forms, including asynchronous procedure call (Asynchronous Procedure Call, abbreviated APC) injection, message injection, registry injection, remote thread injection, input method injection, and the like.

The conventional injection method has the defects that the injected dynamic link library is easily exposed, so that the dynamic link library can be quickly terminated or closed and even deleted, and persistent residence is not easy to realize. For example, remote thread injection is implemented in a user state, and the injection process may be discovered by security software, and thus may be intercepted to cause injection failure. In addition, since this injection method exists in the user mode, it cannot be injected into a highly privileged process, for example, into a process such as a service. In addition, remote thread injection also fails to achieve persistent persistence. In addition, if the file source of the dynamic link library is deleted once, the dynamic link library is completely disappeared. From the user side, this can lead to a loss of connection with the server, resulting in an inability to track the status of the user's product. For example, for a computing device such as a computer, after a driver of hardware such as a graphics card is installed in the computer, there will be a manager corresponding thereto in the computer. However, the manager may be abnormally turned off or uninstalled, which may cause the computer to be disconnected from the server, so that the server cannot collect data such as status information of the graphic card. Such a loss of connectivity may also prevent management of the graphics card and bug fixes.

A unified extensible firmware interface (Unified Extensible Firmware Interface, abbreviated UEFI) is used to define a software interface between an operating system and system firmware as an alternative to BIOS. UEFI is responsible for power-on self test (POST), contacting the operating system, and providing an interface to connect the operating system with hardware. Shell code (Shellcode) is a piece of machine code (binary code) that is used to exploit software vulnerabilities, which is commonly used in the field of computer security, particularly in penetration testing, exploit and malware development.

Disclosure of Invention

According to one aspect of the present disclosure, there is provided a method for injecting a dynamic link library, including: acquiring a UEFI starting file solidified into a storage device; and executing the injection of the dynamic link library by using the UEFI start file. By this method, the functions for injection can be implemented in the UEFI startup file that has been cured in the storage device, thereby providing protection at the file source, since the UEFI startup file is not easily destroyed. In addition, the injection of the dynamic link library is performed by using the UEFI start file, so that the injection can be performed in a kernel state, and the defects of the injection mode in a user state are overcome.

In one aspect, the method further comprises: linking a UEFI boot file with firmware of the storage device to form an image file; and solidifying the image file into the storage device. By the method, the firmware of the storage device further provides hardware firmware protection at the file source, and the source safety is ensured. In addition, the UEFI starting file and the firmware of the storage device are linked into one file, so that the file can be directly loaded by the computer during starting, and the quick starting and the high-efficiency operation are realized.

In one aspect, the curing includes upgrading the image file into the storage device by means of a firmware upgrade interface of the storage device. By the method, the UEFI boot file can be unbound and accessed only on hardware subjected to firmware upgrade. Thus, the access right to the UEFI startup file can be controlled, and the injection safety is improved.

In one aspect, performing injection of a dynamic link library using the UEFI initiation file includes: operating the UEFI start file to execute start work and entering an operating system kernel environment; starting a file loading driver by using the UEFI under the kernel environment of the operating system; utilizing the UEFI to start a driving program loaded by file operation to monitor creation of a designated process by embedding process monitoring; and in response to creation of the specified process, initiating a driver loaded by a file operation with the UEFI to inject the dynamically linked library into an interior of the specified process. By the method, the dynamic link library can be injected into the appointed process under the kernel environment of the operating system, so that the defects of the injection mode in the user mode are overcome.

In one aspect, launching a file load driver with the UEFI in the operating system kernel environment includes: extracting the driver from the shell code data area; distributing a section of memory capable of containing the driver after memory alignment in a memory pool of the kernel environment of the operating system; copying the driver program into the distributed memory; repairing the relocation table entry and the import table entry of the driver; creating a driving object and acquiring an entry point of the driving program; initializing the driving object; and calling an entry point of the driver program, and executing secondary initialization on the driving object. By this method, extracting the driver from the shell code data area increases the security of the driver, reducing the risk of being detected and identified. The method allocates the memory aligned with the memory for the driver, copies the driver into the allocated memory and repairs the relocation table entry and the import table entry of the driver, thereby ensuring that the driver can be correctly linked and executed.

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

In one aspect, in response to creation of the specified process, initiating a driver loaded by a file operation with the UEFI to inject the dynamically linked library into an interior of the specified process comprises: registering a callback function of the driver to be affiliated to the specified process; opening the created device object in a callback function of the driver; storing the device handle, the interrupt vector number and the random token into a user state shell code in the driver; distributing a section of readable and writable executable memory from a virtual address space of the appointed process in a callback function of the driver; writing the specified shell code and the dynamic link library into the readable and writable executable memory in a memory copying mode; replacing the original entry point of the appointed process with the entry point of the dynamic link library; updating a translation look-aside buffer of a central processing unit by taking an address of an entry point of the dynamic link library as a parameter so as to clear the translation look-aside buffer; and releasing the driver from the specified process. By the method, the dynamic link library can be safely and correctly injected into the expected designated process in the kernel environment of the operating system without affecting the running after the designated process. In addition, by the method, the program in the user mode can use the equipment handle, the interrupt vector number and the random token to communicate with the driver, namely, the bidirectional verification is carried out, so that the communication security between the hardware equipment driver and the user side is further improved.

In one aspect, the method further comprises 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 appointed process to perform earliest initialization; the shell code performs relocation work of the dynamic link library based on an entry point of the dynamic link library; the dynamic link library executes self initialization and returns the shell code after finishing; and the shell code returns to the original entry point of the specified process so that initialization of the specified process begins. By the method, the injected dynamic link library can be safely and correctly initialized and validated, and the subsequent safe and correct initialization and operation of the designated process of the injected dynamic link library can be ensured.

According to one aspect of the present disclosure, there is provided an injection apparatus for a dynamic link library, comprising: the starting file acquisition module is used for acquiring the UEFI starting file solidified in the storage device; and the injection module is used for executing the injection of the dynamic link library by using the UEFI start file.

In one aspect, the apparatus further comprises: the link module is used for linking the UEFI starting file and the firmware of the storage device into an image file; and a curing module for curing the image file into the storage device.

In one aspect, the curing includes upgrading the image file into the storage device by means of a firmware upgrade interface of the storage device.

In one aspect, the injection module performing injection of a dynamic link library using the UEFI initiation file includes: operating the UEFI start file to execute start work and entering an operating system kernel environment; starting a file loading driver by using the UEFI under the kernel environment of the operating system; utilizing the UEFI to start a driving program loaded by file operation to monitor creation of a designated process by embedding process monitoring; and in response to creation of the specified process, initiating a driver loaded by a file operation with the UEFI to inject the dynamically linked library into an interior of the specified process.

In one aspect, the injection module to launch a file load driver with the UEFI in the operating system kernel environment includes: extracting the driver from the shell code data area; distributing a section of memory capable of containing the driver after memory alignment in a memory pool of the kernel environment of the operating system; copying the driver program into the distributed memory; repairing the relocation table entry and the import table entry of the driver; creating a driving object and acquiring an entry point of the driving program; initializing the driving object; and calling an entry point of the driver program, and executing secondary initialization on the driving object.

In one aspect, the injection module utilizing the UEFI to initiate a driver loaded by a file operation to embed process monitoring to monitor creation of a specified process includes: creating a device object with a random name in the initialization process of the driver; and registering a process notification callback function of the driver to monitor creation of the specified process.

In one aspect, the injection module, in response to creation of the specified process, initiating a driver loaded by a file operation with the UEFI to inject the dynamically linked library into an interior of the specified process comprises: registering a callback function of the driver to be affiliated to the specified process; opening the created device object in a callback function of the driver; storing the device handle, the interrupt vector number and the random token into a user state shell code in the driver; distributing a section of readable and writable executable memory from a virtual address space of the appointed process in a callback function of the driver; writing the specified shell code and the dynamic link library into the readable and writable executable memory in a memory copying mode; replacing the original entry point of the appointed process with the entry point of the dynamic link library; updating a translation look-aside buffer of a central processing unit by taking an address of an entry point of the dynamic link library as a parameter so as to clear the translation look-aside buffer; and releasing the driver from the specified process.

In one aspect, the apparatus further comprises an initialization module for initializing the dynamic link library by the shell code after the dynamic link library is injected, comprising: the shell code obtains the initial execution right of the appointed process to perform earliest initialization; the shell code performs relocation work of the dynamic link library based on an entry point of the dynamic link library; the dynamic link library executes self initialization and returns the shell code after finishing; and the shell code returns to the original entry point of the specified process so that initialization of the specified process begins.

According to one aspect of the present disclosure, there is provided an electronic device including: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to invoke the instructions stored in the memory to perform the above method.

According to one aspect of the present disclosure, there is provided a computer-readable medium having instructions stored thereon that, when executed, cause a computing device to perform a method described in accordance with the present disclosure.

Through the present disclosure, dynamically linked libraries may be securely injected into a desired process in a protected manner. Injection according to the present disclosure begins from a file source protected, such as hardware firmware, and a dynamically linked library may be injected into a system process in a kernel environment such that it cannot be forced to terminate or shut down. Thus, the injection according to the present disclosure effectively solves the problem that the hardware device manager such as a graphics card is abnormally offloaded, resulting in the loss of the client and the server.

Drawings

Specific exemplary embodiments of the present disclosure will now be described with reference to the accompanying drawings. This disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art. The terminology used in the detailed description of the particular exemplary embodiments illustrated in the accompanying drawings is not intended to be limiting of the disclosure. In the drawings, like numerals refer to like parts.

Fig. 1 is a flow chart illustrating a method of injection of a dynamic link library, according to an embodiment of the present disclosure.

Fig. 2 is a flow chart illustrating a method of performing injection of a dynamically linked library using a UEFI initiation file, in accordance with another embodiment of the present disclosure.

FIG. 3 is a schematic view illustrating injection of a dynamically linked library during a Windows operating system boot process according to another embodiment of the present disclosure.

Fig. 4 is a block diagram illustrating an injection apparatus of 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 objects, technical solutions and advantages of the present disclosure more apparent, the technical solutions of the present disclosure will be further described below with reference to the accompanying drawings and examples. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, steps, operations, components, and/or groups thereof, but do not preclude the presence or addition of one or more other features, steps, operations, components, groups, and/or groups thereof.

Fig. 1 is a flow chart illustrating an injection method 100 of a dynamic link library, according to an embodiment of the present disclosure.

As shown in fig. 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 booting a computing device, such as a computer, including boot programs and other necessary boot information for the operating system of the computing device, such as a computer. In one embodiment, the UEFI startup file may include all functions implemented in accordance with 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 disk, etc.), a removable storage device (e.g., a USB flash drive, SD card, CF card, external hard drive, etc.), an optical disk (e.g., CD-ROM, DVD-ROM, blu-ray disk, etc.), a tape storage device, etc. In the present disclosure, the UEFI boot file may preferably be consolidated into one or more of the following storage devices: hard disk, in particular in a system partition of the hard disk or in an extensible firmware interface (Extensible Firmware Interface ", abbreviated EFI) system partition; a removable storage device in which the UEFI boot file may also be cured so that it may be connected to a computer to enable booting from the removable storage device; the compact disc, the UEFI boot file, may also be cured in the compact disc, such as by making the UEFI boot compact disc or installing the compact disc so that the computer may boot and load the UEFI boot file from the compact disc. In this way, various functions implemented in accordance with the present disclosure may be effectively protected, as data and code embodying these functions may all be implemented in a UEFI boot file that has been solidified into the above-described non-volatile storage device, such UEFI boot file being difficult to destroy and tamper with.

In one example, a UEFI boot file that has been solidified into storage may be obtained by: entering a UEFI setting interface after the computer is powered on; and navigating to a Boot Order (Boot Order) or the like in a Boot (Boot) or the like in the UEFI setting interface, so that the UEFI Boot file can be searched and correspondingly acquired.

Alternatively or additionally, in one embodiment, the UEFI boot file may be linked with the firmware of the storage device into an image file and the image file may be cured into the storage device. The firmware of the storage device is software for managing the hardware device, and contains the driver of the hardware device and other necessary information. The Image file contains an Image that makes a complete copy or backup of 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 read-only memory in a computer system. In one example, the UEFI boot file may be linked with firmware of the storage device into a read-only memory file and the read-only memory file may be solidified into the storage device. For example, the UEFI boot file may be linked with the firmware of the storage device as a read-only memory file by a dedicated image tool, read-only memory copying device, or emulator, and the read-only memory file may be cured into the storage device by burning. Alternatively, the read-only memory file may 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 startup file including all functions according to the present disclosure is further protected by hardware firmware through linking and curing as described above, and the security of the file source is ensured. In addition, the UEFI starting file and the firmware of the storage device are linked into one file, so that the file can be directly loaded by the computer during starting, and the quick starting and the high-efficiency operation are realized.

Alternatively or additionally, the UEFI boot file may also be solidified into the storage device as a whole with the firmware of the storage device by: a file system for 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 starting file and the firmware of the storage device into an installation medium of the operating system, so that the UEFI starting file and the firmware of the storage device can be written into the storage device together when the operating system is installed; special partition, creating a special partition to store UEFI boot files and firmware of the storage device, etc.

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

Alternatively or additionally, in embodiments where the UEFI boot file is linked with firmware of the storage device into a read-only memory file, the UEFI boot file that has been cured in the storage device may be obtained by: after the computer is powered on, the read-only memory file of the storage device is started and initialized; UEFI and/or BIOS (basic input output system) detects UEFI partitions of the storage device to find UEFI boot files; and the firmware of the storage device receives the search request, reads the UEFI starting file from the read-only memory file and returns the UEFI starting file to the memory area designated by the UEFI and/or the BIOS.

At step 104, injection of the dynamic link library is performed using the UEFI start file. As described above, in one embodiment, the acquired UEFI startup file may include all functions implemented in accordance with the present disclosure, such as all functions related to injecting a dynamic link library. Thus, after the computer is powered up and the UEFI performs an initialization of the computer operating system to enter the operating system kernel environment, injection of the dynamically linked library may 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 may be performed in the kernel state so that the injection process is not intercepted by the security software, resulting in the injection failure, and the dynamic link library may be injected into a highly privileged process (e.g., a process of services, lsass, smss, exe, etc.), thereby being able to stay permanently in the operating system. Accordingly, a client using the injected dynamic link library can permanently communicate with the server, thereby permanently tracking the status of the user product.

The method of performing injection of the dynamic link library using the UEFI initiation file will be further described below in conjunction with fig. 2. Fig. 2 is a flow chart illustrating a method 200 of performing injection of a dynamically linked library using a UEFI initiation file, in accordance with another embodiment of the present disclosure.

As shown in fig. 2, at step 202, a UEFI boot file is run to perform boot work, entering the operating system kernel environment. The UEFI startup file may be obtained in the manner as described previously. After the UEFI boot file is obtained, the UEFI may 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 runtime environment (Driver Execution Environment, or DXE); the loader module loader.efi, which when executed, reads system boot data from the bcdet database (which is a database developed by microsoft corporation); the monitoring module Efimonitor.efi is used for enabling the monitoring of system starting; the Bootmrfw.efi module is used for executing a normal starting-up starting flow; the WinPE module is a lightweight operating system environment and is used for deploying, maintaining and recovering a Windows operating system; an EFIBootService module, which is an EFI startup server and comprises event services, memory management services, various protocol services and the like; the BootMgr module is used for managing starting operation and loading an operating system; the windload.efi module is used for loading the kernel (ntoskrnl.exe) of the Windows operating system and other necessary system files; an EFI runtime services (EFI Runtime Services) module to interact with firmware while the operating system is running; an Ntkrnlmp.exe module, which contains the core components and functions of the operating system, responsible for managing and controlling the various resources and operations of the computer; a hardware abstraction layer (Hardware Abstraction Layer, abbreviated Hal) module, which is located between the operating system kernel and the hardware, provides an abstract and unified access interface to the hardware, etc., as shown with reference to fig. 3. In initializing these modules in the kernel environment, the initialization process of the operating system kernel environment may be controlled by monitoring and intercepting various messages generated during system startup through a message processing mechanism such as Hook (Hook), and by a program modification means such as Patch (Patch).

At step 204, a file load driver is started with the UEFI in the operating system kernel environment. A 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, in an example where the hardware device is a graphics card in accordance with the present disclosure, the driver corresponding to the graphics card may be a kernel mode display driver (Kernel Mode Display Driver, abbreviated KMD) of the graphics card that directly interacts with the graphics card hardware and provides an access interface to the graphics card functionality. When the kernel environment of the operating system is established, the driver can be loaded and connected with the hardware equipment, so that the control of the hardware equipment is realized. Loading the driver may include initializing and configuring the driver. The initialization operations may include setting parameters of the driver, allocating memory, registering callback functions, etc. A callback function is a function that passes as a parameter to another function and is called after the function has been executed. According to the present disclosure, initializing and configuring the driver is performed according to the functions implemented in the UEFI boot file. Specifically, a UEFI boot file that includes functionality according to the present disclosure may control initialization of a driver, e.g., to allocate a desired amount of memory and register a particular callback function to achieve a desired operation, e.g., dynamic link library injection, etc.

Alternatively or additionally, initiating a file loading driver with the UEFI may include extracting the driver from a shell code data region. This means that the driver can be stored in advance in the shell code data area, so that the driver can be stored in the storage device without being in a plain text form, increasing the security of the driver. In addition, by embedding the driver in the shell code data area, the driver may be provided with cross-platform or cross-architecture support. The shell code is platform and architecture specific executable code that, by loading and executing the shell code, can run the same driver on different operating systems or architectures. The method may further include allocating a memory segment in a memory pool of the operating system kernel environment that is capable of accommodating the driver after the memory alignment. Therefore, the driver can be stored in the memory pool of the kernel environment of the operating system, so that the driver has higher performance and controllability, and the high-efficiency control of the hardware equipment is realized. Starting a file load driver with the UEFI may also include copying the driver into the allocated memory. In one example, the driver may be copied into the memory on a 4 k-by-region basis, i.e., partition loading of the portable executable (Portable Executable, abbreviated PE) may be performed. The 4K alignment is a memory alignment mode, which can improve the efficiency of memory access, thereby improving the performance of the computer. Specifically, the 4K alignment is to align data by a multiple of 4K bytes, for example, if the start address of data is 0x1000, the start address of data should be a multiple of 0x1000, i.e., 0x1000, 0x2000, 0x3000, etc., in a 4K alignment manner.

Further, the method for loading the driver by using the UEFI start file can further comprise repairing a relocation table entry and an import table entry of the driver. In the above example of partition loading of a PE file, after a driver is loaded into kernel memory, repair needs to be performed on relocation entries and import entries in the PE file to ensure that the driver can be correctly linked and executed. Starting a file loading driver with the UEFI may further include creating a driver object, and obtaining an entry point of the driver. A driver object is an instance of a driver that contains the state and properties of the driver. The entry point of a 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, a driver object needs to be created and a driving entry point is acquired, so that an operating system can call a main function of the driver, and control of hardware equipment is achieved. Initiating a file loading driver using the UEFI may also include initializing the driver object. The process of initializing the driver object may include setting parameters of the driver object, allocating memory, registering callback functions, etc. The method may further comprise initiating a file loading driver using the UEFI, and executing a secondary initialization on the driver object by invoking an entry point of the driver. Performing a secondary initialization on the drive object may further configure and initialize the device object to implement additional functions, such as registering additional callback functions, allocating resources, establishing communication channels, etc., because some initialization steps need to be performed after the device object is created.

At step 206, the creation of the specified process is monitored by embedding process monitoring using the driver loaded by the UEFI startup file operation. In accordance with the present disclosure, a given process may be any process that may be injected into a dynamically linked library, such as an application process, a system process, a service process, and so forth. In particular, in one embodiment, dynamic link libraries may be injected into system processes such as services, lsass, exe, and smss. By injecting the dynamic link library into the system process, the dynamic link library cannot be forcedly terminated or closed, so that the problem of losing connection with the user side and the server is avoided.

Alternatively or additionally, embedded process monitoring may also include creating a random name device object during the driver initialization process. When creating a device object, a random name device object may be created for it. In one example, a specific name may also be assigned to a device object, and the disclosure is not so limited. Embedded process monitoring may also include registering a process notification callback function of the driver to monitor creation of the specified process. By registering the process notification callback function of the driver, 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 the process runs, for example, a dynamic link library is injected into a designated process. Optionally, embedded process monitoring may also include registering interrupt handling, causing the driver to provide an interrupt handling function to the operating system for handling specific interrupt events. Thus, in certain specific cases where the dynamic link library injection is associated with the presence of an interrupt handler, the corresponding input event may be intercepted by registering the interrupt handling function and performing a custom operation in the dynamic link library.

At step 208, in response to creation of the specified process, a driver loaded by a file operation is started with the UEFI to inject the dynamically linked library into the interior of the specified process. In accordance with the present disclosure, dynamic link libraries may be injected into a process in a kernel environment using various approaches, including but not limited to: the method comprises the steps that a kernel module is loaded (Kernel Module Loading), and in a kernel environment, the dynamic link library injection can be realized by loading a custom kernel module, wherein the kernel module can contain custom codes and data and can execute custom operation in the context of a designated process; kernel hook (Kernel hook), which can intercept function call and redirect it to self-defined code by setting hook in system function of appointed process; and kernel driver injection (Kernel Driver Injection), which can execute custom code in the context of a specified process by loading drivers in the kernel environment and registering corresponding callback functions to associate them with the specified process, implementing dynamic link library injection, as described further below.

Alternatively or additionally, injecting the dynamically linked library into the specified process may include registering a callback function of the driver to mount to the specified process. In this operation, during the initialization of the driver, a callback object may be created and a callback function registered first, and then the creation of a specified process may be waited for. In this process, information specifying a process is not required to be known. When a specified process is created, the system may call a callback function registered by the driver in response to the process creation event. Injecting the dynamically linked library into the specified process may further comprise opening the created device object in a 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 state, etc. Injecting the dynamic link library into the specified process may further comprise storing device handle and interrupt vector numbers and random tokens in the driver into user state shell code. Through this operation, when in user mode, the program in user mode can communicate with the driver using the above-described device handle, interrupt vector number, and random token, i.e., bidirectional authentication for the communication can be performed to improve security.

Injecting the dynamically linked library into the specified process may further comprise allocating a section of read-write executable memory from the virtual address space of the specified process in a callback function of the driver. The virtual address space is a block of memory space allocated by the operating system for each process, and is used to store information such as code, data, and stack. It should be noted that the driver may allocate a length of readable and writable executable memory from the high-end address of the virtual address space of the specified process by calling the zwlelocatevirtualpemory function to ensure that the allocated memory can be accessed by the specified process. Zwlllocatevirtualmemory is a function in the Windows kernel that allocates a piece of memory in the virtual address space of a given process. Injecting the dynamically linked library into the specified process may further include writing the specified shell code and the dynamically linked library into the read-write executable memory in a memory copy manner. The segment of memory allocated from the virtual address space of a given process is also referred to as the user mode memory of the given process, which is only visible and operates in the user mode of the given process. The user mode memory of each process is isolated from each other. The shell code and dynamic link libraries may be written into the allocated memory of a given process using various functions, such as WriteProcessMemory. For example, binary data of the shell code may be first written to the starting location of the memory. Binary data of the dynamically linked library is then written to the appropriate location in the memory, typically a location after the shell code.

Injecting the dynamically linked library into the specified process may further comprise replacing an original entry point of the specified process with an entry point of the dynamically linked library. By this operation, it can be ensured that the written data (e.g., the injected dynamic link library) can be accessed by the specified process, thereby initializing the injected dynamic link library before the specified process is initialized. Injecting the dynamically linked library into the specified process may further comprise updating a translation look-aside buffer of a central processor to clear the translation look-aside buffer using an address of an entry point of the dynamically linked library as a parameter. The translation lookaside buffer (Translation Lookaside Buffer, abbreviated TLB) is a cache that stores virtual to physical address mappings. When the CPU accesses the memory, the Memory Management Unit (MMU) first looks up the physical address corresponding to the virtual address in the translation look-up buffer, and if there is no hit in the translation look-up buffer, it needs to walk the page table to obtain the physical address. Updating the translation look-aside buffer with the address of the new entry point as a parameter disables the translation look-aside buffer to be flushed, thus preventing the memory management unit from hitting the physical address in the original translation look-aside buffer when the CPU is fetched. After clearing, the CPU misses on instruction fetches, forcing the CPU to refresh the page table or segment table again to reload new physical memory for the injected dynamically linked library. Injecting the dynamically linked library into the specified process may further comprise un-wrapping the driver from the specified process. By releasing the hooking, the operation (e.g., injection, hook, etc.) that has been performed is removed from the specified process, and the specified process is restored to the original state. For example, un-hooking may include closing or releasing a handle of a specified process, releasing memory allocated from a specified process, and so forth.

Alternatively or additionally, the dynamically linked library may be initialized by the shell code after injection of the dynamically linked library. For example, the dynamic link library is initialized after a specified process is created by monitoring as described above. Initializing the dynamic link library by the shell code may include: the shell code obtains the initial execution rights of the specified process for earliest initialization. Where the operation is enabled, the shell code may obtain a handle to the specified process for subsequent operations; and allocating memory in the designated process for loading and executing the dynamically linked library or other initialization code. Initializing the dynamic link library by the shell code may further comprise: the shell code performs a relocation job of the dynamic link library based on an entry point of the dynamic link library. Relocation refers to the adjustment of address references in a dynamic link library to ensure that code and data can properly access their required memory locations, based on the actual memory layout, before loading the dynamic link library into memory and starting execution. The relocation operation may include loading the dynamic link library into memory, parsing an import table of the dynamic link library, performing a relocation process, and so forth. It should be noted that the relocation operation may be performed by a function used internally by the operating system, and thus there is no need to repair the export table of the dynamically linked library. Initializing the dynamic link library by the shell code may further comprise: and the dynamic link library executes self initialization and returns the shell code after finishing. For example, the initialization of the dynamically linked library itself may be performed by invoking the DllMain function of the Windows operating system so that it may be validated 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 may be copied into a global variable in the DllMain function for later use. The data injected here may include handles or object references in the operating system or application programs, configuration information, and so forth. Initializing the dynamic link library by the shell code may further comprise: the shell code returns to the original entry point of the specified process so that initialization of the specified process begins. After the initialization of the dynamic link library is completed, the shell code returns to the original entry point of the designated process, and the subsequent operation of the designated process is continuously executed to initialize the designated process.

After completion of the process according to the description above, the injected dynamic link library becomes active, and thus available for other program calls and uses. In particular, the dynamic link library may provide some functions or data that, after it is validated, other programs may implement the desired functions by invoking such functions or data in the dynamic link library. For example, the injected dynamic link library may be used to protect a graphics card driver, and the validation of the injected dynamic link library enables the graphics card driver to be assisted in one or more of the following functions: the user-side program can use a random token to perform two-way authentication with the graphics card driver by means of a device handle or interrupt vector stored in the user-mode shell code, for example, as described above, to improve security; online upgrading is carried out on the display card firmware; invoking a graphics card driver to execute various performance strategies to perform various performance optimizations on the graphics card (e.g., adjusting parameters such as operating frequency, voltage, fan speed, etc. of the graphics card); and gathering error logs associated with the graphics card and/or graphics card driver for logging and/or server uploading. It should be appreciated that the graphics card is presented herein by way of example only and that the injected dynamically linked library may implement one or more of the above-described functions for any suitable hardware device.

FIG. 3 is a schematic view illustrating injection of a dynamically linked library during a Windows operating system boot process according to another embodiment of the present disclosure.

As shown in fig. 3, the UEFI boot file and hard disk firmware may be linked together and burned into the hard disk firmware in the various manners described above. After a computing device, such as a computer, is powered up, a UEFI boot file is returned from the hard disk firmware to obtain a UEFI boot file that includes various functions in accordance with the present disclosure. After the UEFI boot file is obtained, the UEFI may 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 FIG. 3, one or more modules in its kernel environment may be initialized, as described above with respect to FIG. 2.

When the initialization operation of the operating system proceeds to the loading of the driver, the dynamic link library injection operation according to the present disclosure may be performed as described above. As shown in FIG. 3, by injecting a dynamic link library into a designated process during the loading of a driver in a kernel environment, a graphics manager in user mode may invoke the dynamic link library to perform various functions after the injected dynamic link library becomes effective. In particular, the graphics manager may send interrupt triggers to the CPU to initiate interactions with the driver. In response, the CPU may initiate interrupt processing to the driver so that the driver and graphics manager may communicate and interact, e.g., to implement the various functions described above.

Fig. 4 is a block diagram illustrating an injection apparatus of a dynamic link library according to another embodiment of the present disclosure. Referring to fig. 4, a block diagram 400 of an injection apparatus of a dynamically linked library is shown, according to one embodiment of the present disclosure. As shown in fig. 4, the apparatus 400 may include a startup file acquisition module 402 and an injection module 404. Specifically, the startup file acquisition module 402 is configured to acquire a UEFI startup file that has been solidified into a storage device. The UEFI boot file solidified into the storage device may include all of the functions implemented in accordance with the present disclosure, such as all of the functions associated with injecting a dynamic link library. The injection module 404 is configured to perform injection of the dynamic link library using the UEFI initiation file. In one embodiment, the injection module 404 may be configured to: operating a UEFI start file to execute start work and entering an operating system kernel environment; the method comprises the steps that a file loading driver is started by using UEFI under the kernel environment of an operating system; using UEFI to start a file operation loaded driver to embed process monitoring to monitor creation of a specified process; and in response to creation of the specified process, initiating a driver loaded by the file operation with the UEFI to inject the dynamically linked library into the interior of the specified process. In another embodiment, the injection module 404 may be used to extract the driver from the shell code data area; distributing a section of memory capable of containing the driver after memory alignment in a memory pool of the kernel environment of the operating system; copying the driving program into the distributed memory; repairing a repositioning table entry and an importing table entry of a driver; creating a driving object and acquiring an entry point of a driving program; initializing a driving object; and calling an entry point of the driver program, and performing secondary initialization on the driving object. In another embodiment, the injection module 404 may be used to create a random-named device object during driver initialization; and registering the process notification callback function of the driver to monitor creation of the specified process. In another embodiment, the injection module 404 may be used to register a callback function of the driver to attach to a specified process; opening the created device object in a callback function of the driver; storing the device handle, the interrupt vector number and the random token into a user state shell code in a driver; distributing a section of memory which can be read and written and can be executed from a virtual address space of a designated process in a callback function of a driver; writing the specified shell codes and the dynamic link library into a readable and writable executable memory in a memory copying mode; replacing the original entry point of the appointed process with the entry point of the dynamic link library; updating the translation look-aside buffer of the CPU by taking the address of the entry point of the dynamic link library as a parameter so as to clear the translation look-aside buffer; and un-trusting the driver for the specified process. In addition, the injection module 404 may perform injection using the UEFI startup file according to any of the methods for performing injection of the dynamically linked library described above, which are not described herein.

Alternatively or additionally, the apparatus 400 may further comprise: the link module is used for linking the UEFI starting file and the firmware of the storage device into an image file; and the solidifying module is used for solidifying the image file into the storage device. Likewise, the linking module and the curing module may perform the above operations according to any of the methods described above, and are not described herein.

Alternatively or additionally, the apparatus 400 may further comprise an initialization module for initializing the dynamic link library through the shell code after the dynamic link library is injected. The dynamic link library may be validated after being initialized so that it may be called and used by other programs. In one embodiment, the initializing module to initialize the dynamic link library with the shell code may include: the shell code obtains the initial execution right of the appointed process to perform earliest initialization; the shell code performs relocation work of the dynamic link library based on the entry point of the dynamic link library; the dynamic link library executes self initialization and returns a shell code after finishing; and the shell code returns to the original entry point of the specified process so that initialization of the specified process begins. Likewise, the initialization module may perform the above operations according to any of the methods described above, which are not described herein.

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

Additionally or alternatively, the above-described methods, general-purpose docking modules, service platforms, or third party platforms of the present disclosure may 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 fig. 5. Herein, a computer, server, or other device that includes a processor is collectively referred to as a computing device. The computing device 502 contains a processor 504, the processor 504 controlling the operation of the computer 502 by executing computer program instructions defining overall operation. The computer program instructions may be stored in a storage device 512 (e.g., disk) and loaded into memory 510 when execution of the computer program instructions is desired. Accordingly, the steps of the method with reference to fig. 1 and 2 may be defined by computer program instructions stored in the memory 510 and/or the storage device 512 and controlled by the processor 504 executing the computer program instructions. 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., display, keyboard, mouse, speakers, buttons, etc.) that enable a user to interact with the computer 502. Those skilled in the art will recognize that embodiments of an actual computer may also contain other components, and that FIG. 5 is a high-level representation of some of the components of such a computer for illustrative purposes.

Storage device 512 and memory 510 each comprise a tangible, non-transitory computer-readable storage medium. Storage device 512 and memory 510 may each comprise high-speed random access memory, such as Dynamic Random Access Memory (DRAM), static Random Access Memory (SRAM), double data rate synchronous dynamic random access memory (DDR RAM), or other random access solid state memory devices, and may comprise non-volatile memory, such as one or more magnetic disk storage devices (such as an internal hard disk and removable magnetic disk), magneto-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 disc read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM) discs, or other non-volatile solid state memory devices.

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

The disclosed embodiments also provide a computer readable storage medium having stored thereon computer program instructions which, when executed by a processor, implement the above-described method. The computer readable storage medium may be a volatile or nonvolatile computer readable storage medium.

The embodiment of the disclosure also provides an electronic device, which comprises: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to invoke the instructions stored in the memory to perform the above method.

Embodiments of the present disclosure also provide a computer program product comprising computer readable code, or a non-transitory computer readable storage medium carrying computer readable code, which when run in a processor of an electronic device, performs the above method.

The electronic device may be provided as a terminal, server or other form of device.

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

While the present disclosure has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.

All publications, patents, and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this disclosure shall not be construed as an admission that such reference is available as prior art to the present disclosure. Where a segment title is used, it should not be construed as necessarily limiting.

Claims (11)

1. A method for injecting a dynamic link library, comprising:

acquiring a UEFI starting file solidified into a storage device; and

and executing the injection of the dynamic link library by using the UEFI start file.

2. The method of injecting a dynamic link library as claimed in claim 1, wherein said method further comprises:

linking the UEFI boot file with firmware of the storage device to form an image file; and

And solidifying the image file into the storage device.

3. The method of injecting a dynamically linked library as recited in claim 2, wherein the solidifying comprises upgrading the image file into the memory device by means of a firmware upgrade interface of the memory device.

4. The injection method of the dynamic link library according to any one of claims 1 to 3, wherein performing the injection of the dynamic link library using the UEFI start file comprises:

operating the UEFI start file to execute start work and entering an operating system kernel environment;

starting a file loading driver by using the UEFI under the kernel environment of the operating system;

utilizing the UEFI to start a driving program loaded by file operation to monitor creation of a designated process by embedding process monitoring; and

in response to creation of the specified process, a driver loaded by a file operation is started with the UEFI to inject the dynamically linked library into an interior of the specified process.

5. The method of injecting a dynamically linked library of claim 4, wherein launching a file load driver with the UEFI in the operating system kernel environment comprises:

Extracting the driver from the shell code data area;

distributing a section of memory capable of containing the driver after memory alignment in a memory pool of the kernel environment of the operating system;

copying the driver program into the distributed memory;

repairing the relocation table entry and the import table entry of the driver;

creating a driving object and acquiring an entry point of the driving program;

initializing the driving object; and

and calling an entry point of the driver, and executing secondary initialization on the driving object.

6. The method of injecting a dynamic link library as claimed in claim 4, wherein using the UEFI to initiate a driver loaded by a file operation to embed process monitoring to monitor creation of a specified process comprises:

creating a device object with a random name in the initialization process of the driver; and

the process registering the driver notifies a callback function to monitor creation of the specified process.

7. The method of injecting the dynamic link library as claimed in claim 6, wherein in response to creation of the specified process, starting the driver loaded by the file operation with the UEFI to inject the dynamic link library into the interior of the specified process comprises:

Registering a callback function of the driver to be affiliated to the specified process;

opening the created device object in a callback function of the driver;

storing the device handle, the interrupt vector number and the random token into a user state shell code in the driver;

distributing a section of readable and writable executable memory from a virtual address space of the appointed process in a callback function of the driver;

writing the specified shell code and the dynamic link library into the readable and writable executable memory in a memory copying mode;

replacing the original entry point of the appointed process with the entry point of the dynamic link library;

updating a translation look-aside buffer of a central processing unit by taking an address of an entry point of the dynamic link library as a parameter so as to clear the translation look-aside buffer; and

and releasing the driver from the specified process.

8. The method of injecting a dynamic link library as claimed in claim 7, 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 appointed process to perform earliest initialization;

The shell code performs relocation work of the dynamic link library based on an entry point of the dynamic link library;

the dynamic link library executes self initialization and returns the shell code after finishing; and

the shell code returns to the original entry point of the specified process so that initialization of the specified process begins.

9. An injection device for a dynamically linked library, comprising:

the starting file acquisition module is used for acquiring the UEFI starting file solidified in the storage device; and

and the injection module is used for executing the injection of the dynamic link library by using the UEFI start file.

10. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to invoke the instructions stored in the memory to perform the method of any of claims 1 to 8.

11. A computer readable medium having instructions stored thereon, which when executed, cause a computing device to perform the method of any of claims 1 to 8.