Protection of commercial off-the-shelf binary files from piracy using hardware secure regions

Abstract

Embodiments of the present disclosure relate to protecting commercial off-the-shelf binary files from piracy using a hardware security region. The present disclosure describes systems and methods for protecting commercial off-the-shelf software program code from piracy. A software program may include a plurality of image files having code and data. The platform may modify the executable file such that the data may be placed in memory at any distance from the code. The platform may encrypt the code and provide it to a computing device that includes a hardware-secure region. The computing device may load encrypted code into the hardware secure region, but load data into memory outside the hardware secure region. The computing device may request a decryption key from the authentication server using the hash of the hardware secure region signed by the processor. If the authentication server verifies the signature and the hash, the authentication server may provide a decryption key. The computing device may decrypt the code and mark the hardware secure region as unreadable.

Description

[0001] This application is a continuation of the invention patent application of Chinese National Application No. 202080091640.1, filed on November 17, 2020, entitled “Protecting Commercial Off-The-Shelf Program Binaries from Piracy Using Hardware Enclaves.” BACKGROUND

[0002] Computing devices can be used to perform a wide 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 communicate the information obtained from the internet. Software applications can include many different files, including executable files.

[0003] Software developers can 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 the application, and uses the unauthorized copy or distributes it to third parties. Preventing piracy can be difficult because an attacker typically has full control of the computing device and system running the application. SUMMARY

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

[0005] The method can also include providing the decryption key to the computing device.

[0006] The method can also include authenticating 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 can include the processor signature.

[0007] The method can also include validating a hash before providing the decryption key. The request for the decryption key can include the hash.

[0008] Modifying the plurality of binaries can include identifying data references in the code of each binary and modifying the data references.

[0009] Modifications to multiple binaries can be done without accessing the source code or debugging symbols of the binaries.

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

[0011] According to another aspect of this disclosure, a system for facilitating the protection of software programs 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 in memory at any distance 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 secure region. The encrypted code of each binary file, but not the data of each binary file, is stored in the hardware secure region. The hardware secure region includes instructions to mark the hardware secure region as unreadable before executing the code.

[0012] The instructions can also be executed by one or more processors to provide a decryption key to the computing device.

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

[0014] The instructions can also be executable by one or more processors to verify the hash before providing the decryption key. A request for the decryption key may include a hash, and verifying the hash may include comparing the hash with a verified hash value.

[0015] Modifying multiple binaries can include identifying data references in the code of each binary and modifying those data references.

[0016] Modifying multiple binaries may not require access to the source code or debugging symbols for those binaries.

[0017] The instructions can also be executable by one or more processors to add a split header to each of the multiple binary files. The split header can indicate that the data of each binary file can be placed in memory at any distance from the code of that binary file, and that the code of that binary file should be placed in a hardware-secure area.

[0018] According to another aspect of this 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 for initiating 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 one or more processors to cause the computing system to load the executable code into a hardware-secured region on the computing system and to load the data into a location in memory on the computing system. This location is outside the hardware-secured region and is not a predetermined distance from the executable code in memory. 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 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 one or more processors to cause the computing system to mark the hardware-secured region as unreadable.

[0019] 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 within a hardware security region.

[0020] The computer-readable medium may also include additional instructions that are executable by one or more processors to cause the computing system to load startup code into a hardware-secure area.

[0021] The computer-readable medium may also include additional instructions that are executable by one or more processors to enable the computing system to measure the hashes of the startup code and the executable code.

[0022] The computer-readable medium may also include additional instructions that are executable by one or more processors to enable a computing system to sign the hash using the signatures of one or more processors.

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

[0024] This summary is provided to introduce the selected concepts in a simplified form, which will be further described in the detailed description below. This summary is not intended to identify key 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.

[0025] Additional features and advantages will be set forth in the description below. The features and advantages of this disclosure can be realized and obtained by means of the systems and methods particularly pointed out in the appended claims. The features of this disclosure will become more apparent from the following description and the appended claims, or may be learned by practice of the subject matter of the disclosure set forth below. Attached Figure Description

[0026] To describe in detail the ways in which the above and other features of this disclosure can be obtained, a more specific description will be given by reference to the specific embodiments illustrated in the accompanying drawings. For better understanding, similar elements are indicated by similar reference numerals in the various drawings. The drawings depict some exemplary embodiments, which will be described and explained with additional specificity and detail using the drawings, in which:

[0027] Figure 1 An example system is shown for using hardware security zones to protect software programs from software piracy.

