Method for preventing malicious software from execution within computer system

The present invention relates generally to avoiding malicious software, and particularly to methods for preventing the execution of malicious software in a computer system.

Malicious software, such as computer viruses, can infiltrate computer systems in a variety of ways. For example, they can invade a computer system via an optical disc that is supposed to be inserted into the computer system or via an email that is supposed to be opened by a user of the computer system. it can. Malicious software causes some problems when run inside a computer system. For example, computer security may be compromised, or files in the computer system may be corrupted.

Some types of malicious software can be easily detected using simple detection techniques such as scanning the search string. However, this form of detection processing is also easily overturned by converting malicious code through compression and encryption, thereby bypassing the scan filter. Another way to detect malicious software is to run the program while trying to prevent malicious behavior while the program is running. This technique, known as behavior blocking, has many drawbacks. Despite attempts to thwart malicious behavior, programs can cause harm to computer systems. In addition, the motion blocking mechanism usually cannot see the entire log of motion for blocking determination. Therefore, the behavioral blocking mechanism may make a suboptimal blocking decision, which means that a harmless program may be blocked while the harmful program is allowed to run.

Yet another way to detect malicious software is to emulate suspicious code within the isolated environment of the computer system so that the computer system is protected from malicious behavior of the suspicious code. .. One drawback of emulation may be that it partially protects the computer system from virus attacks, but it does not protect the computer system itself. In addition, the data can be infected, which leads to destruction in an isolated environment.

<p> Therefore, it is desirable to provide an improved way to prevent the execution of malicious software within a computer system.</p>

<p> According to a preferred embodiment of the invention, a permutation of instructions within an application program results in a sequence of instructions sorted prior to any actual execution of the application program in the computer system. It is done for a subset. The permutation sequence number of the sorted instruction sequence is stored in the sorted instruction pointer table. The sorted instruction sequence is a sequence of sorted instructions stored in the sorted instruction pointer table according to the sequence sequence number of the sorted instruction sequence of the processor in the computer system. It is executed in an execution module that can be translated into actual machine code.</p><p> Also, the computer system cross-compiles the application program to bring about a cross-compiled set of code for the application program before any actual execution of the application program. A cross-compiled set of code for an application program is executed in an execution module that allows the computer system to recognize and translate the cross-compiled set of code for the application program into the actual machine code of the processor.</p>

<p> The present invention provides a method for preventing the execution of malicious software in a computer system. If the VMM (Virtual Computer Manager) maintains a permutation associated with the hash of each sorted application to be executed, even a sampling attack (where the sample sorted application is managed by the attacker). It will not work (even if it is obtained, permuted, virus applied, and sent to carry out the infection).</p>

All features and advantages of the present invention will become apparent in the detailed description below.

The preferred form of use, as well as its purpose and its advantages, as well as the invention itself, will be best understood by reference to the following detailed description of the specific embodiments when reading with the accompanying drawings. ..

There are usually several levels of instruction sets within a computer system. The first (lowest) level is the machine level instruction and the second level is the operating system application binary interface instruction. At the second level, some of the machine-level instructions are extracted to make it easier for the operating system to understand the machine-level instructions. The third level is macro-level instructions, which further extract control of the computer system to allow the application to be easier to program.

Since many techniques have been directed towards the protection of the second and third instruction levels, the present invention is exclusively the first, especially since the first level is the level used by many computer viruses. Directed to protect the level of instruction.

Generally speaking, writing a machine-level program in a computer system that can be run in the computer system without knowing the processor's machine-level instruction set happens, if not impossible. You don't get it. In addition, installing software on a computer system requires software to first understand the instruction set of the installed computer system. Therefore, according to a preferred embodiment of the invention, the application program is first converted into a cross-compiled code set of the application program, and the cross-compiled code set of the application program is then applied. -It is executed in an execution module that can recognize the cross-compiled set of code of the program.

In particular, with reference to FIG. 1, a conceptual diagram of a method for preventing the execution of malicious software in a computer system according to a preferred embodiment of the present invention is shown. As shown, the computer system 10 includes a conversion module 11 and an execution module 12. Any application program that is supposed to run in computer system 10 must go through an installation process. During the installation process, the user of computer system 10 can decide whether the application program should be installed in computer system 10. If the user decides that the application program should be installed in computer system 10, the application program is then sent to conversion module 11, where the application program cross-compiles the application program. Converted to a set of code. The cross-compiled code set of the application program is then executed within Execution Module 12, which can recognize the cross-compiled code set of the application program and translate it into the machine code of the actual processor. The program.

