AU768758B2

AU768758B2 - Method and system for intercepting an application program interface

Info

Publication number: AU768758B2
Application number: AU48883/02A
Authority: AU
Inventors: Yona Hollander; Oded Horovitz; Ophir Rachman
Original assignee: Networks Associates Technology Inc
Current assignee: McAfee LLC
Priority date: 1999-11-14
Filing date: 2002-06-20
Publication date: 2004-01-08
Anticipated expiration: 2020-11-14
Also published as: JP2003515219A; WO2001037095A1; AU4888302A; AU1598601A; CA2386100A1; EP1236114A1

Description

-4.

Regulation 3.2

AUSTRALIA

Patents Act 1990 COMPLETE SPECIFICATION STANDARD PATENT r~k~m~k~c ssotAs Te.chnoo .7Ln c-.

CKLITCDfC0T oQEPillil 7DITVT P L llfUl fIMI-0 1L1

APPLICANT:

Invention Title: METHOD AND SYSTEM FOR INTERCEPTING AN APPLICATION PROGRAM INTERFACE The following statement is a full description of this invention, including the best method of performing it known to me: METHOD AND SYSTEM FOR INTERCEPTING AN APPLICATION PROGRAM INTERFACE BACKGROUND OF THE INVENTION FIELD OF THE INVENTION The present invention relates to a method and system for intercepting an application program interface within a computer system, in general and to a method and system of diverting control from an application program interface to user supplied functions within a computer system, in particular. The present invention further includes dynamic installation of associated software, within the user portion of an operating system and within the kemrnel portion of the operating system for the implementation thereof.

DISCUSSION OF RELATED ART The present invention provides a method of implement better securitywithin a computer system and enhances security capabilities for systems such as Windows and NT. The present invention further provides a method of better control over function call routines also known as application program interface routines (API) in a manner transparent to the user.

Numerous security systems have previously been proposed and implemented in various systems such-as UNIX and the like. None of the previous solutions provide an efficient, time saving and cost effective manner for controlling APis. On the contrary previous systems, relating to security in general, have resulted in high costs to users to implement, maintain and upgrade said systems.

Previously known system, such as the Windows and NT operating system, fail to secure computer systems making use of APIs from misuse of APIs. There is thus a need for a method for intercepting an application program interface within a computer system.

Therefore it is the object of the present invention to provide a method and system whereby API functions called by user applications are not allowed to execute unless the calling process has the requisite authority and privilege.

One application of such a system could be a security application whereby certain API functions called by user applications are not allowed to execute unless the calling process has the requisite authority and privilege.

Another application might include a system profiler whereby any or all API function calls issued by an application are tracked and 2 used to generate statistics about the behavior of the user application.

Yet another application might 4include intensive parameter checking in conjunction with parameter filtering or parameter correction, whereby any or all API function input parameters sent by the calling application program and the return values from the API routine itself are handled according to prescribed rules.

Constructive in the abstraction of providing. API function interception in a .computerized environment is that the user-supplied code can be inserted and installed within the operating system where it can be accessed.

SUMMARY OF THE INVENTION Application Program interface (API) routines are a primary target and executing API routines is a major objective of intruders in the acts of illegal access attempts from outside the operating system platform.

In Operating. Systems having many APIs as the interface between the program applications and the O/S, intruders are required to execute API functions if they want to gain access to higher privileges or obtain O/S services. Thus, intruders are able to obtain critical resources of the computing environment.

It is therefore the object of the present invention to provide a method and system whereby API functions called by user applications are not allowed to execute unless the calling process has the requisite authority and privilege.

It is also the object of the present invention to provide a method and system whereby parameters associated with said API functions to be examined and processed according to the authority and privilege of the calling process.

It is also the object of the present invention to provide a method and system whereby resulting values associated with said API functions to be examined and processed according to the authority and privilege of the calling process.

It is an object of the present invention to initialize API controlling routine and to hook at least one API routine in memory space associated with user application.

It is also the object of the present invention to replace said hooked API routine code with user supplied code, said user supplied code to be executed upon calling said API by said user application program.

It is also the object of the present invention to receive a call from a previously hooked API and generating a predefined series of operations to control said API operation.

