A malicious data application, data file or computer program may be harmful to the operating system or other application currently operating on a user's computer. One example of a malicious data application may be a Trojan horse, which is a type of malicious application that appears to be a legitimate application, but contains a malicious payload if executed by an unknowing user on a corresponding user computer device. The payload could be a virus, spyware, rootkit, logic bomb, or any type of malware currently plaguing the computer community.
In general, malicious software is wrapped with a legitimate file to fool the computer users. For example, one might wrap a spyware program to an innocuous file such as a game. There are many methodologies to perform this type of wrapping process. In one example, there are tools such as ‘EliteWrap’, which will perform the wrapping procedure for a user. Another methodology is actually built into the NTFS file system of Windows® operating systems, which takes advantage of alternate data streams (ADS). An ADS is a methodology within NTFS that allows one to tie a file to another file.
In operation, the user will only see one of the files in Windows Explorer or when listing files from the command line. However, when that file is executed the hidden file will also be executed. This is a well known vulnerability in the security community. Whatever the specific methodology used for tying malicious software to an innocuous program, when the process is complete the resulting program is said to have been ‘Trojaned.’ Current methods for determining if a given file or executable has been Trojaned are frequently ineffective. The current methods depend solely on looking for signatures of known Trojans or simply if the file has features that might contain a Trojan at all.
The ethical hacker (EC) council sponsors the certified ethical hacker certification test and recommends that if one suspects a given executable is Trojaned, the user should compare a MD5 hash of the executable with the MD5 hash provided on the installation media. This comparison process requires the user to first suspect an executable has been Trojaned, then elect to perform a test of that executable. Also, the installation media must have a hash of the original executable, and the user must have a mechanism for hashing the current executable. This methodology while effective is cumbersome. It also is dependent upon both user knowledge, and upon the vendor of the executable having provided a hash of the executable on the installation media. Furthermore, this methodology is only implemented if and when a user suspects a particular executable has been Trojaned. As a result, Trojaned executables would frequently be missed.
Another well known way to perform software application verifications is with code signing. In this example, the software vendor must sign the code. If it was not signed, then the operating system has no way of verifying the software. With code signing the purpose is to verify that the software being downloaded from the Internet is valid. Once the product is installed, it is not checked at each execution. Code signing is dependent upon third party digital signatures, which may not be present in all instances of installation.
USPTO Backgrounds
USPTO Backgrounds