Abstract:

Method, system and computer program product for applying existing
anti-tampering and obfuscation technique to virtual machine technology
and offers several distinct advantages. The anti-tampering and
obfuscation transforms can be applied continuously to prevent adversaries
from gaining information about the program through emulation or dynamic
analysis. In addition, the encryption can be used to prevent hackers from
gaining information using static attacks. The use of a virtual machine
also allows for low overhead execution of the obfuscated binaries as well
as finer adjustment of the amount of overhead that can be tolerated. In
addition, more protection can be applied to specific portions of the
application that can tolerate slowdown. The incorporation of a virtual
machine also makes it easy to extend the technology to integrate new
developments and resistance mechanisms, leading to less development time,
increased savings, and quicker deployment.

Claims:

1. A computer method of increasing the tamper-resistance and/or obscurity
of computer software code, said method comprising:preparing the computer
software code for execution in a designated execution environment for
making it difficult to execute the computer software code independently
from the designated execution environment, wherein said preparation
comprises applying one or more computer software preparation
transformations to the computer software code; andpreparing the execution
environment so that it impedes execution of computer software code in the
execution environment except for a designated computer software code.

6. The method of claim 1, wherein said computer software preparation
transformation further comprises adding additional codes and/or data to
the computer software to verify the integrity of at least one of the
execution environment and the prepared software code.

7. (canceled)

8. The method of claim 1, wherein said computer software preparation
transformation further comprises altering the computer software code such
that proper execution is difficult without undoing the alterations, said
altering including at least one of altering: constant operands; program
control flow; program data layout; data initialization information;
instruction encoding; or file format.

9-10. (canceled)

11. The method of claim 1, wherein said execution preparation comprises
applying one or more preparation execution environment transformations to
the execution environment computer software code, and wherein said
execution environment preparation transformation comprises encrypting
some or all of the execution environment, using a plurality of keys
hidden within the execution environment and/or prepared software code.

12-14. (canceled)

15. The method of claim 1, wherein said execution environment preparation
transformation further comprises adding additional codes and/or data to
the computer software execution environment to verify the integrity of at
least one of the computer software code and the prepared execution
environment.

16. (canceled)

17. The method of claim 1, wherein said method further comprises applying
execution transformations to both of the prepared computer software code
and the prepared execution environment during execution of a computer
software code to improve tamper resistance and/or obscurity in a
designated execution environment, wherein said execution transformation
comprises the execution environment changing the layout of computer
software code data, the computer software code data being one of at least
data used for the execution environment or data to execute the computer
software code or data to execute prepared software code.

18-19. (canceled)

20. The method of claim 17, wherein said execution transformation
comprises the execution environment using conditions generated during
execution, whereby said conditions are difficult to programmatically
decipher to assist in the tamper-resistance and/or obscurity transforms.

21. The method of claim 17, wherein the execution transformations include
at least one of relocating operational locations to increase the
difficulty of determining operation locations for making operation's
locations difficult to determine, and rearranging, eliminating or adding
execution flow for making execution flow and/or control flow difficult to
determine.

22. (canceled)

23. The method of claim 17, wherein the execution transformations include
at least one of inserting additional software code and/or data for making
the software code operations difficult to determine, and inserting
incorrect codes that are intentionally similar to other correct software
codes.

24. The method of claim 17, wherein the execution transformations include
at least one of inserting operations that cannot be feasibly executed,
but appear as though execution is possible, and randomizing operation
order.

33. The method of claim 17, wherein said computer software code comprises
at least one of: binary, byte code, program source, program assembly,
program scripts, machine language, and or program intermediate formats,
or any combination thereof and wherein said program scripts comprises at
least one of the following:Perl, PHP, python, CGI, Java, Java Script, ASP
script, MySQL, Borne shell, bash, tcsh, and or csh, or any combinations
thereof.

34-59. (canceled)

60. A computer method of increasing the tamper-resistance and/or obscurity
of computer software code, said method comprising:applying execution
transformations during execution of a computer software code to improve
tamper resistance and/or obscurity, wherein said preparation comprises
applying one or more computer software preparation transformations to the
computer software code; andpreparing the computer software code for
execution in a designated execution environment for making it difficult
to execute the computer software code independently from the designated
execution environment.

61. The method of claim 60, wherein said execution transformation further
comprises the execution environment changing the layout of computer
software code data, the computer software code data being at least one of
data used for the execution environment or data to execute the computer
software code or data to execute prepared software code.

62. (canceled)

63. The method of claim 60, wherein said execution transformation further
comprises the execution environment using conditions generated during
execution, whereby said conditions are difficult to programatically
decipher to assist in the tamper-resistance and/or obscurity transforms.

64. The method of claim 60, wherein the execution transformations include
at least one of relocating operational locations to increase the
difficulty of determining operation locations for making operation's
locations difficult to determine, and rearranging, eliminating or adding
execution flow for making execution flow and/or control flow difficult to
determine.

65. (canceled)

66. The method of claim 60, wherein the execution transformations include
at least one of inserting additional software code and/or data for making
the software code operations difficult to determine, and inserting
incorrect codes that are intentionally similar to other correct software
codes.

67. The method of claim 60, wherein the execution transformations include
at least one of inserting operations that cannot be feasibly executed,
but appear as though execution is possible, and randomizing operation
order.

68. (canceled)

69. (canceled)

70. The method of claim 60, wherein the execution transformations insert
dynamically operations into the execution to verify the integrity of
computer software code and/or data.

76. The method of claim 60, wherein said computer software code comprises
at least one of: binary, byte code, program source, program assembly,
program scripts, machine language, or program intermediate formats, or
any combination thereof, and wherein said program scripts comprises at
least one of the following:Perl, PHP, python, CGI, Java, Java Script, ASP
script, MySQL, Borne shell, bash, tcsh, or csh, or any combinations
thereof.

83. The method of claim 60, wherein said computer software preparation
transformation comprises at least one of adding additional codes and/or
data to the computer software to verify the integrity of at least one of
the execution environment, and the prepared software code.

84. (canceled)

85. The method of claim 83, wherein said computer software preparation
transformation comprises altering the computer software code such that
proper execution is difficult without undoing the alterations, wherein
said altering includes at least one of: altering constant operands,
program control flow, program data layout, data initialization
information, instruction encoding, or file format, or any combination
thereof.

86. (canceled)

87. The method of claim 60, wherein said execution transformation
comprises interpreting said preparation transformations on the prepared
software codes.

88-125. (canceled)

126. A computer program product comprising a computer useable medium
having computer program logic for enabling at least one processor in a
computer system to increase the tamper-resistance and/or obscurity of
computer software code, said computer logic comprising:preparing the
computer software code for execution in a designated execution
environment for making it difficult to execute the computer software code
independently from the designated execution environment, wherein said
preparation comprises applying one or more computer software preparation
transformations to the computer software code; and preparing the
execution environment so that it impedes execution of computer software
code in the execution environment except for a designated computer
software code.

131. The computer program product of claim 126, wherein said computer
software preparation transformation further comprises adding additional
codes and/or data to the computer software to verify the integrity of at
least one of the execution environment and the prepared software code.

132. (canceled)

133. The computer program product of claim 131, wherein said computer
software preparation transformation further comprises altering the
computer software code such that proper execution is difficult without
undoing the alterations, said altering includes at least one of altering
constant operands, program control flow, program data layout, data
initialization information, instruction encoding, or file format, or any
combination thereof.

134. (canceled)

135. (canceled)

136. The computer program product of claim 126, wherein said system
comprising applying execution transformations to both of the prepared
computer software code and the prepared execution environment during
execution of a computer software code to improve tamper resistance and/or
obscurity in a designated execution environment.

[0003]Software programmers want the ability to make their computer
software protected from undesired change. Such changes can be manual,
such as a malicious user bypassing a licensing check in commercial
software, or automatic, such as a virus modifying a binary to include a
copy of the virus. To verify that it has not been modified, software
attempts to monitor its own code, with execution changing when a
modification to the code is detected (anti-tampering). To thwart a
malicious user from locating and disabling self-checking code, code is
made difficult to understand, and self-checking codes are hidden within
the rest of the application code (obfuscation). Unfortunately, malicious
attackers continue to thwart such checks using a variety of information
gathered from the dynamic execution of the program.

[0004]The issue of protecting software from unauthorized tampering is a
critical problem in modern software deployment. Billions of dollars are
lost in revenue each year due to the efforts of malicious hackers and
software pirates. For example, malicious users may modify software to
bypass a licensing check in commercial software or alter programs to
include a copy of a computer virus. Anti-tampering methods are also of
great importance in the growing area of digital rights management, where
tampering results in the loss of significant royalties and license fees.

[0005]One popular method of protecting a program from modification is code
obfuscation. Code obfuscation involves modifying computer code so that it
is more difficult to understand. This then makes it more difficult for
malicious hackers to figure out what parts of a program to modify. While
a powerful tool in the fight to make software more secure, existing
obfuscation techniques unfortunately possess several drawbacks. Much of
the work in this area only involves making it more difficult to perform
"static analysis" of programs. In other words, many techniques only deter
knowledge of source code or object code but not knowledge of executing
code ("dynamic analysis"), which can often be gained by piecing together
the information from several different runs of the program. Many
obfuscation strategies also involve extremely high overhead, which may be
unacceptable for many people and prevent adoption of the security
measure. Other obfuscation strategies require the use of special hardware
or fail to present complete and implementable solutions.

