IE85016B1 - Method for preventing malicious software from execution within a computer system - Google Patents

Abstract

abstracted control of the computer system to allow for ease of programming. Since many techniques have been dedicated to the protec- tion of the second and third levels of instructions, the present invention is solely directed to the protection of the first level of instruction, especially when this is the level that is used by many computer viruses. Generally speaking, it is improbable, if not impossible, to write a machine level program that can be executed within a computer system without knowing the machine level instruction set of a processor within the computer system. In addition, an installation of software on a computer sys- tem requires the software to first understand the instruc- tion set of the computer system on which it is being in- stalled. Thus, in accordance with a preferred embodiment of the present invention, an application program is ini- tially transformed to a set of cross—compiled code of the application program, and the set of cross-compiled code of the application program is then executed within an execu- tion module that is capable of recognizing the set of cross—compiled code of the application program. Referring now to the drawings and in particular to Figure , there is depicted is a conceptual view of a method for preventing malicious software from execution within a com- puter system, in accordance with a preferred embodiment of the present invention. As shown, a computer system 10 in- cludes a transformation module 11 and an execution module 12. Any application program that is to be executed within computer system 10 needs to undergo an installation proc- ess. During the installation process, a user of computer system 10 can decide whether or not an application program should be installed within computer system 10. If the user decide the application program should be installed within computer system 10, the application program is then sent to transformation module 11 in which the application program will be transformed to a set of cross—compiled code of the application program. The set of cross—compiled code of the application program can subsequently be executed within execution module 12 that is capable of recognizing and translating the set of cross—compiled code of the applica- tion program to the actual machine code of the processor. Without going through the installation process, an appli- cation program will not be able to be executed by execu- tion module 12. For example, as shown in an illicit path 15, even if a virus program has sneaked under the detec- tion of a user and was placed within computer system 10 without the user's knowledge, the virus program still can- not be executed by execution module 12 because the virus program has not undergone the installation process. As such, computer system 10 is safe from the potential harm that could have been brought on by the virus program. In practice, transformation module 11 and execution module 12 should be isolated from each other. In fact, execution module 12 should be prevented from accepting code from any source other than transformation module 11. With reference now to Figure 2, there is depicted a block diagram of a computing environment in which a pre- ferred embodiment of the present invention is incorpo- rated. As shown, a computer system 20 includes a hardware structure 21, a virtual machine manager (VMM) or hypervi— sor 22 and virtual machines 23a-23b. Virtual machines 23a and 23b are preferably located in separate partitions such that any execution within virtual machine 23a is isolated from virtual machine 23b, or vice versa. VMM 22 controls all communications between virtual machines 23a and 23b. In addition, VMM 22 can directly communicate with hardware structure 21. Hardware structure 21 includes such known memory management structures as processors, registers, units, memory devices, input/output devices, etc. An operating system and multiple application programs can be executed concurrently within each of virtual ma- chines 23a—23b. For example, an operating system 24 and an application program 25 are executed within virtual ma- chine 23a, while an operating system 26 and an applica- tion program 27 are executed within virtual machine 23b. Although it is not required, operating system 24 can be different from operating system 26. For example, operating system 24 can be an open source Linux operating system, while operating system 25 can be Windows® operating system manufactured by the Microsoft Corporation. Similarly, the underlying processor emulated by virtual machine 23a can also be different from the underlying processor emulated by virtual machine 23b. For example, the underlying processor emulated by virtual machine 23a can be a Pentium® proces- sor manufactured by the Intel Corporation, while the un- derlying processor emulated by virtual machine 23b can be a PowerPC® processor manufactured by the International Business Machines Corporation. Each of virtual machines 23a-23b, which includes its oper- ating system and associated application programs, operates at a user-level. When VMM 22 uses direct execution, VMM 22 is set to a so—called user—mode (i.e., with reduced privi- leges) so that none of virtual machines 23a—23b can di- rectly access the various privileged registers that con- trol the operation of hardware structure 21. Rather, all privileged instructions will be trapped into VMM 22. In Figure 2, virtual machine 23a is shown to include a cross compiler 28 for performing initial cross-compilations of application programs. In addition, virtual machine 23b is shown to include an execution module 29 for executing the cross—compiled code of the application programs. The cross-compilations are preferably performed via a permu- tation algorithm, and the results are stored in a permuted instruction pointer table 30. Permuted instruction pointer table 30 includes multiple entries of permutation se- quences. Each of the permutation sequences is associated with a set of cross—compiled code of an application pro- gram. All the permutation sequences within permuted in- struction pointer table 30 are likely to be different from each other, although they are not required to be different from each other. In Figure 2, permuted instruc- tion pointer table 30 is shown to be placed within VMM 22; however, permuted instruction pointer table 30 can also be placed within virtual machine 23a provided that it can also be accessed by virtual machine 23b. An exemplary method for performing permutations is as fol- lows. First, a subset of instructions n is selected from a group of instructions for the purpose of permutation. Not all instruction permutations would be equally useful. For example, permutations of identity instructions would be of no use at all. So certain machine instructions (such as a JUMP instruction) should be identified as critical instructions in order to ensure all critical inv structions will get permuted. There are several ways to generate permutations. One method is to utilize a hash or encryption based function such that each instruction in a data segment has a differ- H(A1), H(A2),..., H(Ai), where H is the ent mapping, i.e., hash based function, and A is an instruction. The problem with using a hash or encryption based function is that, from a general compilation standpoint, same instructions may have different hashed results. For example, instruction A; and instruction A9 may be the same instruction, but H(Afi does not necessarily equal to H(A9). Another method is to utilize a different mapping function P(A), where P is the permutation, and A is an instruction, which generates: Pl(A), P2(A), ..., Pn(A). This method yields a more predictable cross—compilation result, since P1(J), where J is the given instruction, should be the same no matter where it appears in code segments. A permutation sequence dictates the way the subset of in- structions n is to be permuted or transformed. Each permuta- tion sequence can be viewed as an entry having multiple slots, and each slot is to be filled with an instruction number. In order to generate an r”‘permutation sequence, a random number between 0 and n!-l is initially chosen. For example, if the subset of instructions n needed to be permuted is 5 (which means there are 5! = 120 permutation sequences), a random num- ber 101 can be chosen between 0 and 51-1 as the lOl”‘permuta— tion sequence. The slot position Pos of the first instruction number is indicated by the dividend of the chosen random number r di- as follows: vided by (n—l)!, Pos= ' (n -1)! The remainder of the division replaces the chosen random num- ber r for the determination of the slot position Pos of the subsequent instruction number until all the slots are filled n in the with instruction numbers. For each determination, denominator (n—l)! is decremented by one. Thus, for the chosen random number 101, the slot position of the first instruction number is 101/(5-1)! = 4, as shown in Figure 3a. The remainder of 101/(5—l)E is 5, and the slot position of the second instruction number is 5/(4-1)! = O, as shown in Figure 3b. The remainder of 5/(4-1)! is 5, and the slot position of the third instruction number is 5/(3- )! = 2, as shown in Figure 3c. The remainder of 5/(3-1)! is 1, and the slot position of the fourth instruction number is 1/(2-1)! = 1, as shown in Figure 3d. The fifth instruc- tion number goes to the remaining open slot position, as depicted in Figure 3e. The permutation sequence "2543l" (from Figure 3e) is then entered into permuted instruction pointer table 30 (from Figure 2) as an entry for the 10l“‘permutation sequence. An application program can be permuted according to the 101” permutation sequence into a set of cross—Compiled (from Figure 2). During execu- code via cross compiler 28 tion, the set of cross-compiled code can be executed via execution module 29 (from Figure 2) according to the 101th permutation sequence stored in permuted instruction pointer table 30. For example, if the five instructions chosen to be per- muted are ADD, SUBTRACT, JUMP, BRANCH and STORE, then each of these instructions is assigned an instruction number ac- cordingly, i.e., instruction number 1 = ADD, instruction number 2 = SUBTRACT, instruction number 3 = JUMP, in- struction number 4 = BRANCH and instruction number : STORE. When the 101” permutation sequence is utilized for performing cross-compilation of an application program within cross compiler 28 of Figure 2, each occurrence of the above—mentioned five instructions within the applica- tion program will be transformed according to the permuta- tion sequence "25431." In other words, each ADD instruc- tion within the application program will be transformed into a SUBTRACT instruction, each SUBTRACT instruction within the application program will be transformed into a STORE instruction, each JUMP instruction within the ap- plication program will be transformed into a BRANCH in- struction, each BRANCH instruction within the application program will be transformed into a JUMP instruction, and each STORE instruction within the application program will be transformed into an ADD instruction. A reversal of the above-mentioned transformation is performed within execution module 29 of Figure 2 during the execution of the cross—compiled code of the application program. The permutation can be performed in either a static or a dynamic manner. If the permutation is performed in a static manner, then a group of computer systems can be set to use the same permutation sequence. Such practice would be easier for an information technology manager be- cause cross compilation of each application program would be required to be performed only once during installation. If the permutation is performed in a dynamic manner, there are several choices. A set of permutation sequences can be changed periodically. Cross compilation for those permutations can be performed once, and then each time a computer system boots, it can run a different set of cross compiled programs, based on the permutation sequence actu- ally in use. Further, the permutation sequence can ran- domly change each time the computer system boots. In such a case, cross compilation would have to be done "on the fly" by a cross compiler running on the computer system. In addition, the permutation sequence can also be changed for each application program, and it can be accom- plished by different methods. The simplest implementation is to have the VMM use the signature hash of an applica- tion as a key for a streaming encryption algorithm, thereby generating a unique instruction set for that ap- plication program. Any altered application program (such as being altered in a main memory due to a virus that will start generating a dif- causes a buffer overflow) ferent instruction set. Alternatively, the VMM can generate a random number each time an application program is being loaded, and the code segments of the application program are run through (since it does not need an streaming encryption, or hash to be reversible) engine to change the cross compilation. This method provides an additional level of security in a constant function that the Pn(A) function becomes P(A) and remains unpredictable. As has been described, the present invention provides a method for preventing malicious software from execution within a computer system. If the VMM keeps a permutation associated with the hash of each permuted application that is to be run, then even a sampling attack (where a sample permuted application is somehow obtained by an attacker, and the permutation determined, applied to a virus, and then sent to perform an infection) fails. It is also important to note that although the present in- vention has been described in the context of a fully func- tional computer system, those skilled in the art will ap- preciate that the mechanisms of the present invention are capable of being distributed as a program product in a va- riety of forms, and that the present invention applies equally regardless of the particular type of signal bear- ing media utilized to actually carry out the distribution. Examples of signal bearing media include, without limita- tion, recordable type media such as floppy disks or com- pact discs and transmission type media such as analog or digital communications links. While the invention has been particularly shown and de- scribed with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without de- parting from the spirit and scope of the invention.