[0028] Figure 2A and 2B The example file is shown in a way that can be modified to facilitate the protection of the example file from software piracy.

[0029] Figure 3 An example method for modifying files to facilitate protection against software piracy is shown.

[0030] Figure 4 An example method for loading files into storage to facilitate the protection of files from software piracy is shown.

[0031] Figure 5 Example methods are shown for authenticating information and providing decryption keys to facilitate the protection of files from software piracy.

[0032] Figure 6 An example method is shown for initiating the execution of a program to facilitate protection against software piracy.

[0033] Figure 7 This shows some components that can be included in a computing system. Detailed Implementation

[0034] Software developers can create applications used on computing devices. An application may include a set of instructions that cause the computing device to perform certain tasks. Software developers may invest significant time and money in designing and creating the application's code. They may aim to profit from selling licensed copies of the application (either by the developer or distributor). Therefore, they may want to protect their application from piracy. Software piracy occurs when a user purchases or obtains a copy of the application, makes an unauthorized copy, and uses or distributes the unauthorized copy to a third party. A third party can use an unauthorized copy of the application instead of purchasing a licensed copy from the software developer or their distributor. Therefore, software piracy can directly impact a developer's revenue and profits. However, preventing piracy can be difficult because attackers often have complete control over the system running the application.

[0035] This disclosure describes systems and methods for using hardware-secured regions to protect program code contained in commercial off-the-shelf (COTS) programs from software piracy. The hardware-secured region can be a defined area of ​​memory whose contents cannot be read or saved by any software not stored within it, including operating systems and even hypervisors. A set of instruction code built into the processor (such as...) Software GuardExtensions SGX (or AMD Secure Encrypted Virtualization (SEV)) can support the creation and use of hardware secure zones. This set of instructions and hardware secure zones 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 a hardware secure zone can trust only the hardware secure zone and can treat any process outside the hardware secure zone (including the operating system or hypervisor) as potentially hostile. The processor can encrypt information stored in the hardware secure zone and decrypt it on the fly within the processor itself.

[0036] While hardware-secure zones can offer the opportunity to protect information from malicious systems (requiring trust only in the processor), software developers may not utilize them because doing so would require modifying their programs. However, the described systems and methods require minimal assistance from the software developer and do not require access to source code or reliance on recompiling the program. Instead, the described systems and methods can be directly applied to commercial off-the-shelf (COTS) program binaries by individuals or entities outside the software developer. Therefore, aspects of the described systems and methods can be provided to the software developer as a service by software distribution platforms, operating system developers, or other trusted parties. Thus, the described systems and methods can increase the utilization of hardware-secure zones to combat piracy of both new and traditional software. Of course, software developers can also implement various aspects of the described systems and methods without relying on third parties.

[0037] Suppose a software development platform provides a COTS application for distribution and sale to consumers. This application may include one or more binary files containing 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 containing information referenced and used by the executable instructions. For the binary file to function correctly, it may be necessary to place the data segments in memory at a predetermined and fixed distance from the code segments. The predetermined and fixed distance can be defined for the application or binary file.

[0038] Before making the application available to buyers, the platform can modify each binary file, including the executable code. The platform can 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.

[0039] First, for each binary file containing executable code, the platform can separate the code segment from the data segment, allowing the code and data to be loaded into two locations in memory that are arbitrarily separated (as opposed to a predetermined distance required before separation). Separating code from data can involve modifying all data references within the code that assume 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 binary's source code or debug symbols. Separating code from data facilitates loading all code segments from multiple binaries contiguously into a single, contiguous memory region.

[0040] Second, after separating the code from the data, the platform can encrypt the code segments included in each modified binary file. The platform may retain the data portion of the binary file as unencrypted plain text.

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

[0042] After modifying the binary file, the platform can sell or distribute the application to the public (using the modified binary file). Users can download the application to the disk storage of a computing device that also includes a hardware secure region. When a user launches the application, the computing device's operating system can load the application's binary file into memory. The operating system can be designed to recognize when code segments in the binary file are separated from data segments. The operating system can also be designed to recognize when code segments should be loaded into the hardware secure region. The operating system can determine, based on the file header, that code and data segments are separated and that code segments should be loaded into the hardware secure region. After loading all code segments from the modified binary file into a contiguous range within the hardware secure region, the operating system can load all data segments from the modified binary file into process memory outside the hardware secure region.

