WO2000062160A2 - Procede et systeme permettant l'injection dynamique de logiques d'execution dans un systeme d'exploitation a fenetres - Google Patents

Procede et systeme permettant l'injection dynamique de logiques d'execution dans un systeme d'exploitation a fenetres Download PDF

Info

Publication number
WO2000062160A2
WO2000062160A2 PCT/US2000/002937 US0002937W WO0062160A2 WO 2000062160 A2 WO2000062160 A2 WO 2000062160A2 US 0002937 W US0002937 W US 0002937W WO 0062160 A2 WO0062160 A2 WO 0062160A2
Authority
WO
WIPO (PCT)
Prior art keywords
operating system
injection
processes
logic
windowed operating
Prior art date
Application number
PCT/US2000/002937
Other languages
English (en)
Other versions
WO2000062160A3 (fr
Inventor
Richard P. Hammond
Original Assignee
Chicago-Soft, Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Chicago-Soft, Ltd. filed Critical Chicago-Soft, Ltd.
Priority to AU29817/00A priority Critical patent/AU2981700A/en
Priority to EP00908485A priority patent/EP1221085A2/fr
Publication of WO2000062160A2 publication Critical patent/WO2000062160A2/fr
Publication of WO2000062160A3 publication Critical patent/WO2000062160A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading

Definitions

  • 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.
  • Dynamic Link Library injection involves loading a Windows 95/98/NT Dynamic Link Library into an address space and placing injection code within a "DllMain" function.
  • 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.
  • loading a Dynamic Link Library into an address space will result in the injected code's execution within an address space.
  • the injected code will only be executed after the process begins executing.
  • 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.
  • User Dynamic Link Library e.g., USER32.DLL
  • 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).
  • both Windows 95/98 and Windows NT implement a
  • SetWindowsHookEx Application Programmer's Interface This function is used to hook events within a primary operating system thread or for other operating system threads.
  • API Application Programmer's Interface
  • This 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.
  • 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.
  • 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.
  • windowed operating system that do not use a shared memory area for processes
  • 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.
  • 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.
  • the injected execution logic should be generally applicable to any process in a windowed operating system that does not use shared memory for processes.
  • 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.
  • 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
  • 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.
  • 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.
  • GUI Graphical User Interface
  • 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.
  • CPU Central Processing Unit
  • a memory for storing program code.
  • 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.
  • RAM Random Access Memory
  • ROM Read-Only Memory
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 located 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 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.
  • the windowed operating system is the Windows NT by the Microsoft Corporation of Redmond,
  • 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.
  • 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.
  • GDI Graphical Device Interface
  • 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.
  • URL Uniform Resource Locator
  • 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").
  • API Application Programming Interface
  • 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").
  • 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.
  • a Win32 process has a single, main thread known as a "primary" thread.
  • 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 OxFFFFFFFFFF 84.
  • 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.
  • DLL Dynamic Link Library
  • libraries are “dynamically linked” because they are linked to an application when it is loaded and executed rather than when it is linked.
  • 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 OxFFFFFF 84 includes 2-GB partition where the Windows NT Kernel 74 resides.
  • an injection service is started from Windows NT.
  • 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.
  • the injection application is started when Windows NT is started. This allows the injection service to monitor other Windows NT services.
  • 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.
  • 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.
  • existing processes in Windows NT are located from the injection service by querying Windows NT process and/or thread performance counters.
  • 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.
  • 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.
  • 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.
  • injection logic is added to a function used to create new processes, so new processes requested by applications will also include the injection logic.
  • 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.
  • 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.
  • an injection service is started on a windowed operating system that does not use a shared memory area for processes.
  • injection logic is generated by the injection service.
  • Step 92 existing processes on the windowed operating system are located from the injection service.
  • 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.
  • the injection logic is copied from the injection service into an unused area of memory in an existing process.
  • Step 98 an additional windowed operating system thread is created in the existing process.
  • the additional windowed operating system thread executes injection logic.
  • the injection service waits for the additional windowed operating system thread to complete execution.
  • 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.
  • the windowed operating system is Windows NT.
  • 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.
  • an injection service is started using Windows NT.
  • Table 1 illustrates psuedo-code for an exemplary injection service for Windows NT.
  • 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.
  • injection logic is generated from the injection service.
  • the injection logic includes a call to the Window NT LoadLibrary function with the name of an injection DLL called
  • Step 92 existing processes on Windows NT are located from the injection service.
  • a Windows NT function called EnumProcesses is called from a Windows NT DLL called PSAPI.DLL.
  • PSAPI.DLL a Windows NT DLL
  • other methods could also be used to determine existing processes on Windows
  • 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.
  • 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.
  • the injection logic generated at Step 90 is copied into a Portable
  • PE Executable
  • 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.
  • the PE header for the KERNEL.DLL is less than 1000 bytes long.
  • 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.
  • 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.
  • a remote windowed operating system thread is created in the existing process.
  • the windowed operating system thread executes injection logic.
  • 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.
  • the injection service waits for the windowed operating system remote thread to complete execution.
  • the Windows NT WaitForSingleObject function call is used to wait for an event to occur.
  • the WaitForSingleObject function call waits for an event indicating completion of the remote thread.
  • the WaitForSingleObject function call suspends a parent's thread until a child thread terminates.
  • a primary thread i.e., the parent
  • running the injection service would be suspended into a secondary thread (i.e., the child) complete execution.
  • 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
  • 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.
  • a request to create a new process is intercepted in a function used to create new processes on the windowed operating system.
  • a process creation parameter is modified to create the new process in a suspended state in the windowed operating system.
  • injection logic generated by an injection service is copied into an unused area of memory in the new process.
  • 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.
  • 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.
  • the windowed operating system is Windows NT.
  • 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.
  • a request to create a new process is intercepting in the Windows NT CreateProcess function used to create new processes on Windows NT.
  • 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.
  • Window 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • references to one or more windowed operating system dynamic link libraries are added in the first N-entries in the temporary table.
  • a reference to an injection dynamic link library is added at entry N+l in the temporary table.
  • entries from the bound import table are copied into in the temporary table beginning at entry N+2.
  • 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.
  • 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.
  • the windowed operating system used with Method 116 is Windows NT.
  • 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.
  • 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.
  • 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.
  • the Bound import table includes a time stamp and a name of each DLL it was bound to.
  • 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.
  • Step 130 of FIG. 7B an address for the temporary table to is returned to the Windows NT module loader.
  • 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.
  • 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.
  • 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.
  • 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.
  • the windowed operating system used with Method 144 is Windows NT.
  • 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.
  • 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.
  • injection service 154 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.
  • a modified operating system import table function 156 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.
  • 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.
  • a windowed operating system that does not use shared memory for process
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)