Description

BACKGROUND OF THE INVENTION . Technical Field The present invention relates to avoiding malicious software in general, and, in particular, to a method for preventing mali- cious software from execution within a computer system.

. Description of Related Art Malicious software, such as computer viruses, can enter a com- puter system in many ways. For example, they can enter a computer system via a disk that is to be inserted into the computer system or they can enter the computer system via an email that is to be opened by a user of the computer system.

Malicious software can cause problems to the computer system if they are executed within the computer system. For example, computer security may be compromised or files within the com— puter system may be destroyed.

Certain types of malicious software can easily be de- tected using simple detection techniques, such as scanning for a search string. However, this type of detection proc- ess can also easily be subverted by converting malicious code via compression or encryption, thus bypassing scan- ning filters. Another approach to detecting malicious software is to run a program while attempting to intercept malicious actions during program execution. This tech- nique, which is known as behavior blocking, has a number of disadvantages. Despite of the attempt to intercept mali— E85016 cious actions, the program may nevertheless cause harm to the computer system. Furthermore, the behavior blocking mechanism typically cannot view an entire log of ac- tions in making a blocking determination. Hence, the be- havior blocking mechanism may make sub-optimal blocking decisions, which means harmless programs may be blocked while harmful programs may be allowed to execute.

Yet another approach to detecting malicious software is to emulate suspect code within an insulated environment of a computer system so that the computer system is protected from malicious actions of the suspect code. One drawback of emulation is that while it may protect parts of the com— puter system from virus attacks, it is not itself pro- tected. Additionally, data can be infected, which leads to a break in the isolation environment.

