Method of and system for malicious software detection using critical address space protection

Description

RELATED APPLICATION

This application claims priority under 35 U.S.C. §119(e) of the co-owned U.S. Provisional Patent Application Ser. No. 61/063,224 filed Jan. 31, 2008, titled “AUTONOMIC NETWORK RESPONSE TO PROCESS HIJACKING,” which is hereby incorporated by reference in its entirety.

FIELD OF THE INVENTION

The invention relates to computer software. Specifically, the invention relates to methods of and systems for detecting malicious software executing on a computer system. The invention uses attributes of memory in which the code is executing to determine whether the executing code is malicious.

BACKGROUND OF THE INVENTION

Networked servers can provide services to other networked hosts. Some of these networked hosts attempt to exploit a server by taking advantage of security loopholes. One exploitation method uses a security hole to inject malicious code into the server memory, and executes the malicious code to exploit the server. This malicious code can search the data structures of an application, a library, or an operating system component to find and utilize server system resources for the purpose of interrupting these services (such as denial of service attacks), to access sensitive information residing on the server, or to perform other malicious steps.

FIG. 1 illustrates one configuration of a malicious host 110 requesting services from a trusted host 120 providing network services. The trusted host 120 is a computer server receiving service requests 112 over a network and providing services 114 such as web, mail, and file sharing. Malicious code is injected from the malicious host 110 into the trusted host 120 using a service request. The malicious host 110 requests a service 112 in which the request encapsulates malicious code. A maliciously structured service request can exploit buffer overflow techniques resulting in the malicious code 140 being loaded into memory 150 of the trusted host 120. Traditional methods of detecting malicious software include special purpose hardware 130 such as a firewall that inspects packets within a network data stream. The packet inspection tools include processing protocols such as HTTP, in which packet payloads are for the most part plain text data. Except for image data or graphics, which can be detected and identified, a firewall will inspect a packet for unexpected binary data. When packet inspection detects unexpected binary data, an indicator of potentially executable and malicious code, the firewall 130 can isolate either the host making the service request or the stream of transmitted data. The disadvantage of this solution is that additional hardware is required. Further, blindly inspecting all packets is processing intensive. Additionally, deep packet inspection techniques require the assembly of payload data streams spread across multiple network packets and result in increased data latency.

Other malicious software identification techniques check for patterns in files and data streams against known virus signatures. The limitation of this technique is that these signatures need to be kept current and are inherently out of date when a new virus is developed.

SUMMARY OF THE INVENTION

A method of and system for detecting memory resident malicious code, based on predetermined address space protection, comprises detecting access to predetermined software addresses by software executing out of writable memory. The predetermined address spaces include memory addresses known to be referenced by malicious code. The method works for computer systems where the memory management is configurable with attributes that cause an exception or event when a configurable address or range of addresses are referenced.

In a first aspect of the present invention, a method of detecting malicious code executing in a computer system comprises identifying the code as malicious if the code is executed from writable memory. In another embodiment the code is identified as malicious when it accesses a predetermined memory address. In some embodiments, the predetermined memory address is limited to the address space of data structures describing an application, a library, or an operating system component or their associated data. In a further embodiment, the predetermined memory address is within the memory range of a process environment block, an import, an export table, a procedure linkage table, a global offset table, a program header, a library header, or a section header. In a further embodiment, the predetermined memory address is not referenced by non-malicious code after the initialization of the application, the library, or the operating system component. In response to the detection of malicious, one embodiment terminates a process, a thread, or an application associated with the code executing in writable memory.

In another embodiment, the method of identifying malicious code comprises generating an exception that invokes an exception handler when the code accesses a memory address range that include the predetermined memory address. Further, the exception handler determines if the code accesses the predetermined memory address and whether the code executes from writable memory if the code that caused the exception accessed the predetermined memory address. In a further embodiment, the exception is generated by configurable hardware for controlling memory attributes of computer system memory. The system is configured to generate an exception when an address within a memory address range, including the predetermined memory address, is accessed. The configurable hardware generates an exception when access to page or range of memory addresses is in violation of the configured attributes for the memory. The configurable attributes include specifying whether the memory is readable or writable. Further, some embodiments the detection generates an indicator of malicious code or terminates a process, a thread, or an application associated with the code causing the exception.

