Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

A method for preventing the unauthorized modification of a software or
unauthorized modification of runtime data. According to this method, a
converter, which is capable of converting the software into a generalized
machine code is provided. The converter is designed such that it cannot
be reverse engineered, by using a conversion process that causes data
loss. An interpreter, which the knowledge of its process method is kept
restricted, is also provided. The interpreter interprets the general
machine code into a specific machine code, while reconstructing the lost
data during the interpretation process.

Claims:

1. A method for preventing the unauthorized modification of a software or
unauthorized modification of runtime data comprising the steps of:a.
Providing a converter, capable of converting said software into a
generalized machine code, that cannot be reversed engineered, by using a
conversion process that causes data loss andb. Providing an interpreter,
which the knowledge of its process method is kept restricted,c.
Interpreting, by said interpreter, said general machine code into a
specific machine code while reconstructing the lost data during the
interpretation process.

2. A method according to claim 1, where the interpreter is compiled by a
CLR.

3. A method according to claim 1, where the software is divided such that
only part of the software is converted with the converter and interpreted
by the interpreter.

4. A method according to claim 1, where the software is a high level
language.

5. A method according to claim 4, where the high level language is an
interpreter based language;

6. A method according to claim 5, where the high level language may be
anyone of the following: Java, Visual J#, J#, C#, or VB.NET.

7. A method according to claim 4, where the high level language is a
compiler based language;

8. A method according to claim 7, where the high level language may be
anyone of the following: C++, VB, or Pascal.

9. A method according to claim 1, where the data loss during conversion is
the removal of code structure metadata.

10. A method according to claim 1, where the data loss during conversion
is the conversion of instructions to other instructions which their
corresponding operand(s) is determined during runtime.

11. A method for preventing the decompilation and runtime modification of
a .NET/CLI software code using tools that rely on .NET/CLI metadata,
comprising:a. Providing a converter, capable of converting said .NET/CLI
software code into a general machine code, where said conversion involves
data loss of .NET/CLI metadata;b. Providing a new interpreter capable of
interpreting said general machine code without requiring .NET/CLI
metadata, where said new interpreter is implemented as .NET/CLI based
software component for maintaining the same level of portability as said
.NET/CLI software code; andc. interpreting said general machine code into
a specific machine code, by said interpreter.

12. A method according to claim 11, where the software is divided such
that only part of the software is converted with the converter and
interpreted by the new interpreter.

13. A method for preventing the tampering of a software license terms
enforcement mechanism in a .NET/CLI environment according to claim 11,
where the decompilation and modification tools that rely on .NET/CLI
metadata become unusable after applying said method.

14. A method according to claim 11, for encrypting a .NET/CLI code while
overcoming lack of code encryption/decryption support in .NET CLR by
performing a partial decryption to presently executed function,
comprising:a. applying a symmetric encryption process on the general
machine code representation of each converted function; andb. decrypting
each general machine code function before execution by the new
interpreter.

15. A method according to claim 14, where the symmetric encryption process
key is delivered to the software user separately, thereby making
unauthorized execution of software impossible.

16. A method according to claim 11, where different implementations of the
new interpreter are provided to software vendors, where said new
interpreter is formed by choosing a complete instruction subset out of a
redundant instruction set, and by dynamically generating a converter and
said new interpreter implementation .NET/CLI assembly using .NET
Framework System.CodeDom API, System.RefLection.Emit API, or direct .NET
language source code generation.

17. A method according to claim 11, where the different implementations of
the new interpreter are provided to software vendors, by applying
obfuscation process with different metadata renaming schemes on the same
base .NET/CLI implementation of said new interpreter, for making said
metadata appear differently in decompilation tools.

18. A method according to claim 17, where the new interpreter is formed by
choosing a complete instruction subset out of a redundant instruction
set, and by dynamically generating a converter and said new interpreter
implementation .NET/CLI assembly using .NET Framework System.CodeDom API,
System.Reflection.Emit API, or direct .NET language source code
generation, and by applying obfuscation process with different metadata
renaming schemes on the same base .NET/CLI implementation of said new
interpreter, for making said metadata appear differently in decompilation
tools.

19. A method for preventing the decompilation and runtime modification of
Java software code using tools that rely on Java class metadata,
comprising:a. Providing a converter capable of converting said Java
software code into a general machine code, where said conversion involves
data loss of Java metadata;b. Providing a new interpreter capable of
interpreting said general machine code without requiring Java class
metadata, where said new interpreter is implemented as Java based
software component for maintaining the same level of portability as said
Java software code software; andc. Interpreting, by said interpreter,
said general machine code into a specific machine code.

