WO2000062160A2

WO2000062160A2 - Method and system for dynamic injection of execution logic into a windowed operating system

Info

Publication number: WO2000062160A2
Application number: PCT/US2000/002937
Authority: WO
Inventors: Richard P. Hammond
Original assignee: Chicago-Soft, Ltd.
Priority date: 1999-04-08
Filing date: 2000-02-03
Publication date: 2000-10-19
Also published as: WO2000062160A3; EP1221085A2; AU2981700A

Abstract

Methods and system for dynamically injecting execution logic into a windowed operating system that does not use shared memory for processes. The methods and system of the present invention allow execution logic to be injected into existing processes and new processes and created by windowed operating systems that do not use shared memory for processes, such as Microsoft Windows NT. The execution logic is executed prior to any application software in executable modules associated with the processes. The methods and system of the present invention may be used for debugging aids, hooking other processes, tracing the execution of a process or a thread, and for other purposes.

Description

METHOD AND SYSTEM FOR DYNAMIC INJECTION OF EXECUTION LOGIC INTO A WINDOWED OPERATING SYSTEM

FIELD OF INVENTION

This invention relates to computer operating systems. More specifically, it relates to a methods and system for dynamic injection of execution logic into a windowed operating system that does not use shared memory for processes.

BACKGROUND OF THE INVENTION

Software applications, such as 32-bit applications (e.g., Win32) for windowed operating systems, such as Windows 95/98/NT, by Microsoft Corporation of Redmond, Washington, execute as separate processes that execute within their own address space. The Windows 95/98/NT operation systems limit code that can execute within an address space to the code associated with a main executable module (e.g., ".EXE") and Dynamic Link Library ("DLL") modules loaded by a process associated with the main executable module. As is known in the art, a Dynamic Link Library provides a mechanism for linking applications to libraries of functions at run-time.

However, there are many situations where additional functionality needs to be added to a process by injecting execution logic into an address space. In particular, there are situations where it is desirable to inject execution logic into new address spaces that will execute before any application-related code executes. For example, applications to monitor or alter the execution of other applications need such additional functionality.

There are a number of techniques known in the art to inject execution logic into an existing windowed operating system's process. However, these techniques have a number of associated problems. Three of these injection techniques include Dynamic Link Library injection, code patching, and remote threads. The Dynamic Link Library injection technique involves loading a Windows 95/98/NT Dynamic Link Library into an address space and placing injection code within a "DllMain" function. A Dynamic Link Library's

DlTMain function is called by the Windows 95/98/NT operating system when a process loads or unloads a Dynamic Link Library as well as when a new operating system thread is started or stopped within a process. Thus, loading a Dynamic Link Library into an address space will result in the injected code's execution within an address space. However, the injected code will only be executed after the process begins executing.

As is known in the art, there are two ways to inject a Dynamic Link Library into a Windows address space including using an operating system registry key "AppInit_DLLs" or calling a "SetWindowsHookEx" API function. As is known in the art, an operating system registry stores hardware, software and user configuration settings for particular a computer.

The AppInit_DLLs registry value can be used with Windows NT but is not implemented by Windows 95/98. A data value for the AppInit_DLLs registry value can contain a list of Dynamic Link Library module file names. When the Windows NT operating system module User Dynamic Link Library (e.g., USER32.DLL) is loaded into an address space, the user Dynamic Link Library will attempt to load the modules listed in this registry setting into a process address space. Use of the AppInit_DLLs registry value will only inject a Dynamic Link Library in a process that executes code within a user's Dynamic Link Library (e.g., USER32.DLL). However, both Windows 95/98 and Windows NT implement a

SetWindowsHookEx Application Programmer's Interface ("API") function. This function is used to hook events within a primary operating system thread or for other operating system threads. When SetWindowsHookEx events occur, a callback function within a Dynamic Link Library is called by the Windows 95/98/NT operating system. If the hooked thread belongs to a different process than the calling thread, Windows 95/98/NT loads the required Dynamic Link Library into the hooked operating system thread's address space. This Dynamic Link Library injection will only be invoked after an application associated with a process has started executing.

Code patching techniques known in the art require an injecting process having access to a target process. First the injected code is copied to a memory area in the target process address space. Next the target process is altered so that the injected logic will be executed. Finally, code within an existing execution thread is altered to execute the injected code. This is typically accomplished by calling injected code within an existing process execution path. Code patching is designed to work only on specific processes modified by a user.

The remote thread technique also requires an injecting process having access to a target thread. The injected code is copied to a memory area in the target thread address space. Then a new thread is started for the target process. This new thread executes the injected code. The remote thread technique also works only on specific processes modified by a user.

These injection techniques do not provide the ability for injected code to be the first non-operating system code to execute in new address space for a new process created by a windowed operating system. In addition these injection techniques are designed to work on specific processes modified by a user and do not allow injection techniques that are generally applicable to any process created by a windowed operating system.

Some of the problems associated with the injection techniques for windowed operating systems that use shared memory for operating system processes (e.g., Windows

95/98) are overcome into co-pending Application No. . However, the methods and system described in this Application may not work with certain windowed operating system that do not use a shared memory area for processes (e.g., Windows NT). Some windowed operating systems, such as Windows 95/98, use a shared memory area for processes. Execution logic loaded into this shared memory area can be executed anytime a new process is created. However, other windowed operating systems, such as Windows NT, do not use a shared memory area for processes. In such a windowed operating system, processes that use injection logic may not be able to the same method as a process in an operating system that does use shared memory for processes.