[0043] To load modified binaries in this manner, the operating system may include a loader different from the standard loader. The loader can be part of the operating system and is designed to move the executable file for the application from disk storage to process memory and to boot the application's startup process. A standard loader can load code segments and data segments together into memory and may not recognize the information in the modified binary that indicates code segments should be loaded together. However, the loader included in the aforementioned operating system is designed to load the code segments of the modified binary together into a hardware-safe region and load the data segments outside of that region. Even though the loader of the aforementioned operating system may differ from the standard loader, the operating system kernel is not customized or altered. Therefore, the described systems and methods can require only minimal modifications to an existing operating system.

[0044] In addition to loading modified binaries, the operating system can also load boot code into a hardware-secure area. This boot code can be included within the operating system and may not be encrypted. Alternatively, the platform can provide the boot code along with applications to the computing device.

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

[0046] Before the application runs, the startup code can mark all hardware-secured region memory as unreadable to code stored within those regions, protecting the application from leaking its code contents. Otherwise, an attacker could attempt to trick the application into leaking code contents by manipulating data pointers not protected by hardware-secured regions. Data segments stored outside of hardware-secured regions may contain pointers. An attacker could potentially change pointers within a data segment to point to a code segment. If the code doesn't check whether data points to code, and if the hardware-secured region isn't marked as unreadable, the code could leak its contents.

[0047] Despite its potential to combat software piracy, hardware secure zones have not been widely adopted. As mentioned above, one reason may be that utilizing hardware secure zones requires software developers to modify existing software. Typically, software developers must modify their programs to make them aware of hardware secure zones and utilize their functionality. However, the disclosed systems and methods do not require software developers to modify their programs. Nor do they require software developers to provide source code. Instead, the disclosed systems and methods allow platform or service providers to modify their programs to utilize hardware secure zones without requiring assistance or additional information from software developers. Thus, the described systems and methods allow software distribution platforms to provide end-to-end anti-piracy solutions for third-party applications without relying on software developers.

[0048] Another reason why hardware-secured regions have not been widely adopted may be the lack of support from major operating systems. However, the described systems and methods maintain compatibility with commodity operating systems because they do not affect how the operating system accesses program data to serve 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 suitable for practical use on multiple platforms (e.g., Windows, Mac, etc.).

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

[0050] Figure 1 An example system 100 is illustrated, 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.

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

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

[0053] 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. 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 provide program 108a to platform 102. Software developer 106 may be concerned that someone may purchase program 108a through platform 102, make unauthorized copies of program 108a, and then distribute unauthorized copies to third parties without compensation to software developer 106. Platform 102 may provide services to software developer 106 to facilitate the protection of program 108a from software piracy.

[0054] Platform 102 may include program 108b. Program 108b may be a modified version of program 108a. Program 108b may include modified files 110b and 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 the 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.

[0055] 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. Encrypted code 114b-1 and encrypted code 114b-2 may be modified versions of the code included in file 110a. When data 116b-1 and 116b-2 are located in memory at any distance from encrypted code 114b-1 and 114b-2, encrypted code 114b-1 and 114b-2 may allow a computing device to execute the modified file 110b. Furthermore, encrypted code 114b-1 and 114b-2 may be encrypted such that a key is required to decrypt and execute encrypted code 114b-1 and 114b-2. Unlike the encrypted codes 114b-1 and 114b-2, the data 116b-1 and 116b-2 can be unencrypted.

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

[0057] The modified file 112b may include encrypted code 114b-3, data 116b-3, and a file header 118b-2. The 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 the encrypted code 114b-3, the encrypted code 114b-3 may allow a computing device to execute the modified file 112b. Furthermore, the encrypted code 114b-3 may be encrypted. Unlike the encrypted code 114b-3, the data 116b-3 may be unencrypted.

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

[0059] Computing device 104 can download software programs from platform 102 for use on computing device 104. Users 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 device 140. Program 108c may be a copy of program 108b. Computing device 104 may have downloaded program 108c from platform 102 via network 142.

[0060] Program 108c may include modified files 110c and 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 a header 118c-1 (which may be a copy of header 118b-1). The 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).

[0061] A user of computing device 104 can initiate program 108c using computing device 104. The operating system 126 of computing device 104 can use loader 128 to load program 108c into the memory 130 of the computing device. Operating system 126 can 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 can be designed to determine whether modified files 110c, 112c include code that has been separated from the data. Loader 128 can determine from file headers 118c-1, 118c-2 that modified files 110c, 112c include code that has been separated from the data.

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

