Protecting commercial off-the-shelf program binaries from piracy using hardware secure enclaves

Abstract

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

Description

Background Art

[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 to convey the information obtained from the internet. A software application can include many different files, including executable files.

[0002] Software developers may be concerned about software piracy. This occurs when an end user purchases or obtains a copy of an application, makes an unauthorized copy of the application, and then uses or distributes the unauthorized copy to a third party. Preventing piracy can be difficult because attackers often have complete control over the computing devices and systems running the application. Summary of the Invention

[0003] According to one aspect of the present disclosure, a method for protecting software from piracy is disclosed. The method includes receiving multiple binary files. Each binary file includes code and data. The method also includes modifying the multiple binary files so that the data of each binary file can be located at any distance from the code of the binary file in memory. The method also includes encrypting the code of each binary file. The method also 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, rather than the data of each binary file, may be stored in the hardware enclave.

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

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

[0006] The method may further comprise validating the hash before providing the decryption key.The request for the decryption key may comprise the hash.

[0007] Modifying the plurality of binary files may include identifying data references in the code of each binary file and modifying the data references.

[0008] Modifying multiple binaries can be accomplished without access to source code or debugging symbols for the multiple binaries.

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

[0010] According to another aspect of the present disclosure, a system for facilitating protection of software programs from piracy is disclosed. The system includes one or more processors, 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 so that the data of each binary file can be located at any distance from the code of the binary file in the memory. The instructions are also executable by the one or more processors to encrypt the code of each binary file instead of 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 security enclave. The encrypted code of each binary file, instead of the data of each binary file, is stored in the hardware security enclave. The hardware security enclave includes instructions to mark the hardware security enclave as unreadable before executing the code.

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

[0012] The instructions may also be executable by the one or more processors 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 may include the processor signature.

[0013] The instructions may also be executable by the 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.

[0014] Modifying the plurality of binary files may include identifying data references in the code of each binary file and modifying the data references.

[0015] Modifying multiple binaries may not require access to source code or debug symbols for the multiple binaries.

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

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

[0018] The executable code may include two or more executable code segments, and the two or more executable code segments may be loaded into a contiguous range in the hardware security area.

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

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

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

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

[0023] This summary is provided to introduce a selection of concepts in a simplified form 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 as an aid in determining the scope of the claimed subject matter.

[0024] Additional features and advantages will be set forth in the description that follows. The features and advantages of the present disclosure may be realized and obtained by the systems and methods particularly pointed out in the appended claims. The features of the present disclosure will become more apparent from the following description and the appended claims, or may be learned by practice of the disclosed subject matter set forth below. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] To describe the manner in which the above-described and other features of the present disclosure can be obtained, a more particular description will be given by reference to specific embodiments illustrated in the accompanying drawings. For better understanding, similar elements are represented by similar reference numerals in the various drawings. 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, in which:

[0026] Figure 1 An example system for utilizing a hardware secure enclave to protect software programs from software piracy is shown.

[0027] Figure 2A and 2B Example files are shown that may be modified in a manner that facilitates protecting the example files from software piracy.

[0028] Figure 3 An example method for modifying a file to facilitate protecting the file from software piracy is shown.

[0029] Figure 4 An example method for loading a file into memory to facilitate protecting the file from software piracy is shown.

[0030] Figure 5 Example methods are shown for authenticating information and providing decryption keys to facilitate protecting files from software piracy.

[0031] Figure 6 An example method for initiating execution of a program to facilitate protecting the program from software piracy is shown.

[0032] Figure 7 Some components that may be included in a computing system are shown. DETAILED DESCRIPTION

[0033] A software developer may create an application for use on a computing device. The application may include a set of instructions that causes the computing device to perform certain tasks. The software developer may invest a significant amount of time and money to design and create the code for the application. The software developer may aim to profit from the sale of authorized copies of the application (by the software developer or a distributor). Therefore, the software developer may want to protect the application from piracy. Software piracy may occur when a user purchases or obtains a copy of the application, makes an unauthorized copy of the application, and uses the unauthorized copy or distributes it to a third party. The third party may use the unauthorized copy of the application instead of purchasing an authorized copy from the software developer or the software developer's distributor. Therefore, software piracy may directly affect the developer's revenue and profits. However, preventing piracy can be difficult because the attacker often has complete control over the system running the application.

[0034] This disclosure describes systems and methods for utilizing hardware secure enclaves to protect program code contained in commercial off-the-shelf (COTS) programs from software piracy. A hardware secure enclave can be a defined area of memory whose contents cannot be read or saved by any software not stored in the hardware secure enclave, including the operating system and even the hypervisor. A set of instruction codes (such as a Software GuardExtensions SGX) or AMD Secure Encrypted Virtualization (SEV) can support the creation and use of hardware secure enclaves. This set of instructions and the hardware secure enclave can allow a remote party to run unmodified programs with confidentiality and / or integrity protection, even if the rest of the system is malicious. Code and data stored in the hardware secure enclave can only trust the hardware secure enclave and can treat any process outside the hardware secure enclave (including the operating system or hypervisor) as potentially hostile. The processor can encrypt information stored in the hardware secure enclave and decrypt the information on the fly within the processor itself.