In a further embodiment, the exception handler resumes the code from where the exception was generated. Execution of the code is resumed by configuring the processor to execute the code and setting the configurable hardware for memory attributes for the predetermined memory address not generate another exception when the system executes the code that referenced the predetermined memory address. Next, the processor is singled stepped to execute the code that caused the exception. The hardware is reconfigured to again trigger an exception when the predetermined memory address is referenced. The code execution is continued at the instruction following the code that caused the exception.

In another embodiment, the method further comprises selecting the predetermined memory address or the address range that incorporates the predetermined memory address. The predetermined memory address is located within a address space of an application, a library, or an operating system component. In a further embodiment, the predetermined memory address is not referenced by the application, library, or operating system component after initialization.

In a second aspect of the invention, a computer processing system is configured for detecting malicious code executing in the computer processing system memory. The system comprises memory and a processing system, wherein the processing system is configured for executing an application for identifying code as malicious if it is determined that the code executed from writable memory. In one embodiment, the identification of the malicious code only occurs when the code accesses a predetermined memory address. In a further embodiment, the predetermined memory address is within an address space of data structures describing an application, a library, or an operating system component or their associated data. In a further embodiment, the predetermined memory address is within a memory range of a process environment block, and import table, an export table, a procedure linkage table, or a global offset table. Additionally, the predetermined memory address can be selected from a memory address that is not referenced by non-malicious code after the initialization of the application, the library, or the operating system component.

In another embodiment, the identification of the malicious code is performed by an exception handler invoked upon the code accessing a memory address within a range of addresses that includes the predetermined memory address, such as a memory page. Further, the system includes software, executing inside or outside the exception handler, that determines if the memory reference causing the exception was an access to the predetermined memory address. Further, the system includes software that determines whether the code executed from writable memory if the code that caused the exception by accessing the predetermined address.

In one embodiment the configurable hardware for controlling memory attributes of the computer system memory is configured to generate an exception when a memory address range, including the predetermined memory address, is accessed. The configurable hardware generates an exception when access to page or range of memory addresses is in violation of the configured attributes for the memory. The configurable attributes include specifying whether the memory is readable or writable. Further, some embodiments generate an indicator of malicious code or terminate a process, a thread, or an application associated with the code executing out of writable memory and accessing the predetermined memory address causing the exception.

In another embodiment, the execution of the code is resumed by configuring a processor associated with the computer processing system to resume code execution at an instruction that caused the exception. The predetermined memory address attribute is set to a memory attribute that will not generate another exception when the code references the predetermined memory address. The processor is then single stepped to execute the code that caused the exception. The memory attribute of the predetermined memory address is then again set to cause an exception upon reference. The execution path that was interrupted by the exception is continued by executing the next instruction following the code that referenced the predetermined memory address or in some embodiment the process, thread, or application associated with the code is terminated.

In third aspect of the present invention, a computer program embodied on a computer-readable device for malicious code detection comprises program code for identifying a code as malicious if the code executes from writable memory of the computer system. In one embodiment, the computer program identifies the code as malicious when the code accesses a predetermined memory address. In some embodiments, the predetermined memory address is within an address space of an application, a library, or an operating system component.

In one embodiment, identifying the code as malicious comprises generating an exception that invokes an exception handler when the code accesses a memory page that includes the predetermined memory address, wherein it is determined that the memory access was to the predetermined memory address, and wherein the exception handler determines that the code executes from writable memory.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a prior art configuration of a malicious host, a trusted host server, and a firewall.