[0006]Previous work has, but not limited thereto, a variety of major
drawbacks as discussed below.

[0007]Much work strives only to make the program hard to statically
analyze [See 21, 33]. For example, an opaque predicate may be hard to
analyze statically, but several runs of the program in a simulator can
determine which branches are highly biased. That information can be fed
into a static disassembler to identify the start of basic blocks. Also,
that same run of the simulator can help reveal (the dynamically executed
portions of) the control flow graph. Combining information from several
runs of the program can yield a highly accurate representation of the
instructions in a program, the opaque predicates, and the control flow
graph.

[0008]Other work requires special hardware [See 28, 30, 24]. For example,
a hardware device that stores a decryption key or a processor that only
executes encrypted instructions can be used to guarantee that only
programs that were generated with a proper encryption key can run.
Unfortunately, specialized hardware may be expensive and not generally or
widely available. Furthermore, users may reject hardware that is
incapable of running a wide variety of programs.

[0009]Some previously proposed techniques have extremely high overhead
[See 2]. In fact, some previous work provides such an unreasonable
execution overhead that an overhead measurement is not even suggested.
Realistic, usable solutions must provide minimal overhead or people will
be unwilling to adopt the security measures.

[0010]Yet other work provides a threat model that does not meet the
tamper-resistance needs of modern hardware, or provides only a partial or
impractical solution [See 16, 18, 27]. Some previous techniques even
assume that an optimal algorithm for performing a checksum calculation
can be computed, that the optimal algorithm runs on a known hardware
configuration (and even a pre-calculated clock rate) and that the result
can transmitted over an unmonitored network within bounded time!

[0011]Thus, there is a continuing need for better ways to secure software,
systems and content by providing a mechanism for the protection of
software from tampering and reverse engineering.

SUMMARY OF THE INVENTION

[0012]An aspect of various embodiments of the present invention provides,
among other things, a mechanism for protection of software from tampering
and reverse engineering. Efficient software dynamic translation is used
to continually provide dynamic tamper-resistance and obfuscation. To
prevent modifications to the pre-translated software version, encryption
is used. Self-checking codes are hidden within the encrypted code, which
help protect both the original program code and the software dynamic
translator's program code. The dynamic translator caches blocks of code
from the original application in a code cache. To protect these cached
blocks, the translator dynamically applies anti-tampering and obfuscation
techniques. The cache is flushed periodically and randomized
anti-tampering and obfuscation techniques are re-applied to protect
dynamic information from being leaked by the execution of the program.

[0013]An aspect of an embodiment of the present invention utilizes recent
trends that enable high-speed translation of program code, and the ever
increasing computing power that is available in modern computer systems.
An approach uses a portion of the CPU time to dynamically perform
anti-tampering and obfuscating transformations.

[0014]An aspect of various embodiments of the present invention is that it
may be utilized for a number of products, applications, implementations,
and services. For instance, any vendor that produces software may be
interested in using or implementing this technology (i.e., method,
system, and/or computer program product). Examples may include, but not
limited thereto, the following: Microsoft, including their Windows and
Office lines of software; Adobe, including their Acrobat products, etc.;
Sun Microsystems, including Solaris products, etc.; and Cloakware
products and virtual machine.

[0015]An aspect of various embodiments of the present invention is
applicable to "vaccinating" a computer system against viruses.
Consequently major virus/worm/spyware/adware detection companies may be
interested, including Symantec or the like.

[0016]Furthermore, malicious software detection programs have a direct
need to avoid modification/disablement by a virus.

[0017]Digital rights management is an important aspect of the proposed
technology as well. By protecting a media player, various embodiments of
the present invention can be used to manage a key hidden within the media
player, thus protecting the media itself.

[0018]Medical applications may be a particularly useful application area
for various embodiments of the present invention. Especially, for
example, as semi-robotic machines take over surgical tasks, it is
important to know that a system is unmodified. Similarly, space
exploration could benefit by detecting failure/modification of a
sub-system with such a mechanism.

[0019]Military applications may benefit from the technology of the various
embodiments of the present invention. Broadly applying such systems may
thwart an "insider attack" on a system as the insider may not be able to
tamper with the software.

[0020]Virtual machine technology applied to anti-tampering and obfuscation
technology provide a stronger mechanism for anti-tampering and
obfuscation than any previous technology. Accordingly, an aspect of
various embodiments of the present invention may provide a number of
advantages, such as but not limited thereto, the following:
[0021]Continuous application of anti-tampering and obfuscation transforms
prevent an adversary from gaining information by using emulation.
[0022]Encryption prevents the adversary from gaining information about
the application using static attacks. [0023]Software dynamic translation
technology allows for low overhead execution of obfuscated binaries.

[0024]Checksumming codes hidden within the encrypted portion ensure that
the virtual machine itself is not modified. [0025]Allows software
producer to tune the amount of protection based on the amount of overhead
which can be tolerated. [0026]More protection can be applied only to
portions of the application that can tolerate slowdown. [0027]Protection
is complementary to other forms of protection. For example, if new
mechanisms for hiding keys in applications are discovered, the virtual
machine technology can provide continuous obfuscation and tamper
resistance for the new mechanism.

[0028]Aspects of various embodiments of the present invention may provide,
but not limited thereto, the following: [0029]ability to prevent users
from making small, meaningful changes to computer programs, such as
overriding copy protection and timeouts in demonstration software and
other software types. [0030]protect computer software against reverse
engineering which might be used to identify valuable intellectual
property contained within a software algorithm or model. In hardware
design, for example, vendors of application specific integrated circuit
(ASIC) cell libraries often provide precise software models corresponding
to the hardware, so that users can perform accurate system simulations.
Because such a disclosure usually provides sufficient detail to reveal
the actual cell design, it is desirable aspect of the present invention
to protect the content of the software model. [0031]hide secret keys in
software programs and transmissions, so that software programs can sign,
encrypt and decrypt transactions and other software modules. At the same
time, these secret keys stays protected against being leaked.

[0032]An aspect of an embodiment of the present invention provides as
method, system or computer Program product for applying existing
anti-tampering and obfuscation techniques to virtual machine technology
and offers several distinct advantages. The anti-tampering and
obfuscation transforms can be applied continuously to prevent adversaries
from gaining information about the program through emulation or dynamic
analysis. In addition, the encryption of an embodiment of the present
invention can be used to prevent hackers from gaining information using
static attacks. The use of a virtual machine also allows for low overhead
execution of the obfuscated binaries as well as finer adjustment of the
amount of overhead that can be tolerated. In addition, more protection
can be applied to specific portions of the application that can tolerate
slowdown. The incorporation of a virtual machine also makes it easy to
extend the technology to integrate new developments and resistance
mechanisms, leading to less development time, increased savings, and
quicker deployment.

[0033]An aspect of an embodiment or partial embodiment of the present
invention (or combinations of various embodiments in whole or in part of
the present invention) may comprise a computer method of increasing the
tamper-resistance and/or obscurity of computer software code. The method
may comprise preparing the computer software code for execution in a
designated execution environment for making it difficult to execute the
computer software code independently from the designated execution
environment. The method may further comprise preparing the execution
environment so that it impedes execution of computer software code in the
execution environment except for a designated computer software code. The
method may further include applying execution transformations during
execution of a computer software code to improve tamper resistance and/or
obscurity.

[0034]An aspect of an embodiment or partial embodiment of the present
invention (or combinations of various embodiments in whole or in part of
the present invention) may comprise a computer method for preparing the
execution environment so that it impedes execution of computer software
code in the execution environment except for a designated computer
software code. The method further include applying execution
transformations during execution of a computer software code to improve
tamper resistance and/or obscurity.

[0035]An aspect of an embodiment or partial embodiment of the present
invention (or combinations of various embodiments in whole or in part of
the present invention) may comprise a computer method for increasing the
tamper-resistance and/or obscurity of computer software code. The method
may comprise applying execution transformations during execution of a
computer software code to improve tamper resistance and/or obscurity. The
method may further include preparing the computer software code for
execution in a designated execution environment for making it difficult
to execute the computer software code independently from the designated
execution environment.

[0036]An aspect of an embodiment or partial embodiment of the present
invention (or combinations of various embodiments in whole or in part of
the present invention) may comprise a computer system of increasing the
tamper-resistance and/or obscurity of computer software code. The system
may comprise preparation means (or module, device, driver, engine,
system, or hardware) for preparing the computer software code for
execution in a designated execution environment for making it difficult
to execute the computer software code independently from the designated
execution environment. The system may further comprise a preparation
means (module, device, system, or hardware) for preparing the execution
environment so that it impedes execution of computer software code in the
execution environment except for a designated computer software code. The
system may further include an application means (or module, device,
driver, engine, system, or hardware) for applying execution
transformations during execution of a computer software code to improve
tamper resistance and/or obscurity.

