Protecting Commercial Off-the-Shelf Program Binaries from Theft Using Hardware Enclaves

Abstract

This disclosure describes a system and method for protecting commercial off-the-shelf software program code from theft. The software program may include multiple image files with code and data. The platform may modify the executable file so that the data can be placed in a location in memory any distance from the code. The platform may encrypt the code and provide it to a computing device with a hardware enclave. The computing device may load the encrypted code into the hardware enclave but load the data into memory outside the hardware enclave. The computing device may request a decryption key from an authentication server using a hash of the hardware enclave signed by the processor. The authentication server may provide the decryption key if it verifies the signature and hash. The computing device may decrypt the code and mark the hardware enclave as unreadable.

Description

Background Art

[0001]

[0001] Computing devices can be used to perform a variety of tasks. Software developers can design and create software programs for use on computing devices. Users of computing devices can use software applications to perform tasks. For example, a user of a computing device can use an Internet browser application to access information on the Internet and then use a presentation application to create a presentation that communicates the information obtained from the Internet. A software application can include several different files, including executable files.

[0002]

[0002] Software developers may be concerned about software piracy. Software piracy can occur when an end user purchases or obtains a copy of an application, makes an unauthorized copy of that application, uses the unauthorized copies, or distributes them to third parties. Preventing piracy can be difficult because attackers often have complete control of the computing devices and systems on which the application is run.

Summary of the Invention

[0003]

[0003] According to one aspect of the present disclosure, a method for protecting software from piracy is disclosed. The method includes receiving a plurality of binary files. Each binary file includes code and data. The method further includes modifying the plurality of binary files such that the data of each binary file can be located at any distance in memory from the code of that binary file. The method further includes encrypting the code of each binary file. The method further includes receiving a request for a decryption key from a computing device. The computing device may include a hardware enclave. The encrypted code of each binary file may be stored within the hardware enclave, but the data of each binary file is not stored within the hardware enclave.

[0004]

[0004] The method may further include providing the decryption key to the computing device.

[0005] The method may further include authenticating a processor signature before providing the decryption key. The processor of the computing device generates a processor signature, and the request for the decryption key may include the processor signature.

[0005]

[0006] The method may further include verifying a hash before providing the decryption key. The request for the decryption key may include the hash.

[0007] The step of modifying the plurality of binary files may include identifying data references within the code of each binary file and modifying the data references.

[0006]

[0008] The step of modifying the plurality of binary files may be performed without access to source code or debug symbols for the plurality of binary files.

[0009] The method may further include the step of adding a separation header to each of a plurality of binary files. The separation header may indicate that the data of each of the plurality of binary files can be placed at any distance in memory from the code of that binary file.

[0007]

[0010] According to another aspect of the present disclosure, a system for facilitating protecting a software program from piracy is disclosed. The system includes one or more processors, a memory in electronic communication with the one or more processors, and instructions stored in the memory. The instructions are executable by the one or more processors to receive a plurality of binary files, each binary file including code and data. The instructions are also executable by the one or more processors to modify the plurality of binary files such that the data of each binary file can be located at any distance in memory from the code of that binary file. The instructions are also executable by the one or more processors to encrypt the code of each binary file but not the data of each binary file. The instructions are also executable by the one or more processors to receive a request for a decryption key from a computing device. The computing device includes a hardware enclave. The encrypted code of each binary file is stored in the hardware enclave, but the data of each binary file is not stored in the hardware enclave. The hardware enclave includes instructions for marking the hardware enclave as non-readable before executing the code.

[0008]

[0011] The instructions may be further executable by the one or more processors to provide the decryption key to the computing device.

[0012] The instructions may be further executable by the one or more processors to authenticate a processor signature before providing the decryption key. The processor of the computing device generates a processor signature, and the request for the decryption key may include the processor signature.

[0009]

[0013] The command may be further executable by one or more processors to verify the hash before providing the decryption key. The request for the decryption key may include the hash, and verifying the hash may include comparing the hash to a verified hash value.

[0010]

[0014] The step of modifying a plurality of binary files may include identifying data references within the code of each binary file and modifying the data references.

[0015] The step of modifying a plurality of binary files may not require access to source code or debug symbols for the plurality of binary files.

[0011]

[0016] The command may be further executable by one or more processors to add a separate header to each of the plurality of binary files. The separate header may indicate that the data of each of the plurality of binary files may be placed at any distance in memory from the code of that binary file and that the code of that binary file should be placed in a hardware enclave.

[0012]

[0017] According to another aspect of the present disclosure, a computer-readable medium is disclosed. The computer-readable medium includes instructions executable by one or more processors to cause a computing system to receive a request to start an application, where the application includes one or more files having executable code and data. The executable code is encrypted. The instructions are also executable by one or more processors to cause the computing system to load the executable code into a hardware enclave on the computing system and to load data into a location in memory on the computing system. The location is outside the hardware enclave and not at a predefined distance in memory from the executable code. The instructions are also executable by one or more processors to cause the computing system to send a request for a decryption key to an authentication server and to decrypt the executable code using the decryption key. The decryption key is received by the computing system after sending the request for the decryption key. The instructions are also executable by one or more processors to cause the computing system to mark the hardware enclave as unreadable.

[0013]

[0018] The executable code may include two or more sections of the executable code, and the two or more sections of the executable code may be loaded into contiguous ranges within the hardware enclave.

[0014]

[0019] The computer-readable medium may further include additional instructions executable by one or more processors to cause the computing system to load startup code into the hardware enclave.

[0015]

[0020] The computer-readable medium may further include additional instructions executable by one or more processors to cause the computing system to measure hashes of the startup code and the executable code.

[0016]

[0021] A computer-readable medium may further include additional instructions executable by one or more processors to cause the computing system to sign the hash using the signature of one or more processors.

[0017]

[0022] A request for a decryption key may include the signature and the hash.

[0023] This summary is provided to introduce, in a simplified form, examples of concepts that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0018]

[0024] Additional features and advantages will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the disclosed subject matter as set forth hereinafter. The features of the present disclosure may be more fully understood from the following description and the appended claims, or may be learned by the practice of the disclosed subject matter as set forth within the specification.

[0019]

[0025] To explain the manner in which the features enumerated above and other features of the present disclosure may be obtained, a more specific description will be provided with reference to specific embodiments of the present disclosure illustrated in the accompanying drawings. For a better understanding, like elements are designated by like reference numerals throughout the various accompanying drawings. With the understanding that the drawings depict some example embodiments, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings.

Brief Description of the Drawings

[0020]

Figure 1

[0026] FIG. is a diagram illustrating an example system for utilizing a hardware enclave to protect a software program from software piracy.

Figure 2A

[0027] A diagram illustrating an exemplary file that can be modified in a manner that promotes protecting the exemplary file from software piracy.

Figure 2B

Figure 3

[0028] A diagram illustrating an exemplary method for modifying a file to promote protecting the file from software piracy.

Figure 4

