Abstract:
A system and a method for determining at least one software signature, comprising: performing process associated with obtaining a software program in a form of a sequence of instructions (SOI) of the software program; and performing processing associated with generating a signature for the software program where the signature comprises a ratio of a set of SOI counts over total SOI counts of the software program.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit of U.S. Provisional Application No. 61/483,238, filed May 6, 2011, entitled “Malware Static Analysis Techniques Using a Multidisciplinary Approach,” which is hereby incorporated by reference in its entirety. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
       [0002]      FIG. 1  is a system diagram, as per an aspect of an embodiment of the present invention. 
         [0003]      FIG. 2  is a flow diagram of a software collection module, as per an aspect of an embodiment of the present invention. 
         [0004]      FIG. 3  is a flow diagram of an instruction extraction module, as per an aspect of an embodiment of the present invention. 
         [0005]      FIG. 4  shows a two-mode weighted matrix where one set of actors are configured to be n-grams and the other set of actors are virus programs, as per an aspect of an embodiment of the present invention. 
         [0006]      FIG. 5  is a flow diagram of a signature establishment module, as per an aspect of an embodiment of the present invention. 
         [0007]      FIG. 6  expresses a method of converting a two-mode matrix into a one-mode matrix, as per an aspect of an embodiment of the present invention. 
         [0008]      FIG. 7  shows a result of applying the conversion method to a weighted two mode matrix, as per an aspect of an embodiment of the present invention. 
         [0009]      FIG. 8  is a flow diagram of clustering software programs into software families, as per an aspect of an embodiment of the present invention. 
         [0010]      FIG. 9  illustrates an image matrix of software program families, as per an aspect of an embodiment of the present invention. 
         [0011]      FIG. 10  shows a version of result display of a visualization module, as, per an aspect of an embodiment of the present invention. 
         [0012]      FIG. 11  is a flow diagram of generating an image matrix of multiple sequences of instructions for a software family, as per an aspect of an embodiment of the present invention. 
         [0013]      FIG. 12  shows a matrix with two sets of actors where the actors are virus programs and respective n-gram counts of the programs in a virus program family, as per an aspect of an embodiment of the present invention. 
         [0014]      FIG. 13  shows a result of applying the conversion method to a weighted two mode matrix, as per an aspect of an embodiment of the present invention. 
         [0015]      FIG. 14  illustrates an image matrix of sequence of instructions (SOI) clusters, as per an aspect of an embodiment of the present invention. 
         [0016]      FIG. 15  illustrates a manner of visualizing an image matrix of clusters of SOIs, as per an aspect of an embodiment of the present invention. 
         [0017]      FIG. 16  is a flow diagram of a classification module, as per an aspect of an embodiment of the present invention. 
         [0018]      FIG. 17  illustrates various ways of calculating a ratio of n-grams of a software program family, as per an aspect of an embodiment of the present invention. 
         [0019]      FIG. 18  illustrates an Euclidean distance formula and a correlation coefficient formula, as per an aspect of an embodiment of the present invention. 
         [0020]      FIG. 19  illustrates an example of calculating a similarity ratio for a new piece of software versus a number of viruses, as per an aspect of an embodiment of the present invention. 
     
    
     DETAILED DESCRIPTION OF EMBODIMENTS 
       [0021]    Embodiments of the present invention may cluster software programs into software families, generate a signature for each software family, or identify unknown software as part of a software family, or any combination thereof. 
         [0022]      FIG. 1  is a system diagram of some embodiments of the present invention in a network environment configuration. A system  100  may comprise: a software analysis application  101 , a client  110 , a server  120 , a software collection module  130 , an instruction extraction module  140 , a signature establishment module  150 , a signature repository  160 , a classification module  170 , a visualization module  180 , a network  190  or any combination thereof. In some embodiments, the client  110  may request to classify a software program. The server  120  may receive the request and manage the software analysis application  101  to classify the software program to a software family. The classification information may be returned to the client  110 . In some embodiments, information may be communicated between the software analysis application  101 , the client  110  and the server  120  directly and/or via a network  190  or through an internet. In some embodiments, the software collection module  130  may filter out multiple software programs based on certain configurations. The instruction extraction module  140  may extract op-codes, a portion of machine language instructions that specifies a programmed operation to be performed, from the software program. The signature establishment module  150  may cluster the multiple software programs into software families and generate a signature for each software family. The signature repository  160  may store the generated signatures. The classification module  170  may receive a software program, obtain a signature for the software program, and classify the software program to a respective software family. The visualization module  180  may display useful information to study the structure of a software program. 
         [0023]    The software analysis application  101  may be any combination of the modules  110 ,  120 ,  130 ,  140 ,  150 ,  160 ,  170 ,  180  and  190 . In some embodiments, the software analysis application  101  may comprise: the instruction extraction module  140  and the signature establishment module  150 . In other embodiments, the software analysis application  101  may comprise: the instruction extraction module  140 , the signature establishment module  150  and the classification module  170 . In other embodiments, the software analysis application  101  may comprise: the signature repository  160  and the signature visualization module  180 . 
         [0024]    Communication between modules can vary based on composition of the modules in the software analysis application  101 . For example, in some embodiments, a software collection module  130  may collect software programs and filter out the programs based on certain configurations. The filtered output can be forwarded to an instruction extraction module  140  to retrieve sequences of instructions (SOIs) (e.g., sequences of assembly instructions grouped in a certain manner) of the programs. The SOIs and the programs may be fed into a signature establishment module  150  to group the programs into program families and to generate signatures for the families. The generated signatures can be stored into a signature repository  160 . In other embodiments, a client  110  may submit a software program to a server  120  via an internet in order to analyze the software program. The server  120  may forward the program to an instruction extraction module  140  to retrieve SOIs of the program. The extracted SOIs can be forwarded to a signature establishment  150  to generate a signature of the program. The generated signature may be stored in signature repository  160 . Also, the generated signature can be forwarded to a classification module  170  to classify a software program family for the forwarded program. The client  110  also can visualize analysis of the software program and/or the software program families using a visualization module  180 . In some embodiments, the instruction extraction module  140  may receive a software program from a client  110 , a server  120 , or the collection module  130 . The signature establishment module  150  may receive extracted op-codes from the instruction extraction module  140 . The classification module  170  may receive a testing software program from the client  110  or a request from the server  120 . The classification module  170  may look into a signature repository  160  to find a signature for the testing software program or may send the software program to the signature establishment module  150  to generate the signature. The visualization module  180  may retrieve a software program from the signature repository  160  and/or send a software program to the signature establishment module  150  and/or to the classification module  170  to generate data necessary for visualizing information of the software. 
         [0025]      FIG. 2  is a flow diagram for the software collection module  130 . The software collection module  130  may be configured with various settings to filter out software programs with certain criteria. In  210 , the software collection module  130  may receive software programs. In  220 , the software collection module  130  may feed the received software programs into a filtering tool or tools such as PEiD Jibz which filters out software programs based on user configurations. For example, in  230 , the tool may filter out operating system (“OS”) non-compatible programs. As another example, in  240 , the tool may filter out software programs which are either compressed or encrypted. The tool can be configured to have any combination of filters, including filters not described herein. In some embodiments, for example, the tool is configured to filter out all of non-Windows XP executables, compressed executables and encrypted executables where, in other embodiments, the tool may filter out only compressed executables. The software collection module  130  may return the filtered executables by the tool. 
         [0026]      FIG. 3  is a flow diagram for the instruction extraction module  140 . A software program is composed of byte sequences of binary codes. In  310  the instruction extraction module  140  may extract an SOI, which may make up the binary codes. For example, when the instruction extraction module  140  receives a software program as an executable, the instruction extraction module  140  can read the binary assembly instructions of the program without executing the program. The binary assembly instructions may be grouped into a large segment of the instructions. A gram is defined as a sequence of a certain number of bytes of the binary assembly instructions. In some embodiments, the number of the bytes for the sequence is four but it can be any number. As explained above, a SOI can be a sequence of assembly instructions grouped in a certain manner For example, in some embodiments, SOI can be defined as a group of two sequential grams (“bi-grams”). In other embodiments; the instruction extraction module  140  may combine each four byte sequence into one gram and treat a sequence of n number of grams (“n-grams”) as a SOI. In other embodiments, the instruction extraction module  140  may treat assembly instructions of an application programming interface (“API”) as a SOI. 
         [0027]    In  320  the software program may be parsed into basic blocks. A basic block may be a segment of code that has one entry point (e.g., no code within the segment is the destination of a jump instruction), one exit point and no jump instructions contained within it (e.g., a sequence of instructions which are all executed if the first one in the sequence is executed). 
         [0028]    In  330 , n-grams may be retrieved from the basic blocks. For example, if a basic block is composed of nine grams as “AABCDASHD”; assuming that each letter represents an instruction with no jump instructions contained, the instruction extraction module  140  can retrieve 8 bi-grams (“AA”, “AB”, “BC”, “CD”, “DA”, “AS”, “SH” and “HD”), 7 tri-grams (“AAB”, “ABC”, “BCD”, “CDA”, “DAS”, “ASH” and “SHD”), or  6  quad-grams (“AABC”, “ABCD”, “BCDA”, “CDAS”, “DASH” and “ASHD”) from the basic block. 
         [0029]    In  340 , based on retrieved SOIs from a software program, the instruction extraction module  140  may count distinct SOIs retrieved from the program. The output of the collection may, be represented as a vector in n-dimensional space with n being the number of the distinct instruction sequences. 
         [0030]    In  350 , the instruction extraction module  140  may combine the vectors of the software programs and create a two-mode weighted matrix of two set of actors: SOIs and software programs. A one-mode Matrix is composed of one set of actors whereas a two-mode matrix is composed of two sets of actors. In a two-mode matrix, the matrix representation is AB n×m  where n is the number of first actors (“A”), m is the number of second actors (“B”) and the matrix is composed of n numbers in a row and m numbers in a column. 
         [0031]    For example,  FIG. 4  shows a two-mode weighted matrix in some embodiments where the first actors are n-grams and the second actors are virus programs. In the embodiment in  FIG. 4 , the instruction extraction module  140  extracted six distinct n-grams from seven virus programs. The numbers in the matrix represent a total count of n-grams in the virus programs. For example, the number 32 in the second row matrix in  FIG. 4  may also suggest that the virus # 1  comprises: 10 n-grams# 1 , 30 n-grams# 2 , 20 n-grams# 3 , 2 n-gram# 4 , 5 n-grams # 5  and 9 n-grams # 6 . 
         [0032]      FIG. 5  is a flow diagram for the signature establishment module  150 . In  510 , the signature establishment module  150  may convert a two-mode matrix into a one-mode matrix which has one set of actors, software programs. In  520 , the signature establishment module  150  may cluster the software programs into software families. In  530 , the signature establishment module  150  may generate a signature for software families. Details on  510 ,  520  and  530  are discussed below. 
         [0033]    In  510 , the signature establishment module  150  may convert the two-mode matrix into the one-mode matrix of software programs.  FIG. 6  expresses a method of converting a two-mode matrix into a one-mode matrix. A weighted two-mode matrix of A, a first set of actors, and B, a second set of actors, may be converted to a one-mode weighted matrix as shown in  610 . In some embodiments, using the conversion illustrated in  610 , a weighted two-mode matrix of AB n×m  can be converted into a weighted one-mode matrix of AA n×m  by finding A n×m  where aa ij , a matrix element in the ith row and the jth column (i≠j), can be calculated using the formula in  610 . Note that aa ij =aa ji : ab ik  is a matrix element of the matrix AB n×m  in the ith row and the kth column and ab jk  is a matrix element of the matrix AB n×m  in the jth row and the kth column. Similarly a weighted two-mode matrix of AB n×m  can be converted into a matrix of BB m×m  where bb ij  bb ji  and a value of bb ij  equals the value calculated using the formula in  620 . Note that ab ki  is a matrix element of the matrix AB n×m  in the kth row and the ith column and ab kj  is a matrix element of the matrix AB n×m  in the kth row and the jth column. 
         [0034]    For example,  FIG. 7  shows a result of applying the conversion to the weighted two mode matrix in  FIG. 4  in some embodiments. The output of the conversion is one mode matrix. The set of actors in  FIG. 7  is a set of virus programs: Virus# 1 , Virus# 2 , Virus# 3 , Virus# 4 , Virus# 5 , Virus# 6  and Virus# 7 . The matrix elements may represent the strength of the ties between actors relative to SOIs extracted from the actors. For example, in the embodiments in  FIG. 7 , the strength of the tie between Virus # 7  and Virus # 3  (398.2384) is greater than the strength of the tie between Virus # 7  and Virus # 1  (30.7653). The difference may suggest that the Virus # 7  has a composition of n-grams that is closer to Virus # 3  than Virus # 1 . 
         [0035]    In  520 , the signature establishment module  150  may cluster the software programs into software families.  FIG. 8  is a flow diagram illustrating details of clustering software programs into the software families. In  810 , the signature establishment module  150  may cluster the software programs into software families through a use of structural equivalence. Structural equivalence may be measured as Euclidean distance or as a correlation coefficient. Other measurement methods may also be used. The signature establishment module  150  may pair software programs and measure the structural equivalence of the pair. The signature establishment module  150  may create a matrix of the structural equivalence by measuring the structural equivalences for all possible pairs of the software programs and combine the structural equivalences as a matrix. The matrix of structural equivalence may show the relative structural similarities of each pair of actors. For example, in some embodiments using Euclidean distance as the measure of structural equivalence, the Euclidean distance formula  1810  in  FIG. 18  can be used to calculate the structural equivalence, where d ij  represents the Euclidean distance between actors i and j; a is the number of actors in the relational matrix; and x ij  is the element in the relational matrix. In other embodiments using a correlation coefficient as the measure of structural equivalence, the correlation coefficient formula  1820  can be used, where c ij  is the correlation coefficient of actors i and j; M i*  is the mean of the values in row i; M *i  is the mean of the values in column i; and x ij  is the element in the relational matrix. 
         [0036]    In  820 , the structural equivalence may be fed into a hierarchical clustering algorithm that may create clusters of software programs based on the structural equivalence matrix. The hierarchical clustering algorithm is a method of cluster analysis which seeks to build a hierarchy of clusters. The software programs may be clustered into distinct clusters, families of the software programs. 
         [0037]    In  830 , the signature establishment module  150  may filter out software programs in a particular software family. For the filtration, the signature establishment module  150  may calculate an average ratio of the software family as a set of SOI counts over total SOI counts within the family. For example, if a software family is comprised of 50 SOIs of type A, 100 SOIs of type B and 350 SOIs of type C, the average ratio of the family can be represented as a vector of [type A SOI, type B SOI, type C SOI]=[50/(50+100+350), 100/(50+100+350), 350/(50+100+350)]=[0.1, 0.2, 0.7]. Also, similar to the way the ratio of the family is calculated, the signature establishment module  150  may calculate a ratio of each software program in the software family as a set of SOI counts of the program over total SOI counts within the software program. The signature establishment module  150  may remove software programs from the software family if the structural equivalence value between the average ratio of the family and the ratio of the software program does not exceed a certain threshold value. The threshold value may be any decimal number between 0 and 1 if the measure of the structural equivalence uses the correlation coefficient. In some embodiments where correlation efficient is the measure of the structural equivalence, the threshold value of 0.95 may be used as the criterion, but the value can be any other number. The signature establishment module  150  may repeat the filtration until structural equivalence values between the family and all the remaining software programs exceed the threshold value. For example, let&#39;s assume that a software family # 1  is initially formed with four distinct software programs (A, B, C and D) after the hierarchy clustering algorithm is applied. The average ratio of the family and individual programs can be calculated based on the formula  1820  in  FIG. 18 . The signature establishment module  150  may calculate the correlation efficient between the family and each program using the calculated average ratios. If the calculated structural equivalences are 0.98 (A), 0.97 (B), 0.85 (C) and 0.95 (D) and the filtering criterion is 0.95, the filtration process may apply to the program C which may result in eliminating the program C from the family. The average ratio of the family is re-calculated with A, B and D because any elimination may cause the change of underlying SOI counts of the family. This filtration process may be reiterated until all the programs in the family can have the correlation efficient value greater than 0.95. 
         [0038]    In  530 , the signature establishment module  150  may generate the signature for software families. In some embodiments, the signature establishment module  150  may establish the average ratio of the software family as one of possible signatures for the software family. 
         [0039]      FIG. 9  illustrates an image matrix of software program families. In  840 , the signature establishment module  150  may create an image matrix which may show relational ties between software families. Given that the structural equivalence matrix of the software families are already calculated, to determine the relational ties between the families, one may use a specific criterion for deciding if there is a tie (e.g., represented as one) or a zero (e.g. if there is no tie). Any criterion can be used for the decision. Some exemplary criteria are listed as follows: 
         [0040]    Perfect fit: This criterion is used for dichotomous relations. For a perfect fit a block must either be all 0&#39;s or all 1&#39;s. Hence the relational tie in the image matrix is a 1 only if the block is all 1&#39;s and 0 if it is all 0&#39;s. 
         [0041]    Zeroblock: This criterion is used for dichotomous relations. The relational tie in the image matrix is a 0 if the entire block is filled with 0&#39;s otherwise it is a 1. 
         [0042]    Oneblock: This is a criterion used for dichotomous relations. It is the opposite of a zeroblock in that the relational tie in the image matrix is a 1 if the entire block is filled with 1&#39;s otherwise it is 0. 
         [0043]    α Density criterion: This is a criterion used for dichotomous relations. The previous criteria rely on the blocks being either fully 1&#39;s or 0&#39;s and real world data is rarely in that form. Therefore a density threshold is defined so that if the density of the block is smaller than the threshold its corresponding relational tie in the image matrix is a 0 else it is a 1. This threshold is usually the calculated density of the whole relation. 
         [0044]    Maximum value: This is a criterion used for multi-valued relations, where blocks that contain only small values in them are considered zeroblocks, and blocks that contain any large values are considered oneblocks. This is similar to the zeroblock criterion, but for multi-valued relations. 
         [0045]    Mean value: This also is a criterion used for multi-valued relations, where the mean value of the entire relation is calculated. Then the mean of each block is calculated and if it is greater than the relation&#39;s mean then it is a oneblock, otherwise it is a zeroblock. It is similar to the density criterion except that instead of using a density value it uses the mean value. 
         [0046]    As an example of showing an image matrix as a result of applying the maximum value criterion,  FIG. 9  illustrates the output matrix of software families after the criterion is applied. In the embodiment in  FIG. 9 , the image matrix may suggest that software programs are clustered into four families (P 1 , P 2 , P 3  and P 4 ) and the relational ties between the families are either one, if the relational tie value is greater than the maximum value, or zero. For example,  FIG. 9  may show that the relational tie from the family P 2  to the family P 3  (0.6) is strong compared to the tie from P 2  to P 1  (0). 
         [0047]      FIG. 10  shows one version of a result display of the visualization module  180  in some embodiments where the image matrix in  FIG. 9  is fed into the visualization module  180 . In  FIG. 9  the image matrix shows that the relational tie value from P 1  to P 1  is “one”. An arrow may represent a tie between families. For simplicity sake, a number of 0.5 and greater may be rounded up to 1 and signify a tie, while a number less then 0.5 may be rounded down to signify no tie. Note that ties and/or the strength of the ties may be represented in many other manners. Referring to  FIG. 10 , the visualization module  180  may visualize the relational ties of  FIG. 9 . For example, an arrow  1010  may be displayed originating from P 1  and forwarding back to P 1  because the value in  FIG. 9  is 1 for P 1  and P 1  (note that this is also true for the relational tie of P 2  to P 2 , P 3  to P 3  and P 4  to P 4 ). Another arrow  1020  between P 2  and P 3  and  1030  between P 3  and P 4  in  FIG. 10  may visualize the relational tie between these families as a tie greater than or equal to 0.5. The visualization module  180  may provide information to a software analyst as a software analyst may see and may further analyze relationships between software that were not apparent. Also from the image matrix one may create an equivalent graph and visualize the analysis of the software families in this manner. 
         [0048]      FIG. 11  is a flow diagram of generating an image matrix of one mode matrix where the actors are SOI clusters of the software family. Generating the image matrix of SOI clusters is similar to generating the image matrix of software programs. One difference can be that the actors in  FIG. 8  are software programs whereas the actors in  FIG. 11  are SOI clusters. 
         [0049]    In  1110 , the signature establishment module  150  may count all the SOIs of software programs within a particular software family. In  1120 , the signature establishment module  150  may create a two mode matrix of SOIs and software programs. For example,  FIG. 12  shows a matrix with two sets of actors in some embodiments where the two sets of actors are virus programs and respective n-gram counts of the programs in a virus program family. In the embodiment in  FIG. 12 , the instruction extraction module  140  extracted six distinct n-grams from seven virus programs. The numbers in the matrix represent a total count of n-grams in virus programs. For example, the number 32 in the third row and second column means the total count of the n-grams# 3  in the virus program # 2 . The matrix in  FIG. 12  may also suggest that the virus # 1  comprises: 10 n-grams# 1 , 30 n-grams# 2 , 20 n-grams# 3 , 2 n-gram# 4 , 5 n-grams # 5  and 9 n-grams # 6 . 
         [0050]    In  1130 , the two mode matrix of the SOIs and the software programs may be converted into the one mode matrix of SOIs.  FIG. 13  shows a result of applying the conversion method to the two mode matrix in  FIG. 12 . The set of actors in  FIG. 13  is a set of six distinct n-grams extracted from one software family: n-gram # 1 , n-gram # 2 , n-gram # 3 , n-gram # 4 , n-gram # 5  and n-gram # 6 . The matrix elements may represent the strength of ties between the set of n-grams relative to the software family from which it was extracted. For example, the matrix in  FIG. 13  may suggest that the strength of the tic between n-gram # 6  and n-gram # 1  (39.2982) is less than the strength of tie between n-gram # 6  and n-gram # 5  (68,9833). 
         [0051]    In  1140 , the signature establishment module  150  may pair two SOIs and calculate structural similarity of the pair for all the possible pairs in the software family to create a structural similarity matrix. Structural equivalence may be measured as Euclidean distance or as a correlation coefficient. Other measurement methods may also be used. The matrix of structural equivalence may show the relative structural similarities of each pair of actors. For example, in some embodiments using Euclidean distance as the measure of structural equivalence, the Euclidean distance formula  1810  in  FIG. 18  can be used to calculate the structural equivalence. (Note that details on  FIG. 18  were set forth earlier in the application.) 
         [0052]    In  1150 , the signature establishment module  150  may feed the structural similarity matrix into the hierarchical clustering algorithm to produce clusters of the SOIs.  FIG. 14  illustrates an image matrix of SOI clusters. In  1160 , similar to creating the image matrix of software programs in  FIG. 9 , the signature establishment module  150  may create the image matrix which may show relational ties between SOI clusters. To determine the relational ties between the n-grams, one may use a specific criterion for deciding if there is a tie represented as one or a zero if there is not. Any criterion can be used for the decision such as Perfect Fit, Zeroblock, Oneblock, a Density Criterion, Maximum Value, Mean Value, or any commonly available criteria in the art, or any combination thereof. 
         [0053]    As an example of showing an image matrix as a result of applying the maximum value criterion,  FIG. 14  illustrates the output matrix of n-grams after the Maximum criterion is applied. The image matrix in  FIG. 14  may suggest that the software family is composed of five distinct types of n-gram clusters (P 1 , P 2 , P 3 , P 4  and P 5 ) and the relational ties between the n-gram clusters are either one, if the relational tie value is greater than the maximum value (e.g., 0.5), or zero. For example, the image matrix may suggest that the relational tie from P 1  to P 3  is strong where the relational tie from P 2  to P 3  is not. 
         [0054]      FIG. 15  illustrates one way of visualizing the image matrix of SOI clusters. The visualization module  180  may receive the image matrix of SOI clusters and visualize the analysis display similar to the image matrix in  FIG. 10 . One difference between  FIG. 10  and  FIG. 15  can be that the actors of the image matrix in  FIG. 15  are SOI clusters instead of software families. 
         [0055]      FIG. 16  is a flow diagram for the classification module  170 . In  1610 , the classification module  170  may receive a sample software program as an input. In  1620 , the classification module  170  may obtain a signature of the sample software program by sending the sample to the signature establishment module  150  and receiving the generated signature or by searching the sample from the signature repository  160 . In  1630 , the classification module  170  may classify the sample software program to a certain software family if the structural equivalence between the signature of the software program and the signature of the family exceeds a certain threshold value. When the measurement method of the structural equivalence is correlation coefficient, the threshold value can be any decimal number between 0 and 1. In some embodiments, 0.95 may be used as the threshold value. Any other value may also be used as the threshold value. 
         [0056]    A signature of a software family can be defined in various ways.  FIG. 17  illustrates many ways of calculating a ratio for a software program families. In the embodiment in  FIG. 17 , as an example, software programs are clustered into three software program families: Software Family # 1  ( 1710 ), Software Family # 2  ( 1720 ) and Software Family # 3  ( 1730 ). Multiple software programs in each family are selected to generate signatures. For example, suppose there are three programs ( 1721 ,  1722  and  1723 ) in Software Family # 2  and these include three types of bi-grams: MOV-JUMP, RETURN-SUB and ADD-JUMP. The first program includes 50 MOV-JUMP grams, 20 RETURN-SUB grams and 100 ADD-JUMP grams. The second program includes 30 MOV-JUMP grams, 28 RETURN-SUB grams and 80 ADD-JUMP grams. The third program includes 43 MOV-JUMP grams, 27 RETURN-SUB grams and 93 ADD-JUMP grams. The total bi-gram counts of the programs in Software Family # 2  for the first, second and third programs are respectively  170 ,  138 , and  163 . In some embodiments, the signature of each, member of Software Family # 2  can be a vector of the ratio of the set of n-gram counts per total numbers of n-grams in the software itself. So, for example, the signature of the first program would be (50/170, 20/170, 100/170), which is approximately (0.29412, 0.11765, 0.58823). The sum of these three components is approximately 1. In the same way, the signature for the second program would be (30/138, 28/138, 80/138), which is approximately (0.21739, 0.20290, 0.57971). Again these sum to 1. Finally, the signature for the third program would be (43/163, 27/163, 93/163), which is approximately (0.26380, 0.16565, 0.57055). As in the previous cases, these also sum to 1. The signature for the family would be the average of all signatures for the programs in the family. In this example, the signature for the family would be approximately (0.25843, 0.16207, 0.57950), which again sums to 1. Both the signatures of the individual programs and the signatures of the families are unit vectors (i.e., they sum to 1). Similarities may be measured by taking the cosine of the angle between the vectors with a cosine near 1 indicating very similar and a cosine near 0 indicating no similarity. The coherency within a family can be measured by the similarity of the signatures of the individual programs to the signature of the family. The dissimilarity between families can be measured by the dissimilarity of their respective signatures. A new, previously unseen program can be assigned to a family by investigating the similarity of its signature to the signature of each family and assigning it to the family for which it has the highest similarity. 
         [0057]      FIG. 19  illustrates an example of calculating a similarity ratio for a new piece of software versus a number of viruses. The first mean similarity ratio for all the viruses is then calculated (e.g., 0.817722). The results can be pruned one or more times to obtain a mean similarity in a range determined to be desirable (e.g., in this example, the final new mean is 0.938448). 
         [0058]    It should be noted that the similarities in the examples of  FIGS. 17 and 19  were measured by taking the cosine of the angle between the vectors. If the vectors point in the same direction, the cosine of the angle is 1 and they are very similar. If the angle is 90 degrees, then the cosine is of the angle 0 and they have no similarity. In other embodiments, similarity can be measured by a number of other distance or similarity measures. For example, other similarity metrics comprise: 
         [0059]    Euclidean: Uses the standard Euclidean (as-the-crow-flies) distance. 
         [0060]    Euclidean Squared: Uses the Euclidean squared distance in cases where one would use regular Euclidean distance in Jarvis-Patrick or K-Means clustering. 
         [0061]    Manhattan: Uses the Manhattan (city-block) distance. 
         [0062]    Pearson Correlation: Uses the Pearson Correlation coefficient to cluster together samples with similar behavior; samples with opposite behavior are assigned to different clusters. 
         [0063]    Pearson Squared: Uses the squared Pearson Correlation coefficient to cluster together samples with similar or opposite behaviors (i.e. samples that are highly correlated and those that are highly anti-correlated are clustered together). 
         [0064]    Chebychev: Uses Chebychev distance to cluster together samples that do not show dramatic differences; samples with a large difference may be assigned to different clusters. 
         [0065]    Spearman: Uses Spearman Correlation to cluster together samples whose profiles have similar shapes or show similar general trends, but whose levels may be very different. 
         [0066]    In additional embodiments, a few number of SOIs can be selected and a ratio may be calculated by counting the SOIs in the programs instead of counting all n-grams in the family. In other embodiments, a count of APIs may be used to generate a signature for the family instead of n-gram counts. 
         [0067]    In this specification, “a” and “an” and similar phrases are to be interpreted as “at least one” and “one or more.” References to “an” embodiment in this disclosure are not necessarily to the same embodiment. “Comprise” and similar phases are to be interpreted as “include but not limited to”. 
         [0068]    Many of the elements described in the disclosed embodiments may be implemented as modules. A module is defined here as an isolatable element that performs a defined function and has a defined interface to other elements. The modules described in this disclosure may be implemented in hardware, a combination of hardware and software, firmware, wetware (e.g., hardware with a biological element) or a combination thereof, all of which are behaviorally equivalent. For example, modules may be implemented using computer hardware in combination with software routine(s) written in a computer language (e.g., C, C++, Fortran, Java, Basic, Matlab) or a modeling/simulation program such as Simulink, Stateflow, GNU Octave, or LabVIEW MathScript. Additionally, it may be possible to implement modules using physical hardware that incorporates discrete or programmable analog, digital and/or quantum hardware. Examples of programmable hardware include: computers, microcontrollers, microprocessors, application-specific integrated circuits (ASICs); field programmable gate arrays (FPGAs); and complex programmable logic devices (CPLDs). Computers, microcontrollers and microprocessors are programmed using languages such as assembly, C, C++ or the like. FPGAs, ASICs and CPLDs are often programmed using hardware description languages (HDL) such as VHSIC hardware description language (VHDL) or Verilog that configure connections between internal hardware modules with lesser functionality on a programmable device. Finally, the above mentioned technologies may be used in combination to achieve the result of a functional module. 
         [0069]    The disclosure of this patent document incorporates material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, for the limited purposes required by law, but otherwise reserves all copyright rights whatsoever. 
         [0070]    While various embodiments have been described above, it should be understood that they have been presented by way of example, and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the spirit and scope. In fact, after reading the above description, it will be apparent to one skilled in the relevant art(s) how to implement alternative embodiments. Thus, the present embodiments should not be limited by any of the above described exemplary embodiments. In particular, it should be noted that, for example purposes, the above explanation has focused on the example(s) software signature application. However, one skilled in the art will recognize that embodiments of the invention could be a malware detection application. 
         [0071]    In addition, it should be understood that any figures that highlight any functionality and/or advantages, are presented for example purposes only. The disclosed architecture is sufficiently flexible and configurable, such that it may be utilized in ways other than that shown. For example, the steps listed in any flowchart may be re-ordered or only optionally used in some embodiments. 
         [0072]    Further, the purpose of the Abstract of the Disclosure is to enable the U.S. Patent and Trademark Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract of the Disclosure is not intended to be limiting as to the scope in any way. 
         [0073]    Finally, it is the applicant&#39;s intent that only claims that include the express language “means for” or “step for” be interpreted under 35 U.S.C. 112, paragraph 6. Claims that do not expressly include the phrase “means for” or “step for” are not to be interpreted under 35 U.S.C. 112, paragraph 6.