[0063] Loader 128 can load encrypted codes 114c-1, 114c-2, and 114c-3 into hardware secure region 132. Loader 128 can load encrypted codes 114c-1, 114c-2, and 114c-3 within a contiguous area of ​​hardware secure region 132. Loader 128 can also load boot code 134 into hardware secure region 132. Boot code 134 can be included in operating system 126. Alternatively, computing device 104 can obtain boot code 134 from platform 102 or as part of program 108b. Boot code 134 can be unencrypted. Loader 128 can load data 116c-1, 116c-2, and 116c-3 outside hardware secure region 132 in memory 130. Data 116c-1, 116c-2, and 116c-3 can be located in memory 130 at any distance from the encrypted codes 114c-1, 114c-2, and 114c-3.

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

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

[0066] As part of performing remote authentication, startup code 134 enables processor 136 to establish a communication channel with authentication server 146 via network 142. This communication channel can be a secure communication channel. Processor 136 can send information to authentication server 146 to prove the authenticity of processor 136 and the contents of hardware secure region 132. For example, processor 136 can send a signed hash to authentication server 146 via the communication channel. Processor 136 can send the signed hash to authentication server 146 as part of a request for decryption key 124. Decryption key 124 can decrypt encrypted codes 114b-1, 114b-2, and 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.

[0067] Authentication server 146 can verify the processor signature received from processor 136. Authentication server 146 can use public certificate 148 to verify the processor signature. Authentication server 146 can verify the processor signature to determine that processor 136 is authentic and trustworthy. 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 the encrypted codes 114b-1, 114b-2, and 114b-3 in a secure area of ​​secure hardware. 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 enable computing device 104 to place the encrypted codes 114b-1, 114b-2, and 114b-3 in an insecure portion of memory 130, use decryption key 124 to decrypt the encrypted codes 114b-1, 114b-2, and 114b-3, and make unauthorized copies of the decrypted codes.

[0068] Authentication server 146 can verify the hash. Authentication server 146 may include a verified hash value 150. Authentication server 146 can determine whether the hash received from processor 136 matches the verified hash value 150. When platform 102 generates modified files 110b, 112b, platform 102 may have already determined the verified hash value 150. Platform 102 may already have access to boot code 134 to generate the verified hash value 150. Authentication server 146 can verify the hash to determine whether computing device 104 has modified the encrypted codes 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 computing device. Otherwise, a user of computing device 104 might be able to modify boot code 134 or encrypted codes 114b-1, 114b-2, 114b-3 to include instructions to provide information about the decrypted contents of hardware security area 132. By verifying the hash, system 100 can protect program 108a from malicious loaders. Even if loader 128 is malicious, it cannot pirate encrypted codes 114b-1, 114b-2, 114b-3 because they are encrypted. And even if loader 128 injects additional information into encrypted codes 114b-1, 114b-2, 114b-3 or incorrectly loads encrypted codes 114b-1, 114b-2, 114b-3, authentication server 146 will not verify the hash.

[0069] If the authentication server verifies that the contents of processor 136 and hardware security area 132 are trustworthy (e.g., by verifying both the processor signature and hash), then authentication server 146 can send decryption key 124 to computing device 104. Processor 136 can use decryption key 124 to decrypt encrypted codes 114b-1, 114b-2, and 114b-3. At this time, hardware security area 132 can contain decrypted codes 120-1, 120-2, and 120-3. Decrypted code 120-1 can be a decrypted version of encrypted code 114c-1. Decrypted code 120-2 can be a decrypted version of encrypted code 114c-2. Decrypted code 120-3 can be a decrypted version of encrypted code 114c-3. Even when the decrypted codes 120-1 and 120-2 are at any distance from the data 116c-1 and 116c-2 in memory 130, the decrypted codes 120-1 and 120-2 can still be executed. Furthermore, even when the decrypted code 120-3 is at any distance from the data 116c-3 in memory 130, the decrypted code 120-3 can still be executed.

[0070] Before processor 136 executes the decrypted codes 120-1, 120-2, and 120-3, startup code 134 causes processor 136 to mark hardware security region 132 as unreadable for all instructions residing within it. Startup code 134 may include these instructions to protect the decrypted codes 120-1, 120-2, and 120-3 from disclosure. Readability and executableness may be two separate permissions. Therefore, marking hardware security region 132 as unreadable may not prevent the execution of decrypted codes 120-1, 120-2, and 120-3. Once processor 136 marks hardware security region 132 as unreadable, processor 136 can execute the decrypted codes 120-1, 120-2, and 120-3. The decrypted codes 120-1, 120-2, and 120-3 can perform the same functions as the code included in files 110a and 112a.