[0029] A diagram illustrating an exemplary method for loading a file into memory to promote protecting the file from software piracy.

Figure 5

[0030] A diagram illustrating an exemplary method for authenticating information and providing a decryption key to protect a file from software piracy.

Figure 6

[0031] A diagram illustrating an exemplary method for starting the execution of a program to promote protecting the program from software piracy.

Figure 7

[0032] A diagram illustrating specific components that may be included in a computing system.

Best Mode for Carrying Out the Invention

[0021]

[0033] Software developers can create applications for use on computing devices. An application can include a set of instructions that cause a computing device to perform a particular task. Software developers can invest a significant amount of time and money in designing and creating the code for an application. Software developers may attempt to profit from the sale of authorized copies of the application (by the software developer or a distributor). As a result, software developers may desire to protect the application from piracy. Software piracy can occur when a user purchases or obtains a copy of an application, creates an unauthorized copy of that application, uses the unauthorized copies, or distributes them to third parties. Third parties may use unauthorized copies of the application instead of purchasing an authorized copy from the software developer or the software developer's distributor. Thus, software piracy can directly affect a developer's revenue and profits. However, stopping piracy can be difficult because attackers often have complete control of the system on which the application is run.

[0022]

[0034] This disclosure describes a system and method for utilizing a hardware enclave to protect program code included in a commercial off-the-shelf (COTS) program from software piracy. A hardware enclave can be a defined region of memory, the contents of which cannot be read or saved by an operating system and even a hypervisor, which are not stored in the hardware enclave. A set of instruction codes, such as Intel® Software Guard Extensions (Intel® SGX) or AMD Secure Encrypted Virtualization (SEV) incorporated in a processor, can support the creation and use of a hardware enclave. The set of instructions and the hardware enclave can enable a remote party to execute an unmodified program with confidentiality and / or integrity protection even if the rest of the system is malicious. The code and data stored in the hardware enclave can trust only the hardware enclave, and any process outside the hardware enclave, including the operating system or hypervisor, can be potentially treated as undesirable. The processor can encrypt the information stored in the hardware enclave and decrypt the information on-the-fly in the processor itself.

[0023]

[0035] Hardware enclaves can provide an opportunity to protect information from malicious systems (requiring trust in only the processor), but doing so requires software developers to modify their programs, and thus software developers may not utilize hardware enclaves. However, the systems and methods described require little assistance from program developers and do not require access to source code or rely on recompiling the program. Instead, the systems and methods described can be directly applied to commercial off-the-shelf (COTS) program binaries by persons or entities other than software developers. Thus, aspects of the systems and methods described can be provided as a service to software developers by a software distribution platform, an operating system developer, or other trusted party. As a result, the systems and methods described can improve the utilization of hardware enclaves to combat piracy for both new and legacy software. Of course, software developers can also implement aspects of the systems and methods described without relying on third parties.

[0024]

[0036] Assume that a software developer provides a COTS application to a platform for distribution and sale to consumers. The application can include one or more binaries containing executable code. In the case of a PC application, the application can include one or more EXE files and one or more DLL files. Each binary can include one or more code sections (sections of executable instructions), as well as one or more data sections containing information referenced and used by the executable instructions. Proper execution of the binary may require that the data section be placed in memory at a default and fixed distance from the code section. The application or binary can define the default and fixed distance.

[0025]

[0037] Before making an application available to a purchaser, the platform may modify each binary containing executable code. The platform may modify each binary in up to three ways: (1) separate the code section from the data section, (2) encrypt the code section, and (3) add a header.

[0026]

[0038] First, for each binary file containing executable code, the platform may separate the code section from the data section so that the code and data can be loaded into two locations in memory that are at an arbitrary distance from each other (opposing the default distance required before separation). Separating the code from the data may involve modifying all data references in the code that assume a fixed distance between the code and the data. The platform may separate the code from the data without relying on any information not contained within the binary. Thus, the platform may separate the code from the data without accessing the binary's source code or debug symbols. Separating the code from the data may facilitate loading all code sections from multiple binaries adjacent to each other into a single contiguous memory region.

[0027]

[0039] Second, after the platform separates the code from the data, the platform may encrypt the code section contained in each modified binary. The platform may leave the data section of the binary in unencrypted plain text.

[0028]

[0040] Thirdly, the platform may add headers or other information to one or more of the modified binaries. The header may communicate to the operating system that the code sections within the modified binary are separated from the data sections within the modified binary. The header may also communicate that the code section should be loaded into the hardware enclave and that the data section should be loaded outside of the hardware enclave.

[0029]

[0041] After modifying the binary, the platform may generally sell or distribute the application (accompanied by the modified binary). The user may similarly download the application to disk memory on a computing device, which may also include a hardware enclave. When the user launches the application, the operating system of the computing device may load the binary of the application into memory. The operating system may be designed to recognize when the code section within the binary is separated from the data section. The operating system may also be designed to recognize when the code section should be loaded into the hardware enclave. Based on the header, the operating system may determine that the code and data sections are separate and that the code section should be loaded into the hardware enclave. After loading all code sections from the modified binary into the hardware enclave within one contiguous range, the operating system may load all data sections from the modified binary into the process memory outside of the hardware enclave.

[0030]

[0042] To load the modified binary in such a manner, the operating system may include a loader different from the standard loader. The loader may be part of an operating system designed to move an executable file for an application from disk storage to process memory and bootstrap the startup process for the application. The standard loader can load the code section and the data section into memory together and cannot recognize the information in the modified binary indicating that the code sections should be loaded together. However, the loader included in the operating system described above is designed to load the code sections of the modified binary together into the hardware enclave and the data section outside the hardware enclave. However, even though the loader of the operating system described above may be different from the standard loader, the operating system kernel is not customized or changed. Thus, the described system and method may require only minimal modifications to an existing operating system.

[0031]

[0043] In addition to loading the modified binary, the operating system may load startup code into the hardware enclave. The startup code may be included in the operating system and may not be encrypted. In an alternative, the platform may provide the startup code to the computing device along with the application.

[0032]

[0044] Once the loader has loaded everything, the operating system may transfer control to the startup code. The startup code may cause the processor to measure the hash of the code present within the hardware enclave and sign the hash using the processor signature. The processor may then establish a secure communication channel with the platform's authentication server and send the signed hash to the authentication server. The authentication server may verify the processor signature to ensure that the processor is genuine. The authentication server may also verify the hash. If the authentication server verifies both the signature and the hash, the authentication server may send a key for decrypting the code to the computing device. The startup code may use that key to decrypt the code present within the hardware enclave.

[0033]

[0045] Before the application runs, the startup code may mark all hardware enclave memory as unreadable with respect to the code stored in the hardware enclave to protect the application from code content leakage. Otherwise, an attacker may attempt to trick the application into leaking code content by manipulating data pointers not protected by the hardware enclave. The data section stored outside the hardware enclave may contain pointers. An attacker may be able to change the pointers within the data section to point to the code section. If the code does not check whether the data points to it and the hardware enclave was not marked as unreadable, the code may leak its content.