[0037]An aspect of an embodiment or partial embodiment of the present
invention (or combinations of various embodiments in whole or in part of
the present invention) may comprise a computer system of increasing the
tamper-resistance and/or obscurity of computer software code. The system
may comprise an execution transformer (or module, device, driver, engine,
system, means, or hardware) for applying execution transformations during
execution of a computer software code to improve tamper resistance and/or
obscurity. The system may further comprise a preparation means (or
module, device, driver, engine, system, or hardware) for preparing the
computer software code for execution in a designated execution
environment for making it difficult to execute the computer software code
independently from the designated execution environment.

[0038]An aspect of an embodiment or partial embodiment of the present
invention (or combinations of various embodiments in whole or in part of
the present invention) may comprise a computer program product comprising
a computer useable medium having computer program logic for enabling at
least one processor in a computer system to increase the
tamper-resistance and/or obscurity of computer software code. The
computer logic comprising: preparing the computer software code for
execution in a designated execution environment for making it difficult
to execute the computer software code independently from the designated
execution environment. The computer program product may further comprise
preparing the execution environment so that it impedes execution of
computer software code in the execution environment except for a
designated computer software code. Further, the computer program product
may include applying execution transformations during execution of a
computer software code to improve tamper resistance and/or obscurity.

[0039]An aspect of an embodiment or partial embodiment of the present
invention (or combinations of various embodiments in whole or in part of
the present invention) may comprise a computer program product comprising
a computer useable medium having computer program logic for enabling at
least one processor in a computer system to operate. The computer logic
may comprise preparing the execution environment so that it impedes
execution of computer software code in the execution environment except
for a designated computer software code. The computer program product may
further include applying execution transformations during execution of a
computer software code to improve tamper resistance and/or obscurity.

[0040]An aspect of an embodiment or partial embodiment of the present
invention (or combinations of various embodiments in whole or in part of
the present invention) may comprise a computer program product comprising
a computer useable medium having computer program logic for enabling at
least one processor in a computer system to increase the
tamper-resistance and/or obscurity of computer software code. The
computer logic may comprise applying execution transformations during
execution of a computer software code to improve tamper resistance and/or
obscurity. The computer program product may further include preparing the
computer software code for execution in a designated execution
environment for making it difficult to execute the computer software code
independently from the designated execution environment.

[0041]These and other objects, along with advantages and features of the
invention disclosed herein, will be made more apparent from the
description, drawings and claims that follow.

BRIEF DESCRIPTION OF THE DRAWINGS

[0042]The accompanying drawings, which are incorporated into and form a
part of the instant specification, illustrate several aspects and
embodiments of the present invention and, together with the description
herein, and serve to explain the principles of the invention. The
drawings are provided only for the purpose of illustrating select
embodiments of the invention and are not to be construed as limiting the
invention.

[0043]FIGS. 1-16 provide a schematic block diagram for various embodiments
of the present invention computer method or system for increasing the
tamper-resistance and/or obscurity of computer software code or other
related.

[0044]FIGS. 17-32 pertains to specific exemplary (and non-limiting)
embodiments as they may pertain to the approach illustrating the present
invention computer method or system embodiments of FIG. 1-16,
respectively.

[0045]FIGS. 33-35 pertain to an exemplary embodiment of the present
invention computer method or system (and related computer program
product) as it pertains to increasing the tamper-resistance and/or
obscurity of computer software code and related. FIG. 33 provides a
schematic block diagram of the Strata architecture with anti-tampering
and obfuscation modules, used to perform dynamic anti-tampering and
obfuscation. FIG. 34 provides a graphical representation of the amount of
application code (as a percent of total application code) that
materializes into the code cache as a function of time. Higher flushing
intervals achieve lower code visibility. FIG. 35 provides a graphical
representation of the runtime overhead of Strata with code cache
flushing. More frequently flushing causes higher overhead.

[0046]FIG. 36(A) is a block diagram of a processor-based system for use
with an embodiment of the present invention.

[0047]FIG. 36(B) is a block diagram of a wireless device for use with one
embodiment of the present invention.

[0048]FIG. 37 is a schematic block diagram for a system or related method
of an embodiment of the present invention in whole or in part.

DETAILED DESCRIPTION OF THE INVENTION

Prepare Computer Software Code

[0049]Referring to FIG. 2, there is provided a schematic block diagram of
the computer method or system 10 (or related method or computer program
product) for increasing the tamper-resistance and/or obscurity of
computer software code 14. The method or related system may comprise
preparing 18 the computer software code 14 for execution in a designated
execution environment 26 for making it difficult to execute the computer
software code 14 independently from the designated execution environment
26.

[0050]In contrast, a previous approach may have allowed the execution of a
computer software code within a generic (i.e., undesignated) execution
environment. Additionally, a previous approach may have defined a wide
range of static obscurity and/or static tamper resistance transformations
(i.e., prior to run time or execution time). Whereas, an aspect of an
embodiment of the present invention provides a method (or system or
computer program product) for only allowing execution of a computer
software code within a specified (i.e., designated) execution
environment. That is, the computer software code is inextricably bound to
the designated execution environment. As an example, codes to verify
integrity of the specified execution environment can be inserted in the
computer software code, thereby increasing the obscurity of the computer
software code and the binding the computer software code to the
designated execution environment. For instance, an example of an
application may involve, but not limited there to, a cell phone, whereby
the cell phone may have a Java VM as the execution environment. See, for
example, Tim Lindholm and Frank Yellin. The Java Virtual Machine
specification, second edition. Addison-Wesley, 1999, of which is hereby
incorporated by reference herein in its entirety. And one may consider a
Java game as a computer software code. An embodiment of the present
invention provides a method (or system or computer program product) that
allows the insertion of checks into the Java game to verify the Java VM's
integrity. Note that this cell phone VM may be different than other Java
VM, even on the same model phone by the same manufacturer and/or may be
ultimately unique to the user.

[0051]The preparation may comprise applying one or more computer software
preparation transformations 16 to the computer software code 14. Further,
the computer software preparation transformation 16 may comprise
encrypting the computer software code. It should be appreciated that the
encryption may be any wide variety of available encryption techniques.
The encryption, for example, may use a plurality of hidden keys.
Moreover, the keys may be hidden within the execution environment 26
and/or prepared software code 22. Similarly, the computer software
preparation transformation 16 may comprise adding additional codes and/or
data to the computer software to verify the integrity of the execution
environment 26. Still yet, the computer software preparation
transformation 16 may comprise providing additional codes and/or data to
the computer software to verify the integrity of the prepared software
code. Still further yet, the computer software preparation transformation
16 may comprise altering the computer software code such that proper
execution (of the prepared software code, for example, but not limited
thereto) is difficult without undoing the alterations. The altering may
include at least one of the following: altering constant operands,
program control flow, program data layout, data initialization
information, instruction encoding, or file format, or any combination
thereof.

Prepare the Execution Environment

[0052]Referring to FIG. 15, there is provided a schematic block diagram of
the computer method or system 10 that may comprise preparing the
execution environment 26 such that it impedes the execution of computer
software code 14 in the execution environment except for a designated
computer software code.

[0053]In contrast, a previous approach may have allowed the execution of a
computer software code within a generic (i.e., undesignated) execution
environment. Additionally, a previous approach may have defined a wide
range of static obscurity and/or static tamper resistance transformations
(i.e., prior to run time or execution time) that could be applied to an
execution environment. Whereas, an embodiment of the present invention
provides a method (or system or computer program product) for only
allowing execution of a designated computer software codes within an
execution environment. That is, the execution environment is inextricably
bound to the designated computer software code. As an example, codes to
verify integrity of the specified designated computer software codes can
be inserted into the execution environment, thereby increasing the
obscurity of the execution environment and the binding the designated
computer software codes to the execution environment. For instance, an
example of an application may involve, but not limited there to, a cell
phone manufacturer that may wish to have a Java VM that only executes the
manufacturer's Java programs. The manufacture could insert integrity
checks into the Java VM to verify that only the manufacturer's program
can be run.

[0054]The preparation may comprise: applying one or more preparation
transformations 34 to the execution environment 26 computer software code
14. The preparation transformation 16 may comprise encrypting some or all
of the execution environment 26. The encryption may use a plurality of
hidden keys. Further, the keys may be hidden within the execution
environment 26 and/or prepared software code 18. Moreover, the
preparation transformation 16 may comprise adding additional codes and/or
data to the computer software to verify the integrity of the computer
software code 14. Still yet, the preparation transformation 34 may
comprise providing additional codes and/or data to the computer software
to verify the integrity of the prepared execution environment 38.

[0055]Next, referring to FIG. 16, provided is a non-limiting example of a
schematic block diagram of the computer method or system of increasing
the tamper-resistance and/or obscurity of computer software code 14 by
preparing both the compute software code 14 and the execution environment
26 as similarly discussed pertaining to FIGS. 2 and 16 above.

Apply Execution Transformations During Execution of a Computer Software
Code

[0056]Referring to FIG. 1, there is provided a schematic block diagram of
the computer method or system 10 for increasing the tamper-resistance
and/or obscurity of computer software code 14.