[0071] Figure 2A and 2B Document 210a and a modified document 210b are shown, illustrating the technology described herein. Document 210a may be... Figure 1 The document shown is an example of file 110a. The modified file 210b could be... Figure 1 The image shows an example of a modified file 110b.

[0072] 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 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. Code segments 220a-1 and 220a-2 may be much smaller than 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 references 242a-1, 242a-2, and 242a-3, and code segment 220a-2 may include data reference 242a-4. Although document 210a includes two code segments and two data segments, in some other embodiments, the document may contain only one code segment and one data segment, or more than two code segments and more than two data segments. The document may also contain unequal numbers of code segments and data segments.

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

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

[0075] The modified file 210b may include encrypted code segments 214b-1, 214b-2, and data segments 216b-1 and 216b-2. The encrypted code segments 214b-1 and 214b-2 may be modified versions of code segments 220a-1 and 220a-2. The encrypted code segments 214b-1 and 214b-2 may be encrypted such that a computing device cannot execute them without first obtaining the decryption key. The data segments 216b-1 and 216b-2 may be copies of data segments 216a-1 and 216a-2. Data segments 216b-1 and 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 and 216b-2 may be unencrypted plain text.

[0076] The encrypted code segment 214b-1 may include modified data references 242b-1, 242b-2, and 242b-3. The 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, and 242b-4 can be modified such that they will point to the correct data during runtime, even if the distance between the encrypted code segments 214b-1 and 214b-2 and the data segments 216b-1 and 216b-2 in memory differs from the fixed and predetermined distance that can be defined in file 210a. For example, if data reference 242a-1 points to data 244a-1 when data segment 216a-1 is placed in memory at a fixed and predetermined distance from code segment 220a-1, then when data segment 216b-1 is placed in memory at a distance different from the fixed and predetermined distance from code segment 214b-1, the modified data reference 242b-1 will point to data 244b-1. Therefore, the modified data references 242b-1, 242b-2, 242b-3, and 242b-4 are designed such that there can be any distance between the encrypted code segments 214b-1 and 214b-2 and the data segments 216b-1 and 216b-2 in memory.

[0077] Modifying data references 242a-1, 242a-2, 242a-3, and 242a-4 may involve identifying and locating data references 242a-1, 242a-2, 242a-3, and 242a-4 within code segments 220a-1 and 220a-2. Locating data references 242a-1, 242a-2, 242a-3, and 242a-4 may involve the use of relocation information. File 210a or a program that includes file 210a may include relocation information about all data references within the code segment. Relocation information may be included to support Address Space Layout Randomization (ASLR). ASLR allows the processor to load a program anywhere in memory. However, ASLR may still require the distance between code and data to be a fixed distance defined in the program. Nevertheless, ASLR can help the platform locate data references 242a-1, 242a-2, 242a-3, and 242a-4. Therefore, the platform can use relocation information to locate data references 242a-1, 242a-2, 242a-3, and 242a-4. After locating data references 242a-1, 242a-2, 242a-3, and 242a-4, the platform can modify these data references to separate code segments 220a-1 and 220a-2 from data segments 216a-1 and 216a-2.

[0078] 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 and 214b-2 have been separated from the data segments 216b-1 and 216b-2, allowing the data segments 216b-1 and 216b-2 to be loaded into memory at any distance from the code segments 214b-1 and 214b-2. The file header 218b may indicate that the code segments 214b-1 and 214b-2 should be loaded into a hardware-secure area and that the data segments 216b-1 and 216b-2 should be loaded outside the hardware-secure area in memory. The platform may add the file header 218b to the modified file 210b.

[0079] Figure 3 Example method 300 for modifying files to facilitate the use of hardware-secured regions to protect programs from piracy is shown.

[0080] Method 300 may include receiving 302 a file comprising code and data. This 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 besides the file. The file may be an executable file. The file may be an unencrypted binary file. The code may be processor-executable instructions. The file may be designed such that data must be stored in memory at a fixed and predetermined distance from the code for the file to execute correctly. A platform (such as platform 102) may receive 302 this file.

[0081] Method 300 may include locating a 304 data reference in code. The data reference may point to specific information or a location within the data. The code may use the data reference as part of obtaining or modifying specific information within 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 within the data during runtime. The platform may locate the 304 data reference. The platform may locate the 304 data reference without using source code or debug symbols associated with the file. The platform may locate the 304 data reference without using information from outside the program's developers.

