Method and system for protecting anti-malware programs

[0001] In general, the present invention relates to computer protection and, in particular, to a system and method for protecting anti-malware programs from malware attacks.

[0002] Anti-malware software programs, also known as anti-malware programs, are designed to protect computers from malware software (“malware”), such as a virus or Trojan horse. Generally described, malware is any type of program designed to perform malicious tasks that damage or disrupt a computer system. Malware often includes information about anti-malware programs, such as .exe or .dll file names, signatures of anti-malware files, the size of anti-malware files, and/or the location of those files. This information may be used by a malware program to locate and destroy the anti-malware process in a computer's memory, remove registry keys that allow the anti-malware to startup properly, and delete the anti-malware or portions of anti-malware from the computer's hard disk.

[0003] To protect anti-malware programs from being destroyed by malware, the anti-malware must detect the malware before it has the opportunity to perform its malicious tasks. Typically, such detection is accomplished using anti-malware scanners and detection engines to analyze files as they are added to or created on a computer. Scanners determine the signature of a new file and compare that signature with signatures stored in a malware library that is maintained by the anti-malware program. Detection engines quarantine files and analyze the behavior of the file to determine if it is likely to be malware. If a scanner or detection engine determines that a file is malware, the anti-malware program prohibits the file from remaining on the computer and does not allow the file to execute. In order for anti-malware scanners and detection engines to be able to detect all of the different forms of malware, the malware library must be frequently updated with information about new malware.

[0004] However, malware is being developed and released in large numbers (generally a malware program is released in small numbers then replicates) and many of those creations are complex and difficult to detect, even with information about the malware. Due to the number and complexity of malware being created and released, it is becoming difficult to keep anti-malware programs up-to-date with information that is needed to detect the newly created malware. If such information is not maintained and as malware becomes more complex, the likelihood increases that a malware program intended to destroy anti-malware programs will accomplish its task.

[0005] Thus, the existing techniques for protecting anti-malware from malware attacks are becoming insufficient. Accordingly, there is a need for a system and method that provide additional protection for anti-malware programs and associated files. Additionally, such a method and system should make malware that is designed to overcome the additional protection easier to detect, thereby providing further protection.

[0006] In general, embodiments of the present invention provide protection for anti-malware software programs (also referred to herein as anti-malware) that are in addition to the protection that currently exists. In particular, instead of only protecting anti-malware programs from malicious attacks by attempting to detect the malware software programs (also referred to herein as malware) before they can accomplish their malicious task, embodiments of the present invention obfuscate, or hide, the anti-malware and/or files associated with the anti-malware. Obfuscating files makes it difficult for malware to locate the information needed to accomplish its malicious tasks. Additionally, because obfuscation makes file location difficult, malware that attempts to overcome this protection technique will likely include and/or use a detection engine. Detection engines are generally large in size and produce an identifiable signature. Thus, malware that includes a detection engine will be readily identifiable using currently existing detection techniques, such as a signature scanner. Additionally, malware that attempts to use an existing detection engine is may be identified as a result of its use of the detection engine.

[0007] In accordance with an aspect of the present invention, a method for protecting information from an attack by a malware program is provided. The method identifies an item of information that is to be protected from an attack by a malware program and obfuscates the identified information by altering the identification of the information. The obfuscation may include changing the identification of the item (e.g., the file name), altering the signature of the item, and/or changing the size of the item. For example, the signature and/or size of the item may be changed by obtaining the binary file for the item and inserting filler code into the binary file. Additionally, functions of the binary file may be reorganized, which may alter the signature of the item when the binary file is recreated.

[0008] In accordance with another aspect of the present invention, a computer system having a computer readable storage medium that includes hardware storage media including a computer-executable program therein for performing the method of protecting files of an anti-malware program from being attacked by a malware program is provided. The computer program protects files of an anti-malware program by identifying the file to be protected, randomizing the file name of the identified file to create a new file name for the anti-malware file, and performing polymorphism on the anti-malware file to alter the size and signature of the anti-malware file.