[0057]In contrast, a previous approach may have allowed applied obscurity
and/or tamper resistance transforms statically (i.e., prior to the
execution of the computer software code). Whereas, an embodiment of the
present invention provides a method (or system or computer program
product) for applying obscurity and/or tamper resistance transforms
dynamically (i.e., during execution of the computer software codes), that
which may possibly in a continuous manner or possibly periodic or random
manner. Furthermore, an embodiment of the present invention provides a
method (or system or computer program product) whereby previously
transformed code and/or data may subsequently be retransformed, thereby
further increasing obscurity and/or tamper resistance. For instance, an
example of an application may involve, but not limited there to, the data
layout of access controlled software in proprietary television set top
boxes that can be changed (i.e. transformed by the execution environment)
every 300 hundred milliseconds of execution, for example. Set top boxes
are subject to persons attempting to gain unauthorized access to set top
services.

[0058]The method or system 10 may comprise applying execution
transformations 34 during execution of a computer software code 14 to
improve tamper resistance and/or obscurity. The execution transformation
may comprise the execution environment changing the layout of computer
software code data. And whereby, the computer software code data may be
data that is used for the execution environment or data to execute the
computer software code 14 or data to execute prepared software code (as
well be discussed below). Further, the execution transformation may
comprises the execution environment using conditions generated during
execution, whereby the conditions are difficult to programmatically
decipher to assist in the tamper-resistance and/or obscurity transforms.
Still yet, the execution transformations may include relocating
operational locations to increase the difficulty of determining operation
locations for making operation's locations difficult to determine. For
instance, disassembly technique. See for example, 22, C. Linn, S. Debray,
and J. Kececioglu.

[0059]Enhancing software tamper-resistance via stealthy address
computations. Proceedings of the 19th Annual Computer Security
Applications Conference (ACSAC 2003), 2003, of which is hereby
incorporated by reference in its entirety. Further yet, the execution
transformations may include inserting additional software code and/or
data to make the execution flow and/or control flow difficult to
determine. The execution transformations may include rearranging,
eliminating, or adding execution flow for making execution flow and/or
control flow difficult to determine. For instance, a control flow
flatting technique. See for example, 33, C. Wang, J. Hill, J. Knight, and
J. Davidson. Software tamper resistance: Obstructing static analysis of
programs. University of Virginia, Charlottesville, Va., 2000, of which is
hereby incorporated by reference in its entirety. Also, the execution
transformations may include creating software code that has operations
that are difficult to determine. Moreover, the execution transformations
may include inserting operations that cannot be feasibly executed, but
appear as though execution is possible. Additionally, the execution
transformations may include inserting incorrect codes that are
intentionally similar to other correct software codes. Yet again, the
execution transformations may include randomizing operation order.
Further, the execution transformations may insert operations to verify
the integrity of software code and/or software data. Moreover, any one of
the execution transformations may comprise at least one of the following:
control flow flattening, guards, disassembly resistance, self
checksumming codes, dynamic disassembly resistance, control flow
obfuscations, ABI transforms, API transforms, sequence transforms,
calling convention transforms or data transform, or any combination
thereof.

[0060]It should be appreciated that the execution environment may be a
variety of available types, including but not limited thereto the
following: software dynamic translation (SDT), virtual machine (VM), Java
VM, Strata VM, program simulators, program emulators, or virtualization
systems, or any combinations thereof.

[0061]It should be appreciated that the e computer software code may be a
variety of available types, including but not limited thereto the
following: binary, byte code, program source, program assembly, program
scripts, machine language, or program intermediate formats, or any
combination thereof. Further, it should be appreciated that the program
scripts may be a variety of available types, including but not limited
thereto the following: Perl, PHP, python, CGI, Java, Java Script, ASP
script, MySQL, Borne shell, bash, tcsh, or csh, or any combinations
thereof.

[0062]Further yet, it should be appreciated that the computer software
code 14 and/or computer software code data may comprises at least one of
the following: prepared computer software code and/or data, unprepared
computer software code and/or data, prepared execution environment code
and/or data, unprepared execution environment code and/or data, or
previously transformed computer software code and/or data, or any
combinations thereof. It should be appreciated that the previously
transformed computer software code and/or data may comprises at least one
of the following: cache, fragment cache, disk, disk drive, RAM, tape,
magnetic tape drive, optical disk drive, or flash memory, or any
combination thereof. For instance, referring to FIG. 3, there is provided
a schematic block diagram of the computer method or system 10 (or related
method or computer program product) whereby execution transformation
occurs on the prepared software code 22. For instance, referring to FIG.
6, there is provided a schematic block diagram of the computer method or
system 10 (or related method or computer program product) whereby the
execution transformation 34 occurs not only on the computer software code
14, but also on the previously transformed computer software code and/or
data of the execution environment software code and/or data 28.

[0063]Similarly, referring to FIG. 5, there is provided a schematic block
diagram of the computer method or system 10 (or related method or
computer program product) whereby execution transformation 34 occurs not
only on the computer software code 14, but also on the prepared execution
environment software code and data 38.

[0064]Similarly, referring to FIG. 7, there is provided a schematic block
diagram of the computer method or system 10 (or related method or
computer program product) whereby execution transformation 34 occurs not
only on the prepared software code 22, but also on the previously
transformed computer software code of the execution environment software
code and data 28.

[0065]Similarly, referring to FIG. 9, there is provided a schematic block
diagram of the computer method or system 10 (or related method or
computer program product) whereby execution transformation 34 occurs not
only on the computer software code 14, but also on the prepared execution
environment software code and data 38, as well as on the previously
transformed computer software code or data of the execution environment
software code and data 28.

[0066]Similar to FIG. 6, FIG. 10 provides a schematic block diagram of the
computer method or system 10 (or related method or computer program
product) whereby execution transformation 34 occurs not only on the
computer software code 14, but also on the previously transformed
computer software code and/or data of the execution environment software
code and data 28.

[0067]Referring to FIG. 11, there is provided a schematic block diagram of
the computer method or system 10 (or related method or computer program
product) comprising preparing 18 the computer software code 14 for
execution in an execution environment 26, but also applying execution
transformation 34 so that it occurs not only on the prepared software
code 22, but also on the previously transformed computer software code
and/or data of the execution environment software code and data 28.
Further, the execution transformation may comprise undoing the
preparation transformations on the prepared software codes.

[0068]Similar to FIG. 9, referring to FIG. 13, there is provided a
schematic block diagram of the computer method or system 10 (or related
method or computer program product) whereby execution transformation 34
occurs not only on the computer software code 14, but also on the
prepared execution environment software code and data 38, as well as on
the previously transformed computer software code and/or data of the
execution environment software code and data.

[0069]Referring to FIG. 4, there is provided a schematic block diagram of
the computer method or system 10 (or related method or computer program
product)comprising preparing 18 the computer software code 14 for
execution in an execution environment 26, but also applying execution
transformation 34 on both the prepared software code 22 and prepared
execution environment 38. Further, the execution transformation may
comprise undoing the preparation transformations on the prepared software
codes.

[0070]Referring to FIG. 8, there is provided a schematic block diagram of
the computer method or system 10 (or related method or computer program
product) comprising preparing 18 the computer software code 14 for
execution in an execution environment 26, but also applying execution
transformation 34 on both the prepared software code 22 and the prepared
execution environment 38 and on the previously transformed computer
software code and/or data of the execution environment software code and
data 28. Further, the execution transformation may comprise undoing the
preparation transformations on the prepared software codes.

[0071]Referring to FIG. 12, there is provided a schematic block diagram of
the computer method or system 10 (or related method or computer program
product) comprising preparing 18 the computer software code 14 for
execution in an execution environment 26, but also applying execution
transformation 34 on the prepared software code 22 and prepared execution
environment 38 and on the previously transformed computer software code
and/or data of the execution environment software code and data 28.

[0072]Referring to FIG. 14, there is provided a schematic block diagram of
the computer method or system 10 (or related method or computer program
product) comprising preparing 18 the computer software code 14 for
execution in an execution environment 26, but also applying execution
transformation 34 on both the prepared software code 22 and on the
previously transformed computer software code and/or data of the
execution environment software code and data 28, and repeat the process
accordingly. Further, the execution transformation may comprise undoing
the preparation transformations on the prepared software codes.

[0073]Some embodiments of the present invention may be implemented in
software for execution by a processor-based system 215, as shown in FIG.
36(A). For example, embodiments may be implemented in code and may be
stored on a storage medium having stored thereon instructions which can
be used to program a system, such as a wireless device to perform the
instructions. The storage medium may include, but is not limited to, any
type of disk including floppy disks, optical disks, compact disk
read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and
magneto-optical disks, semiconductor devices such as read-only memories
(ROMs), random access memories (RAMs), such as a dynamic RAM (DRAM),
erasable programmable read-only memories (EPROMs), flash memories,
electrically erasable programmable read-only memories (EEPROMs), magnetic
or optical cards, or any type of media suitable for storing electronic
instructions, including programmable storage devices.

[0074]In many embodiments of the present invention, the processor-based
system 215 may include a processor 225 coupled to a display 230 and a
system memory 232 through an interface 235. Illustrative interface 235
may be a bridge circuit in one embodiment, or may include one or more
buses in another embodiment. The compiler 238, such as a commercial
compiler, may be loaded into the system memory 232 according to
operations consistent with certain embodiments of the present invention.