It is also an object of the present invention to manage operation of API controlling routine, to collect and store information corresponding to said API routine.

It is also the object of the present invention to identify said API routine, to obtain said API routine address and to determine the address of at least one user supplied module associated with re-direction of flow of execution of said API routine.

It is further the object of the present invention to enable enhanced privileges relating to memory space associated with said API routine, to store API routine code associated with first re-direction of flow of execution to be later replaced, to store API routine code address associated with second re-direction of flow of execution, to store API routine code associated with second re-direction of flow of execution and replacing said API routine code stored with user supplied code associated with first re-direction of flow of said API routine.

It is also the object of the present invention to restore API routine code previously stored associated with first re-direction of flow of execution to be later replaced, to replace API routine code with user supplied code associated with second re-direction of flow of execution of said API routine and to call said API routine based upon response generated corresponding whether API routine is to be executed in association with user predefined rules.

It is further the object of the present invention to replace said API routine code stored with user. supplied code associated with first re-direction of flow of execution of said API routine and to restore previously stored API routine code associated with second re-direction of flow of execution.

It is also the object of the present invention to limit execution of said user application to said specific API routine corresponding to execution time of API routine based on response generated corresponding to whether API routine is to be executed in association with user predefined rules.

It is also the object of the present invention to cancel the limit on execution of said user application to said specific API routine corresponding to execution time of API routine.

It is a further object of the present invention to execute user supplied code for determining return values of said API routine and to manipulate process level flow control structure to enable return of control to user application.

There is also provided in the present invention a method of inserting user supplied code into memory space of user application by injecting loader code into active process memory space associated with said user application and executing loader code to further load user supplied code into memory space, said user supplied code operative to further control API execution.

Also provided in the present invention are an apparatus controlling the method of providing user control of said API, which includes an initalizer for obtaining list of active processes within the computer system, an injector for injecting API interception module into said active processes, means for monitoring predetermined system 7 calls operative to further injection of API interception routine into new created process and means for updating said list of active processes.

There is also provided in the present invention an apparatus to provide system call interception, which includes means to obtain list of active processes within the computer system, means to open processes within a computer system and means to issue notification massages associated with said system calls.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitutes a part of the specification, illustrate preferred embodiments of the invention and, together with the description, serve to explain the principles of the invention: Fig. 1 is a schematic block diagram of an API Interception System environment generally referenced Fig. 2 is a high-level flow diagram of the API Interception Control Server operation referenced in Fig. 1; Fig. 3 is a flow diagram of the API Interception Module injection process referenced in Fig. 2,; Fig. 4 .is a flow diagram of the System Call Interceptor Component operation referenced in Fig. 1; Fig. 5 is a high-level flow diagram of the API Interception Module operation referenced in Fig. 1; Fig. 6 is a flow diagram of the API Interception Module Initialization routine operation referenced in Fig. Fig. 7 is a flow diagram of the API Interception Module Hook and Patch API Routine operation referenced in Fig. Fig. 8 is a block diagram of the API Interception Module run-time operation referenced in Fig. 1; Fig. 9 is a flow diagram of the API Interception Module Dispatch Routine run-time operation referenced in Fig. 8; Fig. 10 is a flow diagram of the API Interception Module Pre-Entry Routine operation referenced in Fig. 8; Fig. 11 is a high-level flow diagram of API Interception Module Depatch routine operation referenced in Fig. 8; Fig. 12 is a flow diagram of the API Interception Module Post-Entry routine operation referenced in Fig. 8.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT An Application Program Interface (API) is a set of routines that an application program calls to request and carry out services performed by the operating system. An API serves as an interface between the application program and the operating system. API function handle important and sensitive areas of the computerized environment such as communications, debugging, file handling, memory management, ,networks, printing, processes control and threads, security, services and the like. API functions object code is generally implemented through the use of dynamic-link libraries (DLL).

DLLs are commonly organized in modules ready to be loaded into the computer's memory device. When a process is created within a computer system, the DLL modules consisting of the API functions are loaded into the process address space.

API functions are powerful and most of them operate on the critical levels of the computerized environment. Because API functions serve as an interface between the Application Program and the Operating System, they commonly run having enhanced privileges Consequently, API routines are a crucial element in the course of illegal access attempts from outside the operating system platform.