Consequently, it would be desirable to provide an im- proved method for preventing malicious software from exe- cution within a computer system.

SUMMARY OF THE INVENTION In accordance with a first embodiment of the present in- vention, a permutation is performed on a subset of instruc- tions within an application program to yield a permuted se- quence of instructions before any actual execution of the ap- plication program on a computer system. A permutation se- quence number of the permuted sequence of instructions is stored in a permuted instruction pointer table. The permuted sequence of instructions is executed in an execution module that is capable of translating the permuted sequence of in- structions to an actual machine code of a processor within the computer system according to the permutation sequence number of the permuted sequence of instructions stored in the permuted instruction pointer table.

In accordance with a second embodiment of the present inven- tion, before any actual execution of an application program on a computer system, the application program needs to be cross-compiled to yield a set of cross-compiled code of the application program. The set of cross-compiled code of the application program can then be executed in an execution mod- ule that is capable of recognizing and translating the set of cross-compiled code of the application program to the actual machine code of the processor.

All features and advantages of the present invention will be- come apparent in the following detailed written description.

BRIEF DESCRIPTION OF THE DRAWINGS The invention itself, as well as a preferred mode of use, further objects, and advantages thereof, will best be un- derstood by reference to the following detailed descrip- tion of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein: Figure 1 is a conceptual View of a method for preventing malicious software from execution within a computer sys- in accordance with a preferred embodiment of the pre— tem, sent invention; Figure 2 is a block diagram of a computing environment in which a preferred embodiment of the present invention is incorporated; and Figures 3a-3e depict a sequence in which instructions is in accordance with a preferred embodiment being permuted, of the present invention.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT Typically, there are several levels of instruction sets within a computer system. The first (lowest) level is the machine level instructions, and the second level is the operating system application binary interface instruc- tions. At the second level, the operating system has ab- stracted some of the machine level instructions to make them easier to be understood. The third level is the macro level instructions, at which an application has further abstracted control of the computer system to allow for ease of programming.