[0075]In the processor-based system 215, a primary bus 240 conforming to
the peripheral component interface (PCI) standard, for example, may
couple a network controller 245, a hard disk drive (HDD) 248 and a basic
input/output system (BIOS) to the processor 225 through the interface
235. In this manner, the primary bus 240 may couple to the interface 235
while providing an interface to peripheral devices. For some embodiments
of the present invention, the processor-based system 215 may be
responsible for distributing the compiler-modified code, for example.
Other systems may be implemented in other embodiments of the present
invention.

[0076]In different embodiments, however, wireless devices may be used. A
wireless device 260 in accordance with one embodiment of the present
invention, as shown in FIG. 36(B) may include a semiconductor nonvolatile
memory 300, a user interface 305, a wireless interface 310, and an
antenna 320. In various embodiments, antenna 320 may be a dipole,
helical, global system for mobile (GSM) communication antenna, or the
like. Components of the wireless device 260, which may be a
processor-based device may further include a controller 275, an interface
280, a read only memory (ROM) 285, and a random access memory (RAM) 290
coupled via an internal bus 295, according to one embodiment of the
present invention. The interface 280 may enable communication via the
wireless interface 310 and the antenna 320 to a platform that may
distribute content, e.g., the compiler-modified code, for example.

[0077]Examples of the wireless device 260 may include mobile devices
and/or cellular handsets that may be targeted for providing various
subscriber services by commercial vendors or service providers. To
manipulate such services or simply to activate or reconfigure a device,
content, e.g., the compiler-modified code, for example, may be received
via an over the air interface at the wireless device 260 in one
embodiment.

[0078]Turning to FIG. 37, FIG. 37 is a functional block diagram for a
computer system 400 for implementation of an exemplary embodiment or
portion of an embodiment of present invention. For example, a method or
system of an embodiment of the present invention may be implemented using
hardware, software or a combination thereof and may be implemented in one
or more computer systems or other processing systems, such as personal
digit assistants (PDAs) equipped with adequate memory and processing
capabilities. In an example embodiment, the invention was implemented in
software running on a general purpose computer 400 as illustrated in FIG.
37. The computer system 400 may includes one or more processors, such as
processor 404. The Processor 404 is connected to a communication
infrastructure 406 (e.g., a communications bus, cross-over bar, or
network). The computer system 400 may include a display interface 402
that forwards graphics, text, and/or other data from the communication
infrastructure 406 (or from a frame buffer not shown) for display on the
display unit 430. Display unit 430 may be digital and/or analog.

[0079]The computer system 400 may also include a main memory 408,
preferably random access memory (RAM), and may also include a secondary
memory 410. The secondary memory 410 may include, for example, a hard
disk drive 412 and/or a removable storage drive 414, representing a
floppy disk drive, a magnetic tape drive, an optical disk drive, a flash
memory, etc. The removable storage drive 414 reads from and/or writes to
a removable storage unit 418 in a well known manner. Removable storage
unit 418, represents a floppy disk, magnetic tape, optical disk, etc.
which is read by and written to by removable storage drive 414. As will
be appreciated, the removable storage unit 418 includes a computer usable
storage medium having stored therein computer software and/or data.

[0080]In alternative embodiments, secondary memory 410 may include other
means for allowing computer programs or other instructions to be loaded
into computer system 400. Such means may include, for example, a
removable storage unit 422 and an interface 420. Examples of such
removable storage units/interfaces include a program cartridge and
cartridge interface (such as that found in video game devices), a
removable memory chip (such as a ROM, PROM, EPROM or EEPROM) and
associated socket, and other removable storage units 422 and interfaces
420 which allow software and data to be transferred from the removable
storage unit 422 to computer system 400.

[0081]The computer system 400 may also include a communications interface
424. Communications interface 424 allows software and data to be
transferred between computer system 400 and external devices. Examples of
communications interface 424 may include a modem, a network interface
(such as an Ethernet card), a communications port (e.g., serial or
parallel, etc.), a PCMCIA slot and card, a modem, etc. Software and data
transferred via communications interface 424 are in the form of signals
428 which may be electronic, electromagnetic, optical or other signals
capable of being received by communications interface 424. Signals 428
are provided to communications interface 424 via a communications path
(i.e., channel) 426. Channel 426 (or any other communication means or
channel disclosed herein) carries signals 428 and may be implemented
using wire or cable, fiber optics, blue tooth, a phone line, a cellular
phone link, an RF link, an infrared link, wireless link or connection and
other communications channels.

[0082]In this document, the terms "computer program medium" and "computer
usable medium" are used to generally refer to media or medium such as
various software, firmware, disks, drives, removable storage drive 414, a
hard disk installed in hard disk drive 412, and signals 428. These
computer program products ("computer program medium" and "computer usable
medium") are means for providing software to computer system 400. The
computer program product may comprise a computer useable medium having
computer program logic thereon. The invention includes such computer
program products. The "computer program product" and "computer useable
medium" may be any computer readable medium having computer logic
thereon.

[0083]Computer programs (also called computer control logic or computer
program logic) are may be stored in main memory 408 and/or secondary
memory 410. Computer programs may also be received via communications
interface 424. Such computer programs, when executed, enable computer
system 400 to perform the features of the present invention as discussed
herein. In particular, the computer programs, when executed, enable
processor 404 to perform the functions of the present invention.
Accordingly, such computer programs represent controllers of computer
system 400.

[0084]In an embodiment where the invention is implemented using software,
the software may be stored in a computer program product and loaded into
computer system 400 using removable storage drive 414, hard drive 412 or
communications interface 424. The control logic (software or computer
program logic), when executed by the processor 404, causes the processor
404 to perform the functions of the invention as described herein.

[0085]In another embodiment, the invention is implemented primarily in
hardware using, for example, hardware components such as application
specific integrated circuits (ASICs). Implementation of the hardware
state machine to perform the functions described herein will be apparent
to persons skilled in the relevant art(s).

[0086]In yet another embodiment, the invention is implemented using a
combination of both hardware and software.

[0087]In an example software embodiment of the invention, the methods
described above may be implemented in SPSS control language or C++
programming language, but could be implemented in other various programs,
computer simulation and computer-aided design, computer simulation
environment, MATLAB, or any other software platform or program, windows
interface or operating system (or other operating system) or other
programs known or available to those skilled in the art.

[0088]Further, it should be appreciated that software or code and data
transferred via communications interface or other give modules may be in
the form of signals which can be electronic, electromagnetic, optical or
other signals capable of being received by communications interface or
other modules. The invention is described in these terms for convenience
purposes only. Further, it should be clear to one skilled in the art that
the invention may be applied to a variety of computer or control systems.
Such systems would include all manner of appliances having computer or
processor control including telephones, mobile telephones, cellular
telephones, televisions, multimedia, games, video games, television set
top units, lap top computers, personal digital assistants (PDAs),
satellites, mobile computers, media players, satellite set top, cable set
top, digital rights management (DRM), digital rights adapters (DTAs),
music players, and automobiles or other land, air, or water vehicles.

[0089]Further, it should be appreciated that any of the modules,
apparatuses, machines, sub-machines, components, sub-components, systems,
sub-systems, software, hardware, firmware, means, drivers, engines,
integrated circuits (ICs), and/or application specific integrated
circuits (ASICs) disclosed herein may be interchangeable with one another
to practice the invention.

[0094]Further, it should be clear to one skilled in the art that the
invention may be applied to a variety of computer or control systems and
their intended applications such as business policy, business assets,
various applications such as data bases in enterprise data centers to
consumer devices.

[0095]An aspect of various embodiments of the present invention may
provide a number of novel and nonobvious features, elements and
characteristics, such as but not limited thereto, the following:

[0096]A strong method for binding a software dynamic translation system
(or any virtual machine) to an application, such that the application
cannot be run without the SDT;

[0098]Dynamically applying program obfuscation within a virtual machine;

[0099]A new approach to self-checksumming that is more difficult to
circumvent than previously proposed techniques;

[0100]The various embodiments of the invention may be used to vaccinate an
executable from attack via a virus. Since the executable is resistant
even from manual modification, viruses cannot automatically insert copies
of themselves;

[0101]Use of a strong encryption algorithm (such as an encryption
algorithm like PKI, symmetric and asymmetric) to guarantee that
application text cannot be modified to remove self checksumming guard
code;

[0103]Using dynamic obfuscations specifically designed to keep an
intelligent adversary from manually or programmatically merging code
fragments from different executions of the program.

Examples and Experimental Results

[0104]Practice of the invention will be still more fully understood from
the following examples and experimental results, which are presented
herein for illustration only and should not be construed as limiting the
invention in any way.

Example Nos. 1-16

[0105]See FIGS. 17-32, which pertain to specific exemplary (and
non-limiting) embodiments as they may pertain to the approach
illustrating the present invention computer method, system or computer
program product embodiments of FIG. 1-16, respectively.

Example No. 17

[0106]An aspect of the embodiment of the present invention provides a way
to protect an application using a virtual machine and a variety of
mechanisms to make sure that the virtual machine cannot be modified.
First, the application's code segment is encrypted. The encrypted text
has code to checksum itself and the virtual machine. As the application
requests new fragments to execute, the virtual machine decrypts portions
of the application's code segment, applies anti-tampering (including
dynamic self-checksumming) and obfuscation (including dynamic resistance
to disassembly, dynamic control flow graph hiding, dynamic instruction
isomorphisms, dynamic dead code, and dynamic code scheduling) techniques
to prevent revealing the application's instructions during execution.
Combined with frequent flushing of the virtual machine's fragment cache,
this invention provides significantly stronger protection than
statically-applied anti-tampering and obfuscation alone.