In Operating Systems having many APIs as the interface between the program applications and the O/S, intruders are required to execute API functions if they want to gain access to higher privileges or obtain O/S services. Thus, intruders are able to obtain critical resources of the computing environment.

O/S do not include a built in mechanism to intercept and examine API functions called from a user application. Once a user run application program calls an API function, there is no possibility of pre-processing said application program arguments, controlling said application program execution flow, monitoring said application program activities, or blocking said application program activation, if and when necessary.

As some API routines operate, while having the highest privileges within the computer operating system, it is desirable in many instances, to intercept API function calls and re-direct them to execute user-supplied custom code instead. Such instances may include general system management functions generally, and system security management functions particularly.

The API Interception System 10 environment and the operational logic of the present invention provides a method of intercepting an API and of diverting control from the API to user-defined custom code. The present invention overcomes the disadvantages of the prior art by providing novel methods, which enhance and add to capabilities of a user to gain access to system events. The user's capabilities to control, to manage, and to handle system events are also extended thereby.

The present invention will be described with reference to the accompanying drawings.

Turning now to Fig. 1 there is provided a schematic illustration of the system environment wherein the API Interception System is operating, generally referred to as system 10, in accordance with a preferred embodiment of the present invention.

System 10 consists of the four major components of the API Interception System, three of which are active and one passive; a) API Interception Control Server 16 is an active component. API Interception Control Server 16 is the operational center of the API Interception System 10. The API Interception Control Server 16 is loaded into the user space memory device 12 of a computer system implementing the present invention.

b) API Interception Module 32, 36, and 40 is an active component. API Interception Module 32, 36, and 40 is a Dynamic Link Library (DLL) module, which is loaded by the API Interception Control Server 16 into each active process address space 18, 20, 22 loaded in user space memory device 12. DLLs are a set of callable subroutines linked as binary image that can be dynamically loaded by computer programs that use them. A binary image is a collection of compiled modules that are combined by a linker into a form that is ready to be loaded for execution. API Interception Module 32 and all its copies 36, inside active process address space 18, 20, 22 are linked with API Interception Control Server 16. The link is established directly by API Interception Module 32, 36, and 40, after API Interception Module 32, 36, 40 have been loaded into active process address space 18, 22. It will be appreciated by those skilled in the art that the number of API Interception Modules copies present within active processes residing within the computer system user address space is associated with the number of process active at any given time. It is, however, one of the objects of the present invention to provide a further user predetermined control on the number of API Interception Modules to be associated with active process. Means for controlling the number of API Interception Modules to be associated with active process is preferably achieved using interactive command console present within API Interception Server 16. Allowing said control would greatly enhance the efficiency and speed of performing the methods contemplated by the present invention. It is further clarified that the number of API Interception Modules 30, 34, 38 and associated active processes 18, 20, 22 as shown in the drawings serve for purpose of illustration and it will be appreciated by the person skilled in the art that many more active process may be associated with corresponding API Interception Modules.

c) System Call Interception Component 24 is an active component. System Call Interception Component 24 operates in the kernel space memory device 14 and is linked to API Interception Control Server 16, present within user space memory device 12; d) API routine 30, 34, 38 is a passive component. API routines 30, 34, 38 are potential objects upon which API Interception System 10 operate. API routines 30, 34, 38 are loaded into each corresponding and associated process address space 18, 20, 22 which are loaded into user space memory device 12.

Turning now to Fig. 2 there is provided a high-level flow diagram of the API Interception Control Server 16 operation.

The API Interception Control Server 16 is the command center of the API Interception System 10. The API Interception Control Server 16 in the framework of its tasks' initializes the system, loads and injects the appropriate DLL into the appropriate address spaces, supervises activities, monitors execution and concentrates messages of the API Interception System 10. The API Interception Control Server 16 monitors the host operating system for the creation and termination of processes, through the System Call Interception Module 24 and in turn will suspend, resume, and terminate processes and threads by issuing commands. to the System Call Interception Module 24.