FIG. 2 illustrates a prior art organization of an application, an operating system component, and a library component loaded into system memory and configured as text and data memory.

FIG. 3 illustrates steps for detecting malicious code in accordance with one embodiment of the present invention.

FIG. 4 illustrates one embodiment of the processing steps for continuing the code execution from the exception point in accordance with one embodiment of the present invention.

FIG. 5 illustrates a block diagram of a computing device configured to detect a memory resident malicious code in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The following description of the invention is provided as an enabling teaching of the invention. Those skilled in the relevant art will recognize that many changes can be made to the embodiment described, while still attaining the beneficial results of the present invention. It will also be apparent that some of the desired benefits of the present invention can be attained by selecting some of the features of the present invention without utilizing other features. Accordingly, those skilled in the art will recognize that many modifications and adaptations to the present invention are possible and can even be desirable in certain circumstances, and are a part of the present invention. Thus, the following description is provided as illustrative of the principles of the present invention and not a limitation thereof.

In accordance with the present invention, malicious code is detected when executing in writable memory of a computer system. Malicious code can infect a computer system in a number of ways. In one way, buffers used in networking are overflowed to inject malicious code. For example, web servers receiving service requests with data from untrusted hosts can be infected with malicious code embedded in the request and loaded by overflowing the web server's buffer. Data is exchanged between a host and a web server using standard network communication protocols including, but not limited to, HTTP, TCP/IP, UDP, and mail protocols. A data payload from each of these protocols can potentially be the source of malicious code. However, other means are possible for the loading of malicious code into memory. The method by which the malicious code is detected is independent of how the data is loaded or injected into memory. A predominant characteristic of malicious code loaded by buffer overflows or by other improper techniques is that the code is loaded into and executed out of memory that is writeable.

In modern computers, physical memory is managed by hardware such as an MMU (memory management unit). The MMU manages memory such that each process is prevented from altering the data or code of other processes. Further, the MMU can give a process an address space that is larger than the physical memory and appears continuous. However, this continuous data/code virtual memory can be scattered around physical memory or even swapped to disk. In one method of managing physical memory, the MMU divides memory into blocks or pages that cover a continuous range of memory addresses. MMUs give each block or page attributes that includes whether the memory is read only (text memory) or read/write (data memory) or write only.

When an application, an operating system, or a library (including a dynamically linked library) is loaded into memory, the code segments are loaded into text or read only memory. Data memory is given the attribute that includes being writable. Data memory is allocated when a program is loaded or as the program executes. Malicious code loaded or injected into data or writeable memory will execute from a writable memory space and not text memory as expected. Detection of code running in a writable memory space is an indication that the code is not under the management of the OS and thus is considered malicious or suspect code.

One method of detecting the execution of malicious code is to check the memory attribute from which every processor instruction executes. If an instruction executes out of writable memory, then it is considered, logged, or tagged as malicious or suspect code. The problem with this approach is the large processing overhead required to check the memory attribute of every executed instruction, degrading the computer system performance. An alternative approach is to leverage off a known behavior of malicious code and the behavior of properly executing code. Malicious code often needs to gain access to system functions to exploit the system. To learn the location of system resources, the malicious code will read the data structures describing operating system, application, or library code or associated data set up when a process or operating system is started or library function loaded. Example structures used by malicious code to locate system resources include, but are not limited to, PEBs (process environment blocks), import tables, export tables, procedure linkage tables, global offset tables or combinations thereof. From these data structures, a determination of library interfaces, system functions, and process addresses can be made either directly or indirectly. This information is a necessary step in further locating system resources needed to exploit the computer system, often an objective of the malicious code.

A useful characteristic of the PEBs and the other data structures mentioned above is that all or part of these data structures are infrequently referenced, usually only during the startup of an application, during a start of an operating system component, or during the initialization of a library component. By limiting the check of the memory space attribute from which the code is executing to a memory address range seldom referenced, but also being an address that is of likely interest to malicious code, the check for malicious code can be performed with minimal impact to the processing system performance and requires minimal or no overhead during normal operation.