[0107]Most anti-tampering and obfuscation schemes require the application
to be in an executable format. Whereas an aspect of the present invention
leverages the security of a strongly encrypted binary by relying on
Strata to perform just-in-time decryption.

[0108]To provide strong assurance against any static attacks, the
invention uses a proven strong encryption algorithm, such as AES [See 29,
D. Lie, C. Thekkath, M. Mitchell, P. Lincoln, D. Boneh, J. Mitchell, and
M. Horowitz. Architectural support for copy and tamper resistant
software. ACM SIGPLAN Notices, 35(11):168-177, 2000, of which is hereby
incorporated by reference in its entirety]. The entire text segment of
the application is encrypted and remains that way for the entire
execution of the program. When a new PC from the executable is requested
to be translated, the block(s) containing the application code are copied
to a buffer, and the buffer is decrypted, the requested instruction(s)
are translated into the fragment cache, and the buffer is zeroed to
prevent decrypted code from being present longer than necessary. FIG. 33
shows an illustration. In the figure, the "hatched" portion on the right
represents the application which has been encrypted--prepared software
code 22. Strata 26, of course, needs to run on the processor to decrypt
the application, and cannot be encrypted. Likewise, the fragment cache 38
cannot be encrypted.

[0109]Strata itself can remain unencrypted as understanding Strata
provides little understanding of the encrypted application. That is not
to say that Strata does not need protection from tampering, but the
understanding of Strata need not be kept secret. The fragment cache,
however, can neither be encrypted (as it must contain instructions that
run on standard hardware) nor can it be easily left unprotected as it
contains the instructions needed to run the application.

[0110]Like the fragment cache, the decryption key must be protected. If
this key is available (dynamically or statically), then the adversary can
scan memory to discover it, and easily decrypt the entire text segment
and find out the contents of the original

[0111]Strata must have the ability to decrypt the application text in
order to run the program. However, in most circumstances it is not
necessary to have a 128-bit encryption key unprotected in memory. The
approach we use to protect the key is the same as outlined by Chow [See
5, S. Chow, P. Eisen, H. Johnson, and P. C. van Oorschot. White-box
cryptography and an AES implementation. Proceedings of the Ninth Workshop
on Selected Areas in Cryptography (SAC 2002), 2002. and See 20, H. E.
Link and W. D. Neumann. Clarifying obfuscation: Improving the security of
white-box encoding. Sandia National Laboratories, Albuquerque, N.M.,
downloaded from eprint.iacr.org/2004/025.pdf, 2004, both of which are
hereby incorporated by reference herein in their entirety.]. Basically,
the constant key is propagated throughout the decryption routine, and
random bijections are used at each step of the AES computation to make
the key significantly harder to extract. Unfortunately, the key is not
impossible to extract, but it does take significant computation time [See
3, O. Billet, H. Gilbert, and C. Ech-Chatbi. Cryptanalysis of a white box
AES implementation, 2004, of which is hereby incorporated by reference
herein in its entirety]. An embodiment of the invention may counter this
weakness by having different portions of an application encrypted by
different keys (represented by different patterning in FIG. 33). Some
portions are encrypted repeatedly, to make it harder for the attacker to
recover AES keys and decrypt the binary.

[0112]By having the key(s) protected in this manner, it is difficult for
an attacker to extract the key(s) needed to decrypt the program.
Furthermore, even if they can observe the decryption buffer, it is very
difficult for an attacker to make small changes to the applications text
segment. For example, if a decryption block contains a guard, and other
instructions necessary for the program to run, the attack cannot convert
the guard code to no-operation instructions without knowing the key used
to encrypt that block. An embodiment of the invention can provably avoid
the ability for an attacker to encrypt code to make small changes by
using an encryption algorithm (e.g., symmetric and asymmetric).

[0113]For the encryption to be useful, the embodiment of the invention
shall ensure that even if an adversary is able to decrypt the binary,
which the binary may only run under Strata's control. To achieve this
goal, the embodiment of the invention provides two mechanisms. The first
is that there are self-checksumming guards within the encrypted
executable. These guards not only checksum the application, but also
checksum Strata's code. Secondly, the decrypted code need not execute
properly on any standard machine. A variety of obfuscations are possible
that would break normal code, but under Strata's control can be "undone"
at translation times. For example, most call instructions specify a
target address. The binary form could have an address f (addr) specified,
and when Strata translates the instruction it applies f1 (addr) to
the address. There are an infinite number of one-to-one onto functions
that could be applied to varying types of instructions: Opcodes could be
shuffled, addressing mode bits could be shuffled, instruction lengths
could be arbitrarily increased, the "next instruction" calculation could
be changed, or a variety of difficult to undo transformations applied.
Together, these techniques make it very difficult for an attacker to
successfully run the program without Strata performing the translation.

[0114]Although the static protection model outlined above is quite strong,
it may still be possible for an adversary to monitor the dynamic
execution of the program. For example, the adversary may be able to
snapshoot the contents of the fragment cache at any point. If the
fragment cache is an exact (or close) representation of the entire
program, the adversary can easily snapshot the program and perform
standard attacks on the unprotected code.

[0115]To combat this problem, an embodiment of the invention applies a
variety of dynamic protections.

[0116]A key to software dynamic translation is the fragment cache and good
locality of the code within it. Unfortunately, for anti-tampering and
obfuscation, this locality is perhaps also SDT's greatest weakness. As
the program executes, the program's encrypted code gets decrypted (as
needed) and materializes in the fragment cache. If an adversary can
capture the contents of the code cache just before program termination,
they can get a snapshot of all the instructions needed to run the
program. Luckily a solution is easy: flush the fragment cache
periodically. Taken to the limit, the fragment cache could be flushed
after each instruction is executed. Per instruction flushing would leak
the minimum amount of information about the application as it executes;
an adversary would never learn more than one application instruction from
any inspection of memory. Unfortunately flushing the code cache after
every instruction causes the system to spend most of its time flushing
and regenerating fragments into the code cache, and very little time
executing application instructions.

[0117]Instead, the code cache needs to be flushed at an interval in which
little information is leaked about the application instructions, yet high
efficiency is maintained. Flushing the code cache periodically hides
information from an adversary, but if much of the application
materializes in the code cache very quickly (say, in half the flushing
interval or less), the amount of hiding may be minimal. To determine how
much information hiding is occurring, consider FIG. 34. The figure shows
the percentage of gcc's application text that is materialized into the
code cache over the course of a single execution of the program. From the
figure, we can conclude that even basic software dynamic translation
keeps less than 45% of the application text from being visible. Flushing
every 10 seconds does provide some benefit, much of the application is
needed only during startup or shutdown, and is discarded shortly after 10
seconds into the execution of the program. Flushing every second does
significantly better at keeping the application's text hidden. For a
majority of the program's execution, less than 10% of the application's
text resides in the fragment cache! Flushing every 0.1 seconds does even
better; most of the time less than 3% of gcc's text is visible in the
code cache.

[0118]We have performed preliminary measurements on the cost of flushing
the fragment cache, shown in FIG. 35. The graph shows the performance of
our SDT system, Strata, for the C benchmarks in the SPEC2000 benchmark
suite. The first bar shows the overhead with no fragment cache flushing.
Overhead averages about 18% slower than native execution. The next three
bars show flushing the cache every 10 seconds, 1 second, and 0.1 seconds.
Overhead averages 19%, 23%, and 47% respectively. Obviously, blindly
flushing every 10th of a second provides significant overhead, but
results are encouraging that flushing every 1 second provides less than
5% additional overhead. Furthermore, we believe that flushing
intelligently may have additional benefits. For example, by selectively
flushing only fragments that have not been used recently we can hide
dynamic information from an adversary without impacting performance.
Also, we expect (selectively) flushing the code cache after a program
phase is complete can hide information with little performance loss.

[0119]In our prototype implementation, the operating system must send a
signal to the application in order for Strata to know that the code cache
should be flushed. A malicious operating system could bypass the flushing
mechanism by not delivering the signal. Other techniques, such as having
fragments "expire" after being executed a predetermined number of times
can provide a stronger guarantee about ensuring the code cache is flushed
after a certain number of fragments are executed.

[0120]Flushing the code cache can keep any one snapshot from revealing
much about the application, but an adversary may take multiple snapshots
of memory and attempt to piece together the contents of the entire
application. To prevent an adversary from being able to easily piece
together the code necessary to run the application, Strata can apply
obfuscating transformations at fragment translation time. To serve as the
base of a variety of dynamic transformations, we introduce the concept of
a dynamic opaque predicate.