20. A method according to claim 19, where the software is divided such
that only part of the software is converted with the converter and
interpreted by the new interpreter.

21. A method for preventing the tampering of a software license terms a
enforcement mechanism in a Java environment according to claim 11, where
the decompilation and modification tools that rely on .NET/CLI metadata
become unusable after applying said method.

22. A method according to claim 19, for encrypting a Java code while
overcoming lack of code encryption/decryption support in Java VM by
performing a partial decryption to presently executed function,
comprising:a. Applying a symmetric encryption process on the general
machine code representation of each converted function; andb. Decrypting
each general machine code function before execution by the new
interpreter.

23. A method according to claim 22, where the symmetric encryption process
key is delivered to the software user separately, for making unauthorized
execution of software impossible.

24. A method according to claim 19, where different implementations of the
new interpreter are provided to software vendors, where said new
interpreter is formed by choosing a complete instruction subset out of a
redundant instruction set, and by dynamically generating a converter and
said new interpreter implementation.

25. A method according to claim 19, where the different implementations of
the new interpreter are provided to software vendors, by applying
obfuscation process with different metadata renaming schemes on the same
base Java implementation of said new interpreter, for making said
metadata appear differently in decompilation tools.

26. A method according to claim 25, where the new interpreter is formed by
choosing a complete instruction subset out of a redundant instruction
set, and by dynamically generating a converter and said new interpreter
implementation, and by applying obfuscation process with different
metadata renaming schemes on the same base implementation of said new
interpreter, for making said metadata appear differently in decompilation
tools.

27. A method according to claim 11, wherein the use of instrumentation
tools that rely on .NET/CLI metadata for tampering a software license
terms enforcement mechanisms is prevented by using new interpreter
architecture to perform calls between converted methods.

28. A method according to claim 19, wherein the use of instrumentation
tools that rely on Java class metadata for tampering a software license
terms enforcement mechanisms is prevented by using new interpreter
architecture to perform calls between converted methods.

Description:

FIELD OF THE INVENTION

[0001]The present invention relates to the field of computer software
protection. More particularly, the invention relates to a method for
protecting computer software from reverse engineering, unauthorized
modification, and runtime data interception.

BACKGROUND OF THE INVENTION

[0002]Many attempts have been made in the recent years to protect original
computer software from duplication and mass distribution. One of the
methods used today involves the requirement of a license or a sequence
key, which is entered manually by the customer, during installation or
during run time. Another popular method for preventing duplicate usage of
software involves the activation of the software after installation. The
activation process requires the software to read ID serial numbers of
hardware elements in the computer, such as the processor's serial number
or graphics card's serial number. Once the hardware ID serial numbers are
read, they may be sent together with the software ID number through the
Internet to the vendor. The vendor stores the ID numbers and sends a
license code to the program through the Internet. The software may be
programmed to cease proper function without a verified license code from
the vendor. In this case, if the software is illegally copied and
installed on a different computer, the software cannot be activated since
the software license is already associated with the hardware of the first
installation and the license code can only be sent to the computer having
the same hardware profiles stored by the vendor. However, these methods
do not prevent an unauthorized party from reverse engineering the
software code, modifying it to exclude these software protection tools,
and mass distributing the modified software.

[0003]Many tools are in use today for software reverse engineering, like
the hexadecimal dumper, which prints or displays the binary numbers of a
software code in hexadecimal format. By knowing the bit patterns that
represent these instructions, as well as the instruction lengths, a
person who wishes to reverse engineer the software can identify certain
portions of a code to see how they work, and then modify them. Another
common tool for reverse engineering and code modification is the
disassembler. The disassembler reads the binary code and then displays
each executable instruction in a textual format. Also, since the
disassembler cannot tell the difference between an executable instruction
and the data used by the code, a debugger may be used. The debugger
allows the disassembler to avoid disassembling the data portions of a
code. For example, if the dissembler reads a command "ADD_INT8", which
means: "add the number depicted in the next 8 bits", the debugger
processes the next 8 bits as the data portion of the command "ADD_INT8",
and the next group of bits is processed as a new command. However, these
tools relay on the publicized knowledge of how the instructions code is
built, where the information resides in the memory, which registers are
used, and how the stack (a data buffer used for storing requests that
need to be handled, in the form of a push-down list) is used.