[0009] In accordance with another aspect of the present invention, a computer system having a computer-readable medium including a computer-executable program therein for enabling the identification of a malware program is provided. The program enables identification of a malware program by obfuscating files associated with an anti-malware program wherein the files are obfuscated such that detection of the files by a malware program requires that the malware program include a detection engine. Once files have been obfuscated, the program searches for and locates an unknown file utilizing a detection engine and, in response to locating an unknown file utilizing the detection engine, identifies that unknown file as a malware program. As described in more detail below, if the file includes a detection engine it is easily identified because detection engines are large and produce an identifiable signature that can be detected by an anti-malware program. Alternatively, as discussed below, if the malware program attempts to use detection engine that is already present on the computer (e.g., the anti-malware's detection engine) the use of that engine may also be detected by an anti-malware program.

[0015] Anti-malware programs generally have static file names for each of their files and associated files. Likewise, those files are typically static in size and stored at common locations. As mentioned above, one technique for attacking and destroying anti-malware is by knowing information about the anti-malware, such as the file name, location and/or size, and using that information to locate anti-malware files, registry keys, etc., and delete the located files from the computer system.

[0016] While currently-existing malware detection techniques, such as scanning and detection engines, are good at detecting known malware, the potential exists for an unidentified malware program to invade a computer and destroy the anti-malware program before it is detected. Thus, additional protection techniques are desirable for protecting anti-malware from malware attacks. In general, such techniques may include techniques utilized by malware programs in an effort to hide themselves. For example, as described in more detail below, such techniques may include randomizing file names that are used by an anti-malware program, randomizing the file name of the anti-malware program itself, changing signature and/or size of the files (polymorphism) used by the anti-malware programs, relocating the files used by the anti-malware programs, and/or a combination of randomizing file names, changing file sizes, and relocating files.

[0017] File name randomization may utilize any type of randomization algorithm to create new file names and may be performed at any time. For example, randomization may be performed at installation of the anti-malware program itself, daily, or upon user request (user, server, etc.) in response to detection of a malware program, or at any other time. Additionally, polymorphism and/or file relocation may be performed at any time.

[0018] Polymorphism, as described in more detail below, includes inserting random code into the binary code of the file, thereby changing the signature and size of the compiled file. Additionally, polymorphism may be accomplished by reorganizing the functions included within a binary file. Such reorganization may also alter the signature of the file when recreated. Still further, polymorphism may include performing both the insertion of random code into the binary file and reorganizing the functions of that file.

[0019] FIG. 1 is a block diagram of an obfuscation routine used to protect anti-malware programs and associated files, in accordance with an embodiment of the present invention. The obfuscation routine 100 begins at block 101 and at block 103 identifies a file associated with the anti-malware program that is to be protected. Upon identification of a file, at decision block 105, the routine 100 determines if the identified file's name is to be randomized. If it is determined that the identified file's name is to be randomized, the randomization subroutine is performed, as illustrated by subroutine block 107 and described in detail with respect to FIG. 2. However, if it is determined at decision block 105 that the file name is not to be randomized, or upon completion of the randomization subroutine 107, at decision block 109, it is determined if polymorphism is to be performed for the identified file. If it is determined at decision block 109 that polymorphism is to be performed, the polymorphism subroutine is performed, as illustrated by block 111 and described in more detail with respect to FIG. 3.

[0020] Upon completion of the polymorphism subroutine 111 or if it is determined at decision block 109 that polymorphism is not to be performed on the identified file, at decision block 113, it is determined if there are additional files that are to be protected. If it is determined at decision block 113 that there are additional files to be protected, the routine 100 returns to block 103 and continues. However, if it is determined at decision block 113 that there are no additional files to be protected, the routine completes, as illustrated by block 115.

[0021] FIG. 2 is a block diagram of a randomization subroutine for randomizing a file name of an identified file in accordance with an embodiment of the present invention. The randomization subroutine 200 begins at block 201, and at block 203, a file identifier for the file identified at block 105 (FIG. 1) is stored by the anti-malware program. The file identifier is stored by the anti-malware program so that it can locate the file after the name has been randomized. The file identifier may be, for example, a hash value for the file. In an alternative embodiment, the file identifier may be the current file name and when the file name is randomized, the mapping to the file may be updated within the anti-malware program to identify the new file name.

[0022] At block 205, a new file name is generated for the identified file and that file is associated with the new file name. At block 207, the newly generated file name is associated with the stored identifier, thereby allowing the anti-malware program to locate and access the newly named file, as necessary. Even though a mapping between the original file name and the new (randomized) file name is maintained, such information is internal to the anti-malware program and not accessible to potential malware or other programs.

[0023] At block 209, the randomization subroutine completes returning control to the obfuscation routine 100. The obfuscation routine 100 and/or the randomization subroutine 200 may be performed at any point in time to alter the names of files that are used and/or associated with anti-malware. For example, the randomization subroutine 200 may be performed upon installation of the anti-malware, at startup of the computer, on a daily interval, or upon request (e.g., user or server request, etc.). The randomization of file names may be accomplished using any type of randomization algorithm to generate file names or based on some predefined randomization scheme.

[0024] Additionally, while the randomization subroutine 200 has been described with respect to storing a file identifier and associating the newly created file name with the stored identifier to allow access by the anti-malware program, other techniques for tracking the newly-named file by the anti-malware program may be utilized in accordance with embodiments of the present invention. For example, the randomization subroutine 200 may, as an alternative to storing a file identifier, generate a new file name for the identified file and update the file location information utilized by the anti-malware to identify this new file name, thereby replacing the previously used file name.

[0025] FIG. 3 is a block diagram of a polymorphism subroutine that is used to perform polymorphism on an identified file, in accordance with an embodiment of the present invention. Similar to the randomization subroutine 200 (FIG. 2), the polymorphism subroutine 300 may be performed at any time, such as at installation of the anti-malware program, at startup of the computer, daily, upon request (e.g., user or server request), etc.

[0026] The polymorphism subroutine 300 begins at block 301, and at block 303, a file identifier for the file identified at block 103 (FIG. 1) is stored. At block 305, the binary code for the identified file is obtained and at decision block 307, a determination is made as to whether the functions of that binary code are to be rearranged. Rearranging functions of binary code may, upon compiling the binary code, alter the signature of the file. Thus, if the malware includes a file signature for the identified file, it will not be able to detect the file as its signature has been changed. If it is determined at decision block 307 that the functions of the binary code are to be rearranged, those functions are rearranged in a random order, as illustrated by block 309.

[0027] Upon completion of the rearrangement of the functions at block 309, or if it is determined at decision block 307 that the functions are not to be rearranged, at decision block 311 a determination is made as to whether “filler code” is to be included into the binary code. “Filler code,” as used herein, is any code that may be included into existing binary code that does not alter the operation of the original binary code. For example, filler code may be a command to write a value to an empty memory location followed by a command to erase that value. Including filler code into a binary code of a file changes the size of the file when compiled and changes the signature of the file itself. Thus, if a malware program includes information about file size and/or file signature that it may use to locate the file, such identification by the malware program will not be accomplished as the file size and file signature have been altered.

[0028] If it is determined at decision block 311 that filler code is to be included into the binary code, at block 313 the filler code is generated and/or obtained from a filler code database and at block 315 inserted into the binary code itself. Filler code may be inserted at any point(s) of the binary code. For example, as described in more detail with respect to FIG. 4, the filler code may be included between different functions of the binary code or interspersed into a function of the binary code.

[0029] Upon insertion of the filler code into the binary code at block 315, or if it determined at decision block 311 that the filler code is not to be included, at block 317 the file is recreated or compiled using the modified binary code. Upon recreation of the identified file, the polymorphism subroutine 300 completes and returns control to the obfuscation routine 100 (FIG. 1), as illustrated by block 319.

[0030] In addition to randomizing the file name and altering the file size and/or signatures using polymorphism, the location of files used by an anti-malware program may also be altered to provide still further protection against malware attacks. For example, if a file used by the anti-malware program is typically stored at C:\ProgramFiles\AntiMalware\, the location of the file may be altered to any other location, such as C:\AntiMalware\. In relocating the files, the anti-malware program is updated to identify the locations of the files so that they can be accessed as necessary.

[0031] FIG. 4 is a block diagram illustrating the obfuscation that may be performed on a file associated with an anti-malware program for protecting that file against potential attacks by malware, in accordance with an embodiment of the present invention. As described above, a file 400 may have a file name, such as 01234.exe 401, and its binary code 402 may include one or more functions, such as Function A 403, Function B 404, Function C 405, Function D 406, Function E 407, Function F 408, and Function G 409. As described above, the file 400 may be protected from attacks by malware by obfuscating the file. For example, the obfuscation routine 431 may be executed on the file 400, thereby creating an obfuscated file 410. As described above, the obfuscation routine 431 may include a randomization subroutine 433 and/or a polymorphism subroutine 434 that is used to obfuscate the file 400 into the file 410 to thereby protect the file from potential malware attacks. Obfuscation provides protection by altering (1) the file name, (2) the file location, (3) the file's signature, and/or (4) the file size. For example, performing the obfuscation routine 431 utilizing both the randomization subroutine 433 and the polymorphism subroutine 434 on the file 400 may result in an obfuscated file, similar to the file 410. The randomization subroutine 433 may alter the file name from 01234.exe 401 to the file name 96482.exe 411. Additionally, the obfuscation routine 431 may move the file to a new location.

[0032] As discussed above, some malware is designed to attack anti-malware programs by having knowledge of the file name or file location. Using knowledge of the file name and/or location, the malware may identify the file and delete that file from the computer's memory. By performing the randomization subroutine on a file that may be identified by malware, thereby changing the file name, it will protect that file from detection by the malware program. Relocating the file also may provide further protection.

[0033] Additionally, utilizing the polymorphism subroutine 434 provides additional protection for a file, such as file 400. For example, utilization of the polymorphism subroutine 434 by the obfuscation routine 431 may result in a file similar to that illustrated by file 410 and its corresponding binary code 412. For example, the polymorphism subroutine 434 may reorganize the functions 403, 404, 405, 406, 407, 408, 409 of the binary code 402 used to create the file 400 into any random order, thereby potentially changing the signature of the file. Also, filler code may be included into the binary code 402 used to generate the file 400, thereby changing the file size and the file signature. For example, filler code, such as fill1 421, fill2 423, fill3 425, and fill4 427, may be included into the binary code 412 used to create obfuscated file 410 when the binary code 402 for the file 400 is obfuscated by the obfuscation routine 431.

[0034] Referring to FIG. 4, completion of the obfuscation routine 431 on file 400 and its corresponding binary code 400 may result in a reorganized file, as illustrated by file 410, wherein, in the binary code 412, Function G 419 appears first and Function D 416 appears second. Additionally, two filler codes, fill1 421 and fill2 423, may be inserted after Function D. Following the fill2 423 code, Function B 414 may be included in the binary code 412, followed by Function A 413. Subsequent to Function A 413, another filler code, fill3 425, may be included, followed by Function C 415. Function F 418 may be included subsequent to Function C 415, followed by Function E 417 and, lastly, by filler code fill4 427. As will be appreciated by one of ordinary skill in the relevant art, the Functions 413, 414, 415, 416, 417, 418, 419 and the filler code 421, 423, 425, 427 may be arranged in any order by the obfuscation routine 431, and the arrangement presented with respect to FIG. 4 is provided for explanation purposes only.

[0035] The embodiments described herein for obfuscating files, such as randomization of file names, polymorphism, and/or relocating files, provide protection for anti-malware programs and associated files in addition to the currently existing scanning and detection engine techniques used to identify malware. However, the embodiments described herein provide the additional benefit that, if malware is designed in an effort to overcome these additional protection techniques, such malware will be easily identifiable.

[0036] In particular, to overcome the obfuscation techniques described herein, the malware will likely include and/or use a detection engine similar to those currently used by anti-malware programs to detect malware. Inclusion of a detection engine will increase the size of the malware itself and will make the malware more detectable due to the common signature of the detection engine within the malware. For example, inclusion of a detection engine in a malware program that is used to detect files that have had their file names randomized would generate an identifiable signature, thereby making the malware itself easily detectable by the anti-malware programs. Alternatively, if the malware program attempts to use a detection engine that currently exists on the computer (e.g., an existing anti-malware detection engine) the use of that engine will be detectable by the anti-malware programs. Thus, embodiments in the present invention not only provide additional protection against malware programs, they thwart additional efforts to overcome these protection techniques.

[0037] While the embodiments of the present invention have been illustrated and described, it will be appreciated that various changes can be made therein without departing from the spirit and scope of the invention.