API Interception Control Server 16 begins its operation by loading System Call Interception Component 24 into kernel space memory device 14. After establishing communication with the System Call Interception Component 24 API Interception Control Server 16 requests from System Call Interception Component 24 the list of active processes (step 52). The list of active processes enables API Interception Control Server 16 to build a list of Managed Processes (step 54). Using the list of Managed Processes API Interception Control Server 16 injects API Interception Module 32, 36, 40 into the address spaces of all active processes 18, 20, 22 which are in user 16 space memory device.12 (step 56).

During its run-time operation AP4 Interception Control Server 16 constantly monitors the host operating system for'system calls through System Call Interception Component 24 (step 58) and taking appropriate action according to the type of system calls detected. If the system call detected is process creation (step 60) then API Interception Control Server 16 injects into the newly created process address space 18, 20, 22 a copy of the API Interception Module 32, 36, 40 (step 64) and returns monitoring system calls (step 58). If the detected system call of the type of process termination (step 62) API Interception Control Server 16 removes the process 18, 18, 22 from the list of the Managed Processes (step 66). and optionally might take further action required according to the type of the -operating system.

Optionally, API Interception Control Server 16 may accept reports from API Interception Module 32, 36, 40 for the purpose of creating various Management Information Structures. Such structures could be used as input to Management Reports such as API function profiles or as frequency of use and length of use, user profiles such as types of API routines 30, 34, 38 used and other statistics. Naturally, such reports would be highly useful and valuable to users in charge of managing and controlling the over-all operation of a computer system and of an operating system platform such as system administrators.

Optionally, API Interception Server 16 might instruct System Call Interception Component 24 to call and run miscellaneous operating system services that can be executed in kernel space memory device 14 only. For example, API Interception Server 16 might request System Call Interception Component 24 to open a new process, to suspend, to resume, or to terminatean active process and the like.

A high-level flow diagram of the method of injecting API Interception Module 30, 34, 38 into address space of an active process 18, 20, 22is illustrated in Fig. 3. API Interception Control Server 16 allocates memory for a Loader Code in the address space of the process 18, 20, 22 (step 70). Consequently, the Loader Code is inserted into the process address space 18, 20, 22 (step 72). The Loader Code is small executable binary image that runs as a thread of the process 18, 20, 22. A thread is an entity within a process 18, 22 that the host operating system schedules for execution. The Loader Code is activated and in turn calls an operating system pre-existing function that loads API Interception Module 32, 36, 40 into a predefined area in the process address space memory device 18, 22 (step 74). For example, CallRemoteThread function, which can be used in conjunction with the NT operating-system manufactured by the Microsoft Corporation, Redwood, Washington, USA, is such an operating system function that may be used to load the API Interception Module into a user predefined process address space memory device.

A remote thread is a thread that is created by a process with a specific instruction to run in the context of a different process. It will be appreciated that through the use of the method of injecting API Interception Module into address space of a memory device, a remote thread 75 is created. Consequently, API Interception Module 32, 36, and the like are injected into the process address space 18, 20, 22 and the like (step 76).

It will be appreciated by those skilled in the art that there are other means that could be utilized for loading API Interception modules into a user process address space memory device such as using Asynchronous Procedure Calls (APCs) and the like. Utilizing APCs enables user programs and/or system routines to execute code in the context of a particular user thread.

A high-level flow diagram of operation of the System Call Interceptor Component 24 is illustrated -in Fig. 4. System calls are requests made by user programs or by other system routines to run operating system routines, functions or services in kernel mode.

Kernel mode refers to a mode of execution in a processor that grants access to system memory devices and all CPU (Central Processing Unit) instructions. System Call Interception Component 24 that operates in kernel space memory device 14 intercepts all operating system calls (step 80). System Call Interception Component 24 will notify API Interception Control Server 16 of system calls relevant to process and thread creation or termination. First System Call interception Component 24 determines the type of system call (step 82, step 84) subsequently sends this information to API Interception Control Sever 12 (step 86). In the present description there is described the operating of the System Call interception Component 24 in relation to system call instructing the O/S to create a process or to terminate a process. It will be appreciated that many other various system call may be identified and processed by the method and system operative in accordance with the present invention.

System Call Interception Component 24 also executes requests made to it by API Interception Control Server 16 (step 88). To get a list of active processes 1.8 which API Interception Control Server 16 needs for the operation of the API- Interception System 10, a request for the list of active processes is made to System Call Interception Component 24 (step 90). The result is this request will be passed back to API Interception Control Server 16 in the form of the requested list.