[0034]

[0046] Despite the potential to combat software piracy, hardware enclaves have not been widely adopted. One reason, as noted above, is that using a hardware enclave may require software developers to modify existing software. Typically, software developers must modify the program so that it is aware of the hardware enclave in order to take advantage of its capabilities. However, the disclosed systems and methods do not require software developers to modify the program. Alternatively, the disclosed systems and methods do not require software developers to provide source code. Instead, the disclosed systems and methods enable a platform or service provider to modify the program to utilize a hardware enclave without requiring assistance or additional information from the software developer. In this manner, the described systems and methods enable a software distribution platform to provide an end-to-end anti-piracy solution for third-party applications without relying on software developers.

[0035]

[0047] Another reason why hardware enclaves have not been widely adopted is the lack of support from major operating systems. However, the systems and methods described are compatible with general-purpose operating systems because they do not affect how the operating system accesses program data and services certain system calls (e.g., loading file contents into the program's memory). Program data still exists within normal process memory that is both readable and writable. Thus, the disclosed systems and methods do not require changes to today's operating system kernels. Instead, operating system developers only need to modify the operating system loader to make this approach suitable for real-world adoption on multiple platforms (e.g., Windows, Mac, etc.).

[0036]

[0048] Another reason why hardware enclaves have not been widely adopted is the limited amount of isolated memory. The systems and methods described reduce memory pressure by using isolated memory only for the program's code section, which is typically much smaller than the program's data section. Additionally, software piracy may be more concerned with application code than data.

[0037]

[0049] FIG. 1 illustrates an example system 100 in which the techniques disclosed herein can be utilized to protect software from piracy. System 100 can include a platform 102, an authentication server 146, and a computing device 104. The platform 102 and the computing device 104 can be connected through a network 142. The computing device 104 and the authentication server 146 can also be connected through the network 142.

[0038]

[0050] Software developer 106 may utilize system 100. Software developer 106 may create program 108a. Program 108a may be a set of instructions and information designed to perform one or more functions or tasks. Program 108a may be a commercial off-the-shelf (COTS) software program that can be executed on a computing device such as computing device 104.

[0039]

[0051] Program 108a may include one or more files such as file 110a and file 112a. Program 108a may include additional files not shown in FIG. 1. In other designs, program 108a may include only one file. Files 110a, 112 may be unencrypted binary files. Files 110a, 112a may include executable code and data. The executable code may be instructions that can be understood and executed by a processor. The executable code within files 110a, 112a may include references to the data included in files 110a, 112a. Files 110a, 112a may be designed such that the data included in files 110a, 112a must be stored at a fixed and predetermined distance in memory from the code included in files 110a, 112a for execution on a computing device. Program 108a or files 110a, 112a may define the fixed and predetermined distance.

[0040]

[0052] Platform 102 may provide software programs for distribution and sale. Platform 102 may include an online store where users can download software programs. Platform 102 may receive Program 108a from Software Developer 106. Software Developer 106 may provide Program 108a to Platform 102 for the purpose of selling an authenticated copy of Program 108a to users of computing devices such as Computing Device 104. Software Developer 106 may be concerned that someone may purchase Program 108a through Platform 102, create an unauthorized copy of Program 108a, and then distribute the unauthorized copy to third parties without compensating Software Developer 106. Platform 102 may provide services to Software Developer 106 to facilitate protecting Program 108a from software piracy.

[0041]

[0053] Platform 102 may include Program 108b. Program 108b may be a revised version of Program 108a. Program 108b may include Revised File 110b and Revised File 112b. Revised File 110b may be a revised version of File 110a, and Revised File 112b may be a revised version of File 112a. Revised Files 110b, 112b may be binary files. Platform 102 may have created Program 108b by modifying Program 108a to facilitate protecting Program 108a from software piracy. Alternatively, Software Developer 106, or an entity other than Platform 102, may create Program 108b by modifying Program 108a.

[0042]

[0054] The modified file 110b may include encrypted code 114b-1, encrypted code 114b-2, data 116b-1, data 116b-2, and header 118b-1. The encrypted code 114b-1 and the encrypted code 114b-2 may be modified versions of the code included in the file 110a. The encrypted codes 114b-1, 114b-2 may enable a computing device to execute the modified file 110b when the data 116b-1, 116b-2 are located at any distance from the encrypted codes 114b-1, 114b-2 in memory. Further, the encrypted codes 114b-1, 114b-2 may be encrypted such that a key is required to decrypt and execute the encrypted codes 114b-1, 114b-2. Unlike the encrypted codes 114b-1, 114b-2, the data 116b-1, 116b-2 may not be encrypted.

[0043]

[0055] The header 118b-1 may include information about the modified file 110b. The header 118b-1 may indicate that the modified file 110b includes separated code and data. In other words, the header 118b-1 may communicate that the data 116b-1, 116b-2 may be placed in memory at any distance from the encrypted codes 114b-1, 114b-2. The header 118b-1 may indicate that the encrypted codes 114b-1, 114b-2 should be placed in a hardware enclave and that the data 116b-1, 116b-2 should be placed in memory outside the hardware enclave. Although shown within the modified file 110b, the information included in the header 118b-1 may instead be included in a program 108b external to the modified file 110b.

[0044]

[0056] The modified file 112b may include an encrypted code 114b-3, data 116b-3, and a header 118b-2. The encrypted code 114b-2 may be a modified version of the code included in the file 112a. The encrypted code 114b-3 may enable a computing device to execute the modified file 112b when the data 116b-3 is stored at any distance from the encrypted code 114b-3 in memory. Further, the encrypted code 114b-3 may be encrypted. Unlike the encrypted code 114b-3, the data 116b-3 may not be encrypted.

[0045]

[0057] The header 118b-2 may include information about the modified file 112b. The header 118b-2 may indicate that the modified file 112b includes separated code and data. In other words, the header 118b-2 may communicate that the data 116b-3 may be placed in memory at any distance from the encrypted code 114b-3. The header 118b-2 may indicate that the encrypted code 114b-3 should be placed in a hardware enclave and the data 116b-3 should be placed in memory external to the hardware enclave. The header 118b-2 is shown within the modified file 112b, but the information included in the header may alternatively be included in a program 108b external to the modified file 112b.

[0046]

[0058] Computing device 104 may download a software program from platform 102 for use on computing device 104. A user of computing device 104 may perform functions and tasks using the downloaded software program. Computing device 104 may include program 108c stored in disk storage 140. Program 108c may be a copy of program 108b. Computing device 104 may download program 108c from platform 102 through network 142.

[0047]

[0059] Program 108c may include modified file 110c and modified file 112c. Modified file 110c may be a copy of modified file 110b, and modified file 112c may be a copy of modified file 112b. Modified file 110c may include encrypted code 114c-1 (which may be a copy of encrypted code 114b-1), encrypted code 114c-2 (which may be a copy of encrypted code 114b-2), data 116c-1 (which may be a copy of data 116b-1), data 116c-2 (which may be a copy of data 116b-2), and header 118c-1 (which may be a copy of header 118b-1). Modified file 112c may include encrypted code 114c-3 (which may be a copy of encrypted code 114b-3), data 116c-3 (which may be a copy of data 116b-3), and header 118c-2 (which may be a copy of header 118b-2).

[0048]

[0060] A user of the computing device 104 may cause the computing device 104 to start program 108c. The operating system 126 of the computing device 104 may use the loader 128 to load program 108c into the memory 130 of the computing device. The operating system 126 may be a program that manages the hardware and software on a computing device such as the computing device 104. The platform 102 may be developing the operating system 126. The loader 128 may be designed to determine whether the modified files 110c, 112c contain code that is separated from the data. The loader 128 may determine from the headers 118c-1, 118c-2 that the modified files 110c, 112c contain code that is separated from the data.

[0049]

[0061] The loader 128 may also determine from the headers 118c-1, 118c-2 that the code contained in the modified files 110c, 112c should be loaded into the hardware enclave 132 of the memory 130. The hardware enclave 132 may be a defined portion of the memory 130 that has secrecy and integrity protection from instructions that do not exist within the hardware enclave 132. The processor 136 of the computing device 104 may manage, protect, and assist the hardware enclave 132.

[0050]

[0062] Loader 128 can load the encrypted codes 114c-1, 114c-2, 114c-3 into the hardware enclave 132. Loader 128 can load the encrypted codes 114c-1, 114c-2, 114c-3 into a continuous range of the hardware enclave 132. Loader 128 can also load the startup code 134 into the hardware enclave 132. The startup code 134 can be included in the operating system 126. In an alternative, the computing device 104 can obtain the startup code 134 from the platform 102 or as part of the program 108b. The startup code 134 may not be encrypted. Loader 128 can load the data 116c-1, 116c-2, 116c-3 into the external memory 130 of the hardware enclave 132. The data 116c-1, 116c-2, 116c-3 can be located at any distance within the memory 130 from the encrypted codes 114c-1, 114c-2, 114c-3.

[0051]

[0063] When loader 128 loads the modified files 110c, 112c into the memory 130, the operating system 126 can start the startup code 134. The startup code 134 can include instructions for causing the processor to perform remote attestation to obtain a key, such as the decryption key 124, for decrypting the encrypted codes 114c-1, 114c-2, 114c-3. As part of performing the remote attestation, the startup code 134 can include instructions for causing the processor 136 to be provided with information for proving the authenticity of the contents of the hardware enclave 132. For example, the startup code 134 can include instructions for causing the processor 136 of the computing device 104 to measure the hash of the encrypted codes 114c-1, 114c-2, 114c-3. The processor 136 can also include the startup code 134 within the hash measurement value. The processor can measure the hash of the encrypted codes 114c-1, 114c-2, 114c-3 and the startup code 134 using a public hash function.

[0052]

[0064] As part of performing remote attestation, the processor 136 may provide information that attests to its authenticity. For example, the processor 136 may include a signature module 138, and the processor 136 may cause the signature module 138 to sign a hash using a processor signature. The signature module 138 may sign the hash using a secret certificate managed by the processor 136.

[0053]

[0065] As part of performing remote attestation, the boot code 134 may cause the processor 136 to establish a communication channel over the network 142 using the authentication server 146. The communication channel may be a secure communication channel. The processor 136 may send to the authentication server 146 information that attests to the authenticity of the processor 136 and the content of the hardware enclave 132. For example, the processor 136 may send a signed hash to the authentication server 146 over the communication channel. The processor 136 may send a signed hash to the authentication server 146 as part of a request for the decryption key 124. The decryption key 124 may enable the decryption of the encrypted codes 114b-1, 114b-2, 114b-3. In some designs, the authentication server 146 may be included in the platform 102. In other designs, the authentication server 146 may be separated from the platform 102. In that case, the authentication server 146 may have received the decryption key 124 from the platform 102.

[0054]

[0066] The authentication server 146 can verify the processor signature received from the processor 136. The authentication server 146 can verify the processor signature using the public certificate 148. The authentication server 146 can verify the processor signature to determine that the processor 136 is genuine and trustworthy. If the authentication server 146 cannot verify the processor signature, the processor 136 may be malicious or controlled by an attacker. In that case, the processor 136 may not have placed the encrypted codes 114b-1, 114b-2, 114b-3 in a secure hardware enclave. If the authentication server 146 cannot verify the processor signature, the authentication server 146 cannot provide the decryption key 124 to the computing device 104. Otherwise, the user of the computing device 104 could place the encrypted codes 114b-1, 114b-2, 114b-3 in an insecure portion of the memory 130 of the computing device 104, use the decryption key 124 to decrypt the encrypted codes 114b-1, 114b-2, 114b-3, and create an unauthorized copy of the decrypted code.

[0055]

[0067] The authentication server 146 can verify the hash. The authentication server 146 may include the verified hash value 150. The authentication server 146 can determine whether the hash received from the processor 136 matches the verified hash value 150. The platform 102 may determine the verified hash value 150 when the platform 102 generates the modified files 110b, 112b. The platform 102 may have access to the startup code 134 to generate the verified hash value 150. The authentication server 146 can verify the hash to determine that the computing device 104 did not modify the encrypted codes 114b-1, 114b-2, 114b-3, or the startup code 134. If the authentication server 146 cannot verify the hash, the authentication server 146 cannot provide the decryption key 124 to the computing device. Otherwise, the user of the computing device 104 may be able to modify the startup code 134, or the encrypted codes 114b-1, 114b-2, 114b-3 to include instructions for providing information about the decrypted content of the hardware enclave 132. By verifying the hash, the system 100 can protect the program 108a from a malicious loader. Even if the loader 128 is malicious, the loader 128 cannot steal the encrypted codes 114b-1, 114b-2 because they are encrypted. Also, even if the loader 128 injects additional information into the encrypted codes 114b-1, 114b-2, 114b-3, or incorrectly loads the encrypted codes 114b-1, 114b-2, 114b-3, the authentication server 146 does not verify the hash.

[0056]

[0068] When the authentication server verifies that the content of the processor 136 and the hardware enclave 132 can be trusted (such as by verifying both the processor signature and the hash), the authentication server 146 may send the decryption key 124 to the computing device 104. The processor 136 may use the decryption key 124 to decrypt the encrypted codes 114b-1, 114b-2, 114b-3. At that time, the hardware enclave 132 may include the decrypted codes 120-1, 120-2, 120-3. The decrypted code 120-1 may be a decrypted version of the encrypted code 114c-1. The decrypted code 120-2 may be a decrypted version of the encrypted code 114c-2. The decrypted code 120-3 may be a decrypted version of the encrypted code 114c-3. The decrypted codes 120-1, 120-2 may be executed even when the decrypted codes 120-1, 120-2 are at any distance from the data 116c-1, 116c-2 within the memory 130. Also, the decrypted code 120-3 may be executed even when the decrypted code 120-3 is at any distance from the data 116c-3 within the memory 130.

[0057]

[0069] Before the processor 136 executes the decoded codes 120-1, 120-2, 120-3, the startup code 134 can mark the hardware enclave 132 as unreadable to all the instructions existing inside the hardware enclave 132 for the processor 136. The startup code 134 can include these instructions to protect the decoded codes 120-1, 120-2, 120-3 from content leakage. Readability and executability may be two separate permissions. Therefore, marking the hardware enclave 132 as unreadable may not prevent the decoded codes 120-1, 120-2, 120-3 from being executed. When the processor 136 marks the hardware enclave 132 as unreadable, the processor 136 can execute the decoded codes 120-1, 120-2, 120-3. The decoded codes 120-1, 120-2, 120-3 can perform the same functions as the codes included in the files 110a, 112a.

[0058]

[0070] Figures 2A and 2B illustrate a file 210a and a modified file 210b according to the techniques described herein. The file 210a can be an example of the file 110a shown in FIG. 1. The modified file 210b can be an example of the modified file 110b shown in FIG. 1.

[0059]

[0071] File 210a may be part of a COTS software program. File 210a may be an unencrypted binary file containing executable code and data. For example, file 210a may include code section 220a-1, code section 220a-2, data section 216a-1, and data section 216a-2. Code sections 220a-1, 220a-2 may contain executable code and may not be encrypted. Code sections 220a-1, 220a-2 may be much smaller in size than data sections 216a-1, 216a-2. Code sections 220a-1, 220a-2 may include one or more references to data sections 216a-1, 216a-2. For example, code section 220a-1 may include data reference 242a-1, data reference 242a-2, and data reference 242a-3, and code section 220a-2 may include data reference 242a-4. File 210a includes two code sections and two data sections, but in other embodiments, the file may include only one code section and one data section, or three or more code sections and three or more data sections. The file may also include an unequal number of code sections and data sections.

[0060]

[0072] Data references 242a-1, 242a-2, 242a-3, 242a-4 may refer to specific data or specific locations within data sections 216a-1, 216a-2. For example, data reference 242a-1 may refer to data 244a-1 within data section 216a-1. Data reference 242a-2 may refer to data 244a-2. Data reference 242a-3 may refer to data 244a-3 within data section 216a-2. Data reference 242a-4 may also refer to data 244a-3. Data references 242a-1, 242a-2, 242a-3, 242a-4 may be formatted to point to the correct data during runtime only if data sections 216a-1, 216a-2 are loaded in memory at a fixed and predetermined distance from code sections 220a-1, 220a-2. Data references 242a-1, 242a-2, 242a-3, 242a-4 may include instructions to obtain specific data included in data section 216a-1 or data section 216a-2. Data references 242a-1, 242a-2, 242a-3, 242a-4 may include instructions to modify specific data included in data section 216a-1 or data section 216a-2. Therefore, if data sections 216a-1, 216a-2 are not loaded at a fixed and predetermined distance from code sections 220a-1, 220a-2, the instructions included in code sections 220a-1, 220a-2 may obtain or modify incorrect data, and file 210a may not function correctly.

[0061]

[0073] The modified file 210b may be a modified version of the file 210a. The developer of the file 210a may modify the file 210a to generate the modified file 210b. In an alternative, a person or entity other than the developer of the file 210a (such as a platform) may modify the file 210a to generate the modified file 210b. A person or entity other than the developer of the file 210a may create the modified file 210b without accessing the source code of the file 210a or the debug symbols of the file 210a.

[0062]

[0074] The modified file 210b may include an encrypted code section 214b-1, an encrypted code section 214b-2, a data section 216b-1, and a data section 216b-2. The encrypted code sections 214b-1, 214b-2 may be modified versions of the code sections 220a-1, 220a-2. The encrypted code sections 214b-1, 214b-2 may be encrypted such that a computing device cannot execute the encrypted code sections 214b-1, 214b-2 without first obtaining a decryption key. The data sections 216b-1, 216b-2 may be copies of the data sections 216a-1, 216a-2. The data sections 216b-1, 216b-2 may include data 244b-1 (which may be a copy of the data 244a-1), data 244b-2 (which may be a copy of the data 244a-2), and data 244b-3 (which may be a copy of the data 244a-3). The data sections 216b-1, 216b-2 may be unencrypted plain text.

[0063]

[0075] The encrypted code section 214b-1 may include a modified data reference 242b-1, a modified data reference 242b-2, and a modified data reference 242b-3. The encrypted code section 214b-2 may include a modified data reference 242b-4. The modified data reference 242b-1 may be a modified version of the data reference 242a-1. The modified data reference 242b-2 may be a modified version of the data reference 242a-2. The modified data reference 242b-3 may be a modified version of the data reference 242a-3. The modified data reference 242b-4 may be a modified version of the data reference 242a-4. Even if the distances in memory between the modified data references 242b-1, 242b-2, 242b-3, 242b-4 and the encrypted code sections 214b-1, 214b-2 and the data sections 216b-1, 216b-2 are different from the fixed and default distances defined in the file 210a, the modified data references 242b-1, 242b-2, 242b-3, 242b-4 may be modified to point to the correct data during runtime. For example, when the data section 216a-1 is placed at a fixed and default distance in memory from the code section 220a-1 and the data reference 242a-1 points to the data 244a-1, the modified data reference 242b-1 points to the data 244b-1 when the data section 216b-1 is placed at a distance in memory from the code section 214b-1 that is different from its fixed and default distance. Thus, the modified data references 242b-1, 242b-2, 242b-3, 242b-4 are designed such that any distance may exist in memory between the encrypted code sections 214b-1, 214b-2 and the data sections 216b-1, 216b-2.

[0064]

[0076] Modifying data references 242a-1, 242a-2, 242a-3, 242a-4 may involve identifying and locating data references 242a-1, 242a-2, 242a-3, 242a-4 within code sections 220a-1, 220a-2. Locating data references 242a-1, 242a-2, 242a-3, 242a-4 may involve using relocation information. File 210a, or a program including file 210a, may include relocation information for all data references within the code section. The relocation information may be included to assist in Address Space Layout Randomization (ASLR). ASLR may enable a processor to load a program at any location within memory. However, ASLR still requires that the distance between code and data be a fixed distance defined in the program. Nevertheless, ASLR may help the platform locate data references 242a-1, 242a-2, 242a-3, 242a-4. Thus, the platform may utilize the relocation information to locate data references 242a-1, 242a-2, 242a-3, 242a-4. After locating data references 242a-1, 242a-2, 242a-3, 242a-4, the platform may modify data references 242a-1, 242a-2, 242a-3, 242a-4 to separate code sections 220a-1, 220a-2 from data sections 216a-1, 216a-2.

[0065]

[0077] The modified file 210b may include a header 218b. The header 218b may contain information regarding the modified file 210b. The header 218b may not be encrypted. The header 218b may indicate that the encrypted code sections 214b-1, 214b-2 are separated from the data sections 216b-1, 216b-2 such that the data sections 216b-1, 216b-2 can be loaded in memory at an arbitrary distance from the code sections 214b-1, 214b-2. The header 218b may indicate that the code sections 214b-1, 214b-2 should be loaded into a hardware enclave and that the data sections 216b-1, 216b-2 should be loaded into memory external to the hardware enclave. The platform may add the header 218b to the modified file 210b.

[0066]

[0078] Figure 3 illustrates an exemplary method 300 for modifying a file to facilitate protecting a program from piracy using a hardware enclave.

[0079] Method 300 may include a step 302 of receiving a file that includes code and data. The file may be part of a program that may be a COTS software product. The file may be file 110a, file 112a, or file 210a. The program may include additional information other than the file. The file may be an executable file. The file may be an unencrypted binary file. The code may be instructions executable by a processor. The file may be designed such that data must be stored at a fixed and predefined distance in memory from the code for the file to execute properly. A platform such as platform 102 may receive the file 302.

[0067]

[0080] Method 300 may include step 304 of locating data references within code. A data reference may refer to specific information or a location within data. The code may use the data reference as part of the portion for obtaining or modifying specific information within the data. The data reference may be designed such that the data must be stored at a fixed default distance in memory from the code in order for the data reference to refer to the correct information within the data during runtime. The platform may locate 304 the data reference. The platform may locate 304 the data reference without using source code or debug symbols associated with a file. The platform may locate 304 the data reference without using information from a developer of a program other than the program.

[0068]

[0081] Locating 304 data references within code may include using relocation information regarding data references included in the code, file, or program. The relocation information may be included to support ASLR.

[0069]

[0082] Method 300 may include step 306 of modifying data references within code. Step 306 of modifying a data reference may include separating the code from the data. When separated, the data may be placed at any distance in memory from the code, and the data reference within the code may still refer to the correct information within the data during runtime. The platform may modify 306 the data reference. The platform may modify 306 the data reference without accessing source code or debug symbols associated with a file. The platform may modify 306 the data reference without accessing information from a developer of a program other than the program.

[0070]

[0083] Method 300 may include step 308 of encrypting the code. Decrypting the encrypted code may require the use of a decryption key. The decryption key may be a secret decryption key. The platform may encrypt the code 308. The platform may not encrypt the data.

[0071]

[0084] Method 300 may include step 310 of modifying the file to include a separation header. The separation header may indicate that data within the file may be placed at any distance from the code in memory. The separation header may indicate that the code should be loaded into memory inside the hardware enclave and that the data should be loaded into memory outside the hardware enclave. The platform may modify the file to include the separation header 310.

[0072]

[0085] Method 300 may include step 312 of measuring the hash of the encrypted code and the startup code. Step 312 of measuring the hash may include performing a public standard hash function on the encrypted code and the startup code. The startup code may be designed to be placed in the hardware enclave together with the encrypted code. Step 312 of measuring the hash may include storing the hash as a verified hash value. The platform may measure the hash 312. The platform may store the hash on the platform or on an authentication server. The hash may be used to authenticate the request for the decryption key to decrypt the encrypted code.

[0073]

[0086] Method 300 may include step 314 of providing the file for distribution. The file may include a separation header, modified data references, and encrypted code. Step 314 of providing the file for distribution may include providing a copy of the file for the user to download. The platform may provide the file for distribution 314. The computing device may download the file from the platform.

[0074]

[0087] Figure 4 illustrates a potential method 400 for loading an application to facilitate protecting the application from software piracy.

[0088] Method 400 may include step 402 of receiving a request to start an application. The application may include one or more files having executable code. Each of the one or more files may include both code and data. The code and data within the one or more files may be separated such that data from each of the one or more files may be loaded at any distance in memory from the code of that file. The code within the one or more files may be encrypted. The data within the one or more files may not be encrypted. An operating system, such as operating system 126, may receive the request 402.

[0075]

[0089] Method 400 may include step 404 of reading a header from one or more files. The header may be included in or associated with the one or more files. The header may indicate that the code and data within the one or more files are separated. The header may indicate that the code should be loaded into a hardware enclave within a contiguous range and that the data should be loaded into memory external to the hardware enclave. The operating system may read the header 404. The operating system may include a loader, such as loader 128, designed to read and understand the header.

[0076]

[0090] Method 400 may include step 406 of loading startup code into the hardware enclave. The startup code may include instructions consumable by the processor. The startup code may cause the processor to measure a hash of information stored in the hardware enclave, sign the hash using a signature, provide the hash and the signature to an authentication server, and may include instructions for marking the hardware enclave as unreadable. The operating system may load 406 the startup code into the hardware enclave. The operating system may include the startup code. In an alternative, the operating system may receive the startup code from the platform.

[0077]

[0091] Method 400 may include step 408 of loading code included in one or more files into the hardware enclave. The code may be encrypted. The step 408 of loading the code may include loading the code into a contiguous range within the hardware enclave. The operating system may load 408 the code included in one or more files into the hardware enclave. The operating system may use a loader to load 408 the code included in one or more files into the hardware enclave.

[0078]

[0092] Method 400 may include step 410 of loading data included in one or more files into a memory external to the hardware enclave. The data may not be encrypted. The step 410 of loading the data may include loading the data into a contiguous range within the memory external to the hardware enclave. The step 410 of loading the data may include loading the data at any distance within the memory from the code. The operating system may load 410 the data included in one or more files into the memory external to the hardware enclave. The operating system may use a loader to load 410 the data.

[0079]

[0093] Method 400 may include step 412 of causing the execution of startup code. The operating system may cause the execution of startup code 412. The startup code may not need to be encrypted.

[0080]

[0094] FIG. 5 illustrates an example method for providing a decryption key in accordance with the techniques described herein.

[0095] Method 500 may include step 502 of receiving a request for a decryption key, the request including a hash and a signature. A computing device may make the request and may provide the hash and the signature. The computing device may make the request as part of a remote attestation process. The computing device may include a processor and a hardware enclave. The hardware enclave may include encrypted code and startup code. The processor may measure the hash of the encrypted code and the startup code. The processor may sign the hash using a signature using a private certificate. A platform or an authentication server may receive the request 502.

[0081]

[0096] Method 500 may include step 504 of authenticating the signature. Step 504 of authenticating the signature may include determining that the hash was signed using a private certificate. Step 504 of authenticating the signature may be performed using a public certificate. A platform or an authentication server may authenticate the signature 504. Step 504 of authenticating the signature may verify that the processor is genuine and can be trusted to enforce the secrecy and / or integrity protection of the hardware enclave.

[0082]

[0097] Method 500 may include step 506 of verifying a hash. Step 506 of verifying a hash may include comparing the hash to a verified hash value. The platform or authentication server may verify the hash 506. Step 506 of verifying a hash may verify that the encrypted code and boot code stored in the hardware enclave have not been modified by the computing device. Step 506 of verifying a hash may verify that the encrypted code and boot code are trustworthy. The platform or authentication server may determine the verified hash value.

[0083]

[0098] Method 500 may include step 508 of providing a decryption key. The decryption key may enable the computing device to decrypt the encrypted code. The boot code may include instructions for causing the processor to decrypt the encrypted code. The platform or authentication server may provide the decryption key 508. The platform or authentication server may not be able to provide the decryption key 508 unless the signature is genuine and the hash matches the verified hash value. If the signature or hash is not verified or validated, the platform or authentication server may notify the computing device that the platform or authentication server will not provide the decryption key.

[0084]

[0099] FIG. 6 illustrates an exemplary method 600 for starting a program modified by the techniques described herein.

[0100] Method 600 may include step 602 of causing a processor to measure a hash of code within a hardware enclave. The startup code stored in the hardware enclave may include instructions for causing the processor to measure a hash of code within the hardware enclave at 602. The processor may measure the hash of code within the hardware enclave using a standard hash function. The code within the hardware enclave may include startup code from a program and encrypted code. The program may include a file in which a code section and a data section are separated. Measuring the hash of code within the hardware enclave may be part of a remote attestation for obtaining a decryption key. Other methods for attesting to the contents of the hardware enclave may be used in addition to measuring the hash.

[0085]

[0101] Method 600 may include step 604 of causing the processor to sign the hash using a signature. The startup code may include instructions for causing the processor to sign the hash using a signature at 604. The processor may sign the hash using a signature using a private certificate. Signing the hash using a signature may be part of a remote attestation process for obtaining a decryption key. Other methods for attesting to the authenticity of the processor may be used in addition to signing the hash using a signature.

[0086]

[0102] Method 600 may include step 606 of causing a processor to request a decryption key from an authentication server, where the request includes a hash and a signature. The startup code may include instructions for causing the processor to request the decryption key 606. The processor may make the request and provide the hash and signature to the authentication server via a secure communication channel. The authentication server may be part of the platform. The authentication server may include the decryption key. The authentication server may provide the decryption key if the authentication server verifies the hash and signature. If the authentication server determines that either the signature is not genuine or the hash is incorrect, the authentication server cannot provide the decryption key. Method 600 includes step 606 of causing a processor to request a decryption key using a hash and a signature, although other authentication methods may be used.

[0087]

[0103] Method 600 may include step 608 of causing the processor to decrypt code. The startup code may include instructions for causing the processor to decrypt the code 608 using the decryption key.

[0088]

[0104] Method 600 may include step 610 of causing the processor to mark a hardware enclave as unreadable. The startup code may include instructions for causing the processor to mark the hardware enclave as unreadable 610 for instructions within the hardware enclave.

[0089]

[0105] FIG. 7 illustrates certain components that may be included within a computer system 700. One or more computer systems 700 may be used to implement the various devices, components, and systems described herein.

[0090]

[0106] Computer system 700 includes a processor 701. The processor 701 may be a general-purpose single or multi-chip microprocessor (e.g., an Advanced RISC (Reduced Instruction Set Computer) Machine (ARM)), a dedicated microprocessor (e.g., a Digital Signal Processor (DSP)), a microcontroller, a programmable gate array, etc. The processor 701 may be referred to as a Central Processing Unit (CPU). Only a single processor 701 is shown in the computer system 700 of FIG. 7, but in an alternative configuration, a combination of processors (e.g., ARM and DSP) may be used.

[0091]

[0107] Computer system 700 also includes a memory 703 in electronic communication with the processor 701. The memory 703 may be any electronic component capable of storing electronic information. For example, the memory 703 may be embodied as, including but not limited to, Random Access Memory (RAM), Read Only Memory (ROM), magnetic disk storage media, optical storage media, flash memory devices within RAM, on-board memory included with the processor, Erasable Programmable Read Only Memory (EPROM), Electrically Erasable Programmable Read Only Memory (EEPROM) memory, registers, and combinations thereof.

[0092]

[0108] Command 705 and data 707 may be stored in memory 703. Command 705 may be executable by processor 701 to implement some or all of the functionality disclosed herein. Executing command 705 may involve using data 707 stored in memory 703. Any of the various examples of modules, components, packages, applications, and operating systems described herein may be implemented, in part or in whole, as command 705 stored in memory 703 and executed by processor 701. Any of the various examples of data described herein may be one of data 707 stored in memory 703 and used during execution of command 705 by processor 701.

[0093]

[0109] Computer system 700 may also include one or more communication interfaces 709 for communicating with other electronic devices. Communication interface 709 may be based on wired communication technology, wireless communication technology, or both. Some examples of communication interface 709 include Universal Serial Bus (USB), Ethernet adapter, wireless adapter operating in accordance with Institute of Electrical and Electronics Engineers (IEEE) 802.11 wireless communication protocol, Bluetooth® wireless communication adapter, and infrared (IR) communication port.

[0094]

[0110] Computer system 700 may also include one or more input devices 711 and one or more output devices 713. Some examples of input device 711 include keyboard, mouse, microphone, remote control device, button, joystick, trackball, touchpad, and light pen. Some examples of output device 713 include speaker and printer. One particular type of output device typically included in computer system 700 is display device 715. The display device 715 used with the embodiments disclosed herein may utilize any suitable image projection technology, such as liquid crystal display (LCD), light emitting diode (LED), gas plasma, electroluminescence, or the like. A display controller 717 may also be provided to convert the data 707 stored in memory 703 into text, graphics, and / or video (if appropriate) shown on display device 715.

[0095]

[0111] The various components of computer system 700 may be coupled together by one or more buses that may include a power bus, a control signal bus, a status signal bus, a data bus, etc. For clarity, the various buses are illustrated in FIG. 7 as bus system 719.

[0096]

[0112] The techniques disclosed herein may be implemented in hardware, software, firmware, or any combination thereof, unless specifically described as being implemented in a particular manner. Any feature described as a module, component, or the like may be implemented together within an integrated logic device or separately as discrete but mutually movable logic devices. When implemented in software, the techniques may be at least partially realized by a non-transitory computer-readable medium storing computer-executable instructions that, when executed by at least one processor, perform some or all of the steps, operations, acts, or other functionality disclosed herein. The instructions may be capable of performing a particular task and / or implementing a particular data type and may be composed of routines, programs, objects, components, data structures, etc., that may be combined or distributed as desired in various embodiments.

[0097]

[0113] The term "processor" may refer to a general-purpose single or multi-chip microprocessor (e.g., an advanced RISC (Reduced Instruction Set Computer) machine (ARM)), a dedicated microprocessor (e.g., a digital signal processor (DSP)), a microcontroller, a programmable gate array, or the like. The processor may be a central processing unit (CPU). In some embodiments, a combination of processors (e.g., an ARM and a DSP) may be used to implement some or all of the techniques disclosed herein.

[0098]

[0114] The term "memory" can refer to any electronic component capable of storing electronic information. For example, the memory can be embodied as, including their combinations, random access memory (RAM), read only memory (ROM), magnetic disk storage media, optical storage media, flash memory devices within RAM, on-board memory included with a processor, erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM) memory, registers, etc.