FIG. 2 illustrates one embodiment of a computer processing system 200 utilizing an MMU 225 to manage physical memory 230. The computer processing system 200 comprises a CPU (central processing unit) 220, the MMU 225 and the physical memory 230. Loaded into the physical memory 230 are an OS component or Application 240, which comprises a block of executable code 242 and a data space 244. The executable code 242 is loaded into virtual memory 280 that maps to physical memory 230. The block of executable code 242 is loaded into text memory, a memory space where the memory manager hardware configures the memory with a read only attribute. Like many MMUs, the MMU 225 contains tables with configurable values specifying the blocks or pages of memory in physical memory and configurable attributes for each block and page. Part of the code residing in text memory is a process environment block 246. The data space 244 used by the OS component or application 240 is configured as data memory having a writable memory attribute.

Further shown loaded into physical memory 230 and residing within virtual memory 280, is a dynamically linked library (DLL) 250. The DLL 250 has a code segment 252 in text memory and associated data segments 254 in writable memory. The code for the DLL 250 includes a data structures that reference import and export tables 258 that also resides, as shown, in text memory. As shown in FIG. 2, the malicious code 256 resides in the writable memory of DLL memory 250.

Malicious code 256 is able to be injected in any number of ways, such as from malicious web service requests that overflow buffers and thus are a gateway to injecting the malicious code 256 into data memory. The malicious code detection method is independent of the method by which the code is injected into writable memory. While the malicious code is shown loaded into the library data memory space, it can also be loaded into the OS data memory, application data memory, process heap memory, thread stack memory, or any other writable memory, to name but a few examples.

FIG. 3 illustrates steps 300 for detecting malicious code using predetermined address space protection 300 in accordance with one embodiment of the present invention. Code in the context of the present invention refers to processor executable instructions. The method begins at the Start step 301 which can include initialization of variables, software states, and hardware.

In the step 310, one or more predetermined memory addresses are selected. In accordance with the invention, code executing from writable memory and accessing the predetermined memory addresses is considered malicious. The predetermined addresses are one or more addresses, an address range including a memory page, or multiple address ranges, or any combination thereof. The more addresses chosen, the more likely that malicious code will be caught, but this increases the overhead needed when these addresses are referenced by non-malicious code. The predetermined addresses can be in read only memory, write only memory, or read/write memory. The predetermined addresses can be located in operating system code or data, in libraries including dynamically linked libraries, or in application programs. Further, the address can also include I/O (input/output) memory addresses, BIOS (Basic Input Output System) memory, and memory mapped devices. Preferably the predetermined memory addresses are located at an address or extend over an address range where the malicious code would reference to gain access to system resources to further exploit the system. Further, preferably the predetermined address or addresses are located in a section of memory that is either seldom referenced or is only referenced during operating system initialization, program initialization, or library initialization.

The selection of predetermined address(es), or memory pages containing a predetermined address 310 can be manually performed or selected by automated means. Operating system components are often loaded at known locations. For example, commonly used operating systems load a process environment block into a predetermined and known location. Automated means are also contemplated. A computer program can be used to automatically locate the addresses of the data structures describing operating system components, and library components including dynamic linked libraries or associated data, and determine the address range of predetermined memory sections. The predetermined sections can include a process environment block, an import table, and export table, a procedure linkage table, a global offset table, or any other memory address that is expected to be exploited by a malicious program.

In a step 320, the attribute for the predetermined memory address, page, block, program header, library header, or section header is configured to generate an exception when referenced. This step includes mapping the predetermined memory address into a memory page or block managed by the system hardware. Because the granularity of the memory management, a page or block is needs to be mapped to the predetermined memory address. Preferably, the computer system has hardware for managing memory such as an MMU (memory management unit) or other types of memory page management hardware that provide for setting memory attributes for the system memory. These attributes can be associated with a single memory address, a fixed size page of memory, or a variable sized block of memory. Preferably, the specifiable attributes include read-only memory for text memory, readable and writable memory for data memory. These attributes are configurable to generate an exception when any memory address within a page is referenced. For example, if the read attribute is configured to be excluded, then read references to this page will cause an exception.