Another request that could be made to System Call Interception Component 24 by API Interception Control Server 16 is Open process request (step 92). The execution of this request will open a process and the result will be passed back to the API Interception Control Server 16.

Optionally, API Interception Control Server 16 mightmake other requests to System Call Interceptor Component 24 such as terminating a thread or a process according to the type of the operating system the API Interception System 10 is running under.

The high-level flow diagram of the API Interception Module 32 operation is illustrated in Fig. API Interception Module 32 begins its operation immediately after being loaded into process 18 address-space by initializing API Interception System 10 (step 10). Consequently API Interception 21 Module 32 hooks and patches APIs 30 active and loaded into the process 18 address space (step 104). During its run-time operation API Interception Module 32 handle API calls that are being made by the application programs in the host operating system (step 106). The manner of operation of the API Interception Module 32 is further explained and illustrated in the following description and drawings.

Referring to Fig. 6 there is provided a flow diagram of the API Interception Module 32 initialization operation of Fig. After API Interception Module 32 is loaded, the API Interception Module 32 establishes connection with API Interception Control Server 16 for future communications and events delivery (step 110). Once communication was established various local variables are allocated within address space (step 112). API Interception Module 32 accesses the pre-defined API Descriptor Structure (step 114) and allocates address space for API Flow Structure (step 116). API Descriptor Structure is a user predefined table consisting and referring to APls to be handled by the API Interception Control Server 16. API Descriptor Structure may consist of the DLL name owning said API, API name, number of parameters passed to API, user function names to be used before API is executed and thereafter. It will be appreciated 22 that such a table may include various other details and information as is persistent with the operation of the present invention. It will be further appreciated that such a table is initially provided as part of the of the API Interception Control Server 16. API Interception Structure is a table created dynamically by API Interception Module 32 as is further detailed in Figure 7 and the accompanying description. API Interception Structure table is used to maintain information pertinent to the operation of the method and system operative in accordance with the present invention. API interception Structure Table may include information such as, address of the hooked API function and protection flag for the memory device page allowing control over memory device changes and updates. API Interception Structure Table may further include address of user function to be executed before the hooked API (Pre-Entry routine), address of user function to be executed after the hooked API is executed (Post-Entry routine) and said hooked API number of parameters to be passed to said API.

It will be appreciated that various means for creating and storing such a table may be employed. It will be further appreciated that such table may be stored and maintained in various locations within said computer system, including within-said user address space of active process in which API Interception Module is operating and 23 the like.

Hooking, as a concept will be used in the context of this document defined as obtaining control of a desired API function Patching, as a concept will be used in the context of this document defined as intentional overwriting of a section or sections of an executable binary file such as an API function 30 as it appears in the process address space 18 for the purpose of deliberately controlling the said code behavior.

A detailed description of Hook and Patch API phase (step 104 in Fig. 5) is illustrated on Fig. 7. First the said routine accesses the API Descriptor Structure Table and selects the first API function from the said structure (step 149). Subsequently the API function address is accessed (step 150). The protection flag of the memory page that includes the API function 30 is saved to API Flow Structure Table and then changed to "write-enable" the page (step 152). A memory page is a unit of data storage that is brought into real storage from auxiliary storage when a requested item of data is not already in real storage. Changing said memory page protection flag allows the API Interception Module to write code or data into said changed 24 memory page.

To activate a function the Call-instruction is used. Like all other executable instructions, the Call instruction represented in object code has a specific length that is expressed in the number of bytes making up the instruction. The number of bytes making up a Call instruction may vary across different processors. Therefore, the Length of the Call Instruction will be referred to as LCI, in order to represent the variable number of bytes.

The first LCI bytes of the API function 30 are saved to API Flow Structure Table (step 154). Additionally, the API function address, Pre-Entry routine address, Post-Entry routine address and the number of the arguments of the API function 30 are loaded into the API Flow Structure Table (step 156).

Calculating the address of the Secondary Patch takes place next (step 158). The address of the Secondary Patch is particularly important as it allows re-patching of the first LCI bytes of the said API to be hooked. Re-patching of the first LCI bytes is desirable in order to allow the API Interception Module 32 to further hook additional or subsequent calls to said API.