[0099]

[0115] The steps, operations, and / or acts of the methods described herein can be interchanged with one another without departing from the scope of the claims. In other words, the order and / or use of particular steps, operations, and / or acts can be modified without departing from the scope of the claims, so long as a particular order of steps, operations, and / or acts is not required for the correct functioning of the methods described.

[0100]

[0116] The term "determine" (and its grammatical variants) can encompass a wide variety of acts. For example, "determine" can include calculate, compute, process, derive, inquire, examine (e.g., examine within a table, database, or another data structure), verify, and the like. Also, "determine" can include receive (e.g., receive information), access (e.g., access data in a memory), and the like. Also, "determine" can include resolve, select, choose, establish, and the like.

[0101]

[0117] The terms "comprising," "including," and "having" are intended to be inclusive and mean that there may be additional elements other than the recited elements. Additionally, it should be understood that references to "one embodiment" or "an embodiment" of the present disclosure are not intended to be construed as excluding the existence of additional embodiments that also incorporate the recited features. For example, any element or feature described in connection with an embodiment herein can be combined with any element or feature of any other embodiment described herein, if compatible.

[0102]

[0118] The present disclosure may be embodied in other specific forms without departing from its spirit or characteristics. The described embodiments are to be considered illustrative and not restrictive. Accordingly, the scope of the present disclosure is indicated not by the foregoing description but by the appended claims. Modifications within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A method for protecting software from piracy, comprising: receiving a plurality of binary files, each binary file including code and data, the code of each binary file including a reference to the data of that binary file, the reference requiring a fixed distance between the code and the data; modifying the plurality of binary files such that the data of each binary file can be located at any distance from the code of that binary file in memory; encrypting the code of each binary file; receiving a request for a decryption key from a computing device, the computing device including a hardware enclave, the hardware enclave including a defined area of the memory of the computing device configured to protect the hardware enclave from instructions outside the hardware enclave, the encrypted code of each binary file being stored in the hardware enclave and the data of each binary file being stored outside the hardware enclave; and a method comprising the steps of.