[0035] Although hardware security zones can provide an opportunity to protect information from malicious systems (requiring only trust in the processor), software developers may not take advantage of hardware security zones because doing so requires the software developer to modify their programs. However, the described systems and methods require little help from the program developer and do not require access to source code or rely on recompiling the program. Instead, the described systems and methods can be applied directly to commercial off-the-shelf (COTS) program binaries by individuals or entities other than the software developer. Therefore, aspects of the described systems and methods can be provided as a service to software developers by software distribution platforms, operating system developers, or other trusted parties. Therefore, the described systems and methods can increase the utilization of hardware security zones to defeat piracy of both new and traditional software. Of course, software developers can also implement various aspects of the described systems and methods instead of relying on third parties.

[0036] Suppose a software developer provides a COTS application to a platform to distribute and sell the application to consumers. The application may include one or more binary files including executable code. In the case of a PC application, the application may include one or more EXE files and one or more DLL files. Each binary file may include one or more code segments (segments of executable instructions) and one or more data segments including information referenced and used by the executable instructions. In order to run the binary file correctly, it may be required to place the data segment in memory at a predetermined and fixed distance from the code segment. The application or binary file can define a predetermined and fixed distance.

[0037] Before making the application available to purchasers, the platform may modify each binary file that contains executable code. The platform may modify each binary file in up to three ways: (1) separating the code segment from the data segment; (2) encrypting the code segment; and (3) adding a file header.

[0038] First, for each binary file including executable code, the platform can separate the code segment from the data segment so that the code and data can be loaded into two locations in the memory at any distance apart (in contrast to the predetermined distance required before separation). Separating code from data can involve modifying all data references in the code assuming a fixed distance between code and data. The platform can separate code from data without relying on any information not included in the binary file. Therefore, the platform can separate code from data without accessing the source code or debugging symbols of the binary file. Separating code from data can facilitate loading all code segments from multiple binary files adjacently into a single continuous memory area.

[0039] Second, after the platform separates the code from the data, the platform may encrypt the code segment included in each modified binary file. The platform may leave the data portion of the binary file as unencrypted plain text.

[0040] Third, the platform may add a file header or other information to one or more of the modified binary files. The file header may communicate to the operating system that the code segment in the modified binary file has been separated from the data segment in the modified binary file. The file header may also communicate that the code segment should be loaded into the hardware secure enclave and the data segment should be loaded outside the hardware secure enclave.

[0041] After modifying the binary file, the platform can sell or distribute the application to the public (using the modified binary file). The user can download the application to the disk storage on the computing device that also includes the hardware security zone. When the user starts the application, the operating system of the computing device can load the binary file of the application into the memory. The operating system can be designed to recognize when the code segment in the binary file is separated from the data segment. The operating system can also be designed to recognize when the code segment should be loaded into the hardware security zone. The operating system can determine that the code and data segments are separated and the code segment should be loaded into the hardware security zone based on the file header. After all the code segments from the modified binary file are loaded into a continuous range in the hardware security zone, the operating system can load all the data segments from the modified binary file into the process memory outside the hardware security zone.

[0042] In order to load the modified binary file in this manner, the operating system may include a loader that is different from the standard loader. The loader may be part of the operating system, designed to move the executable file for the application from the disk storage device to the process memory and to guide the startup process for the application. The standard loader may load the code segment and the data segment into the memory together and may not recognize the information in the modified binary file indicating that the code segments should be loaded together. However, the loader included in the above-mentioned operating system is designed to load the code segment of the modified binary file together into the hardware security zone and load the data segment outside the hardware security zone. But even though the loader of the above-mentioned operating system may be different from the standard loader, the operating system kernel is not customized or changed. Therefore, the described system and method may require only minimal modifications to the existing operating system.

[0043] In addition to loading the modified binary file, the operating system can also load the boot code into the hardware security zone. The boot code can be included in the operating system and may not be encrypted. Alternatively, the platform can provide the boot code to the computing device together with the application.

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

[0045] Before the application runs, the startup code can mark all hardware secure enclave memory as unreadable by code stored in the hardware secure enclave to protect the application from leaking code contents. Otherwise, an attacker could attempt to trick the application into leaking code contents by manipulating data pointers not protected by the hardware secure enclave. Data segments stored outside the hardware secure enclave may contain pointers. An attacker might be able to change pointers in the data segment to point to the code segment. If the code does not check whether the data points to code, the code could leak its contents if the hardware secure enclave is not marked as unreadable.