In order to calculate the address of'the Secondary Patch the API Interception Module 32 uses a known function that returns the length of the next instruction examined (Command Length function).

API Interception Module 32 begins examining the instruction located at the first byte of the said API function 30 to be hooked. API Interception Module 32 calls said Command Length function. If the length of the return answer is less than LCI (Length of Call Instruction) than the API Interception Module 32 advances the number of bytes returned from said Command Length function and repeat the operation. If the return address is more than LCI bytes (commutative from the first byte of the API to be hooked) than the return address is the Secondary Patch Address. It will be appreciated that the Secondary Patch Address may include a cumulative number if more than one call has been made to the Command Length function. The desired result is that the first LCI bytes of the API to be hooked 30 are reserved and saved and may be used for hooking purposes. The second desired result is that the Second Patch Address points to the next beginning byte of an instruction within the API to be hooked but not within the first LCI bytes of the said API. Such result is desirable in order for the method operative in accordance with the present invention to execute the said API The Secondary Patch address Is saved to API Flow Structure Table (step 160) as well as first LCI bytes of the API function on the address of the Secondary Patch (step 162). Finally, the first LCI bytes of the API function 30 are overwritten (patched) with a call instruction to API Interception Module 32.

At this point, the API function 30 is patched with the Primary Patch; LCI bytes beginning at first byte of the API function 30 are overwritten with the API Interception Module 32 re-direction code. The rest of the API function 30 executable binary image is untouched but irrelevant at this point. Each call to API function 30 (that is in the calling process address space 18) in this state will be re-directed to the API Interception Module 32 that loaded into address space of the calling process 18.

Finally the next API function 30 is selected from the API Descriptor Structure Table (step 165) until all API functions 30, 34, and the like that appear in the API Descriptor Structure Table are hooked and patched.

Fig. 8 is a generalized block diagram of the API Interception Module calling sequence in association with its various co-routines and in association with the API 30, 34, 38 and the like to be intercepted and the applications that call API 30, 34, 38 and the like.

An application program 170 that running in process 18 27 address space may make an API function 30 call. The API function is Primary Patched (an operation that was further described on the flow diagram of the Hook and Patch API phase 104 of Fig. 7) by the API Interception Module 32, either at system start-up or when the associated process 18 was created. As a result of said Primary Patch previously placed in the first bytes of said API function 30 control is re-directed from the API function 30 by the call instruction on the patched first LCI bytes of its executable binary image. The API function 30 proceeds with performing the first instruction now placed within said API and calls Dispatch routine 174.

Dispatch routine 174 may call Pre-Entry routine 176 to handle API function 30 arguments. When Pre-Entry routine 176 returns control to Dispatch routine 174, the later executes a series of control operations. First Dispatch routine locks out all other threads present within process 18 from calling the API routine 30 being handled. Such lock mechanism may be implemented via declaring the present operation a critical section, recognized in such operating systems such as NT. Within said critical section stage threads or execution flow other than the one currently calling said critical stage would not be serviced by the computer 'system. Such threads execution is therefore suspended until said critical stage is canceled.

28 Then Dispatch routine re-patches the API routine 30 with a Secondary Patch. Specifically, said Dispatch routine restores the API function 30 original first LCI bytes to its executable binary image and then overwrites the previously calculated Secondary Patch Address (step 158 of Fig. 7) with a call instruction to the Depatch routine 180 of Fig. 5. Finally, it calls said API function API function 30 patched with the Secondary Patch executes its original instructions up to the Secondary Patch. Then as a result of the overwritten Secondary Patch Address it calls the Depatch routine 180.

Depatch routine 180 will restore the Secondary Patch that is, it will overwrite the Secondary Patch Address with the previously saved LCI bytes from said Secondary Patch Address (step 162 of Fig.7). Depatch routine 180 will also re-create the Primary Patch, that is will overwrite the API function 30 executable binary image first LCI bytes with a call instruction to the Dispatch routine 174. Re-writing said call instructions to said API first LCI bytes ensures other calls to said API are hooked as well.