The exceptions are handled by exception routines, which preferably are software routine. If the reference to the memory address, page, or block is in conflict the configured memory access attributes, then the reference invokes an exception routine. Some uses for memory exception or trap routines are to indicate a page fault or inaccessible memory As used by the present invention, the occurrence of an exception indicates that the memory page accessed can contain a predetermined memory address and further checking is required, including determining which memory address was referenced and the attributes of the code that made the reference.

In a step 330 an exception or trap is generated when a processor reference is made to a predetermined memory address, a memory address within a predetermined page, or a reference to an address within a predetermined block. Preferably, the exception or trap is detected and generated by hardware. The exception invokes an exception handler in response to the memory reference.

In a step 340 the exception handler is executed. The normal execution path for exception processing is to process the exception as configured by an operating system, which can include swapping the page into memory. Code is added into the exception handler and is configured into the execution path to test whether the exception was caused by a reference to a predetermined address and test whether the memory address of the code that caused the exception executes out of writeable memory.

In a step 345, it is determined if the exception was caused by a memory reference to the predetermined address or predetermined range of addresses. Because the hardware often manages memory in pages that can include memory address other than the predetermined memory address or range of memory address, the exception can be caused by a reference to a non-predetermined memory address. If the memory reference is not a predetermined memory address or range of addresses, then the execution of the code causing the exception is resumed in a step 370. If the memory reference is a predetermined memory address, then the step 350 is performed.

In a step 350, the memory address of the code that caused the memory reference exception is analyzed to determine the type of memory in which the code is located. Code considered to be non-malicious is located in memory with a read-only attribute or text memory. Code is considered to be malicious when the attribute of the memory from which the code is executing is writable. Techniques for determining the address of the code include but are not limited to examination of the instruction pointer and comparing it to the attribute mapping of virtual memory, used by the MMU, reading state information from the MMU, or examining operating system data structures.

In a step 355, the memory attribute of the code causing the exception is determined. If the memory attribute of the code is not writable, the process continues to the step 370. If the memory attribute of the code is writable, then malicious code handling is performed in a step 360.

In a step 360, a response to the detection of malicious code is executed. The malicious code handling 360 can include a range of responses. In one embodiment, the response includes setting an indicator that malicious code was detected. The information regarding the malicious code detection can include the memory location of the malicious code, which is passed to a routine outside of the exception handler. It is desirable to keep exception handling as quick as possible. Asynchronous handling of the malicious detection event is desirable when the response to detection is computationally intensive. Another response is to kill the process or thread that is executing or is suspected of executing the malicious code. Another response includes blocking access to system input/output calls, generating a set of decoy interface modules for the malicious software to try to exploit, or failing specified future system calls for a processor thread. The details of some of these techniques are found in the copending and co-owned U.S. patent application Ser. No. 10/651,588, filed Aug. 29, 2003 and entitled “DAMAGE CONTAINMENT BY TRANSLATION,” which is herein incorporated by reference in its entirety; U.S. patent application Ser. No. 11/122,872, filed May 4, 2005 and entitled “PIRACY PREVENTION USING UNIQUE MODULE TRANSLATION,” which is herein incorporated by reference in its entirety; and copending and co-owned U.S. patent application Ser. No. 10/935,772, filed Sep. 7, 2004 and entitled “SOLIDIFYING THE EXECUTABLE SOFTWARE SET OF A COMPUTER,” which is herein incorporated by reference in its entirety. Additionally, the response to detection of malicious code includes statistical and heuristic methods to determine the identity of a host that is loading the malicious code. Identification of the malicious host allows for the blocking of the host to prevent re-infection and the potential consequences of such an infection, including a denial of services from the infected server. These statistical and heuristic techniques are disclosed in the co-owned and co-pending application having application Ser. No. 12/322,321 filed Jan. 29, 2009, entitled METHOD OF AND SYSTEM FOR COMPUTER SYSTEM DENIAL-OF-SERVICE PROTECTION,” which is incorporated by reference in its entirety. If further execution processing is required, such as processing a page fault, then these further steps are performed.