[0121]An opaque predicate is a predicate that is known at compile-time,
but is very difficult (NP-Hard) to determine statically once compilation
is complete. Although these predicates provide strong resistance to
static attacks, they provide little strength against dynamic attacks
because once an opaque predicate is calculated dynamically, an adversary
knows all the information about the predicate. By creating an opaque
predicate that is known at fragment creation time, or a dynamic opaque
predicate, it becomes significantly more difficult for an adversary to
know which of the conditional branches are highly biased simply to
provide obfuscating transformations, and which is part of the program.

[0122]Upon the concept of a dynamic opaque predicate, the dynamic
translation system can apply dynamic versions of many static obfuscation
techniques. Some of the most powerful are disassembly resistance and
control flow graph obfuscation.

[0123]One way to obfuscate the code cache is to make it difficult to
determine which portions of the code cache are instructions and which
portions are not. By inserting a dynamically generated opaque predicate,
the translator can use the never taken direction to 1) insert
instructions that branch to a location in the code cache that is not
actually a valid instruction, or 2) insert partial "instructions."
Inserting this information will make an automatic disassembler become out
of synchronization with the actual instruction stream. By branching to a
non-instruction, a recursive-descent disassembler soon has trouble
determining which instructions are actual branch targets and which ones
are not. By inserting partial "instructions", a linear scan disassembler
quickly becomes out of sync.

[0124]If the code that is designed to confuse disassemblers has
predictable placement or makes up only a small portion of the fragment
cache, the security measures can easily be thwarted. On the other hand,
if calculating the predicate and performing the branch is done too
frequently, performance can suffer. One technique that may be useful is
to place more security in less frequently executed fragments.

[0125]Dynamic opaque predicates can provide an efficient mechanism to make
it more difficult to automatically disassemble the fragment cache.
However, it is also important to make it difficult to extract the
program's control flow graph. If each rematerialization of the fragment
cache has the same control flow graph, it may be possible for an
adversary to use the control flow information to stitch together many
fragment cache snapshots to gain complete knowledge of the application.
To avoid any control flow graph information leakage, a technique similar
to disassembly resistance is used. The invention uses a dynamically
generated opaque predicate to provide a mechanism in which each fragment
appears to jump to many other fragments, but only certain paths can
actually be taken. These paths will contain conditional jumps,
unconditional jumps, calls (including argument passing code), hard to
analyze indirect jumps, returns (including stack tear-down code), and
combinations of these techniques.

[0126]Such a technique provides a good way to provide false information
about the control flow graph, but does not allow the real control flow
graph to be obscured. It is possible to convert some direct jumps and
calls into indirect versions. By having the target of the indirect branch
calculated using opaque predicates to obfuscate the actual target, we can
force the adversary to observe the execution of some branches in order to
accurately determine the control flow graph for even a single fragment
cache snapshot.

[0127]Compiler writers have long known that there are many efficient
instruction sequences to achieve a goal. For example, on the IA-32, the
following instructions are equivalent: a) add % eax, #1 b) sub % eax, #-1
and c) lea % eax, % eax+1 all add the constant 1 to the register eax.
There are even more options if the constant 1 or -1 is stored in memory
and a complex addressing mode is used instead of an immediate addressing
mode. A dynamic translation system can use an instruction set's variety
to generate each fragment using different instruction opcodes and
addressing modes. Since an application's instructions will be translated
differently each time, it becomes more difficult for an adversary to
piece together multiple fragment cache snapshots to form a complete
picture of the application's code.

[0128]Unfortunately, an adversary may try to produce a canonical form for
each instruction. Our example add instructions could all be converted to
eax=eax+1, for example. To combat this approach, the translator can
perform a many-to-many transformation on several data-dependent
instructions. By moving operations between instructions it becomes
significantly more difficult to form any canonical form that is
equivalent to corresponding code from another fragment cache snapshot. To
solve this problem, an adversary must form data dependence graphs for
each fragment in a snapshot of the code cache, and try to match graphs
from each snapshot. This is a difficult, NP-Hard problem for even two
snapshots. With frequent flushing, there may be hundreds or thousands of
code cache snapshots that need to be matched. Thus, undoing the
isomorphism transformations would be extremely difficult, if not
intractable.

[0129]Although many-to-many instruction isomorphisms can provide a
significant resistance to revealing the application's instruction
sequence, they may also be expensive to calculate or more expensive
during execution. Careful consideration is needed when deciding how and
when to utilize instruction isomorphisms as well as how to efficiently
calculate them. One promising avenue of research is to pre-calculate the
most needed many-to-many transformations at compile time and store them
in the executable in encrypted form. The translator can carefully look up
these isomorphisms and apply them with minimal overhead.

[0130]Compilers spend significant effort trying to eliminate dead (never
executed) or useless code. An SDT system can carefully insert dead or
useless code for the purposes of obfuscation. For example, the translator
can insert instructions from other parts of the application to make it
hard to line up fragments from multiple fragment cache snapshots. Dead
code can be inserted in a critical algorithm to make the dataflow or
control flow harder to understand. Furthermore, non-working versions of a
critical algorithm can be intermixed with other code that is less
important in order to distract an adversary into analyzing the wrong
portions of code or being unable to determine which version of the code
is the correct version.

[0131]Another way to make fragment cache snapshots appear different and
force an adversary to perform NP-hard data dependence graph matching is
to dynamically reschedule the code. The dynamic translation system can
perform traditional instruction scheduling on each fragment as it is
created, but use different evaluation criteria (including a pseudo-random
number generator) for making scheduling decisions during each time frame.
Perhaps of more importance is that any dynamically generated code for
obfuscation or anti-tampering will be dispersed within the application's
instructions.

[0132]Dynamically generating and using opaque predicates and other
obfuscations can make it more difficult for an adversary to understand
how many snapshots of the fragment cache may work together, but does not
directly protect the fragment cache from changes being applied. To
provide more direct protection for the fragment cache, the invention
alters Strata to insert self-checksumming code into the fragment cache.
This code performs checksums on the fragment cache directly. Like static
self-checksums, the code in the fragment cache calculates and verifies
that portions of the code (the original application's code, Strata's
code, and most importantly code within the fragment cache) are
unmodified. Also like static self checksumming, when a guard fails, it
must alter the program's execution in such a way that the program is no
longer usable. However, unlike static self checksumming, since guards are
generated dynamically and randomly during dynamic translation, revealing
the guard's location once a failure occurs is of little concern: the
guard will be different on future executions of the program. An important
aspect may be, however, that the guard cannot be revealed until it has
failed, thus it must not simply execute an instruction sequence to abort
the program. Instead, the guard will use a dynamic opaque predicate to
help calculate an indirect branch target, such that it is not clear that
an abort is going to happen until the guard fails.

[0133]Considering the importance of tamper resistance, much work has been
done in this area. Perhaps the most widely known is self-checksumming.
Horne, et al. describe how guards or testers are inserted throughout the
application [See 12, B. Horne, L. R. Matheson, C. Sheehan, and R. E.
Tarjan. Dynamic self-checking techniques for improved tamper resistance.
Digital Rights Management Workshop, pages 141-159, 2001, of which is
hereby incorporated by reference in its entirety.]. Each guard checksums
a portion of the application's code (including other guards) and fails
subtly if a modification is detected. Wurster, et al. quickly noted a
simple work around to the guards: separate program and data memory [See
34, G. Wurster, P C van Oorschot, and A. Somayaji. A generic attack on
checksumming-based software tamper resistance. Proceedings of the 2005
IEEE Symposium on Security and Privacy, pages 127-138, 2005, and See 32,
P. C. van Oorschot, A. Somayaji, and G. Wurster. Hardware-assisted
circumvention of self-hashing software tamper resistance. IEEE
Transactions on Dependable and Secure Computing, 2(2):82-92, 2005, both
of which are hereby incorporated by reference in their entirety.]. Giffin
noted a way to prevent this attack with the addition of self-modifying
guard code [See 10, J. T. Giffin, M. Christodorescu, and L. Kruger.
Strengthening software self-checksumming via self-modifying code.
Proceedings of the 21st Annual Computer Security Applications Conference,
pages 23-32, 2005, of which is hereby incorporated by reference in its
entirety]. Neither technique, however, provides resistance to dynamic
techniques that identify guards and remove them. Indeed, the
self-modifying code may make the guards harder to disguise as most
programs do not use any form of self modification.

[0135]Encrypting the binary to provide resistance to tampering,
obfuscation, and anti-piracy was proposed long ago but was believed to
require hardware for efficiency purposes [See 19, D. Lie, C. Thekkath, M.
Mitchell, P. Lincoln, D. Boneh, J. Mitchell, and M. Horowitz.
Architectural support for copy and tamper resistant software. ACM SIGPLAN
Notices, 35(11):168-177, 2000, and See 24, T. Maude and D. Maude.
Hardware protection against software piracy. Communications of the ACM,
27(9):950-959, 1984, both of which are hereby incorporated by reference
in their entirety]. The use of ultra-efficient software dynamic
translation has enabled us to use encryption to prevent code injection
attacks with little overhead [See 13, Wei Hu, Jason D. Hiser, Daniel
Williams, Adrian Filipi, Jack W. Davidson, David Evans, John C. Knight,
Anh Nguyen-Tuong, and Jonathan Rowanhill. Secure and practical defense
against code-injection attacks using software dynamic translation. In
Proceedings of the 2nd International Conference on Virtual Execution
Environments, pages 2-12. ACM Press New York, N.Y., USA, 2006, of which
is hereby incorporated by reference in its entirety]. Our proposed
techniques use SDT to help provide a system that uses encryption without
sacrificing efficiency.

