Abstract:
A method and system for indicating an executable as Trojan Horse, based on the CRC values of the routines of an executable. The method comprising a preliminary stage in which the CRC values of the routines of known Trojan Horses are gathered in a database, and a stage in which indicating an executable as Trojan Horse is carried out by the correspondence of the CRC values of the routines of said executable to the CRC values of the known Trojan Horses, as gathered in said database. The system comprising means for calculating the CRC values of routines; means for identifying the borders of the routines of an executable; a database system, for storing the CRC values of routines of known Trojan Horses; and means for determining the correspondence between two groups of CRC values, thereby enabling detection of the correspondence of an executable to at least one known Trojan Horse.

Description:
FIELD OF THE INVENTION  
       [0001]     The present invention relates to the field of malicious code detection. More particularly, the invention relates to a method and system for indicating an executable as Trojan Horse.  
       BACKGROUND OF THE INVENTION  
       [0002]     The detection of viruses and other forms of malicious objects in a file can be carried out in two major ways; virus signature and code analysis, but actually there are many additional methods known in the art for this purpose.  
         [0003]     A “Virus signature” is a unique bit pattern that a virus leaves on the infected code. Like a fingerprint, it can be used for detecting and identifying specific viruses. The major drawback of the “signature analysis” is that a virus should firstly be detected and isolated (e.g. by comparing the infected code with the original code) and only then can the signature characteristics be distributed by the anti-virus company among its users.  
         [0004]     In order to overcome the signature analysis, the virus “author” may masquerade the signature by adding non-effective machine language commands between the effective commands, thereby creating an unknown signature. Moreover, the added commands can be selected randomly. This way the virus can strike before being detected and consequently cause a great deal of damage.  
         [0005]     Another way of detecting malicious code within an executable is by analyzing its operation. Since the malicious code is usually added at the end of the executable and the executable is changed such that the fist command to be executed will be the added code, indicating such an operation pattern can be an indicator for malicious code. The major drawback of code analysis methods is that it is not a simple procedure and therefore a great deal of effort must be invested in order to achieve meaningful results.  
         [0006]     A malicious executable which is not a result of an infection is actually a “legitimate” executable and therefore is very difficult to be classified as malicious. Such an executable is referred in the art as “Trojan Horse”.  
         [0007]     The term Trojan or Trojan Horse refers herein to a program in which malicious code is contained inside apparently harmless programming or data, in order to cause damage to the computer, such as ruining the file allocation table. The Trojan can either be a compiled code or a non-compiled code, e.g. a script.  
         [0008]     Due to their nature, Trojan Horses are difficult to detect before striking. Moreover, since the malicious code of Trojans is embedded in a program during the design time, the form of the malicious code does not differ from the rest of the program. Contrary to Trojan Horses, viruses “infect” other programs, and therefore the structure of the added code has some characteristics that distinguish them from the rest of the program.  
         [0009]     It is therefore an object of the present invention to provide a method and system for indicating an executable as Trojan Horses, whether the executable is a compiled code or non-compiled code.  
         [0010]     Other objects and advantages of the invention will become apparent as the description proceeds.  
       SUMMARY OF THE INVENTION  
       [0011]     A method and system for indicating an executable as Trojan Horse, based on the CRC values of the routines of an executable. The method comprising a preliminary stage in which the CRC values of the routines of known Trojan Horses are gathered in a database, and a stage in which indicating an executable as Trojan Horse is carried out by the correspondence of the CRC values of the routines of said executable to the CRC values of the known Trojan Horses, as gathered in said database. The system comprising means for calculating the CRC values of routines; means for identifying the borders of the routines of an executable; a database system, for storing the CRC values of routines of known Trojan Horses; and means for determining the correspondence between two groups of CRC values, thereby enabling detection of the correspondence of an executable to at least one known Trojan Horse. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0012]     The present invention may be better understood in conjunction with the following figures:  
         [0013]      FIG. 1  schematically illustrates a typical structure of a compiled executable.  
         [0014]      FIG. 2  is a high-level flowchart of a method for calculating the CRC values of the routines of an executable.  
         [0015]      FIGS. 3   a  and  3   b  are a high-level flowchart of a method for detecting the presence of malicious code within an executable, according to a preferred embodiment of the invention.  FIG. 3   a  describes the preliminary stage of the method, in which a database of CRC values is constructed.  FIG. 3   b  describes the detection of a Trojan Horse.  
         [0016]      FIG. 4  schematically illustrates a system for indicating an executable as Trojan Horse, according to a preferred embodiment of the invention. 
     
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS  
       [0017]     CRC, the acronym of Cyclic Redundancy Checking, is a method of testing data integrity. The mathematical model is made up of polynomials with binary coefficients. Typically it is used to test the integrity of data transferred through a communication channel. In a typical scheme, the CRC is computed to each data block transferred from a source to a destination, and the CRC bytes (i.e. the result of the CRC) are transferred with the corresponding data block. At the destination, the CRC is computed again from the received data block, and if the result corresponds to the received CRC bytes, then the data is considered to be transferred correctly.  
         [0018]     There are a variety of standards for computing and handling CRC. The ITU-TS (CCITT) has a standard for a 16-bit polynomial. IBM&#39;s Synchronous Data Link Control and other protocols use CRC-16, another 16-bit polynomial. A 16-bit cyclic redundancy code detects especially typical communication errors, like single and double-bit errors. It actually ensures detection of 99.998% of all possible errors. This level of detection assurance is considered sufficient for data transmission blocks of 4 kilobytes or less. For larger transmissions, a 32-bit CRC is used. The Ethernet and token ring local area network protocols both used a 32-bit CRC. In Europe, CRC-4 is a multi-frame system of cyclic redundancy checking that is required for switches on E-1 lines.  
         [0019]     A less complicated but less capable error detection method is he checksum method, which is commonly used by modem error-correcting protocols.  
         [0020]     CRC methods are also used for virus detection. A common use of CRC is for detecting the infection of the boot sector of a computer. The Boot sector is one of the first codes to be executed when a computer boots. As a part of the boot procedure, a program which is stored in EPROM (i.e. non-volatile RAM) loads the boot sector into the memory, and executes it. At this stage, no antivirus facilities are yet executed, and therefore at this point the computer is extremely vulnerable.  
         [0021]     The term “source code” refers in the art to a human-readable programming text. In order to be executed, a special program called “compiler” converts the source code to an “object code”, which can be executed by the computer.  
         [0022]     On the one hand, the object code has an advantage over the source code since it is almost impossible to further develop a program from the object code. On the other hand, the compilation stage requires time and consequently the development process becomes more expensive and less convenient to the programmer.  
         [0023]     In order to spare the compilation time, another form of program has been developed, the “interpreter”. An interpreter is a program executed from its source code, i.e. without compilation. The script languages VBScript, JavaScript and others, are examples for interpreted code.  
         [0024]     The term “executable” refers herein to the form of the program which is ready to be executed, whether compiled or non-compiled code. Computing the CRC of routines in an object code In computer art, the term routine (or subroutine or procedure) refers to a sequence of code that is intended to be called and used repeatedly during the executable of a program.  
         [0025]     For example, a routine of a compiled code of Microsoft C starts with three hexadecimal bytes “55 8B EC”, which are the binary code of the Assembler instructions “Push ebp; Mov ebp, esp”. A routine ends with a Ret instruction, where its hexadecimal value is C3, CB, C2, or CA. Thus, according to one embodiment of the present invention, the code of the executable file is scanned in order to find the bytes “55 8B EC” followed by the bytes “C3” (or “CB”, or “C2”, or “CA”). After detecting the “borders” of a routine, its CRC value is calculated, and used for detecting maliciousness, as will be explained herein.  
         [0026]      FIG. 1  schematically illustrates a typical structure of a compiled executable. The figures illustrates three routines, each of which starts with a “Push ebp; Mov ebp, esp” instructions (marked as  101 ,  102 , and  103 ), and ends with a “Ret” assembler instruction (marked as  201 ,  202 , and  203 ). The example is in Assembler. It should be noted that a routine may comprise multiple “Ret” instructions, however the last “Ret” instruction which appears just before the next “Push ebp; Mov ebp, esp” occurrence terminates a routine (marked as  201 ,  202  and  203 ). The other “Ret” instruction,  301 ,  302  and  303 , refers to “Ret” instructions within a routine.  
         [0027]     It should be noted that since instructions that refer to absolute addresses or to addresses outside the routine (e.g. “CALL &lt;Address&gt;”, “JMP FAR &lt;Address&gt;”) comprise an address in the memory, which may be different on each execution of the program, certainly for different Trojans. Therefore, when calculating the CRC value of a routine, this point should be taken into consideration, e.g. by replacing the bytes of an absolute address by zeros, before calculating the CRC value.  
         [0028]     Typically, a “hacker” that specializes in Trojan Horses uses the same group of routines for embedding the maliciousness into a plurality of programs. These routines are referred herein as “core routines”. Of course, in addition to the core routines, the programmer may also use other routines. Indicating the core routines by code analysis The core routines actually characterize a “family” of Trojans. Thus, according to one embodiment of the invention, an anti-virus company detects at its laboratory the core routines of an executable that was indicated as malicious, and calculates the CRC of its routines. The detection can be carried out by analyzing the code, debugging, tracing the execution, etc.  
         [0029]     According to a preferred embodiment of the present invention, indicating if an executable is a Trojan is carried out by calculating the CRC values of its routines, and checking how many CRC values correspond to the CRC values of known core routines of a Trojan Horse family. If, for example, more than a certain percentage of the CRC values of an executable correspond to the CRC values of a certain Trojan family, then the executable may be indicated as malicious.  
         [0000]     Indicating the Core Routine by Statistical Analysis  
         [0030]     According to another preferred embodiment of the invention, the records of a database that comprise CRC values of the routines of a plurality of executables are divided to two groups: the CRC values of executables that were indicated as malicious (the “malicious group”), and the CRC values of executables that were indicated as harmless (the “harmless group”). Then the CRC values that appear in both the malicious group and the harmless group, are eliminated from the malicious group. This way there is a high certainty that the CRC values that remain in the malicious group belong to the core routines.  
         [0031]      FIG. 2  is a high-level flowchart of a method for calculating the CRC values of the routines of an executable. Actually, the executable is a string. It is scanned from its beginning to its end. At  FIG. 2  the sequence “55 8B EC” (presented as hexadecimal bytes) determines in the object code of the C language the start of a routine, and the string “C3” (or “CB”, or “C2”, or “CA”) determines the end of a routine.  
         [0032]     At step  10 , the next occurrence of the string “55 8B EC” is searched. From step  11 , if an occurrence of the string “55 8B EC” is found, the flow continues with step  12 , otherwise the flow continues with step  15 , where the process comes to its end. At step  12 , the next occurrence of the string “55 8B EC” is searched, and whether found or not, at step  13  the previous occurrence of “C3” (or “CB”, or “C2”, or “CA”) is searched. If “55 8B EC” is not found, then “C3” (or “CB”, or “C2”, or “CA”) is searched from the end of the file. The routine is the string between “55 8B EC” and “C3” (or “CB”, or “C2”, or “CA”). After determining what the string of the routine is, the CRC is calculated (step  14 ) and the flow continues with step  10 .  
         [0033]      FIGS. 3   a  and  3   b  is a high-level flowchart of a method for detecting the presence of malicious code within an executable, according to a preferred embodiment of the invention.  
         [0034]      FIG. 3   a  describes the preliminary stage of the method, in which a database of CRC values is built. Each record of the database corresponds to a routine of a Trojan Horse, thus each record comprises a CRC value and its corresponding executable identification (e.g. the name of the executable and its version). In addition to the CRC value, the routine may comprise additional content such as a flag that determines if it is malicious or not, the programming language of its source code, and so forth.  
         [0035]     At step  20 , the borders of a routine within an executable are detected (e.g. as described by  FIG. 2 ), and the routine&#39;s CRC is calculated. At the next step  21 , a record which comprises the CRC, the identification of the executable, is added to the database. From step  22 , if more routines are detected, then the flow continues with step  20 . This process may continue with additional files.  
         [0036]      FIG. 3   b  describes the detection stage of the method. At step  30 , the next routine of the executable is detected, and its CRC is calculated (e.g. in the same manner as described in  FIG. 2 ). Of course, the first time step  30  is carried out, the first routine of the executable is handled. At the next step  31 , the calculated CRC value is searched within the database. From step  32 , if no corresponding CRC value has been found, then the flow continues with step  34 , otherwise with step  33 . At step  33 , a counter which counts the routines that their corresponding value has been detected is increased by one (of course the value of the counter should be reset when before scanning the executable). From step  33 , if more routines are available in the executable, then flow continues with step  30 , otherwise with step  35 . From step  35 , if the value of the counter exceeds beyond a predetermined threshold, than the executable is counted as suspected of comprising a Trojan Horse, otherwise the executable is considered as trusted.  
         [0037]     The threshold doesn&#39;t necessarily have to be an absolute value, but also a percentage of the total number of the routines found in the executable, an expression that uses different weight for certain CRC values, and so forth. Those skilled in the art will appreciate that the threshold is only an example of statistical analysis and the invention can be implemented by a variety of statistical analyses and/or heuristic methods known in the art.  
         [0038]     Those skilled in the art will appreciate that the invention may be implemented by software and/or hardware means. Searching patterns within a string or a file and other operations involved are basically software oriented operations. However, when scanning a huge quantity of files, e.g. at the gateway of an Internet Service Provider, some of the operations may be implemented by hardware means in order to be carried out faster.  
         [0039]      FIG. 4  schematically illustrates a system for indicating an executable as Trojan Horse, according to a preferred embodiment of the invention. The computers  504  are connected to a local network area  505 , which is connected to the Internet  501 . At the gateway between the local area network  505  and the Internet, two facilities are deployed: the firewall  502  and the filtering facility  503 , thus any data received of transferred from/to the local area network  505  can be tested for detecting malicious data. The filtering facility which tests the data is a server (e.g. a dedicated computer) which implements the method for indicating an executable as Trojan Horse, as described herein, along with other methods for detecting maliciousness. The data traffic, especially email and Web pages, is inspected, and whenever an executable is received to the local area network  505  or sent therefrom, it is scanned in the manner described herein, in order to indicate if it is a Trojan Horse.  
         [0040]     Alternatively or additionally, the invention may be implemented at the user&#39;s machine, by analyzing input and/or output traffic (including mail and mail attachments) between the user&#39;s machine and an external network. The invention may also be implemented by scanning the files within the user&#39;s machine, in the manner used in the art for this purpose.  
         [0041]     As explained herein, according to the present invention, detecting the presence of malicious code within an executable is based on calculating the CRC values of its routines. This is different from other methods used in the art that also implement CRC for detecting maliciousness, since: (a) according to the present invention indicating the maliciousness of an executable is carried out by statistical analysis of the CRC values of the routines, while other CRC-based methods only indicate if the code was corrupted; and (b) the present invention makes use of the CRC values of the routines of an executable, contrary to other CRC-based methods used in the art that test the boot sector of a computer, a portion of an executable, and other, but not the routines of an executable.  
         [0042]     It should be noted that in addition to statistical analysis, indicating an executable as Trojan Horse may also be carried out by heuristic analysis.  
         [0043]     It should be noted that the present invention can be implemented for both compiled and non-compiled executables, since the compiled executable is a reflection of the non-compiled executable, and therefore the routines of the non-compiled executable are reflected in its compiled executable.  
         [0044]     Those skilled in the art will appreciate that the invention can be embodied by other forms and ways, without losing the scope of the invention. The embodiments described herein should be considered as illustrative and not restrictive.