Before returning control to the API function 30 Depatch routine 180 will allow all other threads present in process 18 to call API function 30. This is accomplished by canceling said critical section 29 stage. Finally, it will return control to API function 30, which is now patched with the Primary Patch only. API function 30 may now run its instructions to their conclusion. After the end of its execution it will return control to Dispatch routine 174.

As a result of these operations every process that might call API function 30 and the like will either be locked out and wait or will succeed in calling but only the API function 30 with the Primary Patch.

That is, under the API Interception System 10 control, API function and the like will always call Dispatch routine 174. API function 30 and the like execution form will be in three distinct stages: a) patched with a Primary Patch, when execution begins at the start of the executable binary image, the result of which will be immediate re-direction to Dispatch routine 174 b) patched with a Secondary Patch, when execution begins at the start of the executable binary image, the result of which will be normal execution up to the Secondary Patch and then re-direction by its contents to the Depatch routine 180 '4 c) patched with a Primary Patch when execution begins at the return address from Depatch routine 180 and as a result API function 30 and the like will execute the whole series of its instructions to their conclusion.

When control returns to Dispatch routine 174 from API routine 30 Dispatch routine 174 will return directly to the calling application 170 and not to the calling API function 30. This is accomplished by Dispatch routine code that directly manipulates the process-level flow control structures a Procedure Activation Record or Logical Stack Frame under some host operating systems) before returning to its caller.

A high level description of the operation of the Dispatch routine 174 on Fig. 8 is illustrated on Fig. 9. First, Dispatch routine 174 checks if there exists a Pre-Entry routine 176 of Fig. 8 for API function that is being handled (step 180). If Pre-Entry routine 176 exists for the API function 30 then said Pre-Entry routine is called (step 182). In association with the Pre-Entry routine 176 return values, API Interception Module 32 and API Interception Control Server 16, as per user predefined or user on line instructions decide whether to allow the API function 30 to execute (step 184). If the decision is to allow API function 30 to execute the following steps are taken: A lock is put on the API routine 30 to prevent other threads to call it (step 186). A lock is an operating system mechanism that will keep a certain resource exclusive to a single process. Such lock may be implemented through the use of the critical stage command operative within the NT operating system, as further explained above. Next the API function is re-patched with the Secondary Patch and API function 30 is called (step 188). After the API function 30 returns, Dispatch routine 174 checks if there exists a Post-Entry routine 178 of Fig. 8 for the API function 30 that is being handled (step 189). If Post-Entry routine 178 of Fig. 8 exists it is called (step 190). After control returns from Post-Entry routine 178 to Dispatch Routine 174, Dispatch Routine 174 returns control and return values (if applicable) to calling application 170 of Fig. 8 (step 194) and not to the API function 30 by manipulating a process-level flow control structure (step 192).

Fig. 10 illustrates a high-level flow diagram of the Pre-Entry routine 176 of Fig. 8. First, Pre-Entry routine 176 accesses the API function 30 arguments (step 196). Subsequently Pre-Entry routine 176 executes various user-written custom code sections. (step 197) Such user-written custom code may include code required for producing 32 various reports such as statistical reports, system profiles and the like.

Optionally, the API function 30 arguments are processed (step 199) and a decision is made by the Pre-Entry routine whether the API function 30 is allowed to execute in the present environment (step 200). Such decision may rely on user predefined information or on online decision taking by a user or a system administrator controlling operation of said operating systems. Such decision could further be made according to static pre-defined parameters or dynamically according to the type and value of the arguments passed by the calling applications. If the decision is not to allow the API function 30 to execute then a notification associated with prohibition of execution of said API is returned to the Dispatch routine 176 (step 201).

Fig. 11 illustrates a high-level flow diagram of the Depatch routine 180 of Fig. 8. First, Depatch routine 180 restores the Secondary Patch saved in step 162 of Fig. 7 to the calling API 30 (step 202). Then Depatch routine 180 will patch the Primary Patch as in step 164 of Fig. 7 (step 204). Before returning control to calling API Depatch routine 180 will release the lock -from API 30 (step 206) enabling other processes to call the said API.

33 Fig. 12 illustrates a high-level flew diagram of the Post-Entry routine 178 of Fig. 8. Post-Entry routine 178 handles the return values of the API 30. First, Post-Entry routine checks the return values (step 208). Optionally Post-Entry routine 178 could process return values, such as changing said values, filtering said values or blocking said values from returning to the calling application 170 of Fig. 8 (step 210).

