BACKGROUND
|0001| Despite huge efforts by software providers, software protection mechanisms are still
broken on a regular basis, further, a successful attack on one copy can often be replicated automatically on other copies. For example, if a software provider distributes evaluation versions of a piece of software, a crack that removes the time limitation from one copy can be applied to all other distributed copies as well. Yet further, conventional distribution models can allow for serial attacks that quickly affect thousands of users.
|0002] Diversification is a concept that can be used to enhance software security and
confound attack. However, diversification techniques developed for software security are not always transferable to software protection as different rules can apply. For example, most of the run-time diversification introduced for security could easily be turned off when an attacker has physical access to the program and execution environment,
|0003| As described herein, various diversity techniques for software protection provide
renewable defenses in space and in time, for example, by giving every user a different copy and renewing defenses with tailored updates.
SUMMARY
(00041 Various exemplary techniques use virtualization for diversifying code and/or virtual
machines (VMs) to thereby enhance software security. For example, a computer-implementable method includes providing an instruction set architecture (ISA) that comprises features to generate diverse copies of a program, using the instruction set architecture to generate diverse copies of a program and providing a VM for execution of one of the diverse copies of the program. Various other exemplary technologies are also disclosed.
DRAWINGS
|0005| Non-limiting and non-exhaustive examples are described with reference to the
following figures:
|0006| Fig. 1 is a diagram of a system and an overall architecture that includes a
\irtuali/ation layer as a custom/modified instruction set architecture (ISA) and/or a virtual machine
(VM);

[OOOTj Fig, 2 is a block diagram of an exemplary method that includes a security module to
generate custom code and/or a custom VM;
|0008| Fig. 3 is a block diagram of an exemplary method for generating a custom VM.
|0009| Fig. 4 is a block diagram of an exemplary method for diversifying functions in code
to generate custom code;
|0010] Fig. 5 is a diagram of an example that relates to Ihe method of Fig. 4;
|00I1| I'ig. 6 is a block diagram of an exemplary method for diversifying data and/or data
structure.
j0012| Fig, 7 is a block diagram of various framework characteristics that can be used for
diversification and lamper-resistance.
(0013| Fig. 8 is a diagram of an execution model with characteristics that can be used for
diversification and tamper-resistance.
|0014| Fig. 9 is a block diagram of various approaches that can be applied to instruction
semantics ibr purposes of diversification and tamper-resistance.
|00I5] Fig. 10 is a block diagram of various approaches that can be applied to instruction
encoding Ibr purposes ol'diversification and tamper-resistance.
|0016| Fig. 11 is a block diagram of various approaches that can be applied to a fetch cycle
for purposes of diversification and tamper-resistance.
|(l()17] Fig. 12 is a block diagram of various approaches that can be applied to a program
counter (PC) and/or program representation for purposes of diversification.
[0018| Fig. 13 is a diagram of an example of a code fragment in a splay tree, for purposes
of diversified tamper-resistance,
|0019| Fig. 14 is a block diagram of various approaches that can be applied to
implcmenlation of a virtual machine (VM) for purposes of diversification.
|0020) Fig. 15 is a block diagram of an exemplary computing device,
DF:TA1LF;D DKSCRIP'IION Overview
[00211 Exemplary techniques use software-based security for code that executes on a virtual
machine or other machine thai can be controlled (e.g., operaied in a particular manner). Various examples modify code, modifv data and/or modify virtual machine operation in a cooperative manner to enhance security. For example, features associated with code can be identified and used to diversify instances of the code. Various examples include use of a custom or modified Insiruction Set Architecture (ISA) that is emulated on top of an existing architecture or modified

architecture. Where the existing architecture includes a virtualization layer (e.g., a virtual machine or runtime engine or simply "runtime"), an exemplary approach may add another virtualization layer on top of the existing virtualization layer. Implementation of various techniques may occur through use of a custom virtual machine that operates on top of an underlying virtual machine or through use of a modified virtual machine {e.g., modification of an underlying virtual machine). For increased security at the expense of performance, such a process may be iterated to generate a stack of virtual machines, each of which virtualizes the instruction set of the machine directly underneath.
|0022] With respect to diversification, an analogy may be made to genetic diversity where
common components (e.g., DNA building blocks) are assembled in a variety of manners to thereby enhance diversity of a species. In turn, a malicious agent (e.g., a virus) is unlikely to affect all members of the genetically diverse species. An analogy also exists for some parasites where hundreds of genes may manufacture proteins that are mixed and matched. Such protein diversity helps such a parasite evade immune system detection. However, while genetic diversity in species is often associated with phenotypic diversity (i.e., diversity of expression or manifestation), as described herein, code diversification should not alter a user's experience. In other words, given the same inputs, all instances of a diversified code should execute to produce the same result.
|0023| Consider the following generalized equations:
genotype -^ environment ~-~- phenotype (1)
code/data + machine " result (2)
In llqn. 2, with diversified code and/or data, the machine can be a custom machine or a modified or controlled machine that ensures that the result is substantially the same. Where a virtual machine or virtual machines are used, the underlying hardware and/or operafing system is typically unaffected by the exemplary security approaches described herein; noting, however, that such approaches may increase computational demand.
[0024] As described herein, code diversification increases security by confounding attack.
In addition, code diversity can confound serial attacks as replication of a successful auack on one instance of the code is unlikely to succeed on a "genetically" different instance of the code. Further, data (or datastructurc) may be diversified to increase security. Yet further. excmplar>'

techniques tor diversifying a custom or a modified virtual machine may be used to enhance security with or without code and/or data diversification,
[00251 While various examples focus on generation of individualized bylecodes from MSIL
binaries, various exemplary techniques may be used for programs expressed in any programming language, intermediate language, bytecode or manner.
|(1026] As described herein, the process of virtualizafion (e.g., execution of code on a virtual
machine or virtual environment) facilitates (i) the ability to make many different versions of a program and (ii) the ability to make every instance of a program resilient against attack. Various exemplary techniques use virtualization to emulate a custom Instruction Set Architecture (ISA) on top of a portable, verifiable managed CLR environment. A custom runtime or a modified runtime may be used to emulate the custom ISA^ i.e., in some manner, the underlying runtime must be able 10 manage the diversity introduced via the custom ISA.
|0027I Virtuallzation provides degrees of freedom that can be used in diversification. For
example, an Instruction Set Architecture (ISA) {e.g., and/or micro-architecture) typically includes (1) instruction semantics, (2) instruction encoding, (3) opcode encoding. (4) code representation and a program counter, and (5) a corresponding internal implementation of a virtual machine. Given these degrees of Ireedom, various exemplary methods can generate many diverse copies of a program with any of a variety of protection mechanisms,
|0028| Degrees of freedom associated with an ISA provide for design and selection of
lamper-rcsistant programs. For example, tamper-resistance can be the result of (1) making local modiiications more difficult through (a) variable instruction lengths, (b) limited instruction sets, and encouraging (e) physical and (d) semantic overlap; (2) making global modifications more difficult b> a!! of the previous and blurring the boundaries between code, data and addresses; (3) making instruction semantics variable; and (4) constantly relocating the code.
[0029| More specific examples include (i) randomizing instruction semantics by building
instruciions through the combination of smaller instructions; (ii) choosing instruction semantics to enable increased semantic overlap; (iii) departing from the traditional linear code representation to representing the code as a data structure such as a self-adapting (splay) binary tree; (iv) assigning \ariable lengths to opcodes and operands to complicate disassembly and to make local

modifications more diflicult; (v) limiting the instruction set to give the attacker fewer options in analyzing and modifying code; and (vi) making variable the mapping between bit patterns, opcodes and operands. Some of these examples are described in more detail below. The detailed description includes the best mode currently contemplated.
|0030| Prior to describing various details, for purposes of context. Fig. 1 shows a general
system 100 and architecture i05 that includes virtualization. The architecture 105 further shows a custom and/or modified ISA and/or virtual machine in relationship to a virtual machine referred to as a common language runtime (CLR). The CLR in Fig. 1 is, for example, a CLR capable of handling an intermediate language code derived from any of a variety of object-oriented programming languages (OOPLs), hence, the term ''common". While Fig, I is discussed with reference to the .NF/f ^ framework {Microsoft Corp, Redmond, WA), exemplary techniques may be used with other architectures.
|(K)31| The system 100 includes various computing devices 101, 101', 102, 102' in
communication via a network 103. The devices 101, 101' may be clients (e.g.. PCs. workstations, light-weight devices, smart devices, etc.) while the devices 102, 102' are servers, fhe architecture 105 is shown with some links to the device 101, the server 102' and the network 103.
|()032| The .NL'f"^'' framework has two main components: the common language runtime
(CLR) and the .NLT"^' framework class library. These are shown as associated with managed applications. The CLR is a virtual machine (VM) at the foundation of the .NET^^ framework. The CLR acts as an agent that manages code at execution time, providing core services such as memory management, thread management, and remoting, while also enforcing strict type safety and other forms of code accuracy that promote security and robustness. The concept of code management is a fundamental principle of the CLR, Code that targets the CLR is known as managed code, while code that does not target the runtime is known as unmanaged code (right half of architecture).
|0033| In the .Nlv'f"^'' framework programs are executed within a managed execution
environment provided hy the CLR. The CLR greatly improves runtime interactivity between programs, porlabilily. security, development simplicity, cross-language integration, and provides an excellent Ibundation for a rich set of class libraries. Each language targeting the .NEf"^ framework CLR compiles source code and produces metadata and Microsoft® Intermediate Language (MSIL) code. While various examples mention MSIL. various exemplary security

techniques may be used with other language code. For example, various techniques may be used with most any tow-level assembler-style language (e.g., any intermediate language (11.) code). Various techniques may be used with bytecodes such as those of the JAVA^^ framework (Sun Microsystem. Sunnyvale. CA).
|0034| In the .NET framework, program code typically includes information known as
""metadata", or data about data. Metadata often includes a complete specification ibr a program including all its types, apart from the actual implementation of each function. These implementations are stored as MSIL, which is machine-independent code that describes the instructions of a program. The CLR can use this "blueprint" to bring a .NET^'^ program to life at runtime, providing services far beyond what is possible with the traditional approach that relies on compiling code directly to as.sembly language.
|0035) The class library, the other main component of the .NET'^'^^ framework, is a
comprehensive. object-t)riented collection of reusable types to develop applications ranging from traditional command-line or graphical user interface (GUI) applications to applications based on the latest innovations provided by ASP.NET, such as Web Forms and XML Web services.
10036| While the CLR is shown on the managed application side of the architecture 105, the
.N1:T^" framework can be hosted by unmanaged components that load the CLR. into their processes and initiate the execution of managed code, thereby creating a software environment thai can exploit both managed and unmanaged features. The ,NET"^ framework not only provides several runtime hosts, but also supports the development of third-party runtime hosts.
|0037| lor example. ASP.NET hosts the runtime (RT) to provide a scalable, server-side
en\ironmcnt for managed code. ASP.NET works directly with the runtime to enable ASP.NET applications and XML Web services.
|(H)38] The Internet Explorer® browser application (Microsoft Corp.) is an example of an
unmanaged application that hosts the mntime (e.g., in the form of a MIME type extension). Using the Internet l^xplorer® software to host the runtime enables a user to embed managed components or Windows [-'orms controls in HTML documents. Hosting the runtime in this way makes managed mobile code (similar lo Microsoft® ActiveX® controls) possible, but with significant

improvements that only managed code can offer, such as semi-trusted execution and isolated file .storage.
|0039| As described herein, managed code can be any code that targets a runtime (e.g., a
virtual machine, runtime engine, etc.. where the runtime interlaces with an underlying operating system (OS) typically directly associated with control of hardware (HW)). In the .NET^"^ framework, managed code targets the CLR and typically includes extra information known as metadata that "describe itself. Whilst both managed and unmanaged code can run in the CLR, managed code includes information that allows the CLR to guarantee, for instance, safe execution and intcropcrabiiiiy.
|0040| In addition to managed code, managed data exists in the architecture of the .NET^'^
framework. Some .NET"^ languages use managed data by default (e.g.. C#, Visual Basic.NET, .IScript.NET) whereas others (e.g., C++) do not. As with managed and unmanaged code, use of both managed and unmanaged data in .NET applications is possible (e.g., data that does not get garbage collected but instead is looked after by unmanaged code).
10041] A program or code is typically distributed as a portable executable file (e.g., a
"PL"). In a .NI:'f"^ PI-:, the first block of data within the PE wrapper is MSIL, which, as already mentioned, looks approximately like a low-level assembler language code. fhe MSIL is convcniionally what is compiled and executed in the .NET^^ framework. A second block of data with the PI-: is conventionally the metadata and describes the contents of the PE (e.g., what methods it provides, what parameters they take, and what they return). A third block of data is referred to as the manifest, which conventionally describes what other components the executable needs in order lo run. The manifest may also contains public keys of external components, so that the CLR can ensure that the external component is properly identified (i.e., the component required by the executable).
[00421 When running the executable, the .NET'^ CLR can use Just-In-Time (JIT)
compilation. Jfl compiling enables all managed code to run in the nafive machine language of the system on which it is executing (OS/HW). According to JIT, as each method within the executable gels called, it gets compiled to native code and, depending on configuration, subsequent calls to the same method do not necessarily have to undergo the same compilation, which can reduce overhead (i.e.. overhead is only incurred once per method call). Although the CLR provides many standard

runtime scr\'ices, managed code is never interpreted. Meanwhile, the memory manager removes the possibilities of fragmented memory and increases memory locality-of-rcference to further increase performance.
10043) Referring again lo the architecture 105, the relationship of the CLR and the class
library is shown with respect to applications and to the overall system (e.g., the system 100) and shows how managed code operates within a larger architecture.
|0044| fhe CLR manages memory, thread execution, code execution, code safely
verilication. compilation, and other system services. These features are intrinsic to the managed code that runs on the CLR.
|0045| With regards to security, managed components can be awarded varying degrees of
trust, depending on a number of factors that include their origin (such as the Internet, enterprise network, or l{)cal computer). This means that a managed component might or might not be able to perform tllc-access operations, registry-access operations, or other sensitive functions, even if it is being used in the same active application,
|0046| "fhe CLR can enforce code access security. For example, users can trust that an
executable embedded in a Web page can play an animation on screen or sing a song, but cannot access ihcir personal data, tile system, or network. The security features of the CLR can thus enable legitimate Internet-deployed software to be exceptionally feature-rich.
[0047| The CLR can also enforce code robustness by implementing a strict lype-and-eode-
veritlcation infrastructure called the common type system (CTS). The CTS ensures that all managed code is self-describing. Managed code can consume other managed types and instances, while strictly enforcing type fidelity and type safety.
|0()4Ji| The managed environment of the CLR aims to eliminate many common software
issues, i'or example, the CLR can automatically handle object layout and manage references to obiects. releasing them when they are no longer being used. Such automatic memory management resolves the ivvo most common application errors, memory leaks and invalid memory references. Interoperability between managed and unmanaged code can enable developers to continue to use necessary COM components (component object model) and dlls (dynamic-link libraries).

|0049| rhc -NI'T framework CLR can be hosted by high-performance, server-side
applications, such as IVIicrosoft® SQL Server™ and Internet Information Services (US). This infrastructure enables use of managed code for writing business logic, while still using enterprise servers that support runtime hosting.
100501 Server-side applications in the managed domain are implemented through runtime
hosts. Unmanagcd applications host the CLR, which allows custom managed code to control the behavior ol'a server. Such a model provides features of the CLR and class library while gaining the perlbrmance and scalabiliiy of a host server.
|0051] As already mentioned, various exemplary techniques use virlualization to emulate a
custom or modified ISA on top of a portable, verifiable, managed CLR environment- This is shown in the architecture 105 by an exemplary custom/modified ISA and/or VM 107 (dashed are) that sits on top of the boundary of the CLR and the managed applications space (noting that various examples discuss unmanagcd apps as well). This infers that the custom/modified ISA does not interfere with operation of the CLR and the underlying environment or "host" environment (e.g., OS/HW). While a custom ISA may provide for control of the CLR or "VM" to the extent necessary to implement various features of the custom ISA, various examples rely "" ^ custom VM. which may be a modified version of the underlying VM (i.e., a modified CLR). Hence, an exemplary architecture may include a single modified VM or multiple VMs (e.g., a custom VM on lop of a targeted VM). To increase security, at some cost of performance, a plurality of VMs may be slacked in a manner such ihat all but the lowest level VM virtualizes the instruction set of the VM directly underneath.
[0052| In Fig. 1. an arrow points to an example where a conventional CLR has a
\irluali/alion layer with two types of virtualization VMl and VM2 on lop of it and another example where a conventional CLR has two slacked virlualization layers VMl and VM3 on lop of it. In such examples, the underlying CLR could be a custom or proprietary CT.R with security features where the additional one or more virtualization layers further enhance security. An exemplary method includes multiple stacked VMs where each VM virtualizes the instruction set of the machine directly underneath. Noting that the lowest level VM typically virtualizes an operating system that controls hardware while other higher level VMs virlualize another VM, As indicated in iMg, 1. various an-angeinents are possible (e.g., two VMs on top of a VM. stacked VMs. elc). A

multiple "cusiom" VM approach may be viewed as leveraging virtualization to obtain more security, with some cost in performance.
|ft053| Referring again to the analogy with genetics and environment, genetics may be
considered static while the environment may be considered dynamic. Similarly, various diversity-based approached to tamper-resistance may be static and/or dynamic. In general, a static approach diversifies copies of program code while a dynamic approach diversifies VMs or VM operation or the program operation at runtime. Thus, as described herein, various exemplary techniques include virtuaU'/Alion that works statically, dynamically and/or both statically (eg- to generate individualized program code) and dynamically (e.g., to vary program operation at runtime).
10054] An exemplary method may include providing an architecture that includes a first
virtualization layer and providing a second virtualization layer on top of the first virtualization layer where the second virtualization is configured to receive a diversified copy of a program and allow for execution ol' the program using the first virtualizafion layer. Such a method may enhance software security through use of diversification techniques described herein,
|0()55| An exemplary method may include generating individualized copies of a program
code and providing a virtual machine for execution of an individualized copy of the program code wherein the virtual machine can vary program operation at runtime. Such a method may enhance software security through use of diversificafion techniques described herein.
[00561 For sake of convenience, custom and modified ISAs are referred to herein as custom
ISAs- A custom ISA may be used to create a set of different copies (or "versions") of a program with the following properties: (i) Each copy in the set has a reasonable level of defense against tampering and (ii) It is hard to retarget an exisfing attack against one copy to work against another copy, fhc many choices result in a large space of semanUcally equivalent programs that can be generated. An approach may consider this entire space to allow for more diversity or. alternatively, an approach may consider only parts of this space which are believed to be, or proven to be, more tamper-resislant than other parts.
[0057| Tamper-resistant properties include: (i) Prevent static analysis of the program; (ii)
Prevent dynamic analysis of the program; (iii) Prevent local modifications; and (iv) Prevent global modications, "fhe first two are closely related to the problem of obfuscation, while the latter two

are more lampcr-resistance-oriented. However, intelligent tampering requires at least some degree oi'program understanding, which is typically gained from observing the static binary, observing the running executable or a combination and/or repetition of the two previous techniques.
|0058| Various ISAs exist, for example. CISC, RISC and more recently Java''^ bytecode
and managed MSIL. However, the latter two tend to be more easily analyzed due to a number of reasons. First, binaries are typically not executed directly on hardware, but need to be emulated or translated into native code before execution. To enable this, boundaries between code and data need to be known and there can be no confusion between constant data and relocatable addresses. This, of course, comes with the advantage of portability. Besides portability, design principles include support for typed memory management and verifiability. To assure verifiability, pointer arithmetic is not allowed, control flow is restricted, etc. To enable typed memory management, a lot of information needs to be communicated to the executing environment about the types of objects,
|00S9| All of these design principles have led to binaries that are easy to analyze by the
executing environment, but are equally easy to analyze by an attacker. This has led to the creation ofdccompilers lor both Java^'^ and managed MSIL binaries.
|0(I60| In general, a trend exists where design principles of ISAs are becoming increasingly
in conllict with design principles that would facilitate software protection.
|0061 i As described herein, an exemplary technique to counter this trend adds an additional
layer of virtualizaiion (or optionally multiple additional layers of virtualization). More specifically, virtualization can be used to emulate a custom ISA on top of a portable, verifiable, managed runtime environment. Consider the following construction: (i) Write an emulator (e.g.. a custom virtual machine) for the environment which runs on top of a Ct.R; (ii) Take the binary representation oi a binary and add it as data to the emulator and (iii) Have the main procedure start emulation at the entry point of the original executable. Given this construction, the result is a managed, portable and verifiable binary, furthermore, it is as protected as a native binary, as the attacker of a native binary could easily take the native binary and follow the above construction,
\W)fil\ In gencriiL for binaries, experience and inluition indicate that the average IA32
binar; is far more complex to understand and manipulate than the average managed binary. Some underlying reasons include (i) Variable instruction length; (ii) No clear distinction between code

and data: and (iii) No clear distinction between constant data and relocatable addresses. Since instructions (opcode + operands) can have variable length (e.g., 1 -17 bytes), instructions need only be byte-aligned, and can be mixed with padding data or regular data on the 1A32, disassemblers can easily gel out of synchronization. As there is no explicit separation between code and data, both can he read and written transparently and used inter-changeably. This allows for self-modifying code, a feature that is renowned for being difficult to analyze and to confuse attackers.
|0063| The feature thai the binary representation of the code can easily be read has been
used to enable self-checking mechanisms while absence of restrictions on control How has enabled techniques such as control flow flattening and instruction overlapping.
0
|0(I64| The fact that addresses can be computed and that they cannot easily be distinguished
from regular data, complicates tampering with binaries. For example, an attacker can only make local modifications, as he does not have sufficient information to relocate the entire binary. Such observations may be used to generate an exemplary custom ISA that proves hard to analyze ISA. Such an ISA may add security.
|((065j While exemplary techniques may include self-modifying code in an ISA and/or
control tlow Jlallening and/or instruction overlapping, specific examples discussed herein include provisions for variable length of instructions and use of the binary representation of parts of a program for increased tamper-resistance, which may be considered as related to some self-checking mechanisms.
|(I066| Software often knows things it does not want to share in an uncontrolled manner,
for example, trial versions may contain the functionality to perform a given task, but a time limitation might prevent from using it for too long. In digital containers, software is often used to provide controlled access lo the contents. Mobile agents may contain cryptographic keys which need to remain secret.
[0067| fo confound an attack, exemplary approaches include (i) Making the program
different for different installations; (ii) Making the program different over time through tailored updates: and (iii) Making the program different for every execution through runtime randomizations.

|0068| Fig. 2 shows an exemplary security module 200 implemented in conjunction with a
framework that runs portable executable files on a virtual machine. The security module 200 includes a front end process module 210 and a back end process module 250. fhe front end pvoeess module 210 reads an executable binary file 110 that targets a VM and produces a custom executable binary file 150 that targets a modified version of the original target VM or a custom VM. !n either instance, the front end process module 210 can use the file 110 Ui determine informaiion about the original target VM, such as a VM description 115, The back end process nwdulc 250 can use the VM description 215 lo generate code, a dll, etc., for a custom VM 170. For example, a conventional VM may be shipped as a shared library or dll (e.g., a "native" library) and such techniques may be used for a custom VM, noting that where a VM operates on lop of a VM, specifics of the underlying VM may be accounted for in the fonn and/or characteristics of a custom VM. For the sake of convenience, the term "custom" as applied to a VM may include a modified VM (e.g., a modified version of the original target VM of code).
10069] In an example aimed at the .NHT'" framework, the front end process module 210
reads a managed MSII, binary 110, runs a few times over the code to determine its ISA, and produces an XML description 215 of its targeted VM. Once the ISA has been determined, the module 210 can rewrite the original binary into the custom bytecode language 150.
[0(I70| [-ig. 3 shows an exemplary method 300 where the back end process module 250
reads the XML description 215 and creates a managed dll for a custom VM 172. The separation in a back end and front end is somewhat artificial, but it does allow for a more modular design and can facilitate debugging. For example, the back end process module 250 can be instrucied to output C:,'^ code 174 instead of compiling a dll directly (see, e.g, 172). The code 174 can then be inspected and debugged separately.
\i){il\] Fig. 4 shows an exemplary method 400 where various parts of the original binary are
retained. More specificall>, the original VM executable binary 110 includes a wrapper 111 around functions n5(U-{N) and the front end process module 210 rewrites every function 115{1)-(N) into a v.rappcr 113 which calls the VM, passing the necessary arguments. In such an example, all arguments may be passed in an array of objects. For -instance" functions, the method 400 includes the -this" pointer as well. -A.s the method 400 operates on all functions to place each as a single structure, ihe front end process module 210 can also provide lor passing an identification of the

entry point of each function. In addition, the front end process module 210 may provide features to ensure thai a reiurncd object is cast to the return type of the original function, where appropriate,
|0072i ng. 5 shows a particular implementation of the method 400 in more detail. In this
example, the front end process module 210 has converted functions into stubs using a wrapper that invokes a VM. More specially, the function "Too" is wrapped with the call ''InvokeVM".
|0073| As already mentioned, data or data structure may provide a means for
diversilication. Fig. 6 shows an exemplary method 450 where the exemplary front end process module 210 receives a binary 110 with data !I7(1)-(N) in an original data structure and outputs a custom binary 150 with data !17(1)-(N) in a modified or custom data structure 156. While the method 450 also shows wrapping of functions 115(I)-(N), an exemplary method may generate a custom binary b\ diversifying code, diversifying data, and/or diversifying code and data. The phrase ■'diversification ol" data" may include diversification of data and diversification based on data structure,
|0074| I'xemplary methods that include rewriting the original program on a pcr-function
basis only have an advantage in that things like garbage collection do not become an issue, as data structures arc still treated as in the original program. Where techniques are applied for obfuscating, diversifying and making data more tamper-resistant, modificadons may provide for tasks like garbage collection.
10075) Figs. 1-6. described above, illustrate how virtualization can be used to enhance security. More specifically, a front end process module can be used to generate a custom binary code and a back end process can be used to generate a custom VM to execute the custom binary code, l-'igs. 7-14. described below, illustrate how specific features of an ISA and/or a VM may be used to enhance securitv through diversification.
10076) With respect to managed code and various exemplary techniques presented herein, the choice between managed MSIL for the CLR and Java™ bytecode for the .lava Runtime I'nvironmeni (JRIO is somewhat arbitrary as various exemplar>' techniques can be transferred from the .NFT'^' to the Java'^ domain. Further, techniques for obfuscating Java ^ bytecode can be applied to managed MSIi. binaries. The discussion that follows focuses primarily on exemplary techniques that stem from an "added'" or custom virttializafion layer. Automated diversification of

distributed copies, lor example, via Internet distribution is continually gaining acceptance. Hence overhead introduction of any of the exemplary techniques is increasingly economicaiiy viable.
|0077| Various exemplary techniques can introduce protection automaiically at a point
where human interaction is no longer required. It is theoretically possible to generate an unmanageable number of diverse semantically equivalent programs: Consider a program with 300 instructions and choose for every instruction whether or not to prepend it with a no-op. This yields 2"''"' different semantically equivalent programs and 2^"" is larger than 10*', the estimated number of particles in the universe.
|0078| However, uniqueness is not necessarily sufficient as the resulting programs should
be diverse enough to complicate the mapping of information gained from one instance onto another instance, furthermore, the resulting programs should preferably be non-trivial to break. While it is unreasonable lo expect that the codomain of various exemplary diversification techniques will include every semantically equivalent program, a goal can be set to maximize the codomain of a diversii'ier since the bigger the space, the easier it becomes to obtain internally different programs.
|0<)79| An exemplary approach starts from an existing implementation of semantics, rather
than from the semantics itself Through a number of parametrizable transformations different versions are obtained. In various examples that follow, a number of components of an ISA are identified that can be individualized independently.
[0080| V'lg. 7 shows exemplary framework characteristics 500 grouped as binary
components 505 and a V'M implementation component 560. The binary components 505 include instruction semantics 510, instruction encoding 520, operand encoding 530. fetch cycle 540 and program counter (PC) and program representation 550. These components can be individualized in an orthogonal way. as long as the interfaces are respected. The components 505 are sufficient to generate a binary in a custom bjtecode language; i.e., to determine an exemplary custom ISA. in addition, diversification may occur by diversifying the target VM or a custom VM (see, e.g., the VM implementation component 560),
|0081| l-'ig. 8 shows an execution model and interfaces 800. The model 800 includes code
802. data structure 804. a method framework 810 and a custom binary 150. In Fig. 8, arrows

represent interface dependencies and asterisks represent some diversifiable parts. An exemplary approach that uses such a model allows for a modular design and independent development.
|(I082| According to ihe model 800 and the framework 500, diversification may include (i)
randomizing instruction semantics by building instructions through the combination of smaller instructions, (ii) choosing instruction semantics to enable increased semantic overlap, (iii) departing from the traditional linear code representation to representing the code as a data structure such as a self-adapting (splay) binary tree, (iv) assigning variable lengths to opcodes and operands to complicate disassembly and to make local modifications more difficult, (v) limiting the instruction SCI to give the attacker fewer options in analyzing and modifying code, (vi) making variable the mapping between bit patterns, opcodes and operands.
|0083| The code 802 in Fig- 8 gives a high-level overview of an execution engine based on
a fetch-execute cycle. The main internal data structures of the VM are shown as the method framework 810, As already mentioned, arrows indicate interface dependence. For example, DccodeOpcodc expects to be able to fetch a number of bits,
|0084] Fig. 9 shows the instruction semantics 510 of Fig. 5 and some features that may be
used for diversification. The concept of micro-operations can allow for the diversification of instruction semantics, i'or example, an instruction in a custom bylecode language (e.g., per a custom ISA) can be any sequence of a predetermined set of micro-operations. For MSIL, the set of micro-operations currently includes verifiable MSIL instructions and a number of additional instructions to: (i) Communicate meta-information required for proper execution and (ii) Enable additional features such as changing semantics (described in more detail further below).
|f)085| This can be compared to the concept of micro-operations (iJops) in the P6 micro-
architecture. Each 1A32 instruction is translated into a series of ops which are then executed by the pipeline. Ihis could also be compared to super-operators. Super-operators are virtual machine operations automatically synthesized from combinations of smaller operations to avoid costly per-operation over-heads and to reduce executable size.
[0086| An exemplary method may include providing stubs to emulate each of the micro-
operations and these can be concatenated to emulate more expressive instructions in a custom

bylecode language (e.g.. a custom ISA), noting that many emulation functions may rely heavily upon relleclion.
|0087| Consider an example using the following MSIL instructions (addition, load
argument and load constant) and their emulation stubs (which have been simplified):
Idarg Int32:
IvvaluationStack.Push (
Argsln.l*eek(getArgSpec(insNr});
Idc lnt32;
livaluationSlack.Push (
getInt32Spec(insNr) );
add:
livaluationStack.Push (
(lnt32)EvaluationStack.Pop() + {lnt32)I-valualionStack.Pop());
|0088| Suppose that, during the instruction selection phase, we want to create a custom
bylecode instruction with the following semantics:
Customlns n i: load the nth argument, load the constant i and add these two values.
This instruction is then assigned to a ■"case"-statement (e.g., 1) in a large "'switch'^-statement. The case-statement is the concatenation of the different emulation stubs of the miero-operalions:
swilch(insNr) {
case 1:
.'/Concatenation of stubs break:

[0089) With respect to tamper-resistance, lack of knowledge of the semantics of an
instruction will complicate program understanding, as opposed to having a manual in which semantics is specilled. To go one level further, a custom tamper-resistant ISA may choose instruction semantics as adhering to some design principle(s).
[0090| Referring again to Fig. 9, conditional execution 512 may be used, optionally in
conjunction with predicate registers 513 to increase tamper resistance. Conditional execution can further promote merging slightly differing pieces of code. In the presence oi'conditional execution, instructions can be predicated by predicate registers. If the predicate register is set to false, the instruction is interpreted as a no-op {no operation), otherwise, the instruction is emulated. Using this approach, registers are set on or along different execution paths to be able to execute slightly different pieces of code.
|009lj An exemplary method may include providing code sequences a, b, c and a, d, c in
two different contexts in an original program and then "merging"' the code to a, Ipljb, [p2]d, c where pi is set to "true'" and p2 is set to "false" to execute code in the first context and vice versa to execute code in the second context. As a result of settings one or more predicate registers differently, different pieces of code may be executed {e.g., a, b, no-op, c and a, no-op, d, c).
|0092] A limited instruction set 514 may be used to increase tamper resistance. For
example, a custom ISA may lack no-ops 515. limit representable operands 516 and/or eliminate at least some conditional branches 517. Another approach may tailor a custom VM to a specific prograiTi(s): thus, an exemplary approach may ensure that the VM can only emulate operations that are required by that program.
|0093| Rcfemng again to a custom ISA without no-ops 515, this approach accounts for a
common attack technique that removes "undesired" functionality {e.g., a license check or decreasing the heahh of a wounded game character) by overwriting such functionality with no-ops. In many instances, there is little reason to include a no-op instruction in a custom ISA and not ha\ing this instruction v\ill complicate an attacker's attempt to pad out unwanted code.
|0094| With respect to limiting representable operands 516. statistics show that, for
example, of the integer literals from some 600 Java^'^^ programs (1.4 million lines in ali) 80% are

between 0-99. 95% are between 0 and 999 and 92% are powers of two or powers of two plus or minus 1. "I'hus, an exemplary custom ISA may limit the number of represenlable operands, again limiting the freedom of an attack.
|0095] Another exemplary approach can modify or restrict use of at least some conditional
branches 517. For example, usually, there are two versions for each condition: "Branch if condition is set and branch if condition is not set". Since use of two branches is redundanl, a custom ISA could include rewriting code so that only one version is used and its counterpart not included in the ISA. This exemplary technique may be useful, for example, when a license check branches conditionally depending on the validity of the serial number: It will prevent the attacker from simply flipping the branch condition.
|0((96| V]g. 10 shows the instruction encoding block 520 of Fig. 5 with various aspects of
instruction encoding that can be used for diversification. More specifically, the aspects include variable instruction sizes 522, unary encoding for physical overlap 524. non-local semantics 526 and rearranging decoding structure 529.
[0097| Once instruction semantics has been determined, a need exists to determine an
opcode encoding ibr those instructions. The size of all opcodes for traditional architectures is usually constant or only slightly variable. For example, MSIL opcodes arc typically one byte, with an escape value (Oxfc) to enable two byte opcodes for less frequent instructions. The limited variability facilitates fast lookup through table interpretation. But, more generally, any prefix code (no code word is a prefi.\ of any other code word) allows for unambiguous interpretation.
|0098| In its most general form, decoding opcodes to semantics can be done through a
binar\-tree traversal. Decoding normally starts in the root node; when a 0 bit is read, a move to the left child node occurs: when a 1 bit is read, a move to the right child node occurs. When a leaf node is reached, the opcode has been successfully decoded (e.g., consider a leaf node that contains a reference to the casc-.statcmenl emulating the semantics of the instruction).
|((()99| If a custom ISA allows arbitrary opcode sizes, without illegal opcodes, the number
of possible encodings for n instructions is given by the following equation:

2(17-1)
-^'-^.! (3)
n
In Fqn. 3. the fraction represents the number of planar binary trees with n leaves (Catalan number), white the factorial represents the assignment of opcodes to leaves. If fixed opcode sizes were chosen with the shortest possible encoding, i.e. log2(n) bit, it might introduce illegal opcodes. In this case, ihe number of possible encodings is given by the following representation (Eqn, 4):

n

(4)

|0100| Many more possibilities would arise if the custom ISA allowed illegal opcodes for
other reasons than minima! fixed opcode sizes. However, this may increase the si/-e of a binary wrillen in the custom ISA without offering advantages.
|0101| In various examples presented herein, directed to the .NET™ frainework (e.g.,
MSIL). the following modes can be supported: (i) Fixed length opcodes with tabic lookup; (ii) Multi-level table encoding to enable slightly variable instruction sizes (escape codes are used for longer opcodes) and (iii) Arbhrary-length opcodes with binary-tree traversal for decoding. Such modes can be applied to other frameworks as appropriate.
|0102| With respect to tamper resistance, again, not knowing the mapping from bit
sequences to semantics introduces a learning curve for an attacker, for example, an; compared to having such information in a manual. A number of addifional approaches exist to choose a mapping in such a way that it allows for tamper-resistance properties.
1010.^1 As already mentioned, the instructions encoding block 520 of Fig. 10 includes a
variable instruction size approach 522, For example, custom ISA can introduce even more variance in the length of opcodes than allowed in a CISC binary. Variable instruction sizes can also be used to make local modifications more complicated. In general, a larger instruction cannot simply replace a smaller instruction, because it would overwrite the next instruction. A custom ISA can also ensure that smaller non-control-transfer instructions cannot replace larger instructions. For

example, this can be accomplished by ensuring that such instructions cannot be padded out to let control How to the next instruction.
(01041 Consider a code or ISA with 64 instructions where each of the instructions may be
assigned a unique size in a range of bits (e.g., between about 64 bits and about 127 bits). Clearly, larger instructions do not fit into the space of smaller instructions. Further, smaller instructions do fit in the space of larger instructions. Yet, when control falls through to the next bit, there is no instruction available to pad out the remaining bits with no-ops to make sure that control fiows to the next instruction. Ilcncc. under this scheme it is useful to make control-transfer instructions the longest, to keep an attacker from escaping to another location where he can do what he wants.
[0105| The instruction encoding block 520 also includes a unary encoding approach 524 to
achieve, for example, physical overlap. A unary encoding approach can entangle a program by increasing or maximizing physical overlap. For example, such an approach may he able to jump into the middle of another instruction, and start decoding another instruction. This approach can be facilitated by choosing a good encoding. For example, unary encoding can be used to encode the opcodes (0. 01. 001. ..,, O''"*!). In this example, there is a good chance that one finds another instruction when jumping one bit after the beginning of an instruction:

01
001
0001

add mul sub div

Above, four instructions have been assigned an opcode using unary encoding. In this example, if decoding starts at the .second bit of the divide instruction (div), the subtract instruction (sub) is revealed. Likewise, looking at the last bit of the divide, subtract and multiply (mul) instruction re\eals add instruction.
|0106| Another approach for a custom ISA related to instruction encoding uses non-local
semantics 526. Having a unique bytecode language for every distributed copy erects a significant barrier against attackers.

|0107| In general. Ibr an ISA, there is no documentation available on: (i) The mapping from
bii patterns to instructions; (ii) The semantics of instructions; (iii) The mapping from bit patterns to operands: (iv) The representation of data-structures; etc. However, such mappings or representations may eventually be learned by an attacker through static or dynamic inspection. To confound an attack, a custom ISA can use non-local semantics 524 to ensure that a bit pattern has different meaning along different execution paths.
Ifll08| A binary program is just a sequence of "T's and "0"s, which is given meaning by a
processor. The meaning between bit patterns and interpretation is typically fixed by the ISA. On traditional architectures, if the opcode of a certain instruction is represented by a given bit pattern, this pattern is constant for every binary, everywhere it occurs. A custom ISA can make any particular bit pattern variable, noting that not all instruction bit patterns need to be made variable to erect a significant barrier against attack. Hence, the non-local semantics block 526 includes a variable h\\ pauern block 527 approach, for example, for an opcode for an inslruction.
|0109I In a custom ISA, a bit pattern may only be assigned meaning depending on
pre\iousiy executed code. To make the interpretation depend on previously executed code, depending on the (fully specified) input, a custom ISA can allow getting to a program point along ditfcrent execution paths. However, such a custom ISA may still want to have control over the interpretation oi'bits at a given program point. To accommodate this variability, a custom ISA can make interpretation changes explicit rather than implicit as a side effect of some other event. Hence, the non-local semantics block 526 includes a bit pattern block 528 approach, for example, to assign meaning based on prior code cxecudon. FuFther, the non-local semantics block 526 links to interpretation changes explicit in the custom ISA, for example, to get to a program point along dificrent execution paths.
|0110| An exemplary method includes generating diverse copies of a program using
insiruction encoding to rearrange a decoding structure to thereby allow for getting to a point in the program along two or more execution paths where an assigned meaning of a bit pattern at the point depends on the execution path to the point. For example, such a method may assign meaning based on prior code execution, which may differ for different execution paths.
|()1111 A custom ISA may aim to not limit complexity with respect to getfing an executing
cn\ ironment in a specific interpretation state. In other words, such an approach may ensure that, if

gelling to a program poinl from different execution paths in different interpretation stales is allowed, il can be relatively easily to migrate to a single target interpretation state no matter what the different interpretation states may be.
|0n21 A particular approach involves rearranging structure 529. For example, changing
interpretation may amount to nothing more than rearranging a decoding tree. Taking into account ihc previous observations, a custom ISA may only allow a limhed form of diversification. To this end. a custom ISA may have a chosen level at which subtrees (or other substructures) can be moved around. Such a choice is a trade-off between how many different interpretations are possible and how easy il is to go to a fixed interpretation from a set of possibly different interpretation states.
|0113| In an example, consider choosing the third level of a tree structure. Assuming that
the shortest opcode is 3 bit, this allows for 8! interpretation states, while any interpretation state is reachable in at most 8 micro-operations. Such an approach can be applied to a set of MSIL micro-operations, for example, consider the following micro-operations:
Swap(lJlnt3 position!. Ulnt3 position2),which exchanges the nodes at position position! and posilion2 and
Set(Ulnt3 label, Ulnt3 position).which exchanges the node with label (wherever it may be) and the node at position position.
In the case of table interpretation, this is implemented as a two-level table interpretation. The first level can refer to other tables which can be swapped.
jOI 14| In the foregoing example, micro-operations largely correspond to MSIL instructions
and the operand types correspond largely to MSIL operand types. Micro-operation emulation stubs that use operands use function calls to ensure that opcode encoding can be diversified orthogonally. Such callbacks iurthermorc pass an argument "insNr" identifying a custom VM instruction from which it was called (sec. e.g.. example of instruction semantics 510). This allows for encoding operands differently for different custom VM instructions. Note that due to the concatenation of stubs, an arbitrary number of operands can follow the opcode. Thus, the approach for operand encoding 530 may include such techniques. Hence, similar approaches for diversif>ing opcode encoding can be made as for instruction encoding.

|0II5J Diversifying the fetch cycle may be considered an "artificial" form of
diversification. Fig. 11 shows the fetch cycle block 540 as including various approaches that use "filters" 542. A basic "non-custom" fetch cycle simply gets a number of bits from a custom byiccodc binary, depending on the current Program Counter (PC). However, use of one or more filters 542 allows for a custom fetch cycle that improves tamper-resistance. Such filter or filters can transform the aciual bits in the binary to the bits that will be interpreted by the VM.
|0116| Fetch cycle filters 542 may add complexity by combining one or more requested bits
with other information. For example, the actual requested bits may be combined with other parts of a program 543. In such a manner, a program becomes more inter-dependent as changing one part of the program may impact other parts as well. Other filter approaches include a filter that combines one or more bits with a random value 544 (e.g., derived from a secret key) and a filter thai combines one or more bits with the program counter (PC) 545 to complicate pattern matching techniques,
|0I]7| The most traditional representation of code is as a linear sequence of bytes. In such
an approach, a program counter (PC) simply points to the next byte to execute, and control transfers typically specify the byte to continue execution at as a relative offset or an absolute address. This may be essentially viewed as a structure that represents code as an array of byies.
|l) 11 H\ Fig. i 2 shows the program counter and program representation block 550 along with
various structural approaches, including array 553, tree 554, linked list 555 and hash table 556. A custom ISA may represent code as a splay tree such as the splay trees 1320 and 1330 of Fig. 13. While code may be represented as a splay tree, an exemplary approach for a custom ISA may aUcrnatively or additionally represent data in a splay tree or other selected structure to enhance security. In general, such approaches can provide for diversification more readily than a traditional linear representation (see. e.g., linear approach 1310 of Fig. 13).
|0119| Splay trees have a number of advantages: They are self-balancing, which will allow
for automatic relocation of code. Furthermore, they are nearly opdmal in terms of amortized cost for arbitrary sequences. Finally, recently accessed nodes tend to be near the root of the tree, which allows far partial leverage of spatial and temporal locality present in most executables.

|0120| Because of the self-balancing property, a piece of code could be in many different
locations in memory, depending on the execution path that led to a certain code fragment. Code fragments can be moved around, as long as there is a way to refer to ihem for controMlow transfers, and so that they can be retrieved when control is transferred to them. An exemplary structure approach uses keys of nodes in splay tree where control transfers specify the key of the node lo which control needs lo be transferred. In such an example, it is required that targets of ct)ntro! How be nodes (i.e.. cannot readily jump into the middle of the code contained within a node). In practice this means that execution starts a new node for each basic block, Fall-through paths can be handled by making all control flow explicit. In such an example, ail control flow targets may be specified as the keys of the node containing the target code. Further, the size of the code in a node may be constant. Yet further, if a node is too small to contain an entire basic block, it can overflow to another node and continue execution there.
[0121| Fig, 13 illustrates an exemplary approach using splay trees 1320, 1330 for a given
linear approach 1310 for a factorial function "Fac'". When, for example, ihe function '"Fac" is called for the first lime, the node with key 1 will be referenced and percolated lo the root, as shown in part (2). Another thing that is worth noting in this example is thai calls no longer need to specify the function signature, as this code w-ill not be subject to verifiealion.
[0I22| If such a technique is implemented naively, only pointers will be moved around, and
the aciual code will remain at the same place on the heap. To complicate this further, an explicit exchange of the actual contents (of primitive types) of the nodes can occur, or alternatively, an allocation of a new code buffer may occur along with copying of the code buiYer to the allocated space, possibly with re-encryption and/or with different garbage padding.
[0123| Referring again lo the framework characteristics 500 of Fig. 7, exemplary
approaches may be applied to VM implementation 560. Some approaches are shown in Fig. 12. [■'or a given internal implementation, an evaluation stack is not determined on the basis of the ISA (e.g., consider components 505). In such an example, emulation stubs for micro-operations may rely only on an interface which supports a number of operations such as "pop'" and "push". An exemplar) approach for an internal implementation of a slack data structure 562 introduces independent diversity via. for example, an array, a linked list, etc. An exemplary approach may optionally provide a number of different implementations of such interfaces.

|0124| Another approach aims to diversify VM generation 564. For example, once the
parameters ibr the above specilied forms of diversification are fully specified, an exemplary back end process may combine code snippets from various locations along with some auio-generated code to assemble a managed C# representation for the implementation of the custom VM. Aliernatively, an exemplary back end process can directly output a dll.
101251 Another exemplary approach involves diversifying dlls 566, for example, using
randomizabie versions of existing code transformations from various domains such as software opiimi/ation. software obfuscation, (non-virtualization-based approaches to) software diversillcation. etc.
|(I126| While various exemplary techniques discussed herein generally introduce some
overhead, where digllal rights management, sensitive information (e.g., government, proprietary, etc.). licenses, etc. arc involved, then such overhead may be tolerated, given the enhanced security introduced via diversification. In such instances, diversification techniques may be applied to the typically largctcd areas and not applied lo runtime features that require some degree of contemporaneous or "real-time" execution. For example, diversification may be applied to code associated with digital rights managemenl and not to associated code that requires some form of digital rights OK prior to execution.
[0I27| Virtuaiization opens up a wide range of possibilities ibr both diversity and tamper-
resislance. Controlling an execution environment provides significant leverage Vo complicate the task of an allacker. While various examples refer to a particular framework for software protection based on the concept of virtuaiization. various approaches have also been identified where diversity and/or tamper-resistant features can be introduced in a largely independent way. Modular de\ clopmenl and/or deployment can be used.
|()]28| Fig. 15 illustrates an exemplary computing device 1500 that may be used to
implement various exemplary components and in forming an exemplary system. For example, the servers and clients of the system of Fig. 1 may include various features of the device 1500.
J0I29| In a verv basic configuration, computing device 1500 typically includes at least one
processing unit 1502 and system memory 1504. Depending on the exact configuration and type of computing device, system memory 1504 may be volatile (such as RAM), non-volatile (such as

ROM, Hash memory, etc.) or some combination of the two. System memory 1504 typically includes an operating system 1505. one or more program modules 806, and may include program data 1507. The operating system 1506 include a component-based framework 1520 that supports components (including properties and events), objects, inheritance, polymorphism, reflection, and provides an object-oriented component-based application programming interface (API), such as that of the .NI:'f Framework manufactured by Microsoft Corporation. Redmond, WA. The operating system 1505 also includes an exemplary framework 1600. such as. but not limited to, an exemplary framework with a custom ISA and/or custom VM. Further, the computing device 1500 may include a software module for generating a custom ISA and/or a custom VM. Yet further, the computing device 1500 may include a software module for testing a custom ISA and/or a custom VM. fhe computing device 1500 may include a software module for generating a custom code and/or a custom VM to. at least in part, execute a custom code. The device 1500 is of a very basic configuration demarcated by a dashed line 1508. Again, a terminal may have fewer components bm will imcraei wivh a computing device thai may have such a basic configuration.
|0130| Computing device 1500 may have additional features or functionality. For example,
computing device 1500 may also include addhional data storage devices (removable and/or non¬removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in Fig. 15 by removable storage 1509 and non-removable storage 1510. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. System memory 1504, removable storage 1509 and non-rcmovabte storage 1510 are all examples of computer storage media. Computer storage media includes, but is not limited to. RAM, ROM, EEPROM. flash memory or other memory technology, CD-ROM. digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device 1500. Any such computer storage media may be part of device 1500. Computing de\icc 1500 may also have input device{s) 1512 such as keyboard, mouse, pen. voice input device, touch input device, etc. Output device(s) 1514 such as a display, speakers, printer, etc. may also be included. These devices are well know in the art and need not be discussed at length here.
|(H311 Computing device 1500 may also contain communication connections 1516 that
allow the device to communicate with other computing devices 1518. such as over a network (e.g..

consider the aforementioned web or Internet network 103). Communication connections 1516 are one example of eommunieation media. Communication media may typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in sueh a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media sueh as a wired network or direct-wired connection, and wireless media sueh as acoustic, RF, infrared and other wireless media. The term computer readable media as used herein includes both storage media and communication media.
IVI132) Although the subject matter has been described in language specifvc Vo structural
features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

lAVE CLAIM:
1. A computer-impleinentable method comprising;
providing an instruction set architecture (200) that comprises features to generate diverse copies of a program;
using the instruction set architecture to generate diverse copies of a program (150); and providing a virtual machine (170) for execution of one of the diverse copies of the program.
2. The method of claim 1 wherein the providing a virtual machine comprises generating a virtual machine dynamic-link library (172).
3. fhe method of claim I wherein the features to generate diverse copies of a program comprise instruction semantics (510) that provide for conditional execution (512) using predicate registers (513),
4. The method of claim 1 wherein the features to generate diverse copies of a program comprise instruction semantics (510) with a limited instruction set (514), optionally wherein the limited instruction set does not include a "no operation" instruction (515), optionally wherein the limited instruction set has limited representation of operands (516), and optionally wherein the limited instruction set limits at least some conditional branches (517).
5. The method of claim 1 wherein the features to generate diverse copies of a program comprise instruction encoding (520) for variable instruction sizes (522). optionally wherein the features lo generate diverse copies of a program comprise instruction encoding for assigning an opcode using unary encoding to introduce physical overlap (524), optionally wherein the features to generate diverse copies of a program comprise instruction encoding to introduce a variable bit pattern for an opcode for an instruction (527), optionally wherein the features lo generate diverse copies of a program comprise instruction encoding to assign a bit pattern based on prior execution of an opcode (528), and optionally wherein the fealures to generate diverse copies of a program comprise instruction encoding to rearrange a decoding structure (529) to thereby allow for getting to a point in the program along two or more execution paths wherein an assigned meaning of a bit patiern at the point depends on the execution path to the point.

6. The mclhod of claim I wherein ttie features to generate diverse copies ol' a program
comprise one or more letch cycle filters (542), optionally wherein the one or more fetch cycle
lillers (542) comprises a filter that adds information to a requested bit or bits of a code (543),
optionally wherein (he information comprises a random value (544). optionally wherein the
informalion comprises a program counter value (545) or information based at least in part on a
program counter value.
7. The method of claim ! wherein the features to generate diverse copies of a program
comprise al least one structure, selected from a group (550) consisting of splay trees, linked hsts
and hash tables, to represent the program.
8. A eomputer-implemcntable method comprising:
providing code that targets a virtual machine (110); and
generating a diversified virtual machine by combining pieces of the code from various locations and some auto-generated code to assemble a managed code representation for implementation of virtual machine or to output a diversified virtual machine dli (17Q).
9. A method for enhancing software security (105), the method comprising:
providing a base virtualization layer that comprises an instruction set; and
providing one or more additional virtualization layers wherein at least one of the one or more additional virtualization layers virtualizes the instruction set of the base virtualization layer.
10. The melhod of claim 9 further comprising:
generating individualized copies of a program code (150); and
providing a virtual machine (170) for execution of an individualized copy of the program code wherein the virtual machine can vary program operation at runtime.