The application program will not be executed by Execution Module 12 without going through the installation process. For example, as shown in Illegal Path 15, the virus program is installed during the installation process, even if the virus program sneaks in under the user's detection and exists in computer system 10 without the user's knowledge. It has not been executed by execution module 12 yet because it has not passed through. As such, computer system 10 is safe from potential harm that may be caused by virus programs.

In fact, the conversion module 11 and the execution module 12 should be independent of each other. Virtually, execution module 12 should be prevented from accepting code from any source other than conversion module 11.

By the way, referring to FIG. 2, a block diagram of a computing environment incorporating a preferred embodiment of the present invention is illustrated. As shown, the computer system 20 includes a hardware structure 21, a virtual computer manager (VMM) or hypervisor 22, and virtual computers 23a-23b. The virtual computers 23a and 23b are preferably installed in separate compartments so that any execution within the virtual computer 23a is independent of the virtual computer 23b and vice versa. The VMM22 controls all communications between the virtual computers 23a and 23b. In addition, the VMM22 can communicate directly with the hardware structure 21. The hardware structure 21 includes known structures such as a processor, a register, a memory management device, a memory element, and an input / output device.

It is possible for the operating system and multiple application programs to run simultaneously in each of the virtual computers 23a-23b. For example, operating system 24 and application program 25 run on virtual computer 23a, while operating system 26 and application program 27 run on virtual computer 23b.

Although not required, operating system 24 may differ from operating system 26. For example, operating system 24 can be an open source Linux operating system, while operating system 26 can be a Windows® operating system created by Microsoft Corporation. Similarly, the underlying processor emulated by the virtual computer 23a may also differ from the underlying processor emulated by the virtual computer 23b. For example, the underlying processor emulated by virtual computer 23a is a Pentium® processor created by Intel Corporation, while the underlying processor emulated by virtual computer 23b is created by International Business Machines Corporation. It can also be a PowerPC® processor.

Each of the virtual computers 23a-23b contains its operating system and associated application programs, but operates at the user level. When VMM22 uses direct execution, VMM22 is in so-called user mode (ie, so-called user mode) so that neither of the virtual computers 23a-23b can directly access the various privileged registers that control the operation of hardware structure 21. , Limited privileges). Rather, all privileged instructions will be trapped in VMM22.

In Figure 2, the virtual computer 23a is shown to include a cross-compiler 28 for initial cross-compilation of application programs, and the virtual computer 23b is an execution module 29 for executing cross-compiled code. Is illustrated to include. Cross-compiling is preferably done via a permutation algorithm and the results are stored in the sorted instruction pointer table 30. The sorted instruction pointer table 30 contains entries for multiple permutation sequences. Each permutation sequence is associated with a cross-compiled set of code in an application program. All permutation sequences in the sorted instruction pointer table 30 need not be different from each other, but tend to be different from each other. In FIG. 2, the sorted instruction pointer table 30 is shown to be placed inside the VMM22, but if the sorted instruction pointer table 30 can be accessed by the virtual computer 23b. It can also be installed in the virtual computer 23a.

The typical way to perform permutations is as follows. First, a subset of instructions, n, is selected from a group of instructions for permutation purposes. Not all instruction permutations are equally useful. For example, the permutation of identification (ID) instructions is completely useless. Therefore, certain machine instructions (such as JUMP instructions) are identified as important instructions and ensure all important instructions that will be sorted.

There are several ways to generate permutations. One method is to utilize a feature-based hash or encryption such that each instruction in the data segment has a different mapping. That is, the mapping is H (A)_l), H (A₂), ..., H (A)_i), Where H is a function-based hash and A is an instruction. The problem with using feature-based hashes or encryption is that from a general compilation point of view, the same instruction may result in different hashes. For example, instruction A₅And instruction A₉May be the same command as, but H (A₅) Is not necessarily H (A₉) Is not the same.

The other method is to use a different mapping function, P (A). Where P is a permutation and A is an instruction, but P (A) is P_l(A), P₂(A), ... P_nGenerate (A). This method is P_l(J), where J is a given instruction, but should be the same no matter where it occurs in the code segment, resulting in a more predictable cross-compilation result.

Permutation sequences dictate how n, a subset of instructions, is sorted or transformed. Each permutation sequence can be considered as an entry with multiple slots, each slot being to be filled with an instruction number. A random number between 0 and n! -1 is selected first to generate the rth permutation sequence. For example, if n, which is a subset of the instructions needed to be sorted (which means a permutation sequence of 5! = 120), then the random number 101 is 0 and 5! -1 as the 101st permutation sequence. Selected between.

The slot position of the first instruction number, Pos, is represented by the quotient of the selected random number r divided by (n-1) !, and is as follows.

<maths num="1"><img file="JP2007220091A_D0001.tif" /></maths>