[0082] Locating data references in 304 error codes can include relocation information about the data references contained in code, files, or programs. This relocation information can be included to support ASLR.

[0083] Method 300 may include modifying a data reference in code 306. Modifying a data reference 306 may include decoupling the code from the data. When decoupled, the data can be placed in memory at any distance from the code, and the data reference in the code will still point to the correct information in the data during runtime. The platform may modify the data reference 306. The platform may modify the data reference 306 without accessing the source code or debug symbols associated with the file. The platform may modify the data reference 306 without accessing information from outside the program's developers.

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

[0085] Method 300 may include modifying file 310 to include a split header. The split header may indicate that data in the file can be placed in memory at any distance from the code. The split header may indicate that the code should be loaded inside a hardware-secure region in memory and that the data should be loaded outside the hardware-secure region in memory. The platform may modify file 310 to include the split header.

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

[0087] Method 300 may include providing a 314 file for distribution. This file may include a separated file header, modified data references, and encrypted code. Providing a 314 file for distribution may include providing a copy of the file for users to download. A platform may provide the 314 file for distribution. Computing devices may download the file from the platform.

[0088] Figure 4 A potential method 400 for loading applications to facilitate protection against software piracy is shown.

[0089] Method 400 may include receiving a request 402 for initiating 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, such that data from each of the one or more files can be loaded into memory at an arbitrary distance from the code of that 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 the request 402.

[0090] Method 400 may include reading a 404 file header from one or more files. The file header may be contained within 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 contiguous range of hardware-secured regions, and data should be loaded outside of the hardware-secured regions in memory. The operating system may read the 404 file header. The operating system may include a loader, such as loader 128, which is designed to read and understand the file header.

[0091] Method 400 may include loading boot code 406 into a hardware secure region. The boot code may include instructions that are processor-consumable. The boot code may include instructions that cause the processor to measure a hash of information stored in the hardware secure region, sign the hash using a signature, provide the hash and signature to an authentication server, and mark the hardware secure region as unreadable. The operating system may load the boot code 406 into the hardware secure region. The operating system may include the boot code. Alternatively, the operating system may receive boot code from the platform.

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

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

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

[0095] Figure 5 An example method for providing a decryption key according to the techniques described herein is shown.

[0096] Method 500 may include receiving a 502 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 signature. The computing device may include the request as part of a remote authentication process. The computing device may include a processor and a hardware secure area. The hardware secure area may include encrypted code and boot code. The processor may have already measured the hash of the encrypted code and boot code. The processor may have already signed the hash using a private certificate. A platform or authentication server may receive the 502 request.

[0097] Method 500 may include authenticating a 504 signature. Authenticating a 504 signature may include determining that the hash was signed using a private certificate. Authenticating a 504 signature may also be done using a public certificate. The platform or authentication server may authenticate the 504 signature. Authenticating a 504 signature can verify that the processor is authentic and trustworthy to enforce confidentiality and / or integrity protection for hardware security zones.

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

[0099] Method 500 may include providing a 508 decryption key. The decryption key may allow the computing device to decrypt the encrypted code. The startup code may include instructions for causing the processor to decrypt the encrypted code. The platform or authentication server may provide the 508 decryption key. The platform or authentication server may not provide the 508 decryption key unless the signature is authentic and the hash matches a verified hash value. If the signature or hash is not verified or validated, the platform or authentication server may notify the computing device that it will not provide a decryption key.

[0100] Figure 6 An example method 600 for initiating a program based on the technical modifications disclosed herein is shown.

[0101] Method 600 may include enabling processor 602 to measure the hash of code within a hardware-secure region. The boot code stored in the hardware-secure region may include instructions for enabling processor 602 to measure the hash of the code within the hardware-secure region. The processor may use a standard hash function to measure the hash of the code within the hardware-secure region. The code within the hardware-secure region 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 within the hardware-secure region may be part of a remote authentication process for obtaining a decryption key. In addition to measuring the hash, other methods may be used to authenticate the contents of the hardware-secure region.

[0102] Method 600 may include instructing processor 604 to sign the hash using a signature. The startup code may include instructions for instructing processor 604 to sign the hash using a signature. The processor may use a private certificate to sign the hash using a signature. Signing the hash using a signature may be part of a remote authentication process for obtaining a decryption key. In addition to signing the hash using a signature, other methods may be used to prove the authenticity of the processor.

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