Abstract

La présente invention concerne des procédés et un système permettant d'injecter de façon dynamique une logique dans un système d'exploitation à fenêtres qui n'utilise pas de mémoire partagée pour les traitements. Ces procédés et ce système permettent l'injection d'une logique d'exécution dans des traitements existants et dans de nouveaux traitements, créés par des systèmes d'exploitation à fenêtres tels que Microsoft Windows NT. La logique d'exécution est exécutée avant tous logiciels d'application dans des modules exécutables associés au traitement. Ces procédés et ce système peuvent être utilisés comme outil de débogage, pour des branchements d'autres traitements, pour le suivi d'exécution d'un traitement ou d'une unité d'exécution, et à d'autres fins.
PCT/US2000/002937 1999-04-08 2000-02-03 Procede et systeme permettant l'injection dynamique de logiques d'execution dans un systeme d'exploitation a fenetres WO2000062160A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU29817/00A AU2981700A (en) 1999-04-08 2000-02-03 Method and system for dynamic injection of execution logic into a windowed operating system
EP00908485A EP1221085A2 (fr) 1999-04-08 2000-02-03 Procede et systeme permettant l'injection dynamique de logiques d'execution dans un systeme d'exploitation a fenetres

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US28519599A 1999-04-08 1999-04-08
US09/285,195 1999-04-08

Publications (2)

Publication Number Publication Date
WO2000062160A2 true WO2000062160A2 (fr) 2000-10-19
WO2000062160A3 WO2000062160A3 (fr) 2001-01-04

Family

ID=23093175

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/002937 WO2000062160A2 (fr) 1999-04-08 2000-02-03 Procede et systeme permettant l'injection dynamique de logiques d'execution dans un systeme d'exploitation a fenetres

Country Status (3)