The remainder of the split replaces the random number r chosen to determine Pos, which is the slot position of the subsequent instruction number until all slots are filled with the instruction number. For each decision, n in the denominator (n-1)! Is decremented by one.

In this way, for the selected random number 101, the slot position of the first instruction number is 101 / (5-1)! = 4 as shown in FIG. 3a. The remainder of 101 / (5-1)! Is 5, and the slot position of the second instruction number is 5 / (4-1)! = 0 as shown in FIG. 3b. The remainder of 5 / (4-1)! Is 5, and the slot position of the third instruction number is 5 / (3-1)! = 2 as shown in Fig. 3c. The remainder of 5 / (3-1)! Is 1, and the slot position of the 4th instruction number is 1 / (2-1)! = 1 as shown in FIG. 3d. The fifth instruction number is the remaining open slot position as shown in Figure 3e.

The permutation sequence "25431" (from Figure 3e) is then entered into the instruction pointer table 30 (from Figure 2) sorted as an entry for the 101st permutation sequence. The application program is sorted into a cross-compiled set of code via cross-compiler 28 (from Figure 2) according to the 101st permutation sequence. During execution, the cross-compiled set of code is executed via execution module 29 (from Figure 2) according to the 101st permutation sequence stored in the sorted instruction pointer table 30.

For example, if the five instructions selected to be sorted are ADD, SUBTRACT, JUMP, BRANCH and STORE, then each of these instructions is ADD for instruction number 1 and SUBTRACT for instruction number 2. One instruction number is assigned, such as JUMP for number 3, BRANCH for instruction number 4, and STORE for instruction number 5. When the 101st permutation sequence is used to cross-compile the application program within the cross-compiler 28 of Figure 2, each occurrence of the above five instructions in the application program follows the permutation sequence "25431". Will be converted. In other words, each ADD instruction in the application program is converted to a SUBTRACT instruction, each SUBTRACT instruction in the application program is converted to a STORE instruction, and each JUMP instruction in the application program is converted to a BRANCH instruction. Then, each BRANCH instruction in the application program is converted into a JUMP instruction, and each STORE instruction in the application program is converted into an ADD instruction. The reverse of the above conversion is done in the execution module 29 of Figure 2 during the execution of the cross-compiled code of the application program.

The sequence can be done either statically or dynamically. If permutations are done in a static way, groups of computer systems are set to use the same permutation sequence. Such a practice would be easier for information technology managers, as cross-compiling of each application program would only be required to be performed once during installation.

If permutations are done in a dynamic way, there are several choices. The set of permutation sequences can be changed cyclically. Cross-compiling for those permutations can only be done once, and each time the computer system is booted, it actually runs a different set of cross-compiled programs based on the permutations in use. be able to. In addition, the permutation sequence can change irregularly each time the computer system is booted. In such cases, the cross-compilation would have to be done "on the fly" by a cross-compiler running on the computer system.

In addition, permutation sequences can be modified for each application program as well, and the modifications can be made in different ways. The simplest practice is to have the VMM use the application's signature hash as the key to the streaming encryption algorithm, thereby generating a unique set of instructions for that application program. Any modified application program will begin to generate different instruction sets (as modified in main memory by a virus that causes a buffer overflow).

Alternatively, the VMM will generate a random number each time the application program is loaded, and the code segment of the application program will have a hash to modify the streaming encryption or cross-compilation (it does not have to be reversible). It runs through the engine. This method is P_n(A) The function becomes a constant function P (A), which provides another level of security in that it remains unpredictable.

Although the present invention has been described in the context of a fully functional computer system, the mechanisms of the present invention can be distributed as program products in various forms, and the present invention will actually carry out the distribution. It is also important to note that those skilled in the art appreciate the equal fit regardless of the particular type of signal bearing media used for this purpose. Examples of signal-carrying media include, without limitation, recordable media such as floppy disks and compact discs, and transmission media such as analog or digital communication links.

Although the invention is illustrated and described with reference to particularly preferred embodiments, it will be appreciated by those skilled in the art that various changes in form and detail will be made without departing from the spirit and scope of the invention. ..

<figref num="1">FIG. 5 is a conceptual diagram of a method for preventing the execution of malicious software in a computer system based on a preferred embodiment of the present invention.</figref><figref num="2">FIG. 6 is a block diagram of a computer environment incorporating preferred embodiments of the present invention.</figref><figref num="3">It represents a sequence rearranged in an instruction according to a preferred embodiment of the present invention.</figref>

Code description

10, 20 Computer system 11 Conversion module 12, 29 Execution module 21 Hardware structure 22 Virtual computer manager 23a, 23b Virtual computer 24, 26 Operating system 25, 27 Application program 28 Cross compiler 30 Sorted instruction pointer ·table