Since many techniques have been dedicated to the protec- tion of the second and third levels of instructions, the present invention is solely directed to the protection of the first level of instruction, especially when this is the level that is used by many computer viruses.

Generally speaking, it is improbable, if not impossible, to write a machine level program that can be executed within a computer system without knowing the machine level instruction set of a processor within the computer system.

In addition, an installation of software on a computer sys- tem requires the software to first understand the instruc- tion set of the computer system on which it is being in- stalled. Thus, in accordance with a preferred embodiment of the present invention, an application program is ini- tially transformed to a set of cross—compiled code of the application program, and the set of cross-compiled code of the application program is then executed within an execu- tion module that is capable of recognizing the set of cross—compiled code of the application program.

Referring now to the drawings and in particular to Figure , there is depicted is a conceptual view of a method for preventing malicious software from execution within a com- puter system, in accordance with a preferred embodiment of the present invention. As shown, a computer system 10 in- cludes a transformation module 11 and an execution module 12. Any application program that is to be executed within computer system 10 needs to undergo an installation proc- ess. During the installation process, a user of computer system 10 can decide whether or not an application program should be installed within computer system 10. If the user decide the application program should be installed within computer system 10, the application program is then sent to transformation module 11 in which the application program will be transformed to a set of cross—compiled code of the application program. The set of cross—compiled code of the application program can subsequently be executed within execution module 12 that is capable of recognizing and translating the set of cross—compiled code of the applica- tion program to the actual machine code of the processor.