In the step 370, the execution path of the code causing the exception is resumed. The method by which the execution path is resumed depends on the architecture of the processor. Described in FIG. 4 below are the details of a method of resuming the flow path in accordance with one embodiment of the present invention. The process ends in step 399.

FIG. 4 illustrates one embodiment of the method steps of resuming execution of the code as described above in step 370 of FIG. 3. The method starts at step 401.

In the step 410, preferably executed within the exception handler, the attribute of the predetermined memory address is configured not to cause an exception upon referencing the predetermined memory address. This step is required because the instruction of the code that caused the exception must be retried or reexecuted. Thus, this instruction needs to be executed without causing another exception. An exemplary method by which the attribute is changed includes changing attribute bits on the memory management hardware. The purpose of changing the attribute is to prevent another exception when the processor is single stepped to execute the instruction that was stopped by the exception.

In a step 420, the processor is configured to execute in a single step the processor instruction that caused the exception by referencing the predetermined address. The method by which this is implemented depends on the architecture of the processor. As one example, the instruction pointer is set back to reference the instruction that caused the exception. Some processors support hardware for single stepping code. The single stepping process can include reading and adjusting hardware registers and reading and adjusting stack values as required for a specific processor. In the 440, the attribute of the predetermined memory address or the memory page that includes the predetermined memory address is reconfigured to cause an exception when the predetermined address is referenced. The program flow is continued by continuing the program execution path in the step 450. The process ends in the step 499.

In operation the first step for a processing system to detect memory resident malicious code is to identity one or more predetermined addresses. The predetermined addresses are identified through manual or automated techniques. The predetermined addresses are preferably contained in data structures describing applications, libraries, operating system components, or their associated data. Further, these predetermined addresses includes an address within a process environment block, an export table, an import table, a procedure linkage table, or a global offset table. Alternatively, a software program examines these components to determine the location of the predetermined addresses and mapping them to the associated memory pages. These memory addresses can be further limited to sections of the that are seldom referenced after system initialization and are of interest to malicious code. Particularly useful are the base addresses of the system components because malicious code uses the base address in conjunction with the related data structures to locate system APIs. The base address of libraries are used by malicious code to find associated import and export tables used by the malicious code in the exploitation of the system.

Next the hardware that manages the memory attributes, such as an MMU, is programmed for a memory page or pages that includes the one or more predetermined addresses to generate an exception when referenced. This attribute configuration can occur before, during, or after the loading and initialization of these components. Preferably, the configuration is preformed after the operating system initialization, library loading, and application loading but before the system reaches a state where it can be infected with malicious code. Further, by configuring the malicious detection code after the component initialization, the overhead processing of predetermined address access detection is avoided in systems not infected with malicious code.

Preferably, the predetermined addresses selected are only accessed during the component initialization and startup, or infrequently. The computer system then operates, providing the desired services. For a web server, web pages are provided to host machines until a malicious host connects and uses techniques, including but not limited to buffer overflow to infect writable memory with malicious code. Once the malicious code starts execution, it locates the base address and using the associated data structures to find and utilize system services. Such services can include the APIs for communication socket functions to connect and provide information to an Internet connected system. If one of the predetermined addresses is a base address or a memory address of a data structure describing application, library or operating system components or associated data, then an exception will occur when the malicious code references the predetermined address. The exception will cause the invoking of exception handler code.