[0104] Method 600 may include code that causes the 608 processor to decrypt. The startup code may include instructions for causing the 608 processor to decrypt the code using a decryption key.

[0105] Method 600 may include causing the 610 processor to mark a hardware secure region as unreadable. The startup code may include instructions for causing the 610 processor to mark the hardware secure region as unreadable by instructions within it.

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

[0107] Computer system 700 includes processor 701. Processor 701 can be a general-purpose single-chip or multi-chip microprocessor (e.g., an advanced RISC (Reduced Instruction Set Computer) machine (ARM)), a special-purpose microprocessor (e.g., a digital signal processor (DSP), microcontroller, programmable gate array, etc.). Processor 701 can be referred to as a central processing unit (CPU). Although in... Figure 7 The computer system 700 shows only a single processor 701, but in alternative configurations, a combination of processors (e.g., ARM and DSP) can be used.

[0108] The computer system 700 also includes a memory 703 that is in electronic communication with the processor 701. The memory 703 can be any electronic component capable of storing electronic information. For example, the memory 703 can be embodied as random access memory (RAM), read-only memory (ROM), disk storage medium, optical storage medium, flash memory in RAM, onboard memory integrated with the processor, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, etc., including combinations thereof.

[0109] Instruction 705 and data 707 may be stored in memory 703. Instruction 705 may be executed by processor 701 to implement some or all of the functions disclosed herein. Executing instruction 705 may involve using data 707 stored in memory 703. Any example of the various examples of modules, components, packages, applications, and operating systems described herein may be implemented in whole or in part as instruction 705 stored in memory 703 and executed by processor 701. Any example of the various examples of data described herein may be within data 707 stored in memory 703 and used during the execution of instruction 705 by processor 701.

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

[0111] 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 keyboards, mice, microphones, remote control devices, buttons, joysticks, trackballs, touchpads, and light pens. Some examples of output devices 713 include speakers and printers. A particular type of output device typically included in computer system 700 is a display device 715. Display devices 715 used with the embodiments disclosed herein can utilize any suitable image projection technology, such as liquid crystal displays (LCDs), light-emitting diodes (LEDs), gas plasma, electroluminescence, etc. A display controller 717 may also be provided for converting data 707 stored in memory 703 into text, graphics, and / or moving images (as applicable) to be displayed on display device 715.

[0112] Various components of the computer system 700 can be coupled together via one or more buses, which may include power buses, control signal buses, status signal buses, data buses, etc. For clarity, the various buses are... Figure 7 It is shown as bus system 719.

[0113] The techniques disclosed herein can 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, etc., can also be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, these techniques can be implemented at least in part by a non-transient 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. The instructions can be organized into routines, programs, objects, components, data structures, etc., which can perform specific tasks and / or implement specific data types, and can be combined or distributed as needed in various embodiments.