[0004]The problem of reverse engineering and code modification by
unauthorized users is even more apparent when dealing with
interpreter-based programming languages, as opposed to compiler based
programming languages. A description of compiler-based programming
language can be found in FIG. 1, which generally illustrates the prior
art software process of compiler-based programming languages, such as C
or Pascal. When a programmer programs in a high-level language using an
editor or the like, his code's instructions 10, or source code, cannot be
read directly by the computer's hardware. Therefore, the source code 10
has to undergo a translation process known as compilation by compiler 11.
Compiler 11 compiles source code 10 into a specific Machine Code (MC) 12,
which the computer's hardware is able to read and execute. Since the MC
12 is specifically compiled to a certain platform, it cannot be
transferred from one platform to another. In the compiler-based
programming languages the source code 10 is compiled for each platform
individually, producing a different specific MC 12 for each platform. An
example of different platforms may be an Intel® based PC with
Windows® XP and Mac® OS X.

[0005]A description of interpreter-based programming language can be found
in FIG. 2a which is a flow chart, generally illustrating the prior art
software process of interpreter-based programming languages, such as
JAVA. Similar to the compiler based programming languages, the
interpreter based languages are written in high level language, using an
editor or the like, referred to hereinafter as source statements 20.
However, according to this approach, the compiler 21 translates the high
level source statements 20 to a Byte Code (BC) 22 which is a generalized
MC not limited to a certain platform. Nevertheless, in order to execute
the BC 22, a specific interpreter 23 is needed to translate BC 22 into
specific MC 24. The specific interpreter 23 is usually installed along
with the operating system. The main advantage of this approach is that BC
22 may be distributed for different platforms. Once BC 22 is executed on
a certain platform, the specific interpreter 23 translates only one BC 22
instruction at a time, producing a specific MC 24 instruction for the
computer hardware to execute. However, since the interpreter method of
processing is a common knowledge, it is fairly easy to read, understand,
and modify the BC 22 which is an instruction set for interpreter 23. A
hacker may buy a legal copy of a code written in BC, decipher its
instructions and erase or modify some of the original instructions of the
BC. Once the BC has been modified, it can be mass copied and resold.

[0006]Another method used by hackers is known in the art as "runtime data
interception". By intercepting and reading the data flow during the
execution of a legal program by the interpreter, the hacker can simulate
the process when executing an illegal program.

[0007]One method for preventing easy understanding and deciphering of the
code behavior utilizes encryption of the code, as described in US
2004/0015710. According to this approach, the encrypted code is sold with
a decryption key for decrypting the code. Each instruction in the code is
first decrypted and interpreted by an interpreter for execution by the
processor. However, once the code has been decrypted, a hacker may read
the decrypted code to reverse engineer the original code. Furthermore,
the decryption process may be monitored by a user for formulating the
decryption key. In addition, once the code is decrypted, it is loaded
unprotected into the memory of the computer and may be copied from there,
as well.

[0008]Another method for preventing modification of a software code is
splitting the code into 2 parts, a sensitive part comprising the code
protection, and a less sensitive part. The less sensitive part of the
code is sold to the user, as before, ready for interpretation, whereas
the sensitive part of the code is stored on hardware products, such as
smart-cards. The interpretation of the sensitive part of the code is done
in hardware, such as a smart-card reader, where it cannot be monitored or
read. However, in some of the cases, the additional hardware may be
expensive, and redistribution of code updates generated by the provider
is complicated.

[0009]A method for preventing modification of a software code is described
in a paper by Enriquillo Valdez and Moti Yung "DISSECT: Distribution for
SECurity Tool" (G. I. Davida and Y. rankel (Eds.):ISC 2001, LNCS 2200,
pp. 125-143, 2001. Springer-Verlag Berlin Heidelberg 2001). The method
suggests splitting the code into 2 parts, a sensitive part and a less
sensitive part. The less sensitive part of the code is sold to the user,
as before, ready for interpretation, whereas the sensitive part of the
code is stored on a secured server. The interpretation of the sensitive
part of the code is done on a secured server, where it cannot be
monitored or read. However, this approach requires maintaining a direct
contact to the designated server for executing the code.

[0010]It is therefore an object of the present invention to provide an
inexpensive method for preventing software reverse engineering,
unauthorized modification, and runtime data interception.

[0011]It is another object of the present invention to provide a method
for preventing unauthorized modification of software, without needing
additional hardware.

[0012]It is still another object of the present invention to provide a
method that on one hand, prevents any modification by an unauthorized
user and on the other hand, allows modification and update by the vendor.