[0046] Despite its potential to combat software piracy, hardware secure enclaves have not yet been widely adopted. As mentioned above, one reason may be that utilizing hardware secure enclaves requires software developers to modify existing software. Typically, software developers must modify programs to make them aware of the hardware secure enclave in order to utilize its functionality. However, the disclosed systems and methods do not require software developers to modify programs. The disclosed systems and methods also do not require software developers to provide source code. Instead, the disclosed systems and methods allow platforms or service providers to modify programs to utilize hardware secure enclaves without requiring assistance or additional information from the software developer. In this way, the described systems and methods allow software distribution platforms to provide an end-to-end anti-piracy solution for third-party applications without relying on software developers.

[0047] Another reason hardware secure enclaves haven't seen widespread adoption may be a lack of support from major operating systems. However, the described systems and methods retain compatibility with commodity operating systems because they do not affect how the operating system accesses a program's data to service certain system calls (e.g., loading file contents into the program's memory). The program's data still resides in ordinary process memory, which is both readable and writable. Therefore, 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 practical for adoption on multiple platforms (e.g., Windows, Mac, etc.).

[0048] Another reason hardware secure enclaves haven't been widely adopted may be the limited amount of secure enclave memory. The described systems and methods alleviate memory pressure by using secure enclave memory only for a program's code segments, which are typically significantly smaller than a program's data segments. Furthermore, software pirates may be more interested in application code than data.

[0049] Figure 1 An example system 100 is shown in which the techniques disclosed herein for protecting software from piracy can be utilized. System 100 may include a platform 102, an authentication server 146, and a computing device 104. Platform 102 and computing device 104 may be connected via a network 142. Computing device 104 and authentication server 146 may also be connected via network 142.

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

[0051] Program 108a may include one or more files, such as file 110a and file 112a. Program 108a may include Figure 1Additional files not shown in the program 108a. In some other designs, the program 108a may include only one file. The files 110a, 112a may be unencrypted binary files. The files 110a, 112a may include executable code and data. The executable code may be instructions that a processor can understand and execute. The executable code in the files 110a, 112a may include references to the data included in the files 110a, 112a. The files 110a, 112a may be designed so that when running on a computing device, the data included in the files 110a, 112a must be stored in memory at a fixed and predetermined distance from the code included in the files 110a, 112a. The program 108a or the files 110a, 112a may define the fixed and predetermined distance.

[0052] Platform 102 may provide software programs for distribution and sale. Platform 102 may include an online store from which 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 enabling platform 102 to sell authorized copies 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, make unauthorized copies of program 108a, and then distribute the unauthorized copies 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.

[0053] Platform 102 may include program 108b. Program 108b may be a modified version of program 108a. Program 108b may include modified file 110b and modified file 112b. Modified file 110b may be a modified version of file 110a, and modified file 112b may be a modified version of file 112a. Modified files 110b and 112b may be binary files. Platform 102 may have modified program 108a to create program 108b in order to facilitate protection of program 108a from software piracy. Alternatively, software developer 106 or an entity other than platform 102 may modify program 108a to create program 108b.

[0054] The modified file 110b may include encrypted code 114b-1, encrypted code 114b-2, data 116b-1, data 116b-2, and a file 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. When the data 116b-1, 116b-2 is located in memory at any distance from the encrypted code 114b-1, 114b-2, the encrypted code 114b-1, 114b-2 may allow the computing device to execute the modified file 110b. In addition, the encrypted code 114b-1, 114b-2 may be encrypted so that a key is required to decrypt and execute the encrypted code 114b-1, 114b-2. Unlike the encrypted code 114b-1, 114b-2, the data 116b-1, 116b-2 may be unencrypted.

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

[0056] Modified file 112b may include encrypted code 114b-3, data 116b-3, and a file header 118b-2. Encrypted code 114b-2 may be a modified version of the code included in file 112a. When data 116b-3 is stored in memory at any distance from encrypted code 114b-3, encrypted code 114b-3 may allow a computing device to execute modified file 112b. Furthermore, encrypted code 114b-3 may be encrypted. Unlike encrypted code 114b-3, data 116b-3 may be unencrypted.

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

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

[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 file header 118c-1 (which may be a copy of file 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 file header 118c-2 (which may be a copy of file header 118b-2).

[0060] A user of computing device 104 may cause computing device 104 to launch program 108c. Operating system 126 of computing device 104 may use loader 128 to load program 108c into memory 130 of computing device 104. Operating system 126 may be a program that manages the hardware and software on a computing device, such as computing device 104. Platform 102 may have already developed operating system 126. Loader 128 may be designed to determine whether modified files 110c, 112c include code that has been separated from data. Loader 128 may determine from file headers 118c-1, 118c-2 that modified files 110c, 112c include code that has been separated from data.

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

[0062] The loader 128 may load the encrypted code 114c-1, 114c-2, 114c-3 into the hardware secure enclave 132. The loader 128 may load the encrypted code 114c-1, 114c-2, 114c-3 within a contiguous range of the hardware secure enclave 132. The loader 128 may also load startup code 134 into the hardware secure enclave 132. The startup code 134 may be included in the operating system 126. Alternatively, the computing device 104 may obtain the startup code 134 from the platform 102 or as part of the program 108b. The startup code 134 may be unencrypted. The loader 128 may load the data 116c-1, 116c-2, 116c-3 into the memory 130 outside the hardware secure enclave 132. The data 116c-1, 116c-2, 116c-3 may be located in the memory 130 at any distance from the encrypted code 114c-1, 114c-2, 114c-3.

[0063] Once the loader 128 has loaded the modified files 110c, 112c into the memory 130, the operating system 126 can initiate the boot code 134. The boot code 134 can include instructions to cause the processor to perform remote attestation to obtain a key, such as decryption key 124, for decrypting the encrypted code 114c-1, 114c-2, 114c-3. As part of performing the remote attestation, the boot code 134 can include instructions to cause the processor 136 to provide information that proves the authenticity of the contents of the hardware secure enclave 132. For example, the boot code 134 can include instructions to cause the processor 136 of the computing device 104 to measure a hash of the encrypted code 114c-1, 114c-2, 114c-3. The processor 136 can also include the boot code 134 in the hash measurement. The processor can use a common hash function to measure the hash of the encrypted code 114c-1, 114c-2, 114c-3 and the boot code 134.

[0064] As part of performing remote attestation, processor 136 may provide information proving its authenticity. For example, processor 136 may include signature module 138, and processor 136 may cause signature module 138 to sign the hash using a processor signature. Signature module 138 may sign the hash using a private certificate maintained by processor 136.

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

[0066] Authentication server 146 may verify the processor signature received from processor 136. Authentication server 146 may use public certificate 148 to verify the processor signature. Authentication server 146 may verify the processor signature to confirm that processor 136 is authentic and can be trusted. If authentication server 146 cannot verify the processor signature, processor 136 may be malicious or controlled by an attacker. In this case, processor 136 may not have placed encrypted code 114b-1, 114b-2, 114b-3 in a secure hardware enclave. When authentication server 146 cannot verify the processor signature, authentication server 146 may not provide decryption key 124 to computing device 104. Otherwise, a user of computing device 104 may be able to cause computing device 104 to place encrypted code 114b-1, 114b-2, 114b-3 in an unsecured portion of memory 130, decrypt encrypted code 114b-1, 114b-2, 114b-3 using decryption key 124, and make unauthorized copies of the decrypted code.

[0067] Authentication server 146 may verify the hash. Authentication server 146 may include a verified hash value 150. Authentication server 146 may determine whether the hash received from processor 136 matches verified hash value 150. Platform 102 may have determined verified hash value 150 when platform 102 generated modified files 110b, 112b. Platform 102 may have had access to boot code 134 to generate verified hash value 150. Authentication server 146 may verify the hash to determine that computing device 104 has not modified encrypted code 114b-1, 114b-2, 114b-3 or boot code 134. If authentication server 146 cannot verify the hash, authentication server 146 may not provide decryption key 124 to the computing device. Otherwise, a user of computing device 104 may be able to modify boot code 134 or encrypted code 114b-1, 114b-2, 114b-3 to include instructions to provide information about the decrypted contents of hardware secure enclave 132. By verifying the hash, system 100 can protect program 108a from malicious loaders. Even if loader 128 is malicious, loader 128 cannot pirate encrypted code 114b-1, 114b-2, 114b-3 because it is encrypted. And even if loader 128 injects additional information into encrypted code 114b-1, 114b-2, 114b-3 or mistakenly loads encrypted code 114b-1, 114b-2, 114b-3, authentication server 146 will not verify the hash.

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

[0069] Before the processor 136 executes the decrypted code 120-1, 120-2, 120-3, the boot code 134 may cause the processor 136 to mark the hardware security area 132 as unreadable for all instructions residing in the hardware security area 132. The boot code 134 may include these instructions to protect the decrypted code 120-1, 120-2, 120-3 from leaking its contents. Readability and execution may be two separate permissions. Therefore, marking the hardware security area 132 as unreadable may not prevent the decrypted code 120-1, 120-2, 120-3 from being executed. Once the processor 136 marks the hardware security area 132 as unreadable, the processor 136 may execute the decrypted code 120-1, 120-2, 120-3. The decrypted code 120-1, 120-2, 120-3 may perform the same functions as the code included in the files 110a, 112a.

[0070] Figure 2A and 2B Shown are file 210a and modified file 210b according to the techniques described herein. File 210a may be Figure 1 An example of file 110a is shown. The modified file 210b may be Figure 1 An example of a modified file 110b is shown.

[0071] File 210a may be part of a COTS software program. File 210a may be an unencrypted binary file including executable code and data. For example, file 210a may include code segment 220a-1, code segment 220a-2, data segment 216a-1, and data segment 216a-2. Code segments 220a-1 and 220a-2 may include executable code and may be unencrypted. The size of code segments 220a-1 and 220a-2 may be much smaller than that of data segments 216a-1 and 216a-2. Code segments 220a-1 and 220a-2 may include one or more references to data segments 216a-1 and 216a-2. For example, code segment 220a-1 may include data reference 242a-1, data reference 242a-2, and data reference 242a-3, and code segment 220a-2 may include data reference 242a-4. Although file 210a includes two code segments and two data segments, in some other embodiments, a file may include only one code segment and one data segment, or more than two code segments and more than two data segments. A file may also include unequal numbers of code segments and data segments.

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

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

[0074] Modified file 210b may include encrypted code segment 214b-1, encrypted code segment 214b-2, data segment 216b-1, and data segment 216b-2. Encrypted code segments 214b-1, 214b-2 may be modified versions of code segments 220a-1, 220a-2. Encrypted code segments 214b-1, 214b-2 may be encrypted so that a computing device cannot execute encrypted code segments 214b-1, 214b-2 without first obtaining a decryption key. Data segments 216b-1, 216b-2 may be copies of data segments 216a-1, 216a-2. Data segments 216b-1, 216b-2 may include data 244b-1 (which may be a copy of data 244a-1), data 244b-2 (which may be a copy of data 244a-2), and data 244b-3 (which may be a copy of data 244a-3). Data segments 216b-1, 216b-2 may be unencrypted plain text.

[0075] Encrypted code segment 214b-1 may include modified data reference 242b-1, modified data reference 242b-2, and modified data reference 242b-3. Encrypted code segment 214b-2 may include modified data reference 242b-4. Modified data reference 242b-1 may be a modified version of data reference 242a-1. Modified data reference 242b-2 may be a modified version of data reference 242a-2. Modified data reference 242b-3 may be a modified version of data reference 242a-3. Modified data reference 242b-4 may be a modified version of data reference 242a-4. The modified data references 242b-1, 242b-2, 242b-3, 242b-4 can be modified so that the modified data references 242b-1, 242b-2, 242b-3, 242b-4 will point to the correct data during runtime even if the distance in memory between the encrypted code segments 214b-1, 214b-2 and the data segments 216b-1, 216b-2 is different from the fixed and predetermined distance that may be defined in the file 210a. For example, if the data reference 242a-1 points to the data 244a-1 when the data segment 216a-1 is placed in memory at a fixed and predetermined distance from the code segment 220a-1, then the modified data reference 242b-1 will point to the data 244b-1 when the data segment 216b-1 is placed in memory at a distance different from the fixed and predetermined distance from the code segment 214b-1. Therefore, the modified data references 242b-1, 242b-2, 242b-3, 242b-4 are designed so that any distance can exist between the encrypted code segments 214b-1, 214b-2 and the data segments 216b-1, 216b-2 in memory.

[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 segments 220a-1, 220a-2. Locating data references 242a-1, 242a-2, 242a-3, 242a-4 may involve the use of relocation information. File 210a or a program including file 210a may include relocation information for all data references within the code segments. Relocation information may be included to support Address Space Layout Randomization (ASLR). ASLR may allow a processor to load a program anywhere in memory. However, ASLR may still require that the distance between code and data be a fixed distance defined in the program. However, ASLR can help the platform locate data references 242a-1, 242a-2, 242a-3, 242a-4. Therefore, the platform can use the relocation information to locate the data references 242a-1, 242a-2, 242a-3, 242a-4. After locating the data references 242a-1, 242a-2, 242a-3, 242a-4, the platform can modify the data references 242a-1, 242a-2, 242a-3, 242a-4 to separate the code segments 220a-1, 220a-2 from the data segments 216a-1, 216a-2.

[0077] The modified file 210b may include a file header 218b. The file header 218b may include information about the modified file 210b. The file header 218b may be unencrypted. The file header 218b may indicate that the encrypted code segments 214b-1, 214b-2 have been separated from the data segments 216b-1, 216b-2, so that the data segments 216b-1, 216b-2 can be loaded into the memory at any distance from the code segments 214b-1, 214b-2. The file header 218b may indicate that the code segments 214b-1, 214b-2 should be loaded into the hardware security zone and that the data segments 216b-1, 216b-2 should be loaded into the memory outside the hardware security zone. The platform may add the file header 218b to the modified file 210b.

[0078] Figure 3 An example method 300 is shown for modifying a file to facilitate using a hardware secure enclave to protect a program from piracy.

[0079] Method 300 may include receiving 302 a file including code and data. The file may be part of a program, which may be a COTS software product. The file may be file 110a, file 112a, or file 210a. The program may include additional information in addition to 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 so that the data must be stored in memory at a fixed and predetermined distance from the code in order for the file to execute correctly. A platform (such as platform 102) may receive 302 the file.

[0080] Method 300 may include locating 304 a data reference in the code. A data reference may point to specific information or a location in the data. The code may use the data reference as part of obtaining or modifying specific information in the data. The data reference may be designed such that the data must be stored in memory at a fixed, predetermined distance from the code so that the data reference points to the correct information in 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 the file. The platform may locate 304 the data reference without using information from the developer of the program outside of the program.

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

[0082] Method 300 may include modifying 306 data references in the code. Modifying 306 the data references may include separating the code from the data. When separated, the data can be placed in memory at any distance from the code, and the data references in the code will still point to the correct information in the data during runtime. The platform may modify 306 the data references. The platform may modify 306 the data references without accessing source code or debug symbols associated with the file. The platform may modify 306 the data references without accessing information from the developer of the program outside of the program.

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

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

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

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

[0087] Figure 4 A potential method 400 for loading applications to facilitate protecting the applications from software piracy is shown.

[0088] Method 400 may include receiving 402 a request to initiate an application. The application may include one or more files having executable code. Each of the one or more files may include code and data. The code and data in the one or more files may have been separated so that data from each of the one or more files can be loaded into memory at any distance from the code of the file. The code in the one or more files may be encrypted. The data in the one or more files may be unencrypted. An operating system (such as operating system 126) may receive 402 the request.

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

[0090] Method 400 may include loading 406 boot code into the hardware secure enclave. The boot code may include instructions consumable by the processor. The boot code may include instructions for the processor to measure a hash of information stored in the hardware secure enclave, sign the hash with a signature, provide the hash and signature to an authentication server, and mark the hardware secure enclave as unreadable. The operating system may load 406 the boot code into the hardware secure enclave. The operating system may include the boot code. Alternatively, the operating system may receive the boot code from the platform.

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

[0092] Method 400 may include loading 410 data contained in one or more files into memory outside the hardware secure enclave. The data may be unencrypted. Loading 410 the data may include loading the data into a contiguous range in memory outside the hardware secure enclave. Loading 410 the data may include loading the data at any distance from the code in memory. An operating system may load 410 the data contained in the one or more files into memory outside the hardware secure enclave. The operating system may use a loader to load 410 the data.

[0093] Method 400 may include causing execution of boot code at 412. The operating system may cause execution of the boot code at 412. The boot code may be unencrypted.

[0094] Figure 5 An example method for providing decryption keys according to the techniques described herein is shown.

[0095] Method 500 may include receiving 502 a request for a decryption key, the request including a hash and a signature. The computing device may make the request and provide the hash and 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 secure enclave. The hardware secure enclave may include encrypted code and boot code. The processor may have measured a hash of the encrypted code and boot code. The processor may have signed the hash with a signature using a private certificate. A platform or authentication server may receive 502 the request.

[0096] Method 500 may include authenticating 504 the signature. Authenticating 504 the signature may include determining that the hash is signed using a private certificate. Authenticating 504 the signature may be accomplished using a public certificate. The platform or an authentication server may authenticate 504 the signature. Authenticating 504 the signature may verify that the processor is authentic and can be trusted to enforce confidentiality and / or integrity protection of the hardware secure enclave.

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

[0098] Method 500 may include providing 508 a decryption key. The decryption key may allow 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 508 the decryption key. The platform or authentication server may not provide 508 the decryption key unless the signature is authentic 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.

[0099] Figure 6 An example method 600 is shown for initiating a program modified according to the techniques disclosed herein.

[0100] Method 600 may include causing a processor 602 to measure a hash of code in a hardware secure enclave. Boot code stored in the hardware secure enclave may include instructions for causing the processor 602 to measure a hash of the code in the hardware secure enclave. The processor may use a standard hash function to measure the hash of the code in the hardware secure enclave. The code in the hardware secure enclave may include boot code and encrypted code from a program. The program may include a file whose code and data segments have been separated. Measuring the hash of the code in the hardware secure enclave may be part of a remote attestation process for obtaining a decryption key. In addition to measuring the hash, other methods for attesting the contents of the hardware secure enclave may also be used.

[0101] Method 600 may include causing 604 the processor to sign the hash with a signature. The boot code may include instructions for causing 604 the processor to sign the hash with a signature. The processor may sign the hash with a signature using a private certificate. Signing the hash with a signature may be part of a remote attestation process for obtaining a decryption key. In addition to signing the hash with a signature, other methods for proving the authenticity of the processor may also be used.

[0102] Method 600 may include causing the processor 606 to request a decryption key from an authentication server, the request including a hash and a signature. The boot code may include instructions for causing the processor 606 to request the decryption key. 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. If the authentication server verifies the hash and signature, the authentication server may provide the decryption key. If the authentication server determines that the signature is not authentic or the hash is incorrect, the authentication server may not provide the decryption key. Although method 600 includes causing the processor 606 to request a decryption key using a hash and a signature, other authentication methods may also be used.

[0103] The method 600 may include causing 608 the processor to decrypt the code. The boot code may include instructions for causing 608 the processor to decrypt the code using a decryption key.

[0104] The method 600 may include causing 610 the processor to mark the hardware security enclave as unreadable. The boot code may include instructions for causing 610 the processor to mark the hardware security enclave as unreadable for instructions within the hardware security enclave.

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

[0106] Computer system 700 includes a processor 701. Processor 701 may be a general-purpose single-chip or multi-chip microprocessor (e.g., Advanced RISC (Reduced Instruction Set Computer) Machine (ARM)), a special-purpose microprocessor (e.g., a digital signal processor (DSP), a microcontroller, a programmable gate array, etc. Processor 701 may be referred to as a central processing unit (CPU). Although in Figure 7 Just a single processor 701 is shown in the computer system 700 , but in an alternative configuration, a combination of processors (eg, an ARM and DSP) could be used.

[0107] Computer system 700 also includes memory 703 in electronic communication with processor 701. Memory 703 can be any electronic component capable of storing electronic information. For example, memory 703 can be embodied as random access memory (RAM), read-only memory (ROM), magnetic disk storage media, optical storage media, flash memory devices in RAM, onboard memory within the processor, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) memory, registers, and the like, including combinations thereof.

[0108] Instructions 705 and data 707 may be stored in memory 703. Instructions 705 may be executed by processor 701 to implement some or all of the functionality disclosed herein. Executing instructions 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 instructions 705 stored in memory 703 and executed by processor 701. Any of the various examples of data described herein may be among the data 707 stored in memory 703 and used during execution of instructions 705 by processor 701.

[0109] The computer system 700 may also include one or more communication interfaces 709 for communicating with other electronic devices. The communication interface(s) 709 may be based on wired communication technology, wireless communication technology, or both. Some examples of the communication interface 709 include a universal serial bus (USB), an Ethernet adapter, a wireless adapter operating according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 wireless communication protocol, Wireless communication adapter and infrared (IR) communication port.

[0110] The computer system 700 may also include one or more input devices 711 and one or more output devices 713. Some examples of input devices 711 include a keyboard, a mouse, a microphone, a remote control device, buttons, a joystick, a trackball, a touchpad, and a light pen. Some examples of output devices 713 include speakers and a printer. One specific type of output device that is typically included in the computer system 700 is a display device 715. The display device 715 used with the embodiments disclosed herein can utilize any suitable image projection technology, such as a liquid crystal display (LCD), a light emitting diode (LED), gas plasma, electroluminescence, etc. A display controller 717 may also be provided for converting data 707 stored in the memory 703 into text, graphics, and / or moving images (as appropriate) displayed on the display device 715.

[0111] The various components of the computer system 700 may be coupled together via one or more buses, which may include a power bus, a control signal bus, a status signal bus, a data bus, etc. For clarity, the various buses are shown in FIG. Figure 7 Shown in FIG. 7 is a bus system 719 .

[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 features described as modules, components, and the like may also be implemented together in an integrated logic device, or separately as discrete but interoperable logic devices. If implemented in software, the techniques may be implemented at least in part by a non-transitory computer-readable medium having computer-executable instructions stored thereon that, when executed by at least one processor, perform some or all of the steps, operations, actions, or other functions disclosed herein. Instructions may be organized into routines, programs, objects, components, data structures, and the like that may perform specific tasks and / or implement specific data types, and which may be combined or distributed as desired in various embodiments.

[0113] The term "processor" may refer to a general-purpose single-chip 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 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.

[0114] The term "memory" may refer to any electronic component capable of storing electronic information. For example, memory may be embodied as random access memory (RAM), read-only memory (ROM), magnetic disk storage media, optical storage media, flash memory devices in RAM, onboard memory within a processor, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, and the like, including combinations thereof.

[0115] The steps, operations, and / or actions of the methods described herein may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps, operations, and / or actions is required for proper operation of the method being described, the order and / or use of specific steps, operations, and / or actions may be modified without departing from the scope of the claims.

[0116] The term "determine" (and its grammatical variations) can encompass a variety of actions. For example, "determine" can include calculating, computing, processing, deriving, investigating, searching (e.g., searching in a table, database, or another data structure), ascertaining, etc. Furthermore, "determine" can include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), etc. Furthermore, "determine" can include resolving, selecting, choosing, establishing, etc.

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

[0118] The present disclosure may be embodied in other specific forms without departing from the spirit or characteristics of the present disclosure. The described embodiments are to be considered illustrative rather than restrictive. Therefore, the scope of the present disclosure is indicated by the appended claims rather than by the foregoing description. Changes within the meaning and range of equivalence of the claims are to be included within their scope.

Claims

1. A method for protecting software from piracy, the method comprising: receiving a plurality of binary files, each binary file comprising code and data, wherein the code of each binary file comprises a reference to the data of the binary file, and the reference requires a fixed distance between the code and the data; modifying the plurality of binary files so that the data of each binary file can be located at any distance in memory from the code of the binary file; encrypting said code for each binary file; as well as A request for a decryption key is received from a computing device, wherein the computing device includes a hardware secure enclave, wherein the hardware secure enclave comprises a defined area of memory of the computing device, the defined area configured to protect the hardware secure enclave from instructions residing outside the hardware secure enclave, wherein the encrypted code for each binary file is stored in the hardware secure enclave, and wherein the data for each binary file is stored outside the secure enclave.

2. The method according to claim 1, further comprising: The decryption key is provided to the computing device.

3. The method according to claim 2, further comprising: A processor signature is authenticated prior to providing the decryption key, wherein a processor of the computing device generates the processor signature and the request for the decryption key includes the processor signature.

4. The method according to claim 3, further comprising: A hash is verified before providing the decryption key, wherein the request for the decryption key includes the hash. 5 . The method of claim 1 , wherein modifying the plurality of binary files comprises modifying data references in the code of each binary file, the data references requiring the data to be placed in memory a fixed distance from the code. 6 . The method of claim 5 , wherein modifying the plurality of binary files is accomplished without access to source code or debugging symbols for the plurality of binary files.

7. The method according to claim 1, further comprising: A separate file header is added to each binary file in the plurality of binary files, wherein the separate file header indicates that the data of each binary file in the plurality of binary files can be placed at any distance from the code of the binary file in the memory.

8. A system for facilitating protection of software programs from piracy, comprising: one or more processors; a system memory in electronic communication with the one or more processors; as well as Instructions stored in the system memory, the instructions being executable by the one or more processors to: receiving a plurality of binary files, each binary file comprising code and data, wherein the code of each binary file comprises a reference to the data of the binary file, and wherein the references are designed such that the data must be stored in a memory at a fixed predetermined distance from the code; modifying the plurality of binary files so that the data of each binary file can be located at any distance from the code of the binary file in the memory; encrypting the code of each binary file, but not encrypting the data of each binary file; as well as A request for a decryption key is received from a computing device, wherein the computing device includes a hardware secure enclave, wherein the encrypted code for each binary file is stored in the hardware secure enclave, wherein the data for each binary file is stored outside the hardware secure enclave, wherein the hardware secure enclave includes instructions to mark the hardware secure enclave as unreadable prior to execution of the code, and wherein the hardware secure enclave includes a defined area of memory of the computing device, the defined area configured to have confidentiality and integrity protection from other instructions residing outside the hardware secure enclave.

9. The system of claim 8, the instructions further executable by the one or more processors to: provide the decryption key to the computing device.

10. The system of claim 9, the instructions being further executable by the one or more processors to: authenticate a processor signature before providing the decryption key, wherein a processor of the computing device generates the processor signature and the request for the decryption key includes the processor signature.

11. The system of claim 10, the instructions being further executable by the one or more processors to: verify a hash before providing the decryption key, wherein the request for the decryption key includes the hash, and verifying the hash includes comparing the hash to a verified hash value. 12 . The system of claim 8 , wherein modifying the plurality of binary files comprises identifying data references in the code of each binary file and modifying the data references.

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

14. The system of claim 8, the instructions being further executable by the one or more processors to: add a separate file header to each binary file in the plurality of binary files, wherein the separate file header indicates that the data of each binary file in the plurality of binary files can be placed in the memory at any distance from the code of the binary file and that the code of the binary file should be placed in the hardware secure enclave.

15. A non-transitory computer-readable medium comprising instructions executable by one or more processors to cause a computing system to: receiving a request to launch an application, the application comprising one or more files having executable code and data, wherein the executable code is encrypted; loading the executable code into a hardware secure enclave on the computing system; loading the data into a location in memory on the computing system, wherein the location is outside the hardware secure enclave and is not a predetermined distance from the executable code in the memory on the computing system, wherein the hardware secure enclave comprises a defined area of the memory and only software stored in the hardware secure enclave can read or save contents of the hardware secure enclave; Sending a request for a decryption key to the 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 Mark the hardware security area as unreadable. 16 . The non-transitory computer-readable medium of claim 15 , wherein the executable code comprises two or more executable code segments, and the two or more executable code segments are loaded into a contiguous range in the hardware security enclave.

17. The non-transitory computer-readable medium of claim 15, further comprising additional instructions executable by the one or more processors to cause the computing system to load boot code into the hardware secure enclave.

18. The non-transitory computer-readable medium of claim 17, further comprising additional instructions executable by the one or more processors to cause the computing system to measure hashes of the boot code and the executable code.

19. The non-transitory computer-readable medium of claim 18, further comprising additional instructions executable by the one or more processors to cause the computing system to sign the hash with a signature of the one or more processors.

20. The non-transitory computer-readable medium of claim 19, wherein the request for the decryption key comprises the signature and the hash.

Images