Thus, it is desirable to inject execution logic into processes that will execute before any application-related code associated with the process that execute in windowed operating systems that do not use a shared memory area for processes. The injected execution logic should be generally applicable to any process in a windowed operating system that does not use shared memory for processes.

SUMMARY OF THE INVENTION In accordance with preferred embodiments of the present invention, some of the problems associated with injecting execution logic in a windowed operating system that does not use shared memory for processes are overcome. Methods and system for dynamically injecting execution logic into a windowed operating system that does not use shared memory for processes are provided.

One aspect of the present invention includes a method for dynamically injecting execution logic in a windowed operating system that does not use a shared memory for processes. An injection service is started on a windowed operating system that does not use shared memory area for processes. The injection service provides security features and prevents unauthorized processes from altering operations of the injection service. Existing processes already created in the windowed operating system are located from the injection service. Injection logic from the injection service is loaded into the existing processes in the windowed operating system such that the existing processes and any additional processes created by the existing processes include the injection logic. Injection logic is also added from the injection service to a function used to create new processes on the windowed operating system. The injection logic intercepts requests to create new processes on the windowed operating system. The injection logic is executed by new processes prior to executing any other application related logic associated with the new process.

Another aspect of the invention includes methods for dynamically injecting execution logic specifically for existing processes and for new processes in a windowed operating system that does not use shared memory for processes. Another aspect of the invention includes a system for dynamically injecting execution logic into a windowed operating system that does not use shared memory for processes.

The methods and system of the present invention allow execution logic to be injected into processes created by windowed operating systems that do not use shared memory for processes (e.g., Windows NT). The execution logic is executed prior to any other application related logic associated with the new processes. The methods and system of the present invention may be used for debugging aids, hooking other processes, tracing the execution of a process or thread, and for other purposes.

The foregoing and other features and advantages of an illustrative embodiment of the present invention will be more readily apparent from the following detailed description, which proceeds with references to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS Preferred embodiments of the present invention are described with reference to the following drawings, wherein:

FIG. 1 is a block diagram illustrating an exemplary computing system with a windowed operating system;

FIG. 2 is a flow diagram illustrating a method for dynamically injecting execution logic in a windowed operating system that does not use shared memory for processes;

FIG. 3 is a block diagram illustrating exemplary Windows NT operating system components; FIG. 4 is a block diagram illustrating a Windows NT implementation of a Win32 process's address space;

FIG. 5 is a flow diagram illustrating a method for dynamically injecting execution logic for existing processes in a windowed operating system that does not use shared memory for processes; FIG. 6 is a flow diagram illustrating a method for dynamically injecting execution logic for new processes in a windowed operating system that does not used shared memory for processes;

FIGS. 7 A and 7B are a flow diagram illustrating a method for dynamically loading injection logic for new processes in a windowed operating system that does not use shared memory for processes;

FIG. 8 is a flow diagram illustrating a method for using dynamically injected execution logic in a shared memory space in a windowed operating system; and FIG. 9 is a block diagram illustrating an exemplary injection system for dynamically injecting execution logic into a windowed operating system that does not use shared memory for processes. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS Exemplary computing system

FIG. 1 is a block diagram illustrating an exemplary computing system 10 with a windowed operating system for a preferred embodiment of the present invention. The computing system 10 includes a computer 12 with a generic windowed operating system 14. The generic windowed operating system 14 generally includes a hardware layer 16, a device driver layer 18, a file system layer 20, a graphics system layer 22, a system services layer 24 and a user applications layer 26. The hardware layer 16, device driver layer 18, file system layer 20, graphics system layer 22, and system services layer 24 comprise an operating system kernel 28. The generic windowed operating system 14 provides a Graphical User Interface ("GUI") 30 with multiple windows. However, more or fewer windowed operating system components could also be used and the present invention is not limited to the generic windowed operating system components illustrated in FIG. 1. The hardware layer 16 is the actual hardware on the computer 12 such as monitor, keyboard, disk drive, etc. The device driver layers 18 is used to interact with actual hardware in the hardware layer 16. The file system layer 20 is used to create, save, retrieve and delete files. The graphic system layer 22 is used to create the GUI 30 with the multiple windows. The system services layer 24 is used to provide windowed operating system services. The user application layer 26 is used to provide user applications that interact with the windowed operating system kernel 28.

An operating environment for the computing system 10 for preferred embodiments of the present invention include a processing system with one or more high speed Central Processing Unit(s) ("CPU") and a memory. In accordance with the practices of persons skilled in the art of computer programming, the present invention is described below with reference to acts and symbolic representations of operations or instructions that are performed by the processing system, unless indicated otherwise. Such acts and operations or instructions are referred to as being "computer-executed" or "CPU executed."

It will be appreciated that acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. An electrical system represents data bits which cause a resulting transformation or reduction of the electrical signals, and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to the data bits.

The data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, organic memory, and any other volatile (e.g., Random Access Memory ("RAM")) or non-volatile (e.g., Read-Only Memory ("ROM")) mass storage system readable by the CPU. The computer readable medium includes cooperating or interconnected computer readable medium, which exist exclusively on the processing system or be distributed among multiple interconnected processing systems that may be local or remote to the processing system. Injecting execution logic into a windowed operating system