Because, the memory resolution of the MMU managing memory pages can cause an exception for memory reference not associated with the predetermined address, the reference causing the exception needs to be check that it is associated with a predetermined address or addresses. If the memory reference is not associated with the predetermined address or address, then the code causing the exception is resumed. If the memory access is associated with a predetermined memory address, then the exception handler checks the memory attribute of the program code that caused the exception. If the attribute indicates writable memory, then the process or thread associated with the code causing the reference is terminated or an indicator of malicious code is set or sent to another process or thread which can aggregate information and implement the appropriate response. This indicator can include the time of the execution, the address of processor code causing the exception, the process or thread identifier associated with the code causing the exception, or a combination of these. This indicator can be passed to a routine outside of the exception handler or can be handled within the exception handler. The response to the detection of malicious code can include terminating the thread or process, blocking access to I/O routines or interfaces, translating an interface the code is trying to access, or using heuristic and statistical methods to correlate the network hosts and the network addresses with the malicious code infection event.

If the thread or process executing the malicious code is not killed, then malicious code is resumed. To execute the processor instruction that caused the exception, the attribute of the predetermined memory address that caused the exception is set so that another exception is not caused. Next, the processor instruction that caused the exception is executed. In one embodiment, this function is performed by configuring the hardware to single step the processor. Next the memory attribute of the predetermined address is reconfigured to cause an exception the next time this address is referenced. Finally, the exception ends and the execution path previously interrupted by the exception is resumed.

FIG. 5 illustrates a block diagram of a computing device 500 configured to implement a computer automated method of detecting malicious code operating in writable memory through predetermined address protection, in accordance to one embodiment of the present invention. The computing device 500 can be part of a system for providing network services where the computing device is in communications with untrusted hosts. The computing device 500 receives service requests including file sharing services, web server services, and e-mail services. The computing device 500 includes a storage device 512 for program and data storage. The data storage can also include web pages, files, e-mails, or combinations thereof. The storage of the malicious code detection program and data can be stored on separate devices or on the same device as the computing device 500. For example, the programming code for detection of malicious code can be stored on a tape, a local hard drive, a CD-ROM, a DVD, or solid state memory. Further, the computing device 500 can communicate with other computational systems including a human interface such as a graphical user interface. The communication can be through a network, direct communication through a dedicated communications link, or through an operating system communication channel such as a socket.

The computing device 500 includes a network interface 502, a memory 504, a memory management unit (MMU) 520, a processor 506, I/O device(s) 508, a bus 510 and a storage device 512. The processor 506 can be almost any type, so long as it has sufficient speed. The memory 504 can be any conventional computer memory known in the art. The storage device 512 can include a hard drive, tape, CDROM, CDRW, DVD, DVDRW, flash memory card or any other storage device. The computing device 500 can include one or more network interfaces 502. An example of a network interface includes a network card coupled to an Ethernet or other type of LAN. The I/O device(s) 508 can include one or more of the following: keyboard, mouse, monitor, display, printer, modem, touchscreen, button interface and other devices including remote systems. The code for the malicious code detection (MCD) 540 through predetermined address protection can be configured into the OS 530 as part of the OS exception handling routine and can be part of the OS initialization. The response handling code 550 for the detection of malicious code can be a component separate from the OS. Additionally, automated predetermined address selection and configuration code 560 is located on the storage. More or fewer components shown in FIG. 5 can be included in the computing device 500. Additional processors, either distributed or local, and additional storage can be incorporated.

Reference has been made in detail to the preferred and alternative embodiments of the invention, examples of which are illustrated in the accompanying figures. While the invention has been described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention. It will be readily apparent to one skilled in the art that various modification may be made to the embodiments without departing from the spirit and scope of the invention as defined by the appended claims. Furthermore, in the detailed description of the present invention, numerous specific details have been set forth in order to provide a thorough understanding of the present invention. However, it should be noted that the present invention can be practiced without these specific details. In other instances, well known methods, procedures and components have not been described in detail so as not to unnecessarily obscure aspects of the present invention.