[0013]Other objects and advantages of the invention will become apparent
as the description proceeds.

SUMMARY OF THE INVENTION

[0014]The present invention is directed to a method for preventing the
unauthorized modification of a software or unauthorized modification of
runtime data. A converter, capable of converting the software into a
generalized machine code that cannot be reversed engineered, by using a
conversion process that causes data loss and an interpreter that may be
compiled by a CLR, are provided. The knowledge of the interpreter's
process method is kept restricted. The general machine code is
interpreted by the interpreter into a specific machine.

[0015]The software may be a high level language (e.g., Java, Visual J#,
J#, C#, or VB.NET or a compiler based language, e.g., C++, VB, or
Pascal), such as an interpreter based language, and may be divided such
that only part of the software is converted with the converter and
interpreted by the interpreter.

[0016]The data loss during conversion may be the removal of code structure
metadata or the conversion of instructions to other instructions which
their corresponding operand(s) is determined during runtime.

[0021]FIG. 3 is a flow chart generally illustrating the prior art software
process of programming languages of .NET, such as Visual J#;

[0022]FIG. 4 is a flow chart generally illustrating the implementation of
the invention according to one of the embodiments;

[0023]FIG. 5 is a block diagram illustrating one of the embodiments of the
invention;

[0024]FIG. 6 is a flow chart generally illustrating the implementation of
the invention according to another embodiment of the invention; and

[0025]FIG. 7 is a flow chart generally illustrating the implementation of
the invention according to one of the embodiments, for compiler based
programming languages.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0026]For the sake of brevity, the following terms are defined explicitly:
[0027]A platform is the computer's operating system which is built on
the instruction set for the computer's processor, the hardware that
performs logic operations and manages data movement in the computer.
[0028]Machine Code (MC) is the code which can be read and executed
directly by the computer's processor. [0029]Specific Machine Code is the
code which can only be read and executed by a specific platform, or a
number of specified platforms. [0030]Generalized Machine Code is the code
which is not limited to a specific platform. [0031]A compiler converts a
set of instructions into a machine code.

Description of Well Known Processes

[0032]FIG. 2b is a flow chart generally illustrating the prior art
software process of interpreter based programming languages, such as
JAVA. Similar to the compiler based programming languages, the
interpreter based languages are written in high level language, using an
editor or the like, referred to hereinafter as source statements 200.
According to this approach, the compiler 210 translates the high level
source statements 200 to a Byte Code (BC) 220, which is a generalized MC
that is not limited to a certain platform. Nevertheless, in order to
execute the BC 220, a specific interpreter 230 is needed to translate BC
220 into a specific MC 240. The specific interpreter 230 is usually
installed along with the operating system. The main advantage of this
approach is that BC 220 may be distributed for different platforms. Once
BC 220 is executed on a certain platform, the specific interpreter 230
translates one BC command at a time, thereby producing a specific MC
command for the computer hardware to execute. When dealing with Sun
Microsystems® Java, BC 220 is called Java Byte Code and the
interpreter 230 is called a Virtual Machine (VM). In some cases, the VM
comes together with a Just-in-time compiler 250 and is used optionally.
The Just-in-time compiler 250 compiles Java BC 220 into a specific MC 260
as if the program had been compiled initially for that specific program.
In both cases of VM 230 and Just-in-time compiler 250, the computer
hardware reads its intended specific MC. However, since interpreter 230
translates one BC 220 command at a time during execution, it may run
slower on the computer.

[0033]The Java VM, which operates as an interpreter between Java BC and a
specific MC, is individual for each platform. Once a Java VM has been
provided for a platform, any compiled Java BC may be run on that
platform. Therefore, when a user has a Java VM installed on his computer,
he may acquire any program in Java BC, and execute it on his computer.
When a programmer programs in Java and compiles the program into a Java
BC, he may distribute the Java BC widely to any user, as the Java BC is
compatible for all popular platforms. The Java VM is responsible for
allocating memory, setting registers, stack, "garbage" heap, and method
area (method area of a Java VM is a logical area of memory which stores
all the information about the loaded types), for the program execution.