Without going through the installation process, an appli- cation program will not be able to be executed by execu- tion module 12. For example, as shown in an illicit path , even if a virus program has sneaked under the detec- tion of a user and was placed within computer system 10 without the user's knowledge, the virus program still can- not be executed by execution module 12 because the virus program has not undergone the installation process. As such, computer system 10 is safe from the potential harm that could have been brought on by the virus program.

In practice, transformation module 11 and execution module 12 should be isolated from each other. In fact, execution module 12 should be prevented from accepting code from any source other than transformation module 11.

With reference now to Figure 2, there is depicted a block diagram of a computing environment in which a pre- ferred embodiment of the present invention is incorpo- rated. As shown, a computer system 20 includes a hardware structure 21, a virtual machine manager (VMM) or hypervi— sor 22 and virtual machines 23a-23b. Virtual machines 23a and 23b are preferably located in separate partitions such that any execution within virtual machine 23a is isolated from virtual machine 23b, or vice versa. VMM 22 controls all communications between virtual machines 23a and 23b. In addition, VMM 22 can directly communicate with hardware structure 21. Hardware structure 21 includes such known memory management structures as processors, registers, units, memory devices, input/output devices, etc.

An operating system and multiple application programs can be executed concurrently within each of virtual ma- chines 23a—23b. For example, an operating system 24 and an application program 25 are executed within virtual ma- chine 23a, while an operating system 26 and an applica- tion program 27 are executed within virtual machine 23b.

Although it is not required, operating system 24 can be different from operating system 26. For example, operating system 24 can be an open source Linux operating system, while operating system 25 can be Windows® operating system manufactured by the Microsoft Corporation. Similarly, the underlying processor emulated by virtual machine 23a can also be different from the underlying processor emulated by virtual machine 23b. For example, the underlying processor emulated by virtual machine 23a can be a Pentium® proces- sor manufactured by the Intel Corporation, while the un- derlying processor emulated by virtual machine 23b can be a PowerPC® processor manufactured by the International Business Machines Corporation.

Each of virtual machines 23a-23b, which includes its oper- ating system and associated application programs, operates at a user-level. When VMM 22 uses direct execution, VMM 22 is set to a so—called user—mode (i.e., with reduced privi- leges) so that none of virtual machines 23a—23b can di- rectly access the various privileged registers that con- trol the operation of hardware structure 21. Rather, all privileged instructions will be trapped into VMM 22.

In Figure 2, virtual machine 23a is shown to include a cross compiler 28 for performing initial cross-compilations of application programs. In addition, virtual machine 23b is shown to include an execution module 29 for executing the cross—compiled code of the application programs. The cross-compilations are preferably performed via a permu- tation algorithm, and the results are stored in a permuted instruction pointer table 30. Permuted instruction pointer table 30 includes multiple entries of permutation se- quences. Each of the permutation sequences is associated with a set of cross—compiled code of an application pro- gram. All the permutation sequences within permuted in- struction pointer table 30 are likely to be different from each other, although they are not required to be different from each other. In Figure 2, permuted instruc- tion pointer table 30 is shown to be placed within VMM 22; however, permuted instruction pointer table 30 can also be placed within virtual machine 23a provided that it can also be accessed by virtual machine 23b.

An exemplary method for performing permutations is as fol- lows. First, a subset of instructions n is selected from a group of instructions for the purpose of permutation.

Not all instruction permutations would be equally useful.

For example, permutations of identity instructions would be of no use at all. So certain machine instructions (such as a JUMP instruction) should be identified as critical instructions in order to ensure all critical inv structions will get permuted.