Finally Post-Entry routine 178 checks the API's return code (step 212) and optionally could change it (step 214).

Additional advantages will readily occur to the person skilled in the art. The invention, in its broader aspects is, therefore, not limited to the specific details, representative methods, systems and examples shown and described. It will be further appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather the scope of the the applicant's general inventive concept and the claims which follow.

Claims

2. The method of claim 1. wherein said step of Initializing API controlling routine comprises the steps of managing operation of API controlling routine and collecting and Istoring information corresponding to said API routine:
3. The method according to claim 1. wherein said step of hooking at least one API routing in said memory space associated with user application comprises the steps of; identifying said API routine: Sobtaining said API routine address: and determining address of at least one user supplied module associated with re-direction of flow of execution of said API routine:
4. In a computer system running an operating system platform, said operating system including a kernel space and a process space, a user application running in process space. said user application using application program interface function (API), whereby said API function is executed in process space of the memory space, a method of providing user control of said API function in conjunction with previously hooked API functions associated with user application and responsive to call made to said API function by said user application, said method comprising steps of: restoring API routine code previously stored associated with first re-direction of flow of execution to be later replaced; replacing API routine code with user supplied code associated with second re-direction of flow of execution of said API routine; calling said API routine based on response generated corresponding to whether API routine is to be executed in association with user predefined rules; replacing said API routine code stored with user supplied code associated with first re- direction of flow of execution of said API routine; restoring previously stored API routine code associated with second re-direction of flow of execution;
5. The method according to claim 4, initially comprising the step of limiting execution of said user application to said specific API routine corresponding to execution time of API routine based on response generated corresponding to whether API routine is to be executed in association with user predefined rules. S6. The method according to claim 4. further comprising the step of canceling limiting execution of said user application to said specific API routine corresponding to execution 00.. time of API routine.
7. The method according to claim 4. further comprising the steps of: Sexecuting user supplied code for determining return values of said API routine; manipulating process level flow control structure to enable return control to user application.
8. In a computer system running an operating system platform, said operating system including a kernel space and a process space, a user application running in process space, said user application using application program interface function (API), whereby said API function is executed in process space of the memory space, a method of inserting user supplied code into memory space of user application, said user supplied code operative to further control API execution, said method comprising steps of: injecting loader code into active process memory space associated with said user application; and executing loader code to further load user supplied code into memory space, said user supplied code operative to further control API execution: wherein said user supplied code replaces API routine code by: storing API routine code associated with first re-direction of flow of execution to be later replaced: storing API routine code address associated with second re-direction of flow of execution: storing API routine code associated with second re-direction of flow of execution; replacing said API routine code stored with user supplied code associated with first re- direction of flow of execution of said API routine.
9. In a computer system running an operating system platform, said operating system including a kernel space and a process space, a user application running in process space, said user application using application program interface function (API), whereby said API function is executed in process space. an apparatus controlling the method of providing user control of said API function, said apparatus comprising: an initializer for obtaining list of active processes within computer system; an injector for injecting API Interception module into said active processes; means for monitoring predetermined system calls operative to further injection of API Interception routine into new created process: Smeans for updating said list of active processes: means for replacing a hooked API routine code with user supplied code, comprising: means for storing API routine code associated with first re-direction of flow of execution to be later replaced; means for storing API routine code address associated with second re-direction of flow of execution: means for storing API routine code associated with second re-direction of flow of execution: means for replacing said API routine code stored with user supplied code associated with first re-direction of flow of execution of said API routine. The apparatus according to claim 9, wherein said initializer includes a system call interception module operative to obtain list of active processes within a computer system. I 1. The apparatus according to claim 9, wherein said initializer includes a system call interception module further operative to open processes within a computer system.
12. The apparatus according to claim 9, wherein said initializer includes a system call interception module further operative to issue notification associated with to system calls.
13. The User Control method as substantially described hereinabove. 0 14. The User Control method as illustrated in any of the drawings.
15. The User Control Apparatus as substantially described hereinabove.
16. The User Control Apparatus as illustrated in any of the drawings.