Country Link
EP (1) EP1221085A2 (fr)
AU (1) AU2981700A (fr)
WO (1) WO2000062160A2 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100424642C (zh) * 2005-10-24 2008-10-08 神基科技股份有限公司 以预设优先次序执行电脑程序的方法
US20100083261A1 (en) * 2008-09-30 2010-04-01 Microsoft Corporation Intelligent context migration for user mode scheduling
US8473964B2 (en) 2008-09-30 2013-06-25 Microsoft Corporation Transparent user mode scheduling on traditional threading systems
US20150254084A1 (en) * 2013-06-19 2015-09-10 Empire Technology Developement LLC Processor-optimized library loading for virtual machines
CN113760274A (zh) * 2020-09-04 2021-12-07 北京京东振世信息技术有限公司 一种前端组件逻辑注入方法和装置
CN116755999A (zh) * 2023-05-17 2023-09-15 安芯网盾(北京)科技有限公司 一种应用于Windows系统的调试服务进程的启动方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998033106A1 (fr) * 1997-01-29 1998-07-30 Shopnow.Com, Inc. Procede et systeme pour l'injection d'un nouveau code a l'interieur d'une application de code existante
US5812848A (en) * 1995-08-23 1998-09-22 Symantec Corporation Subclassing system for computer that operates with portable-executable (PE) modules

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5812848A (en) * 1995-08-23 1998-09-22 Symantec Corporation Subclassing system for computer that operates with portable-executable (PE) modules
WO1998033106A1 (fr) * 1997-01-29 1998-07-30 Shopnow.Com, Inc. Procede et systeme pour l'injection d'un nouveau code a l'interieur d'une application de code existante

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HUNT G., BRUBACHER D.: "DETOURS: BINARY INTERCEPTION OF WIN32 FUNCTIONS" TECHNICAL REPORT MSR-TR-98-33, MICROSOFT RESEARCH, MICROSOFT CORPORATION, ONE MICROSOFT WAY, REDMOND, WA 98052, US, [Online] February 1999 (1999-02), pages 1-9, XP002146206 Retrieved from the Internet: <URL:ftp://ftp.research.microsoft.com/pub/ tr/tr-98-33.pdf> [retrieved on 2000-08-28] *
KASPERESKY E. V.: "WIN95.K32" CENTRAL COMMAND INC., [Online] 1998, page 1 XP002146208 Retrieved from the Internet: <URL:http://www.avpve.com/viruses/win95/k3 2.html> [retrieved on 2000-08-29] *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100424642C (zh) * 2005-10-24 2008-10-08 神基科技股份有限公司 以预设优先次序执行电脑程序的方法
US20100083261A1 (en) * 2008-09-30 2010-04-01 Microsoft Corporation Intelligent context migration for user mode scheduling
US8321874B2 (en) * 2008-09-30 2012-11-27 Microsoft Corporation Intelligent context migration for user mode scheduling
US8473964B2 (en) 2008-09-30 2013-06-25 Microsoft Corporation Transparent user mode scheduling on traditional threading systems
US9229789B2 (en) 2008-09-30 2016-01-05 Microsoft Technology Licensing, Llc Transparent user mode scheduling on traditional threading systems
US20150254084A1 (en) * 2013-06-19 2015-09-10 Empire Technology Developement LLC Processor-optimized library loading for virtual machines
US9710291B2 (en) * 2013-06-19 2017-07-18 Empire Technology Development Llc Processor-optimized library loading for virtual machines
CN113760274A (zh) * 2020-09-04 2021-12-07 北京京东振世信息技术有限公司 一种前端组件逻辑注入方法和装置
CN113760274B (zh) * 2020-09-04 2023-11-03 北京京东振世信息技术有限公司 一种前端组件逻辑注入方法和装置
CN116755999A (zh) * 2023-05-17 2023-09-15 安芯网盾(北京)科技有限公司 一种应用于Windows系统的调试服务进程的启动方法
CN116755999B (zh) * 2023-05-17 2024-03-29 安芯网盾(北京)科技有限公司 一种应用于Windows系统的调试服务进程的启动方法

Also Published As

Publication number Publication date
EP1221085A2 (fr) 2002-07-10
AU2981700A (en) 2000-11-14
WO2000062160A3 (fr) 2001-01-04

Similar Documents

Publication Publication Date Title
US6463583B1 (en) Dynamic injection of execution logic into main dynamic link library function of the original kernel of a windowed operating system
EP0689693B1 (fr) Systeme d&#39;exploitation oriente objets
US6351778B1 (en) Object-oriented operating system
CA2149870C (fr) Systeme hote oriente objets
US5491808A (en) Method for tracking memory allocation in network file server
US9189263B1 (en) Object synchronization in shared object space
US5404529A (en) Object-oriented interprocess communication system interface for a procedural operating system
US5473777A (en) Wrapper for enabling an object otented application to maintain virtual memory using procedural function calls
US6779187B1 (en) Method and system for dynamic interception of function calls to dynamic link libraries into a windowed operating system
US5519867A (en) Object-oriented multitasking system
KR100898315B1 (ko) 인핸스드 런타임 호스팅
US7543301B2 (en) Shared queues in shared object space
US7114152B2 (en) Method, apparatus, and program to determine the mutability of an object at loading time
US6742123B1 (en) Apparatus and methods for preventing denial of service attacks
US20030005168A1 (en) System and method for auditing system call events with system call wrappers
US20030018909A1 (en) Method and apparatus for enforcing security policies in Java applications
WO2006128112A2 (fr) Serveur de groupement assurant un partage de donnees de machine virtuelle
US20050251803A1 (en) Method of performing kernel task upon initial execution of process at user level
JPH09171473A (ja) エラーを管理するための方法およびデータ処理システム
EP1221085A2 (fr) Procede et systeme permettant l&#39;injection dynamique de logiques d&#39;execution dans un systeme d&#39;exploitation a fenetres
US6752836B1 (en) Method and apparatus for high-concurrency client locking with java in a data processing system
Beg et al. A memory accounting interface for the Java programming language
Palakollu et al. Process and Signals
Veerappan et al. Mach micro kernel–A case study

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWE Wipo information: entry into national phase

Ref document number: 2000908485

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2000908485

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2000908485

Country of ref document: EP