There are several ways to generate permutations. One method is to utilize a hash or encryption based function such that each instruction in a data segment has a differ- H(A1), H(A2),..., H(Ai), where H is the ent mapping, i.e., hash based function, and A is an instruction. The problem with using a hash or encryption based function is that, from a general compilation standpoint, same instructions may have different hashed results. For example, instruction A; and instruction A9 may be the same instruction, but H(Afi does not necessarily equal to H(A9).

Another method is to utilize a different mapping function P(A), where P is the permutation, and A is an instruction, which generates: Pl(A), P2(A), ..., Pn(A). This method yields a more predictable cross—compilation result, since P1(J), where J is the given instruction, should be the same no matter where it appears in code segments.

A permutation sequence dictates the way the subset of in- structions n is to be permuted or transformed. Each permuta- tion sequence can be viewed as an entry having multiple slots, and each slot is to be filled with an instruction number. In order to generate an r”‘permutation sequence, a random number between 0 and n!-l is initially chosen. For example, if the subset of instructions n needed to be permuted is 5 (which means there are 5! = 120 permutation sequences), a random num- ber 101 can be chosen between 0 and 51-1 as the lOl”‘permuta— tion sequence.

The slot position Pos of the first instruction number is indicated by the dividend of the chosen random number r di- as follows: vided by (n—l)!, Pos= ' (n -1)! The remainder of the division replaces the chosen random num- ber r for the determination of the slot position Pos of the subsequent instruction number until all the slots are filled n in the with instruction numbers. For each determination, denominator (n—l)! is decremented by one.

Thus, for the chosen random number 101, the slot position of the first instruction number is 101/(5-1)! = 4, as shown in Figure 3a. The remainder of 101/(5—l)E is 5, and the slot position of the second instruction number is 5/(4-1)! = O, as shown in Figure 3b. The remainder of 5/(4-1)! is 5, and the slot position of the third instruction number is 5/(3- )! = 2, as shown in Figure 3c. The remainder of 5/(3-1)! is 1, and the slot position of the fourth instruction number is 1/(2-1)! = 1, as shown in Figure 3d. The fifth instruc- tion number goes to the remaining open slot position, as depicted in Figure 3e.

The permutation sequence "2543l" (from Figure 3e) is then entered into permuted instruction pointer table 30 (from Figure 2) as an entry for the 10l“‘permutation sequence.

An application program can be permuted according to the 101” permutation sequence into a set of cross—Compiled (from Figure 2). During execu- code via cross compiler 28 tion, the set of cross-compiled code can be executed via execution module 29 (from Figure 2) according to the 101th permutation sequence stored in permuted instruction pointer table 30.

For example, if the five instructions chosen to be per- muted are ADD, SUBTRACT, JUMP, BRANCH and STORE, then each of these instructions is assigned an instruction number ac- cordingly, i.e., instruction number 1 = ADD, instruction number 2 = SUBTRACT, instruction number 3 = JUMP, in- struction number 4 = BRANCH and instruction number : STORE. When the 101” permutation sequence is utilized for performing cross-compilation of an application program within cross compiler 28 of Figure 2, each occurrence of the above—mentioned five instructions within the applica- tion program will be transformed according to the permuta- tion sequence "25431." In other words, each ADD instruc- tion within the application program will be transformed into a SUBTRACT instruction, each SUBTRACT instruction within the application program will be transformed into a STORE instruction, each JUMP instruction within the ap- plication program will be transformed into a BRANCH in- struction, each BRANCH instruction within the application program will be transformed into a JUMP instruction, and each STORE instruction within the application program will be transformed into an ADD instruction. A reversal of the above-mentioned transformation is performed within execution module 29 of Figure 2 during the execution of the cross—compiled code of the application program.

The permutation can be performed in either a static or a dynamic manner. If the permutation is performed in a static manner, then a group of computer systems can be set to use the same permutation sequence. Such practice would be easier for an information technology manager be- cause cross compilation of each application program would be required to be performed only once during installation.

If the permutation is performed in a dynamic manner, there are several choices. A set of permutation sequences can be changed periodically. Cross compilation for those permutations can be performed once, and then each time a computer system boots, it can run a different set of cross compiled programs, based on the permutation sequence actu- ally in use. Further, the permutation sequence can ran- domly change each time the computer system boots. In such a case, cross compilation would have to be done "on the fly" by a cross compiler running on the computer system.

In addition, the permutation sequence can also be changed for each application program, and it can be accom- plished by different methods. The simplest implementation is to have the VMM use the signature hash of an applica- tion as a key for a streaming encryption algorithm, thereby generating a unique instruction set for that ap- plication program. Any altered application program (such as being altered in a main memory due to a virus that will start generating a dif- causes a buffer overflow) ferent instruction set.

Alternatively, the VMM can generate a random number each time an application program is being loaded, and the code segments of the application program are run through (since it does not need an streaming encryption, or hash to be reversible) engine to change the cross compilation.

This method provides an additional level of security in a constant function that the Pn(A) function becomes P(A) and remains unpredictable.

As has been described, the present invention provides a method for preventing malicious software from execution within a computer system. If the VMM keeps a permutation associated with the hash of each permuted application that is to be run, then even a sampling attack (where a sample permuted application is somehow obtained by an attacker, and the permutation determined, applied to a virus, and then sent to perform an infection) fails.

It is also important to note that although the present in- vention has been described in the context of a fully func- tional computer system, those skilled in the art will ap- preciate that the mechanisms of the present invention are capable of being distributed as a program product in a va- riety of forms, and that the present invention applies equally regardless of the particular type of signal bear- ing media utilized to actually carry out the distribution.

Examples of signal bearing media include, without limita- tion, recordable type media such as floppy disks or com- pact discs and transmission type media such as analog or digital communications links.

While the invention has been particularly shown and de- scribed with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without de- parting from the spirit and scope of the invention.

Claims (1)

1. CLAIMS What is claimed is: 1.A method for preventing malicious software from execu- tion within a computer system, said method comprising: performing a permutation on a subset of instructions within an application program to yield a permuted se- quence of instructions before any actual execution of said application program on said computer system; storing a permutation sequence number of said per- muted sequence of instructions in a permuted instruc- tion pointer table; and executing said permuted sequence of instructions in an execution module that is capable of translating said per- muted sequence of instructions to an actual machine code of a processor within said computer system according to said permutation sequence number of said permuted se- quence of instructions stored in said permuted instruc- tion pointer table. The method of Claim 1, wherein said application program can be executed in a computer system without being cross- compiled. The method of Claim 1, wherein said method further in- cludes providing a first virtual machine to perform said permutation; and providing a second virtual machine to perform said executing. The method of Claim 3, wherein said method further in- cludes providing a virtual memory manager within said com- puter system for controlling said first and second virtual l6 machines. The method of Claim 3, wherein said method further includes placing said first and second virtual machines in separate partitions. The method of Claim 3, wherein said method further in- cludes providing different operating systems in said first and second virtual machines. . A computer usable medium having a computer program prod- uct for preventing malicious software from execution within a computer system, said computer usable medium comprising: program code means for performing a permutation on a sub- set of instructions within an application program to yield a permuted sequence of instructions before any actual exe- cution of said application program on said computer sys- tem; program code means for storing a permutation sequence number of said permuted sequence of instructions in a per- muted instruction pointer table; and program code means for executing said permuted sequence of instructions in an execution module that is capable of translating said permuted sequence of instructions to an actual machine code of a processor within said computer system according to said permutation sequence number of said permuted sequence of instructions stored in said per- muted instruction pointer table. The computer usable medium of Claim 7, wherein said appli- cation program can be executed in a computer system without being cross—compi1ed. 10 ll 17 The computer usable medium of Claim 7, wherein said com- puter usable medium further includes program code means for providing a first virtual machine to contain said program code means for performing said permutation; and program code means for providing a second virtual machine to contain said program code means for executing. .The computer usable medium of Claim 9, wherein said com- puter usable medium further includes program code means for providing a virtual memory manager within said computer system for controlling said first and second virtual ma- chines. .The computer usable medium of Claim 9, wherein said com- puter usable medium further includes program code means for placing said first and second virtual machines in separate partitions. .The computer usable medium of Claim 9, wherein said com- puter usable medium further includes program code means for providing different operating systems in said first and sec- ond virtual machines. .A computer system capable of preventing malicious soft- ware from being executed, said computer system compris- ing: means for performing a permutation on a subset of in- structions within an application program to yield a per- muted sequence of instructions before any actual execu- tion of said application program on said computer sys- tem; a permuted instruction pointer table for storing a 14 15. l6. l7. permutation sequence number of said permuted sequence of instructions; and means for executing said permuted sequence of instruc- tions in an execution module that is capable of trans- lating said permuted sequence of instructions to an ac- tual machine code of a processor within said computer system according to said permutation sequence number of said permuted sequence of instructions stored in said permuted instruction pointer table. .The computer system of Claim 13, wherein said appli- cation program can be executed in a computer system without being cross-compiled. The computer system of Claim 13, wherein said computer system further includes; a first virtual machine to contain said means for per- forming a permutation; and a second virtual machine to contain said means for executing. The computer system of Claim 15, wherein said computer system further includes a virtual memory manager for controlling said first and second virtual machines. The computer system of Claim 15, wherein said first and second virtual machines are located in separate parti- tions. .The computer system of Claim 15, wherein an operating system within said first virtual machine is different an operating system within said second virtual machine. 19 19.The method according to Claim 1, wherein the permutation 20. 21. 22. 23. 24. comprises cross-compiling and wherein an application pro- gram is cross—compiled to yield a set of cross—compiled code of said application program before any actual execution of said application program on said computer system; and said set of cross—compiled code of said application program is executed in an execution module that is capable of rec- ognizing and translating said set of cross—compiled code of said application program to an actual machine code of a processor within said computer system. The method of Claim 19, wherein said method further in- cludes: providing a first virtual machine to perform said cross- compiling; and providing a second virtual machine to perform said execut- ing. The method of Claim 20, wherein said method further in- cludes providing a Virtual memory manager within said com- puter system for controlling said first and second virtual machines. The method of Claim 20, wherein said method further in- cludes placing said first and second virtual machines in separate partitions. The method of Claim 20, wherein said method further in- cludes providing different operating systems in said first and second virtual machines. The computer usable medium according to claim 7, wherein 20 the permutation comprises cross-compiling and the computer usable medium comprises program code means for cross-compiling an application pro- gram to yield a set of cross—compiled code of said appli- 5 cation program before any actual execution of said appli- cation program on said computer system; and program code means for executing said set of cross—compiled code of said application program in an execution module that is capable of recognizing and translating said set of 10 cross—compiled code of said application program to an ac- tual machine code of a processor within said computer sys- tem. 25. The computer usable medium of Claim 24, wherein said com- l5 puter usable medium further includes: program code means for providing a first virtual machine to contain said program code means for cross-compiling; and program code means for providing a second virtual machine 20 to contain said program code means for executing. 26. The computer usable medium of Claim 25, wherein said com- puter usable medium further includes program code means for providing a virtual memory manager within said computer 25 system for controlling said first and second virtual ma- chines. 27. The computer usable medium of Claim 25, wherein said com- puter usable medium further includes program code means for 30 placing said first and second virtual machines in separate partitions. 28. The computer usable medium of Claim 25, wherein said com- 29. 30. 31. 32. 33. 21 puter usable medium further includes program code means for providing different operating systems in said first and second virtual machines. The computer system according to claim 13, wherein the permutation comprises cross-compiling and said computer system comprises: means for cross-compiling an application program to yield a set of cross-compiled code of said application program be- fore any actual execution of said application program on said computer system; and means for executing said set of cross-compiled code of said application program in an execution module that is capable of recognizing and translating said set of cross- compiled code of said application program to an actual ma- chine code of a processor within said computer system. The computer system of Claim 29, wherein said computer system further includes a first virtual machine to contain said means for cross-compiling; and a second virtual machine to contain said means for execut- ing. The computer system of Claim 30, wherein said computer system further includes a virtual memory manager for con- trolling said first and second virtual machines. The computer system of Claim 30, wherein said first and second virtual machines are located in separate parti- tions. The computer system of Claim 30, wherein an operating 34. 22 system within said first virtual machine is different an operating system within said second virtual machine. A method for preventing malicious software from execution within a computer system, substantially as described herein with reference to the accompanying drawings. 35. A computer usable medium having a computer program prod- uct for preventing malicious software from execution within a computer system, substantially as described herein with reference to the accompanying drawings. 36. A computer system adapted to prevent malicious software from being executed, substantially as described herein with reference to the accompanying drawings.