[0114] The term "processor" can refer to a general-purpose single-chip or multi-chip microprocessor (e.g., an 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. A processor can be a central processing unit (CPU). In some embodiments, a combination of processors (e.g., ARM and DSP) can be used to implement some or all of the technologies disclosed herein.

[0115] The term "memory" can refer to any electronic component capable of storing electronic information. For example, memory can be manifested as random access memory (RAM), read-only memory (ROM), disk storage media, optical storage media, flash memory devices in RAM, onboard memory integrated into the processor, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, and combinations thereof.

[0116] Without departing from the scope of the claims, the steps, operations, and / or actions of the methods described herein may be interchanged with each other. In other words, unless the proper functioning of the described method requires a specific order of steps, operations, and / or actions, the order and / or use of specific steps, operations, and / or actions may be modified without departing from the scope of the claims.

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

[0118] The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that other elements besides those listed may be present. Furthermore, it should be understood that references to “one embodiment” or “embodiment” in this disclosure are not intended to exclude the existence of additional embodiments that also include the described features. For example, any element or feature described with respect to embodiments herein may be combined with any element or feature of any other embodiment described herein, where compatible.

[0119] This disclosure may be embodied in other specific forms without departing from the spirit or characteristics thereof. The described embodiments are to be considered illustrative rather than restrictive. Therefore, the scope of this disclosure is indicated by the appended claims rather than by the foregoing description. Variations within the meaning and scope of the equivalents of the claims will be included within its scope.

Claims

1. A method for protecting software from piracy, the method comprising: Receive a binary file comprising code and data, wherein the code includes data references based on a fixed distance between the code and the data in memory; Modify the data reference in the code; as well as The binary file is modified to indicate that the code of the binary file should be loaded into a hardware-secure region, and that at least a portion of the data of the binary file should be loaded outside the hardware-secure region in the memory.

2. The method according to claim 1, further comprising: The code in the binary file is encrypted, but the data in the binary file is not encrypted; Receive a request for a decryption key from a computing device, wherein the computing device includes the hardware security region; as well as The decryption key is provided to the computing device.

3. The method of claim 2, wherein the hardware security region comprises a defined region in the memory of the computing device, and the hardware security region provides protection against instructions that do not reside within the hardware security region.

4. The method according to claim 2, further comprising: The processor signature is authenticated before the decryption key is provided, wherein the processor of the computing device generates the processor signature, and the request for the decryption key includes the processor signature.

5. The method according to claim 4, further comprising: The hash is verified before the decryption key is provided, wherein the request for the decryption key includes the hash.

6. The method according to claim 1, further comprising: Identify the data references in the code of the binary file without accessing the source code or debugging symbols of the binary file.

7. The method of claim 6, wherein identifying the data reference includes accessing relocation information about the data reference.

8. A system for facilitating the protection of software programs from piracy, comprising: One or more processors; The memory is in electrical communication with the one or more processors; as well as Instructions, stored in the memory, are executable by the one or more processors to: Receive a binary file comprising code and data, wherein the code includes data references based on a fixed distance between the code and the data in device memory; Modify the data reference in the code; as well as The binary file is modified to indicate that the code in the binary file should be loaded into a hardware-secure region, and that at least a portion of the data in the binary file should be loaded outside the hardware-secure region in the device memory.

9. The system of claim 8, wherein modifying the binary file to indicate that the code of the binary file should be loaded into a hardware-secure region, and that at least a portion of the data of the binary file should be loaded outside the hardware-secure region in the device memory comprises: Modify the binary file to include a separated file header.

10. The system of claim 8, wherein the instructions are further executable by one or more processors to: The code in the binary file is encrypted, but the data in the binary file is not encrypted; Receive a request for a decryption key from a computing device, wherein the computing device includes the hardware security region; and The decryption key is provided to the computing device.

11. The system of claim 10, wherein the hardware security zone includes instructions for marking the hardware security zone as unreadable before executing the code.

12. The system of claim 10, wherein the instructions are further executable by one or more processors to: The processor signature is authenticated before the decryption key is provided, wherein the processor of the computing device generates the processor signature, and the request for the decryption key includes the processor signature; and Verify the hash before providing the decryption key, wherein the request for the decryption key includes the hash, and verifying the hash includes comparing the hash with a verified hash.

13. The system of claim 8, wherein the instructions are further executable by one or more processors to: identify the data references in the code of the binary file without accessing the source code or debug symbols of the binary file.

14. The system of claim 13, wherein identifying the data reference includes accessing relocation information about the data reference.

15. A non-transient computer-readable medium comprising instructions, said instructions being executable by one or more processors to cause a computing system to: Receive a binary file comprising code and data, wherein the code includes data references based on a fixed distance between the code and the data in memory; Modify the data reference in the code; as well as The binary file is modified to indicate that the code of the binary file should be loaded into a hardware-secure region, and that at least a portion of the data of the binary file should be loaded outside the hardware-secure region in the memory.

16. The non-transient computer-readable medium of claim 15, wherein modifying the binary file to indicate that the code of the binary file should be loaded into a hardware-secure region, and that at least a portion of the data of the binary file should be loaded outside the hardware-secure region in the memory comprises: Modify the binary file to include a separated file header.

17. The non-transient computer-readable medium of claim 15, further comprising additional instructions executable by the one or more processors to cause the computing system to: The code in the binary file is encrypted, but the data in the binary file is not encrypted; Receive a request for a decryption key from a computing device, wherein the computing device includes the hardware security region; and The decryption key is provided to the computing device.

18. The non-transient computer-readable medium of claim 17, wherein the hardware secure region includes instructions for marking the hardware secure region as unreadable prior to execution of the code.

19. The non-transient computer-readable medium of claim 18, further comprising additional instructions executable by one or more processors to cause the computing system to: The processor signature is authenticated before the decryption key is provided, wherein the processor of the computing device generates the processor signature, and the request for the decryption key includes the processor signature; and Verify the hash before providing the decryption key, wherein the request for the decryption key includes the hash, and verifying the hash includes comparing the hash with a verified hash.

20. The non-transient computer-readable medium of claim 15, wherein modifying the data reference does not require access to the source code or debugging symbols of the binary file.

Images