2. The method of claim 1, further comprising providing the decryption key to the computing device.

3. The method of claim 2, further comprising authenticating a processor signature before providing the decryption key, the processor of the computing device generating the processor signature, the request for the decryption key including the processor signature.

4. The method of claim 3, further comprising verifying a hash before providing the decryption key, the request for the decryption key including the hash.

5. The method according to claim 1, wherein the step of modifying the plurality of binary files is a step of modifying references to data within the code of each binary file, the references to the data requiring that the data be placed at a fixed distance from the code in memory, the method comprising the step.

6. The method according to claim 5, wherein the step of modifying the plurality of binary files is performed without access to the source code or debug symbols of the plurality of binary files.

7. The method according to claim 1, further comprising the step of adding a separation header to each of the plurality of binary files, the separation header indicating that the data of each of the plurality of binary files can be placed at any distance from the code of that binary file in the memory.

8. A system for facilitating protection of a software program from piracy, one or more processors, a system memory in electronic communication with the one or more processors, instructions stored in the system memory and comprising, the instructions causing the system to receive a plurality of binary files, each binary file including code and data, the code of each binary file including a reference to the data of that binary file, the reference being designed such that the data must be stored at a fixed predetermined distance from the code in memory, receiving the plurality of binary files; modify the plurality of binary files such that the data of each binary file can be located at any distance from the code of that binary file in the memory; encrypt the code of each binary file, but not encrypt the data of each binary file; Receiving a request for a decryption key from a computing device, wherein the computing device includes a hardware enclave, the encrypted code of each binary file is stored in the hardware enclave, the data of each binary file is stored outside the hardware enclave, the hardware enclave includes instructions for marking the hardware enclave as unreadable before executing the code, and the hardware enclave includes a specified area of the memory of the computing device configured to have confidentiality protection and integrity protection from other instructions outside the hardware enclave, receiving a request for a decryption key A system executable by the one or more processors to cause the above to be performed. **Claim 9** The system according to claim 8, wherein the instructions are further executable by the one or more processors to cause the system to provide the decryption key to the computing device. **Claim 10** The system according to claim 9, wherein the instructions are further executable by the one or more processors to cause the system to authenticate a processor signature before providing the decryption key, the processor of the computing device generates the processor signature, and the request for the decryption key includes the processor signature. **Claim 11** The system according to claim 10, wherein the instructions are further executable by the one or more processors to cause the system to verify a hash before providing the decryption key, the request for the decryption key includes the hash, and verifying the hash includes comparing the hash with a verified hash value. **Claim 12** The system according to claim 8, wherein modifying the plurality of binary files includes identifying references to data in the code of each binary file and modifying the references to the data.