[0136]The largest portion of tamper-resistance research involves making
the program difficult to understand. It is widely believed that some
level of understanding of the program is necessary in order to make
meaningful modifications. For example, if self-checksumming is used, it
is necessary to understand which instructions are needed for the self
checksumming and which are needed for execution of the program before
changes can be made. Techniques that make it difficult to understand a
program may actually be best described as obfuscations. Previous
obfuscation work can be classified into two types: static and dynamic.

[0137]Static obfuscation techniques aim to make the program difficult to
statically analyze [See 8, C. Collberg, C. Thomborson, and D. Low.
Manufacturing cheap, resilient, and stealthy opaque constructs. In
Proceedings of the 25th ACM SIGPLAN-SIGACT Symposium on Principles of
Programming Languages, pages 184-196. ACM Press New York, N.Y., USA,
1998, See 17, C. Kruegel, W. Robertson, F. Valeur, and G. Vigna. Static
disassembly of obfuscated binaries. In Proceedings of the 13th USENIX
Security Symposium, Berkeley, Calif., USA, 2004. USENIX Association, See
22, C. Linn, S. Debray, and J. Kececioglu. Enhancing software
tamper-resistance via stealthy address computations. Proceedings of the
19th Annual Computer Security Applications Conference (ACSAC 2003), 2003,
and See 33, C. Wang, J. Hill, J. Knight, and J. Davidson. Software tamper
resistance: Obstructing static analysis of programs. University of
Virginia, Charlottesville, Va., 2000, all of which are hereby
incorporated by reference in their entirety]. This can be done by using
problems that are known to be NP-Hard to solve statically. One example is
using alias analysis to create opaque constructs [See 8, C. Collberg, C.
Thomborson, and D. Low. Manufacturing cheap, resilient, and stealthy
opaque constructs. In Proceedings of the 25th ACM SIGPLAN-SIGACT
Symposium on Principles of Programming Languages, pages 184-196. ACM
Press New York, N.Y., USA, 1998, of which is hereby incorporated by
reference in its entirety] to prevent easy disassembly of the program
[See 21, C. Linn and S. Debray. Obfuscation of executable code to improve
resistance to static disassembly. Proceedings of the 10th ACM conference
on Computer and Communications Security, pages 290-299, 2003, of which is
hereby incorporated by reference in its entirety.]. Another example is
using aliases to obscure the program's control flow graph [See 33, C.
Wang, J. Hill, J. Knight, and J. Davidson. Software tamper resistance:
Obstructing static analysis of programs. University of Virginia,
Charlottesville, Va., 2000, of which is hereby incorporated by reference
in its entirety.]. Although these techniques provide very powerful
guarantees about the information that can be gained from static analysis,
they provide little strength against attacks that observe the execution
of the program. For example, tracing the instruction sequence with a
simulator provides exact information for disassembling the program. An
aim was to provide resistance against all forms of attacks, including
attacks that combine static and dynamic information.

[0138]Another class of obfuscation techniques are dynamic obfuscations
which make static attacks difficult by using self-modifying code to
obscure where the program's instructions are located [See 23, M. Madou,
B. Anckaert, P. Moseley, S. Debray, B. De Sutter, and K. De Bosschere.
Software protection through dynamic code mutation. Proceedings of the 6th
International Workshop on Information Security Applications (WISA, pages
194-206, 2005, See 2, D. Aucsmith. Tamper resistant software: an
implementation. In Proceedings of the First International Workshop on
Information Hiding, pages 317-333. Springer-Verlag London, UK, 1996, and
See 15, Y. Kanzaki, A. Monden, M. Nakamura, and K. Matsumoto. Exploiting
self-modification mechanism for program protection. Proceedings of the
27th Annual International Computer Software and Applications Conference,
pages 170-179, 2003, all of which are hereby incorporated by reference in
their entirety.]. One example uses edit scripts [See 23, M. Madou, B.
Anckaert, P. Moseley, S. Debray, B. De Sutter, and K. De Bosschere.
Software protection through dynamic code mutation. Proceedings of the 6th
International Workshop on Information Security Applications (WISA, pages
194-206, 2005, of which is hereby incorporated by reference in its
entirety.]. The edit scripts are run by an editing engine that patches
functions just before execution and hides the function after execution.
For efficiency, the replacement is done "in place." Again, an adversary
that is observing the dynamic instruction trace may be able to remove the
editing scripts and place the correct functions in the proper place. Our
work strives to make this impossible by continually performing
obfuscations and applying tamper-resistant guards. Perhaps the strongest
dynamic technique was proposed by Aucsmith, et al. [See 2, D. Aucsmith.
Tamper resistant software: an implementation. In Proceedings of the First
International Workshop on Information Hiding, pages 317-333.
Springer-Verlag London, UK, 1996, of which is hereby incorporated by
reference in its entirety.]. This technique involves the creation and
execution of "integrity verification kernels" that each use and generate
cryptographic keys. Multiple threads are executed in a nondeterministic
manner to make it difficult for an adversary to trace the execution of
the program. Unfortunately, it is unclear how to implement this
technique, especially if program efficiency is a concern.

[0139]An interesting, but related subject is software aging or evolution
[See 6, F. B. Cohen. Operating system protection through program
evolution. Computers and Security, 12(6):565-584, 1993, and See 14, M.
Jakobsson and M. Reiter. Discouraging software piracy using software
aging. Digital Rights Management Workshop, pages 1-12, 2001, both of
which are hereby incorporated by reference in their entirety.]. Software
aging techniques attempt to mitigate the cost of piracy by continually
updating software with new cryptographic keys. Pirated software fails to
get the updates, and soon becomes significantly less useful, or incurs
large performance overhead. Unfortunately, these techniques are only
applicable to document-centric applications. Furthermore, by themselves,
they provide little resistance to tampering with a system.

[0206]Unless clearly specified to the contrary, there is no requirement
for any particular described or illustrated activity or element, any
particular sequence or such activities, any particular size, speed,
material, duration, contour, dimension or frequency, or any particularly
interrelationship of such elements. Moreover, any activity can be
repeated, any activity can be performed by multiple entities, and/or any
element can be duplicated. Further, any activity or element can be
excluded, the sequence of activities can vary, and/or the
interrelationship of elements can vary. It should be appreciated that
aspects of the present invention may have a variety of sizes, contours,
shapes, compositions and materials as desired or required.

[0207]In summary, while the present invention has been described with
respect to specific embodiments, many modifications, variations,
alterations, substitutions, and equivalents will be apparent to those
skilled in the art. The present invention is not to be limited in scope
by the specific embodiment described herein. Indeed, various
modifications of the present invention, in addition to those described
herein, will be apparent to those of skill in the art from the foregoing
description and accompanying drawings. Accordingly, the invention is to
be considered as limited only by the spirit and scope of the following
claims, including all modifications and equivalents.

[0208]Still other embodiments will become readily apparent to those
skilled in this art from reading the above-recited detailed description
and drawings of certain exemplary embodiments. It should be understood
that numerous variations, modifications, and additional embodiments are
possible, and accordingly, all such variations, modifications, and
embodiments are to be regarded as being within the spirit and scope of
this application. For example, regardless of the content of any portion
(e.g., title, field, background, summary, abstract, drawing figure, etc.)
of this application, unless clearly specified to the contrary, there is
no requirement for the inclusion in any claim herein or of any
application claiming priority hereto of any particular described or
illustrated activity or element, any particular sequence of such
activities, or any particular interrelationship of such elements.
Moreover, any activity can be repeated, any activity can be performed by
multiple entities, and/or any element can be duplicated. Further, any
activity or element can be excluded, the sequence of activities can vary,
and/or the interrelationship of elements can vary. Unless clearly
specified to the contrary, there is no requirement for any particular
described or illustrated activity or element, any particular sequence or
such activities, any particular size, speed, material, dimension or
frequency, or any particularly interrelationship of such elements.
Accordingly, the descriptions and drawings are to be regarded as
illustrative in nature, and not as restrictive. Moreover, when any number
or range is described herein, unless clearly stated otherwise, that
number or range is approximate. When any range is described herein,
unless clearly stated otherwise, that range includes all values therein
and all sub ranges therein. Any information in any material (e.g., a
United States/foreign patent, United States/foreign patent application,
book, article, etc.) that has been incorporated by reference herein, is
only incorporated by reference to the extent that no conflict exists
between such information and the other statements and drawings set forth
herein. In the event of such conflict, including a conflict that would
render invalid any claim herein or seeking priority hereto, then any such
conflicting information in such incorporated by reference material is
specifically not incorporated by reference herein.