As was discussed above, it is desirable to inject execution logic into processes that will execute before any application-related code associated with a process executes. Some windowed operating systems, such as Windows 95/98, by Microsoft Corporation of Redmond, Washington, use a shared memory area for processes. Execution logic loaded into this shared memory area is executed anytime a new process is created. In an operating system that uses a shared memory for processes, injection logic can be injected once into a shared memory area and then used by any process that is created on the windowed operating system. However, other windowed operating systems, such as Windows NT, do not use a shared memory area for processes. In such a windowed operating system, processes that will use injection logic are modified with different methods. FIG. 2 is a flow diagram illustrating a Method 32 for dynamically injecting execution logic in a windowed operating system that does not use a shared memory for processes. At Step 32, an injection service is started on a windowed operating system that does not use a shared memory area for processes. The injection service provides security features and prevents unauthorized processes from altering operations of the service. At Step 34, existing processes already created in the windowed operating system are located from the injection service. At Step 36, injection logic from the injection service is loaded into the existing processes located in the windowed operating system such that the existing processes and any additional processes created by the existing processes include the injection logic. At Step 38, injection logic is added from the injection service to a function used to create new processes on the windowed operating system. The injection logic intercept requests to create new processes on the windowed operating system. The injection logic is executed by new processes prior to executing any other application related logic associated with the new processes.

In one exemplary preferred embodiment of the present invention, the windowed operating system is the Windows NT by the Microsoft Corporation of Redmond,

Washington. However, other windowed operating systems that do not use shared memory for processes could also be used and the present invention is not limited to the Microsoft Windows NT operating systems. For more information on the Windows NT operating system see "Beginning Windows NT Programming," by Julian Templeman, WROX Press Inc., Chicago, Illinois, 1998, ISBN 1-861000-17-0, incorporated herein by reference.

Windows NT is a preemptive multitasking operating system with multiple "processes" and "threads." A preemptive multitasking operating system uses a predetermined method to determine which application attached to a process is to be run at a given time, based upon factors such as an application's priority, whether it is blocked waiting to read or write, etc.

FIG. 3 is a block diagram illustrating exemplary Windows NT operating system components 42. The Windows NT operating system 42 includes a Hardware layer 44, a Hardware Abstraction Layer ("HAL") 46, a Micro-kernel layer 48, an I/O Manager 50, an Object Manager 52, a Security Reference Monitor 54, a Process Manager 56, a Local Procedure Call ("LPC") facility 58, a Virtual Machine Manager ("VMM") 60, Graphics Device Drivers layer 62, a Graphical Device Interface ("GDI") 64, a System Services layer 66, an operating system Registry 68, an Executive Services layer 70, and User Applications layer 72. The operating system components below the User Applications layer 70 comprise an operating system kernel 74.

The Hardware layer 44 includes actual hardware on a computer (e.g., the computer 12). The HAL 46 comprises a library of hardware specific routines that sits between the hardware of computer 12 and the rest of the operating system. The HAL 46 provides standard entry points for access by higher-level functions. The Micro-kernel 48 is responsible for keeping the CPU(s) busy and efficient, scheduling threads, interrupts and exceptions, synchronizing activity between CPUs on multiprocessor machines, initiating system recovery after a power failure and other kernel tasks.

The I/O Manger 50 is responsible for managing input/output for the operating system. The Object Manager 52 is responsible for creating managing and deleting operating system kernel objects. The Security Reference Monitor 54 provides operating system security information for the Object Manager 52. The Process Manager 56 creates and destroys processes, and is responsible for managing processes and threads and provides a standard set of services for using processes and threads. The LPC facility 58 provides communications between applications and operating system services. The VMM 60 is responsible for reading operating system pages and mapping the pages into process address space. The Graphics Device Drivers layer 62 is a layer of device drivers to provide graphics. The Graphical Device Interface ("GDI") 64 provides graphic services to create a multi-windowed GUI.