13. The system according to claim 12, wherein modifying the plurality of binary files does not require access to the source code or debug symbols of the plurality of binary files.

14. The system according to claim 8, wherein the instructions are further executable by the one or more processors to cause the system to add a separation header to each of the plurality of binary files, the separation header being capable of placing the data of each of the plurality of binary files at an arbitrary distance from the code of that binary file in the memory, and indicating that the code of that binary file should be placed in the hardware enclave.

15. A computer-readable storage medium comprising instructions, the instructions causing a computing system to receive a request to start an application, the application including one or more files having executable code and data, the executable code being encrypted, receive a request to start the application, and load the executable code into a hardware enclave of the computing system. Loading the data at a location in the memory of the computing system, wherein the location is outside the hardware enclave and is not at a predetermined distance from the executable code in the memory of the computing system, the hardware enclave includes a defined area of the memory, and only the software stored in the hardware enclave can read and save the content of the hardware enclave, and loading the data; Sending a request for a decryption key to an authentication server; Decrypting the executable code using the decryption key, wherein the decryption key is received by the computing system after sending the request for the decryption key, and decrypting the executable code; Marking the hardware enclave as unreadable; A computer-readable storage medium executable by one or more processors to cause the above to be performed.

16. The computer-readable storage medium according to claim 15, wherein the executable code includes two or more sections of executable code, and the two or more sections of executable code are loaded into a continuous range of the hardware enclave.

17. The computer-readable storage medium according to claim 15, further including additional instructions executable by the one or more processors to cause the computing system to load startup code into the hardware enclave.

18. The computer-readable storage medium according to claim 17, further including additional instructions executable by the one or more processors to cause the computing system to measure the hash of the startup code and the executable code.

19. A computer-readable storage medium according to claim 18, further comprising additional instructions executable by one or more processors to cause the computing system to sign the hash using the signature of the one or more processors.

20. A computer-readable storage medium according to claim 19, wherein the request for the decryption key includes the signature and the hash.

Images