[0034]FIG. 3 is a flow chart generally illustrating the prior art software
process of programming languages which are designed to run on
Microsofte®.NET, such as Visual J#. Generally speaking, the .NET
environment allows the use of the Web resources rather than the computer
resources for various services. Visual J# or J# allows programmers to
program in "similar to Java" language and run the program on .NET. The
source statements 300, written in Visual J# high level language, are
compiled by compiler 310 into Microsoft Intermediate Language (MSIL) 320,
which is a general MC that is not limited to a specific platform. The
MSIL 320 is equivalent to the Java BC 220 in its functions, and the Java
BC 220 can even be converted easily to MSIL 320. Similar to the process
described above, the MSIL 320 is converted to a specific MC 340 using
Common Language Runtime (CLR) 330, which is equivalent to the function of
JAVA VM 230. As understood., other .NET programming languages such as C#
and VB.NET undergo a similar process from sources statements 300 to MSIL
320 to specific MC 340.

[0035]It should be noted that the memory allocations of the described VM
and CLR is widely known to hackers, such as the setting of the registers,
stack, "garbage" heap, and method area of the program. Using this
information, the hacker can understand which commands of the Java BC or
MSIL refer to the requirement of license and modify these commands.

[0036]A .NET metadata in the Microsoft .NET framework describes the .NET
CIL (Common Intermediate Language) code. A .NET language compiler will
generate the metadata and store this in the assembly containing the CIL.
The metadata describes all classes and class members that are defined in
the assembly, and the classes and class members that the current assembly
will call from another assembly. The metadata for a method contains the
complete description of the method, including the class (and the assembly
that contains the class), the return type and all of the method
parameters. When the CLR executes CIL, it verifies that the metadata of
the called method is the same as the metadata that is stored in the
calling method. This ensures that a method can only be called with
exactly the right number of parameters and exactly the right parameter
types. Therefore, in environments like .NET and Java it is easier to
reverse engineer the code as the code and metadata are provided together
as part of the redistributable package. The metadata is necessary for
Just-In-Time compilation of code to the target platform. However, in
compiler-based languages such as C++, the metadata is dropped during the
compilation and link stages and it is not redistributed to end users.

General Description of the Invention

[0037]The essence of the invention is an interpreter, which its method of
operation and memory allocations are unpublicized. The new unrevealed
interpreter or "Secret VM", is referred to hereinafter as SVM. Each SVM
is paired with a correlated converter, or in other words, each SVM may
only interpret a code that has been produced by a correlated converter.
Therefore, each vendor of original software that requires software
protection may purchase an exclusive correlated pair of converter and
SVM. The methods of operation, such as instruction encoding or memory
allocations, may vary between different SVMs.

[0038]FIG. 4 illustrates an implementation of the invention according to
one of the embodiments, where the source statements 400 are written in
high level programming language of .NET. Compiler 410 compiles source
statements 400 into MSIL 420 as described in the prior art. At this
point, converter 421 is used to convert MSIL 420 into a Secret Virtual
Machine Language (SVML) 422. The SVML 422 is a general MC, not limited to
a certain platform. However, the commands of the SVML 422 are different
from the known general MCs commands such as the Java BC or MSIL 420
commands. Therefore, deciphering of the SVML 422 is exceptionally
complicated, since no known disassembler or debugger exists for SVML 422.
The SVML 422 may be distributed together with the corresponding SVM 423.
The SVM 423 is compiled on the designated computer using the local CLR
430 for adding the data concerning the Specific platform of the
designated computer. Since the SVM 423 performs as an interpreter, it
comprises not only new data for interpreting SVML 422, but also data
concerning the platform profile from CLR 430. Thus, when SVML 422 is
executed on the designated computer, SVM 423 interprets each command to
the hardware for execution. Since the SVM 423 method of processing is
unknown, a hacker will find it difficult to understand and modify the
code, or to try intercepting the data during runtime.

General Description of the Proposed Converter's Attributes

[0039]One of the designated attribute of the converter involves the
producing of different SVML programs for the same MSIL input (otherwise
known as "code morphing"). The code morphing relies on a redundancy in
the SVML instruction set, for example, SUB instruction can be replaced by
NEG and ADD instructions. This attribute is mostly effective for
preventing attempts to compare the MSIL instructions set with the
equivalent SVML instructions set. This attribute relies on a redundancy
in the SVML instruction set, for example, SUB instruction can be replaced
by NEG and ADD instructions.

[0040]I. Another designed attribute of the converter is the possibility of
dynamic encoding of instructions, meaning the changing of corresponding
bit pattern, or code, of a certain instruction. As opposed to the MSIL,
where same instructions are expected to be encoded similarly, in SVML the
same instruction may appear in different codes. For example, the
instruction may be encoded with its address as shown in the following
tables:

[0041]Therefore, even if a hacker might try to find repeating patterns in
an SVML code to deduce common instructions, he will find it more
complicated than assumed.

