Abstract:
Methods, apparati and computer readable media for countering malicious code infections that spread from a first computer to a second computer. A searching module ( 51 ) searches for a communications module ( 20 ) within the first computer ( 1 ( 1 )). An examining module ( 52 ) examines a function location directory ( 27 ) within the communications module ( 20 ). A locating module ( 53 ) locates a send function within the function location directory ( 27 ). A declaring module ( 54 ) declares the presence of malicious code when the function location directory ( 27 ) states that the send function is slated to start executing at a non-normal location.

Description:
TECHNICAL FIELD 
   This invention pertains to the field of countering infections to computer systems caused by malicious code such as computer worms. 
   BACKGROUND ART 
   As used herein, “malicious code” is any computer program, module, or piece of code that enters a computer system without the authorized user&#39;s knowledge and/or without the authorized user&#39;s consent. The term “malicious code” includes viruses, Trojan horse programs, and worms. The malicious code may or may not have the ability to replicate itself. 
   This invention has particular applicability to malicious code that has the ability to replicate itself from one computer to another, e.g., over a computer network. The computer network may be a closed proprietary network or an open network such as the Internet. Such malicious code is often referred to as a “worm”. Szor, Peter, “Attacks on Win32”,  Virus Bulletin Conference , October 1998, England, and Szor, Peter, “Attacks on Win32—Part II”, Virus Bulletin Conference, September 2000, England, describe various attacks by malicious code, including worms, on computer systems, with particular applicability to the Win32 API (Application Programming Interface). 
   DISCLOSURE OF INVENTION 
   The present invention comprises methods, apparati, and computer readable media for countering malicious code infections that spread from a first computer to a second computer. A preferred embodiment of the inventive method comprises the steps of: 
   searching ( 43 ) for a communications module ( 20 ) within a first computer ( 1 ( 1 )); 
   examining ( 45 ) a function location directory ( 27 ) within the communications module ( 20 ); 
   locating ( 46 ) a send function within the function location directory ( 27 ); and 
   declaring the presence of malicious code when the function location directory ( 27 ) states that the send function is slated to start executing at a non-normal location. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     These and other more detailed and specific objects and features of the present invention are more fully disclosed in the following specification, reference being had to the accompany drawings, in which: 
       FIG. 1  is an illustration of a computer network in which the present invention has applicability. 
       FIG. 2  is an illustration of a PE (Portable Executable) file format  20  for which the present invention has particular applicability. 
       FIG. 3  is an illustration of a function location directory  27  upon which the present invention operates. 
       FIG. 4  is a flow diagram illustrating a preferred embodiment of the present invention. 
       FIG. 5  is a block diagram illustrating software, firmware, and/or hardware modules  51 – 56  used in a preferred embodiment of the present invention. 
   

   DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     FIG. 1  illustrates an environment in which the present invention has applicability. A plurality of computers  1  are interconnected in a closed proprietary network  2 .  FIG. 1  illustrates n interconnected computers, where n is an arbitrary positive integer. Computer  1 ( 1 ) is also coupled via an open network such as the Internet  3  to another computer  4 . It is assumed that malicious code attacks computer  1 ( 1 ), with the ability to replicate itself and thus attack another computer  1  via network  2 , or attack computer  4  via network  3 . Such malicious code is often referred to as a “worm”. 
     FIG. 2  illustrates a communications module  20  by which the malicious code may replicate itself. As used herein, “communications module” means any discrete piece of code within computer  1 ( 1 ) that can assist computer  1 ( 1 ) to send or receive information to or from another computer  1 , 4 . For purposes of illustration only, module  20  is shown as being in the PE (Portable Executable) format, a standard format for files used in the Win32 API (Application Programming Interface). Win32 is used in 32 bit operating systems manufactured by Microsoft Corporation. 
   Module  20  may be a DLL (Dynamic Link Library) such as WSOCK32.DLL. “SOCK” stands for “socket” as in SSL (Secure Socket Layer), i.e., an Internet Protocol interface used for communications. WSOCK32.DLL is independent of any particular communications card. A DLL contains a plurality of items that are used in common by several applications. The purpose of such a DLL is to save memory space within computer  1 . One DLL may contain one or more APIs (functions) or partial APIs. A DLL can contain executable files and data files, usually in PE format. 
   The method of operation for spreading the malicious code may be that the malicious code attaches a “hook” (extraneous code) onto at least one API in the WSOCK32.DLL of the host computer  1 ( 1 ). The hook may cause the recipient computer  1 , 4  to get an extraneous message in an e-mail received from the host computer  1 ( 1 ). The user of the recipient computer  1 , 4  then clicks on the extraneous message, which causes the recipient computer&#39;s WSOCK32.DLL  20  to become infected in the same manner as the host computer  1 ( 1 ) became infected. 
   A file header  21  is present within file  20 . File header  21  contains a listing of each section within file  20  and its location within file  20 , usually expressed as an offset from the beginning of file  20 . File  20  normally contains one or more code sections  22 , 23 , one or more data sections  24 , 25 , an import directory table  26 , and an export directory table  27 . 
   Each section  22 – 27  within file  20  contains a header, which gives, among other information, the size of useful information contained within that section. This enables the identification of slack regions within the section. A slack region is a region that does not contain useful information. For example, a slack region may contain all zeroes, all ones, or a combination of zeroes and ones devoid of meaning and signifying nothing. The reason that slack regions exist is that a section normally comprises a discrete number of sectors having fixed length, e.g., 512 bytes, and only by sheer coincidence would the size of the useful information be an exact multiple of 512 bytes. 
   In the communications module  20  illustrated in  FIG. 2 , there are two code sections  22 ,  23  and two data sections  24 ,  25 . In a given communications module  20 , there can be an arbitrary number of code sections and an arbitrary number of data sections. 
   Export control directory  27  is a special case of a “function location directory”. A function location directory is a section within module  20  that lists functions (and the locations of these functions) used by module  20  in linking with other files, such as executable programs. The file to which module  20  is linked will have a matching import directory table. Similarly, import directory table  26  is used for linking with an external file, and matches to a corresponding export directory table within that file. 
     FIG. 3  illustrates the contents of a typical export directory table  27 , in this case, one having four columns. The first column contains an arbitrary function number, the second column contains the name of the function, the third column contains the number of the section where the function is located, and the fourth column contains the address within file  20  where the function is located, i.e., the entry point address for that particular function. This address is normally expressed as an offset from the beginning address of the specified file  20 . 
     FIG. 3  shows these offsets being represented in hexadecimal notation.  FIG. 3  illustrates four common functions: RECEIVE, SEND, BIND, and CONNECT. In the illustrated example, BIND and CONNECT are stated to begin within the first code section  22 ; and RECEIVE and SEND are stated to begin within the second data section  25 . Since RECEIVE and SEND are stated to begin in a section  25  other than a code section, a presumption is created that RECEIVE and SEND contain malicious code. 
     FIG. 4  illustrates a preferred embodiment of the present inventive method. The method steps illustrated in  FIG. 4  can be implemented by means of the modules illustrated in  FIG. 5 . The modules  51 – 56  illustrated in  FIG. 5  can be implemented in hardware, software, and/or firmware. These modules  51 – 56  may reside on a computer-readable medium  60  such as a hard disk, floppy disk, CD, DVD, etc. 
   The method begins at step  40  with searching module  51  searching through all or a preselected subset of the files of computer  1 , seriatim. At step  42 , searching module  51  asks whether there are any such files that are yet to be searched. If there are not any such files, the method ends at step  41 . If there are such files, i.e., searching module  51  has a current file to operate on, module  51 , at step  43 , asks whether the file being operated on contains a communications module  20 . This determination is preferably made by module  51  first determining whether there is a function location directory (such as export directory table  27 ) within the module  20 , and, if so, by looking for specific names (such as WSOCK32.DLL) of known communication modules  20  in the header of the function location directory  27 . In an alternative embodiment, searching module  51  looks for specific names (such as WSOCK32.DLL) of known communications modules  20  in the header of the file  20 . The reason that it is preferred to look in the header of the function location directory  27  rather than in the header of the file  20  is that it is more common for nefarious persons to deceitfully change the header of the file  20  than to deceitfully change the header of the directory  27 . 
   If the file being operated upon does not contain a communications module  20 , the method proceeds to step  44 , where searching module  51  searches the next file within computer  1 , and then to step  42 . 
   If the file being operated upon contains a communications module  20 , control passes to examining module  52 . At step  45 , examining module  52  examines the function location directory (e.g., export directory table  27 ) within the communications module  20 . Control then passes to locating module  53 , which, at step  46 , locates the send function that is normally present within any communications module  20 . In a Win32 API, the send function is located by name, i.e., export directory table  27  contains the word “SEND”. In other operating system environments, the send function may be identified by other means, e.g., a hexadecimal identifier. “Send function” is used in this specification (including claims) in a general sense, and is meant to encompass similar functions that are not labeled “SEND” as such, e.g., functions that may be labeled “EXPORT”, “ATTACH”, “BIND”, “MAIL”, etc. 
   Control then passes to declaring module  54 , which, at step  47 , inquires as to whether the address for the send function, as specified in directory  27 , is a non-normal address, i.e., directory  27  gives as a starting address for the function a location that is not the normal starting location for that function. As used herein, a “non-normal location” can be one of three things: 
   1) An address within a slack region of a code section  22 , 23  within the communications module  20 . 
   2) An address within a section (e.g.,  24 ,  25 ,  26 ,  27 ) of the communications module that is not a code section  22 , 23 . 
   3) An address completely outside the communications module  20 . 
   In alternative embodiments, only one or two, rather than three, of the above criteria are used in deciding whether a certain starting address is a “non-normal” location. 
   If declaring module  54  determines at step  47  that the starting address for the send function is a normal location, i.e., one not satisfying the above definition of a non-normal location, control is passed to step  44 , i.e., the communications module  20  being operated upon is deemed to not contain malicious code. If, on the other hand, declaring module  54  determines that the starting address of the send function is a non-normal location, control is passed to step  50 , or, in an embodiment where optional steps  48  and  49  are present, to optional step  48 . At step  48 , declaring module  54  inquires as to whether the address of the send function is completely outside the confines of communications module  20 . This corresponds to criterion  3  within the above definition of “non-normal location”. If the answer is no, it is known that either criterion  1  or criterion  2  of the above definition has been satisfied, and, at step  50 , module  54  makes a determination that module  20  has been attacked by malicious code. This determination may be flagged to the operator of computer  1 ( 1 ). 
   Control then passes to optional scanning module  55 , which may be an anti-malicious code scan engine. At optional step  58 , module  55  scans the code comprising the send function to confirm that malicious code is present therein. This confirmation can be achieved by any one of a number of techniques, or by a combination of techniques. For example, if a certain section of code is found by scanning module  55  to coincide with a characteristic signature of known malicious code, the declaration of malicious code made in step  50  is confirmed. If, on the other hand, evidence is found indicating or suggesting that malicious code is not after all present in the send function, the declaration of malicious code made in step  50  is deemed to be erroneous and is rescinded in step  58 . Such evidence might comprise one or both of the following items: 
   1) The send function, while starting at a non-normal location, starts with a jump instruction jumping control to a normal start location for a send function. This is evidence of repaired code, rather than malicious code. 
   2) The send function contains a large number of zeroes and/or NOPs (no operations). Again, this is evidence of repaired code, rather than malicious code. 
   Control then passes to excising module  56 , which, at optional step  59 , excises the malicious code from within the send function, if the declaration of malicious code hasn&#39;t been rescinded in step  58 . As used herein, “excise” is used in a broad sense, and encompasses any repair of the send function such that the malicious code is no longer able to harm computer  1 ( 1 ). The method then proceeds to step  44 . It should be noted that step  59  may be present even if step  58  is not present. With respect to  FIG. 5 , excising module  56  may be present even when scanning module  55  is not present. In such a case, excising module  56  is coupled to declaring module  54  directly, rather than through scanning module  55 . 
   If the answer to the question in step  48  is “yes”, i.e., criterion  3  has been satisfied, two different things may happen. In a first embodiment, declaring module  54  at step  49  reports the file containing communications module  20  as being corrupted rather than as being infected with malicious code, on the theory that it is so unusual for the starting address of the send function to be completely outside module  20  that a typical virus writer would not do this. The method then proceeds to step  44 . In a second embodiment (not illustrated), declaring module  54 , at step  49 , reports the module  20  as containing malicious code, as in step  50 . As a sub-embodiment to the second embodiment, steps  48  and  49  are not present at all, i.e., no distinction is made as to whether the “non-normal location” satisfies criterion  1 ,  2 , or  3 . 
     FIG. 5  illustrates a computer-readable medium  60  containing the inventive modules  51 – 56 . Searching module  51  is coupled to examining module  52 , which is coupled to locating module  53 . which is coupled to declaring module  54 , which is coupled to optional scanning module  55 , which is coupled to optional excising module  56 . 
   The above description is included to illustrate the operation of the preferred embodiments and is not meant to limit the scope of the invention. The scope of the invention is to be limited only by the following claims. From the above discussion, many variations will be apparent to one skilled in the art that would yet be encompassed by the spirit and scope of the present invention. For example, instead of basing the declaration of malicious code upon the condition that the starting address of a send function is a non-normal location, the basis for declaring malicious code could be that another function, e.g., a receive function, a bind function, or a connect function, is stated to have, within function location directory  27 , a starting address that is non-normal.