The System Services layer 66 provides an interface between the operating system kernel 71 and the User Applications layer 70. The operating system Registry 68 is a hierarchical database that stores hardware, software and user configuration settings for a computer (e.g., the computer 12). The Executive services layer 70 provides a common set of services that can be used by all components of the operating system. The User Applications layer 72 is used for running user applications. This description of Windows NT components is intended to for illustrative purposes only and is not intended to be a complete description of the components and details included in the Windows NT architecture. Additional information on the Windows NT operating system components can also be obtained on the Internet at the Uniform Resource Locator ("URL") ''''http://msdn.microsoft.com/developer/windowsnt. " Windows NT Win32 processes use a 4 Giga-Byte ("GB") address space and can't access any other process's address space. Windows NT use Win32 processes. Win32 processes are processes that use a 32-bit Win32 Application Programming Interface ("API"). In general, a Win32 process is an object that owns resources used by an application. Win32 processes are generally inert. That is, a Win32 process executes nothing, it simply owns a 4-GB address space that includes code and data for an application's executable module (".EXE").

For a Win32 process to accomplish anything, the process must own a thread. A thread is responsible for executing code that is contained in a process's address space. A thread is separate path of execution within a process. Threads share a process's virtual address space, code and global data, but execute independently of one another and have independent program stacks. In a simplest case, a Win32 process has a single, main thread known as a "primary" thread. When a Win32 process is created, a Win32 primary thread is automatically created. The Win32 primary thread can create additional threads, and these additional threads can create more threads.

FIG. 4 is a block diagram illustrating a Windows NT implementation of a Win32 a process's address space 76. The Windows NT Win32 process address space 76 includes a partition from 0x00000000 through OxOOOOFFFF 78, a partition from 0x00010000 through 0x7FFEFFFF 80, a partition from 0x7FFF0000 through 0x7FFFFFFF 82, and a partition from 0x80000000 through OxFFFFFFFF 84. Unlike Windows 95/98 when a Windows NT Win32 process is created and given its address space, the bulk of this usable address space 76 is free, or unallocated.

The partition from 0x00000000 through OxOOOOFFFF 78 includes 64 Kilo-Byte ("KB") range at the bottom of a process's address space that is set aside by Windows NT to help programmers catch NULL-pointer assignments. The partition from 0x00010000 through 0x7FFEFFFF 80 includes a 2,147,352,576-byte (2-GB minus 64-KB) partition is where the process's private (i.e., un-shared) address space resides. When a Win32 process loads, it will require access to operating system dynamic-link libraries, including NTDLL.DLL, KERNEL32.DLL, USER32.DLL, GD132.DLL, and ADVAP132.DLL. The code for these DLLs as well as for any other DLLs is loaded into this partition 80. As is known in the art, a Dynamic Link Library ("DLL") provides a mechanism for linking applications to libraries of functions at run-time. These libraries are "dynamically linked" because they are linked to an application when it is loaded and executed rather than when it is linked. When an application uses a DLL, the operating system loads the DLL into memory, resolves references to functions in the DLL so that they can be called by the application, and unloads the DLL when it is no longer needed. Loading a DLL into an address space results in execution of code within a DLL.

The partition from 0x7FFF0000 through 0x7FFFFFFF 82 includes a 64-KB partition. This partition 82 is off-limits to other processes, and any attempt to access memory in this partition causes an access violation. The partition from 0x80000000 through OxFFFFFFFF 84 includes 2-GB partition where the Windows NT Kernel 74 resides.

Returning to FIG. 2, in one exemplary preferred embodiment of the present invention, at Step 32, an injection service is started from Windows NT. As is known in the art, a Windows NT service is a Win32 process that is run by Windows NT itself as opposed to being executed by a user. A Windows NT service also includes security features that prevent un-authorized processes from altering the operations of the service. In one exemplary preferred embodiment of the present invention, the injection application is started when Windows NT is started. This allows the injection service to monitor other Windows NT services. In another exemplary preferred embodiment the present invention, the injection service is executed when a login session is established on Windows NT. Starting the injection service when a login session is established prevents the injection service from injection logic that is the first execution logic that executes in processes that are already active in Windows NT. However, the injection service can be started in other ways and the present invention is not limited to starting the injection service with the methods described. At Step 34, existing processes in Windows NT are located from the injection service by querying Windows NT process and/or thread performance counters.

At Step 36, injection logic is added from the injection service to the existing processes located in Windows NT such that the existing processes and any additional processes created by the existing processes include the injection logic. In one preferred embodiment of the present invention, the injection logic is added to existing processes in an unused memory area in a Portable Executable header in a Windows NT dynamic link library called "KERNEL32.DLL." A remote thread is created to execute the injection logic added to the KERNEL32.DLL. A method for adding injection logic to existing processes in a windowed operating system that does not use a shared memory area for processes is illustrated in FIG. 5.

At Step 38, injection logic is added from the injection service to the Windows NT CreateProcess function used to create new processes on Windows NT. The injection logic intercepts requests to create new processes on Windows NT. A method for adding injection logic to new processes in a windowed operating system that does not use a shared memory area for processes is illustrated in FIG. 6.

Method 34 of FIG. 2 allows injection logic to be added to processes in a windowed operating system that does not use a shared memory area for processes. Existing processes are modified such that injection logic will be added to the existing processes and to new processes created by the existing processes. In addition, injection logic is added to a function used to create new processes, so new processes requested by applications will also include the injection logic.

In one exemplary preferred embodiment of the present invention, the injection logic will be executed by all new processes prior to any applications related code for the new processes. In another preferred embodiment of the present invention, the injection logic is executed by most new processes, but less than all new processes.

Injecting execution logic into existing processes in a windowed operating system

As was discussed above for at Step 36 of Method 32 (FIG. 2), injection logic is added from the injection service to the existing processes located in Windows NT such that the existing processes and any additional processes created by the existing processes include the injection logic. Method 86 illustrates adding injection logic to existing processes in such a manner. However, other methods could also be used to add injection logic into existing processes in a windowed operating system. FIG. 5 is a flow diagram illustrating a Method 86 for dynamically injecting execution logic for existing processes in a windowed operating system that does not use shared memory for processes. At Step 88, an injection service is started on a windowed operating system that does not use a shared memory area for processes. At Step 90, injection logic is generated by the injection service. At Step 92, existing processes on the windowed operating system are located from the injection service. At Step 94, a loop is entered to repeat Steps 96, 98, 100 and 102 for the existing processes found on the windowed operating system at Step 92. At Step 96, the injection logic is copied from the injection service into an unused area of memory in an existing process. At Step 98, an additional windowed operating system thread is created in the existing process. The additional windowed operating system thread executes injection logic. At Step 100, the injection service waits for the additional windowed operating system thread to complete execution. At Step 102, the injection logic is deleted from the unused area of memory in the existing process. The injection logic is available to the existing processes as well as any additional new processes the existing processes may create. In one exemplary preferred embodiment of the present invention, the windowed operating system is Windows NT. However, the present invention is not limited to

Windows NT and other windowed operating systems that do not use shared memory for processes could also be used. In an embodiment using Windows NT, at Step 88 an injection service is started using Windows NT. Table 1 illustrates psuedo-code for an exemplary injection service for Windows NT. However, the present invention is not limited to the exemplary injection service illustrated in Table 1 for Windows NT, and other injection services and other windowed operating systems could also be used.

The injection service provides security features and prevents unauthorized processes or users from altering operations of the injection service.

At Step 90, injection logic is generated from the injection service. In one exemplary preferred embodiment of the present invention, the injection logic includes a call to the Window NT LoadLibrary function with the name of an injection DLL called

LNJECT.DLL.

At Step 92, existing processes on Windows NT are located from the injection service. In one exemplary preferred embodiment of the present invention, a Windows NT function called EnumProcesses is called from a Windows NT DLL called PSAPI.DLL. However, other methods could also be used to determine existing processes on Windows

NT.

At Step 94, a loop is entered to repeat Steps 96, 98, 100 and 102 from the injection service for the existing processes found on the windowed operating system at Step 92. At

Step 96, the injection logic generated at Step 90 is copied from the injection service into an unused area of memory in an existing process. In one exemplary preferred embodiment of the present invention, the injection logic generated at Step 90 is copied into a Portable

Executable ("PE") header for the KERNEL32.DLL. For more information on a Portable

Executable header see, "Peering Inside the PE: A Tour of the Win32 Portable Executable

File Format" by Matt Pietrek, Microsoft Systems Journal, March 1994, incorporated herein by reference. The injection logic is placed in a PE header of the KERNEL32.DLL and then is executed with a Windows NT CreateRemoteThread function call as is explained at Step 98.

In Windows NT, the PE header for the KERNEL.DLL is less than 1000 bytes long.

However, the PE header is mapped into an address space on a Windows NT operating system page boundary of 4096 bytes. This leaves over 3000 bytes of unused memory in PE header in which the injection logic can be copied. However, other areas of memory within a process address space could also be used, and the present invention is not limited to using a PE header.

At Step 98, a remote windowed operating system thread is created in the existing process. The windowed operating system thread executes injection logic. In one exemplary preferred embodiment of the present invention, the remote thread is created with the Window NT CreateRemoteThread function. The remote thread issues a LoadLibrary function call from the injection logic in the KERNEL32.DLL PE header and the injection DLL, INJECT.DLL is added to the existing process. At Step 100, the injection service waits for the windowed operating system remote thread to complete execution. In one exemplary preferred embodiment of the present invention, the Windows NT WaitForSingleObject function call is used to wait for an event to occur. In one exemplary preferred embodiment of the present invention, the WaitForSingleObject function call waits for an event indicating completion of the remote thread. However, other method could also be used to wait for the execution of the windowed operating system thread to complete, and the present invention is not limited using the WaitForSingleObject function call. The WaitForSingleObject function call suspends a parent's thread until a child thread terminates. Thus, a primary thread (i.e., the parent) running the injection service would be suspended into a secondary thread (i.e., the child) complete execution. At Step 102, the injection logic is deleted from PE header in the KERNEL32.DLL in the existing process. Steps 94, 96, 98, 100 and 102 are repeated by the injection service for other existing processes located at Step 90, if any.

Method 86 is used to inject injection logic into existing processes on a windowed operating system. The injection logic is available to the existing processes as well as any additional new processes the existing processes may create. Injecting execution logic into new processes in a windowed operating system

At Step 38, of Method 32 (FIG. 2) injection logic is added from the injection service to a function used to create new processes on the windowed operating system. The injection logic intercept requests to create new processes on the windowed operating system. Method 104 illustrates adding injection logic to new processes in such a manner. However, other methods could also be used to add injection logic in new processes in a windowed operating system.

FIG. 6 is a flow diagram illustrating a Method 104 for dynamically injection execution logic for new processes in a windowed operating system that does not used shared memory for processes. At Step 106, a request to create a new process is intercepted in a function used to create new processes on the windowed operating system. At Step 108, a process creation parameter is modified to create the new process in a suspended state in the windowed operating system. At Step 110, injection logic generated by an injection service is copied into an unused area of memory in the new process. At Step 112, an import table function is modified by the injection logic. The import table function is used to load dynamic link libraries within the new process in the windowed operated system. Modifying the new process creates a modified new process. At Step 114, a request is made to the windowed operating system to begin execution of the modified new process. Method 104 allows new processes created in a windowed operating system that does not use shared memory for processes to use injection logic.

In one exemplary preferred embodiment of the present invention, the windowed operating system is Windows NT. However, the present invention is not limited to Windows NT and other windowed operating systems that do not use shared memory for processes could also be used. In an embodiment using Windows NT, at Step 106 a request to create a new process is intercepting in the Windows NT CreateProcess function used to create new processes on Windows NT. At Step 108 a process creation parameter fdwCreate from the CreateProcess function is modified to include a CREATE_SUSPENDED flag to create the new process in a suspended state in Windows NT. When Window NT creates a process in a suspended state, it loads a new process's executable module and an operating system DLL, NTDLL.DLL into a new Win32 process address space 76. Windows 32-bit executable modules are formatted using a PE header format.

As was discussed above, a Win 32 process PE header is mapped into an address space for the NTDLL.DLL on a Windows NT operating system page boundary of 4096 bytes. The NTDLL.DLL takes up about 750 bytes of memory. This leaves over 3000 bytes of unused memory in PE header in which the injection logic can be copied. Because NTDLL.DLL is loaded into every new process address space 76 before the CreateProcess function returns, this unused memory can be referenced by an application that issued the CreateProcess function call.

At Step 110, the injection logic generated is copied into PE header for the NTDLL.DLL in the new process as was described above for Step 96 of Method 86 (FIG. 5). At Step 112, the Windows NT import table function RtllmageDirectoryEntryToData is modified in the NTDLL.DLL with injection logic copied into the PE header for the NTDLL.DLL. As is known in the art, the Windows NT RtllmageDirectoryEntryToData import table function is used to return a pointer to a table including a list of imported modules for a currently loaded executable module associated with a process. At Step 1 14, a request is made to Windows NT to begin execution of the modified process with a call to the Windows NT ResumeThread function using the identifier for the primary thread created for the new process. FIGS. 7 A and 7B are a flow diagram illustrating a Method 116 for using dynamically injected execution logic for new processes in a windowed operating system that does not used shared memory for processes. At Step 118 of FIG. 7 A, a request is received for an import table address in a modified import table function on a modified new process from a module loader on the windowed operating system. The modified import table function determines a list of dynamic link libraries that should be loaded for the modified new process. The modified new process was modified by an injection service on the windowed operating system when the new process was created (e.g., with Method 104 of FIG. 6). At Step 120, a test is conducted to determine if the modified new process includes a bound import table. If the modified new process includes a bound import table, then at Step 122, a temporary table is created. At Step 124, references to one or more windowed operating system dynamic link libraries are added in the first N-entries in the temporary table. At Step 126, a reference to an injection dynamic link library is added at entry N+l in the temporary table. At Step 128, entries from the bound import table are copied into in the temporary table beginning at entry N+2.

At Step 130 of FIG. 7B an address for the temporary table to is returned to the module loader from the modified import table function on the modified new process. At Step 132, the temporary table is deleted after the modified import table is used by the module loader. If the executable module for the modified new process does not include a bound import table at Step 122, then the executable module uses a bound non-import table. Steps 134, 136, 138, 140, 130 and 132 of FIG. 7B are executed for a non-bound import table.

In one exemplary preferred embodiment of the present invention, the windowed operating system used with Method 116 is Windows NT. However, the present invention is not limited to Windows NT and other windowed operating systems that do not use shared memory for processes could also be used.

In FIG. 7 A at Step 118, a request is received for an import table address in an import table function on a modified new process from a Windows NT module loader on Windows NT. The Windows NT module loader calls a modified Windows NT import table function called RtllmageDirectoryEntrytoData. As is known in the art, the Windows NT import table function RtllmageDirectoryEntrytoData returns a pointer to a table including addresses of imported modules associated with an executable module currently loaded for a process. The RtllmageDirectoryEntrytoData function that resides in the NTDLL.DLL that is used by the modified new process. The NTDLL.DLL includes the modified RtllmageDirectoryEntrytoData function that is first used to determine if module includes a Bound import table or just an import table. The modified RtllmageDirectoryEntryToData function in the NTDLL.DLL was modified at Step 112 ofMethod l04 (FIG. 6).

Windows NT uses an import table to automatically load all DLLs that are implicitly referenced by an executable module associated with a process. It is possible to "bind" an executable module to all of its implicitly referenced DLLs. The binding process includes altering the executable module's PE header to create a "Bound import table" based on modules listed in the import table. When a module is "bound" to a set of imported DLLs, the Bound import table includes a time stamp and a name of each DLL it was bound to.

At Step 120, a test is conducted within the modified RtllmageDirectoryEntrytoData function to determine if an executable module for the modified new process includes a bound import table. If the executable module for the modified new process includes a bound import table, then at Step 122, a temporary table is created. At Step 124, references to one or more windowed operating system dynamic link libraries including the modified NTDLL.DLL are added in the first N-entries in the temporary table. At Step 126, a reference to an injection dynamic link library called INJECT.DLL is added at entry N+l in the temporary table. At Step 128, entries from the bound import table are copied into in the temporary table beginning at entry N+2.

At Step 130 of FIG. 7B an address for the temporary table to is returned to the Windows NT module loader. At Step 132, the temporary table is deleted after it is used by the Windows NT module loader. If the executable module for the modified new process does not include a bound import table at Step 122, then it uses a non-bound import table. Steps 134, 136, 138, 140, 130 and 132 of FIG. 7B are executed for a non-bound import table. Using execution logic injected into a windowed operating system

FIG. 8 is a flow diagram illustrating a Method 144 for using dynamically injected execution logic a windowed operating system that does not use shared memory for processes. At Step 146, a request to start a new process on a windowed operating system that does not use shared memory for processes is received on the windowed operating system. At Step 148, a modified operating system dynamic link library is loaded in a memory space for the new process created by the windowed operating system. The modified operating system dynamic link library was modified by an injection service. At Step 150, a modified import table function in the modified operating system dynamic link library is used to load an injection dynamic link library to inject execution logic into the new process. The execution logic is used for debugging aids, hooking other processes, tracing the execution of a process or thread, and for other purposes. In one exemplary preferred embodiment of the present invention, the windowed operating system used with Method 144 is Windows NT. However, the present invention is not limited to Windows NT and other windowed operating systems that do not use shared memory for processes could also be used. Exemplary dynamic execution logic injection system

FIG. 9 is a block diagram illustrating an exemplary injection system 152 for dynamically injecting execution logic into a windowed operating system that does not use shared memory for processes. The injection system 152 includes an injection service 154, a modified operating system import table function 156, a modified create process function 158 and an injection dynamic link library 160. However more or fewer components could also be used in the exemplary injection system 152 and the present invention is not limited to the system components illustrated.

The injection service 154 modifies existing processes, new processes, an operating system dynamic link library and an operating system import table function. The operating system import table function 156 is used to automatically load dynamically link libraries that are implicitly referenced by an executable module associated with a new process in a windowed operating system that does not use shared memory for processes. The modified create process function 158 allows processes to be created including injection logic. The injection dynamic link library 160 includes multiple injection functions for injecting execution logic. The injection functions from the injection dynamic link library 160 are used execute logic prior to executing any other applications related logic for an executable module associated with a process on a windowed operating system.

The methods and system described herein overcome some of the problems associated with injecting execution logic on a windowed operating system that does not use shared memory for process, such as Windows NT. However, the present invention is not limited to Windows NT operating systems, and other windowed operating systems that do not use shared memory for processes could also be used. The methods and system of the present invention may be used for debugging aids, hooking other processes, tracing the execution of an application, and for other purposes. It should be understood that the programs, processes, methods and systems described herein are not related or limited to any particular type of computer or network system (hardware or software), unless indicated otherwise. Various types of general purpose or specialized computer systems may be used with or perform operations in accordance with the teachings described herein. In view of the wide variety of embodiments to which the principles of the present invention can be applied, it should be understood that the illustrated embodiments are exemplary only, and should not be taken as limiting the scope of the present invention. For example, the steps of the flow diagrams may be taken in sequences other than those described, and more or fewer elements may be used in the block diagrams. While various elements of the preferred embodiments have been described as being implemented in software, in other embodiments hardware or firmware implementations may alternatively be used, and vice-versa.

The claims should not be read as limited to the described order or elements unless stated to that effect. Therefore, all embodiments that come within the scope and spirit of the following claims and equivalents thereto are claimed as the invention.

Claims

I CLAIM;

1. In a computer with a windowed operating system with a plurality of processes, wherein the windowed operating system does not use a shared area of memory for the plurality of processes, a method for dynamically injecting execution logic for processes in the windowed operating system, comprising the steps of: starting an injection service on the windowed operating system; locating existing processes in the windowed operating system from the injection service; adding injection logic from the injection service to the existing processes located in the windowed operating system to allow the existing processes and any additional processes created by the existing processes to include the injection logic; and adding injection logic from the injection service to a function used to create new processes on the windowed operating system, wherein the injection logic intercepts requests to create new process on the windowed operating system, and wherein the injection logic is executed by new processes prior to executing any other application related logic associated with the new process executed by the windowed operating system.

2. A computer readable medium having stored therein instructions for causing a central processing unit to execute the method of Claim 1.

3. The method of Claim 1 wherein the windowed operating system is Windows

NT.

4. The method of Claim 1 wherein the step of starting an injection service on the windowed operating system includes starting the injection service whenever the windowed operating system is started.

5. The method of Claim 1 wherein the step of locating existing processes on the windowed operating system from the injection service includes querying performance counters for existing processes on the windowed operating system.

6. The method of Claim 5 wherein the step of querying performance counters for existing processes on the windowed operating system includes querying a function called

EnumProcesses within Windows NT.

7. The method of Claim 1 wherein the step of adding injection logic from the injection service to the existing processes includes adding injection logic into an unused memory area in a header for a operating system dynamic link library.

8. The method of Claim 7 wherein the header is a Portable Executable header for an operating system dynamic link library called KERNEL32.DLL in Windows NT.

9. The method of Claim 1 wherein the step of adding injection logic from the injection service includes adding the injection logic to a function used to a create a new process called CreateProcess in Windows NT.

10. In a computer with a windowed operating system with a plurality of processes, wherein the windowed operating system does not use shared memory for the plurality of processes, a method for dynamically injecting execution logic for existing processes in the windowed operating system, comprising the steps of: starting an injection service on the windowed operating system; generating injection logic from the injection service; locating existing processes on the windowed operating system from the injection service; and repeating the following steps from the injection service for the existing processes located on the windowed operating system: copying the injection logic generated by the injection service into an unused area of memory in an existing process; creating a windowed operating system thread in the existing process, wherein the windowed operating system thread executes injection logic; waiting for the windowed operating system thread to complete execution; and deleting injection logic from the unused area of memory in the existing process, wherein the injection logic is available to the existing processes as well as any additional processes the existing processes may create.

11. A computer readable medium having stored therein instructions for causing a central processing unit to execute the method of Claim 10.

12. The method of Claim 10 wherein the windowed operating system is Windows NT.

13. The method of Claim 10 wherein the injection service includes security features that prevents unauthorized users from altering execution of the injection service.

14. The method of Claim 10 wherein the step of creating injection logic from the injection service, includes loading an injection dynamic link library called INJECT.DLL within Windows NT.

15. The method of Claim 10 wherein the step of locating existing processes on the windowed operating system from the injection service includes querying a function for determining existing processes on the windowed operating system.

16. The method of Claim 10 wherein the step of querying performance counters for existing processes on the windowed operating system includes querying a function called EnumProcesses within Windows NT.

17. The method of Claim 10 wherein the step copying the injection logic from the injection service into an unused area of memory in an existing process includes copying the injection logic into unused memory in a windowed operating system dynamic link library header.

18. The method of Claim 17 wherein the step of copying the injection logic into unused memory in a windowed operating system dynamic link library header includes copying injection logic into unused memory in a Portable Executable header in an operating system dynamic link library called KERNEL32.DLL within Windows NT.

19. In a computer with a windowed operating system with a plurality of processes, wherein the windowed operating system does not use shared memory for the plurality of processes, a method for dynamically injecting execution logic for new processes in the windowed operating system, comprising the steps of: intercepting a request to create a new process in a function used to create new processes on the windowed operating system; modifying a process creation parameter to create the new process in a suspended state on the windowed operating system; copying injection logic generated by an injection service into an unused area of memory in the new process; modifying an import table function in the new process, thereby creating a modified new process, wherein the import table function is used to dynamic link libraries used by the new process; and requesting the windowed operating system begin execution of the modified new process.

20. A computer readable medium having stored therein instructions for causing a central processing unit to execute the method of Claim 19.

21. The method of Claim 19 wherein the windowed operating system is Windows

NT.

22. The method of Claim 19 wherein the step of intercepting a request to create a new process in a function used to create new processes on the windowed operating system includes intercepting a request to create a new process in a function called CreateProcess within Windows NT.

23. The method of Claim 19 wherein the step of copying injection logic generated by an injection service into an unused area of memory in the new process includes copying injection logic into unused memory in a Portable Executable header in an operating system dynamic link library called NTDLL.DLL within Windows NT.

24. The method of Claim 19 wherein the step of modifying an import table function in the new process includes modifying an import table function called

RtllmageDirectoryEntryToData within an operating system dynamic link library called NTDLL.DLL within Windows NT.

25. In a computer with a windowed operating system with a plurality of processes, wherein the windowed operating system does not use shared memory for the plurality of processes, a method for dynamically injecting execution logic for new processes in the windowed operating system, comprising the steps of: receiving a request for an import table address on a modified import table function in a modified operating system dynamic link library, from a module loader on the windowed operating system, wherein the modified import table function includes a list of dynamic link libraries used by the modified new process, and wherein the modified import table function and the modified new process were modified by an injection service on the windowed operating system; determining if the modified new process includes a bound import table, and if so, creating a temporary table; adding references to one or more windowed operating system dynamic link libraries in the first N-entries in the temporary table; adding a reference to an injection dynamic link library at entry N+l in the temporary table; and copying entries from the bound import table in the temporary table beginning at entry N+2; and returning an address for the temporary table to the module loader.

26. A computer readable medium having stored therein instructions for causing a central processing unit to execute the method of Claim 25.

27. The method of Claim 25 further comprising: determining if the modified new process includes a bound import table, and if not, creating a temporary table; adding references to one or more windowed operating system dynamic link libraries in the first N-entries in the temporary table; adding a reference to an injection dynamic link library at entry N+l in the temporary table; and copying entries from an import table in the temporary table beginning at entry N+2.

28. The method of Claim 25 further comprising deleting the temporary table after the module loader uses the temporary table.

29. The method of Claim 25 wherein the step of receiving a request for an import table address includes receiving the request on a function called RtllmageDirectoryEntrytoData in an operating system dynamic link library called NTDLL.DLL on a modified new process within Windows NT.

30. In a computer with a windowed operating system with a plurality of processes, wherein the windowed operating system does not use shared memory for the plurality of processes, a method for using dynamically injected execution logic for processes in the windowed operating system, comprising the steps of: receiving a request to start a new process on a windowed operating system that does not use shared memory for processes; loading a modified operating system dynamic link library in a memory space created for the new process by the windowed operating system, wherein the modified operating system dynamic link library was modified by an injection service; and loading an injection dynamic link library using a modified import table function in the modified operating system dynamic link library to inject execution logic into the new process, wherein the execution logic is executed before any applications related logic for the new process and wherein the modified import table was modified by the injection service.

31. A computer readable medium having stored therein instructions for causing a central processing unit to execute the method of Claim 30.

32. The method of Claim 30 wherein the windowed operating system is Windows NT.

33. The method of Claim 30 wherein the modified operating system dynamic link library includes a modified operating system dynamic link library called NTDLL.DLL, and the modified import table function includes a function called RtllmageDirectoryEntryToData within Windows NT.

34. The method of Claim 30 wherein the step of loading an injection dynamic link library using a modified import table function in the modified operating system dynamic link library to inject execution logic into the new process includes loading execution logic for any of debugging aids, hooking other processes, or tracing the execution of a process or thread.

35. A system for dynamically injecting execution logic into a windowed operating system that does not use shared memory for processes, comprising in combination: an injection service for modifying existing processes, new process, an operating system dynamic link library and an operating system import table function; a modified operating system import table function for automatically loading dynamically link libraries that are implicitly referenced by an executable module associated with a process in a windowed operating system that does not use shared memory for processes; a modified create process function for creating process with injection logic; an injection dynamic link library with a plurality of injection functions for executing logic, wherein the injection functions from the injection dynamic link library are used to execute logic prior to executing any other applications related logic for an executable module associated with a process created by a windowed operating system that does not use shared memory space for processes.

36. The system of Claim 35 wherein the windowed operating system is Windows NT.