[0042]II. The main designed attribute of the converter is the causing of
data loss during conversion for making the conversion process practically
irreversible. One example of data loss is the removal of code structure
metadata, such as method declarations, since in .NET it is not required
when a method is called only by other transformed methods. Additional
example of data loss is the following: a widely known instruction set
comprises the following instructions: ADD_INT8, ADD_INT16, and ADD_INT32.
These instructions instruct the processor to add the numbers of 8, 16, or
32 bits accordingly. During the process of conversion, using the unique
converter, all these instructions are converted to open instructions
"ADD". The type of operand and number of bits, which should be added (8,
16, or 32) is determined during runtime. Therefore, reverse compilation
is impossible without knowing the number for adding in the "ADD"
instruction. Since the conversion process is irreversible, the code
cannot be converted back to a standard MSIL/Java BC format, and therefore
it cannot be decompiled, disassembled, debugged or modified using
standard tools.

Example of SVM Architecture and Corresponding SVML Instruction Set

[0043]FIG. 5 is a block diagram illustrating an example of SVM
architecture, according to one of the embodiments. Arithmetic Logic Unit
500 performs the logic operations on operand registers 510 and 520, and
stores the result in register 530. Data transfer register 560 is used for
transferring data between registers and Memory Banks 540 and 550. Memory
Banks 540 and 550 are used for storing local variables and method
parameters. The bank selector register 570 stores the number of Memory
Bank in use.

[0044]An example of a subset of instructions of SVML and their meaning:

[0045]For the sake of brevity a non limitative example is shown herein
below comparing an assembly program code of prior art general MC to that
of the SVML. In both cases, the given task required processing the
equation 4+3-1.

[0048]As shown in the program code above, the processed operands (4, 3,
and 1) are never depicted explicitly in the instructions. A hacker trying
to reverse engineer the program cannot deduct from the present set of
instructions what are the values of operands in the equation, as each
value is read from memory during runtime.

Additional Embodiments of the Invention

[0049]In one of the embodiments, each vendor is equipped with his own pair
of converter and SVM. Therefore, knowing the method of process of one SVM
does not reveal the method of process of other SVMs.

[0050]The method proposed by the present invention may be used with any
interpreter based language. For example, for J# of .NET the SVM is
compiled by the CLR, for JAVA the SVM is compiled by the VM, and so on.
The proposed invention may be used for any software whether a high level
language such as C# or VB.NET, a software code, a source code or a
machine code.

[0051]FIG. 6 illustrates an example of another embodiment of the
invention, where the source statements 500 are written in high level
language, such as Visual J#. Compiler 410 compiles source statements 400
into MSIL 420 as described before. However, before conversion, the MSIL
420 instructions are divided into two groups, sensitive instructions,
which may include the license requirements, and insensitive instructions.
The sensitive instructions are converted by converter 421 into SVML 422,
whereas the insensitive instructions are not converted. The general MC
425, or program, which consists of a part MSIL and a part SVML, may be
distributed together with the corresponding SVM 423 to any popular
platform. In order to execute the program, SVM 423 is compiled by CLR 430
on the designated platform. During execution, each instruction is
examined for compatibility with MSIL 420 or SVML 422. The MSIL 420
instructions are interpreted directly by CLR 430, whereas SVML 422
instructions are interpreted by SVM 423.

[0052]FIG. 7 illustrates an implementation of the invention, according to
one of the embodiments, for compiler based programming languages. As
described in the background, the source code 700 is compiled by compiler
710 into specific MC 720. The specific MC 720 is converted using a
designated converter 721 into an SVML 722, where the SVML 722 is platform
dependant, or in other words it is a specific MC. The SVML 722 is
distributed with an SVM 723 designed for the specific platform of the
SVML 722. Since the distributed SVM 723 is already specified for a
designated platform, it does not require compilation on the designated
computer. Therefore, the SVM 723 is capable of translating the SVML 722
into specific MC 740, for the hardware of designated computer.

[0053]In another embodiment for compiler based programming languages, only
the sensitive instructions are converted by converter 721 into SVML 722.
The SVML 722 is distributed with the SVM 723 and the remaining
instructions of specific MC 720. During execution the SVM 723 executes
the instructions of the SVML 722.

[0054]While some embodiments of the invention have been described by way
of illustration, it will be apparent that the invention can be carried
into practice with many modifications, variations and adaptations, and
with the use of numerous equivalents or alternative solutions that are
within the scope of persons skilled in the art, without departing from
the spirit of the invention or exceeding the scope of the claims.