阅读说明：本技术 软件保护方法及其系统 (Software protection method and system ) 是由 张皓杰 刘佳琳 倪万昇 于 2020-05-29 设计创作，主要内容包括：一种软件保护方法及其系统,该软件保护方法包含通过处理器对已加密的执行档解密,其中解密的步骤包含以下操作。在第一执行环境中,执行连结指令；在第一执行环境中,根据连结指令,产生对应于已加密的执行档的特征值；在第一执行环境中,根据特征值及杂凑表,执行解密演算法并产生金钥；以及在第一执行环境中,将金钥传送至不同于第一执行环境的第二执行环境中的已加密的执行档。一种软件保护系统亦在此公开。(A software protection method and a system thereof, the software protection method comprises the step of decrypting an encrypted execution file through a processor, wherein the step of decrypting comprises the following operations. Executing the linking instruction in the first execution environment; in the first execution environment, generating a characteristic value corresponding to the encrypted execution file according to the link instruction; in the first execution environment, according to the characteristic value and the hash table, executing a decryption algorithm and generating a key; and in the first execution environment, transmitting the key to an encrypted execution file in a second execution environment different from the first execution environment. A software protection system is also disclosed.)

1. A software protection method, comprising:

decrypting the encrypted execution file by a first processor, wherein the decrypting comprises:

executing the linking instruction in a first execution environment;

generating a characteristic value corresponding to the encrypted execution file in the first execution environment according to the link instruction;

executing a decryption algorithm and generating a key according to the feature value and a hash table in the first execution environment; and

in the first execution environment, the key is transmitted to the encrypted execution file in a second execution environment different from the first execution environment.

2. A software protection method as recited in claim 1, wherein the step of decrypting further comprises:

in the second execution environment, the encrypted execution file is decrypted and restored to the execution file according to the key,

the first execution environment and the second execution environment are mutually independent operation environments, and the first execution environment carries out data transmission with the second execution environment through a core driver.

3. A software protection method as claimed in claim 2, wherein

The first execution environment is associated with a first operating system,

the second execution environment is associated with a second operating system,

the second operating system is used for storing and executing the encrypted execution file

The first operating system is used for storing computer program codes for executing the decryption step and the hash table.

4. A software protection method as recited in claim 2, wherein the step of decrypting further comprises:

additional code is executed in the second execution environment to send the link instruction to the first execution environment via the kernel driver.

5. The software protection method of claim 1, further comprising:

encrypting the execution file by a second processor communicatively coupled to the first processor, wherein the encrypting comprises:

generating the characteristic value corresponding to the execution file;

executing an encryption algorithm and generating the key according to the characteristic value and the hash table; and

encrypting the execution file according to the key to generate the encrypted execution file,

wherein the encrypted execution file includes the link instruction.

6. The software protection method of claim 5, further comprising:

the encrypted execution file is transmitted by the second processor to a memory associated with the first processor.

7. A software protection method as recited in claim 1, wherein

The encrypted execution file contains additional program code, and

the additional program code is used for pointing to a core driver of the memory corresponding to the first processor and transmitting the link instruction to an execution environment for executing the decryption step through the core driver.

8. A software protection system, comprising:

a first processor; and

a first memory for storing the first computer program code,

wherein the first processor is configured to execute the first computer program code in the first memory to:

executing a decryption program, comprising the steps of:

executing the linking instruction in a first execution environment;

in the first execution environment, generating a characteristic value corresponding to the encrypted execution file according to the link instruction;

executing a decryption algorithm and generating a key according to the feature value and a hash table in the first execution environment; and

in the first execution environment, the key is transmitted to the encrypted execution file in a second execution environment different from the first execution environment.

9. The software protection system of claim 8, wherein said first memory is further configured to store:

the encrypted execution file associated with the second execution environment; and

the decryption program and the hash table associated with the first execution environment,

the first execution environment and the second execution environment are mutually independent operation environments, and the first execution environment carries out data transmission with the second execution environment through a core driver.

10. The software protection system of claim 9, wherein said first processor is configured to execute said first computer program code in said first memory to perform, in said second execution environment:

the link instruction is transmitted to the decryption program in the first execution environment through the core driver.

11. The software protection system of claim 9, wherein said first processor is configured to execute said first computer program code in said first memory to perform, in said second execution environment:

receiving the key from the first execution environment; and

and decrypting and restoring the encrypted execution file into the execution file according to the key.

12. The software protection system of claim 8, further comprising:

a second processor communicatively coupled to the first processor; and

a second memory for storing the second computer program code,

wherein the second processor is configured to execute the second computer program code in the second memory to:

executing an encryption program, comprising the steps of:

generating the characteristic value corresponding to the execution file;

executing an encryption algorithm and generating the key according to the characteristic value and the hash table; and

encrypting the execution file according to the key to generate the encrypted execution file,

wherein the encrypted execution file includes the link instruction.

Technical Field

The present disclosure relates to software protection technology, and more particularly, to a technology for encrypting an execution file.

Background

With the rapid development of science and technology, software technology also correspondingly progresses. The current technology for software protection includes encrypting the execution file, and encrypting some program codes in the execution file by using a key to achieve the purpose of protection, wherein the key required for encryption and decryption needs to be considered to be hidden. However, the current ways of hiding keys are limited, including network connection requirements, computing capability of devices loaded with software, or requirements for supporting dongle (dongle) devices.

Disclosure of Invention

The present disclosure provides a software protection method comprising decrypting, by a first processor, an encrypted execution file, wherein the step of decrypting comprises the following operations. Executing the linking instruction in the first execution environment; in the first execution environment, generating a characteristic value corresponding to the encrypted execution file according to the link instruction; in the first execution environment, according to the characteristic value and the hash table, executing a decryption algorithm and generating a key; and in the first execution environment, transmitting the key to an encrypted execution file in a second execution environment different from the first execution environment.

The disclosure also provides a software protection system, which includes a first processor and a first memory. The first memory is used for storing a first computer program code, wherein the first processor is used for executing the first computer program code in the first memory so as to execute the decryption program. The step of executing the decryption program comprises the following operations. Executing the linking instruction in the first execution environment; in the first execution environment, generating a characteristic value corresponding to the encrypted execution file according to the link instruction; in the first execution environment, according to the characteristic value and the hash table, executing a decryption algorithm and generating a key; and in the first execution environment, transmitting the key to an encrypted execution file in a second execution environment different from the first execution environment.

Drawings

Fig. 1 shows an architectural schematic of a software protection system according to an embodiment of the present disclosure.

Fig. 2 shows a schematic diagram of the architecture according to fig. 1 for performing an encryption flow.

Fig. 3 shows a flow chart of a method of cryptographic operation according to fig. 2.

Fig. 4A and 4B are schematic diagrams illustrating a method for performing a decryption operation according to the architecture of fig. 1.

Fig. 5 shows a flow chart of a method of operation of decryption according to fig. 3.

Description of reference numerals:

d1: first device

D2: second device

110: first processor

120: second processor

130: first memory

140: second memory

P1: encryption program

P2: additional program

P3: decryption program

H: hash table

E1: execution file

E2: encrypted execution file

310: step (ii) of

320: step (ii) of

330: step (ii) of

340: step (ii) of

350: step (ii) of

410: generic execution environment

415: integrating application program interfaces

420: development end application program interface

425: client application program interface

430: memory cell

435: generic driver

440: trusted execution environment

445: payment authentication program

450: enterprise confidential program

455: trusted application interface

460: trust core

465: trust function library/trust link library

470: hardware abstraction layer

475: hardware

510: step (ii) of

515: step (ii) of

520: step (ii) of

525: step (ii) of

530: step (ii) of

535: step (ii) of

540: step (ii) of

545: step (ii) of

Detailed Description

The following detailed description is provided to best understand the embodiments of the present disclosure, but the embodiments are not provided to limit the scope of the present disclosure, and the structural operations are not described to limit the execution sequence thereof, and any structure resulting from the rearrangement of elements to produce an apparatus with equivalent technical effects is also within the scope of the present disclosure. Moreover, the drawings are for illustrative purposes only and are not drawn to scale in accordance with industry standard and conventional practice, and the dimensions of the various features may be arbitrarily increased or decreased for clarity of illustration. In the following description, the same elements will be described with the same reference numerals for ease of understanding.

Furthermore, the words "comprising," including, "" having, "" containing, "and the like, as used in this disclosure, are open-ended words that mean" including, but not limited to. Further, as used herein, "and/or" includes any and all combinations of one or more of the associated listed items.

In this disclosure, when an element is referred to as being "connected" or "coupled," it can be referred to as being "electrically connected" or "electrically coupled. "connected" or "coupled" may also be used to indicate that two or more elements are in mutual engagement or interaction. Moreover, although terms such as "first," "second," …, etc., may be used herein to describe various elements, these terms are used merely to distinguish one element or operation from another element or operation described in similar technical terms. Unless the context clearly dictates otherwise, the terms do not specifically refer or imply an order or sequence nor are they intended to limit the invention.

The software protection system or method in each embodiment of the disclosure is to encrypt an execution file (executable file) or a destination file (object file) of software, and achieve the technical effect of software protection by encrypting a certain section of program code in the software through a key and hiding the key. In the embodiments of the present disclosure, an operation in which the execution file performs encryption or decryption is exemplified.

In some embodiments, the execution file includes program code and data, and the execution file is divided into a plurality of different regions (sections). Each region contains the corresponding program code or data, and the first byte is used as the address of the region corresponding to the memory for accessing the corresponding data and executing the corresponding operation. In some embodiments, the executable file or the executable program described in the present disclosure refers to a code or an instruction (instruction) that is compiled (build) and can be executed to perform a specific function.

Fig. 1 is an architectural diagram of a software protection system according to some embodiments of the present disclosure. As shown in fig. 1, the software protection system 100 includes a first processor 110, a second processor 120, a first memory 130, and a second memory 140. The first processor 110 and the first memory 130 operate in a first device D1, and the second processor 120 and the second memory 140 operate in a second device D2, wherein the first device D1 and the second device D2 are communicatively connected to each other.

In some embodiments, the first memory 130 is used for storing the decryption program P3, wherein the first processor 110 is used for executing the decryption program P3 in the first memory 130, so that the software protection system 100 can perform the decryption operation on the encrypted execution file. In some embodiments, the second memory 140 is used to store the encrypted program P1, wherein the second processor 120 is used to execute the encrypted program P1 in the second memory 140, so that the software protection system 100 can encrypt the executable file.

In some embodiments, the encryption program P1 is an application program for encrypting an executable file (or a destination file), and the executable file, the destination file or other files can be encrypted by using an encryption algorithm through the execution of the encryption program P1. In some embodiments, the encryption algorithm comprises a feature extraction algorithm, a hash algorithm, or other similar algorithms.

In some embodiments, the decryption program P3 is an application program for decrypting an encrypted execution file (or destination file), and the decryption algorithm is used to find the key of the encrypted execution file (or destination file) for decrypting and restoring the encrypted execution file (or destination file) to generate the original execution file (or destination file).

In some embodiments, the first processor 110 and the second processor 120 are each implemented by one of a Central Processing Unit (CPU), a multi-core processor (multi-core processor), a distributed computing system, and an Application Specific Integrated Circuit (ASIC), and the kinds of the first processor 110 and the second processor 120 are not limited herein.

In some embodiments, the first memory 130 and the second memory 140 are each implemented by a computer readable medium and are respectively one of a solid-state memory, a magnetic tape, a removable computer diskette, a Random Access Memory (RAM), a read-only memory (ROM), a compact disc-read-only memory (CD-ROM), a compact disc-read/write (CD-R/W), and a Digital Video Disc (DVD), and the types of the first memory 130 and the second memory 140 are not limited herein.

In some embodiments, the first memory 130 and the second memory 140 respectively include a Volatile Memory (VM) unit (not shown) and a non-volatile memory (NVM) unit (not shown). In some embodiments, the volatile memory unit of the first memory 130 is used for storing the decryption program P3, and the non-volatile memory unit of the first memory 130 is used for storing the hash table (hash table) H. The volatile memory unit of the second memory 140 is used for storing the encryption program P1, and the non-volatile memory unit of the second memory 140 is used for storing the hash table H.

In some embodiments, the first device D1 and the second device D2 are one of a server, a mobile device and a computer, respectively, and the types of the first device D1 and the second device D2 are not limited herein. In operation, the first device D1 communicates with the second device D2 via wireless transmission and is configured to transmit the encrypted executable file to the second device D2, such that the second memory 140 stores the encrypted executable file.

For example, the second device D2 is a server and corresponds to a software development end, and carries an executable file and an encryption program P1 in the second memory 140. The first device D1 is a smart phone and corresponds to an arbitrary user, and receives the encrypted execution file from the second device D2 via bluetooth transmission, and further loads the encrypted execution file into the first memory 130. The user can operate the first device D1 to make the first processor 110 execute the decryption program P3 to decrypt the encrypted executable file, thereby restoring the unencrypted executable file, and then the user can execute the restored executable file through the first device D1 to perform the corresponding operation.

In various embodiments, the software protection system 100 may include a plurality of first processors 110, a plurality of second processors 120, a plurality of first memories 130 and/or a plurality of second memories 140, and the above elements may be correspondingly operated in the plurality of first devices D1 and/or the plurality of second devices D2, which does not limit the number of processors and memories of the software protection system 100.

For example, in various embodiments, the first processors 110 run in a first device D1 and share a first memory 130, and the second processors 120 run in the second devices D2 respectively and operate correspondingly to the second memories 140 respectively.

Fig. 2 is a schematic diagram illustrating a process for performing encryption according to some embodiments of the present disclosure. The following embodiment shown in fig. 2 is described by taking the second device D2 shown in fig. 1 as an example, but not limited thereto, and any device capable of performing the encryption process shown in fig. 2 is within the scope of the present disclosure.

As shown in fig. 1 and fig. 2, the second processor 120 and the second memory 140 cooperate to execute the encryption operation, wherein the second memory 140 is used to store the executable file E1, the encryption program P1, the hash table H, and the encrypted executable file E2. The specific flow of the above encryption operation is as follows.

Fig. 3 is a flow diagram illustrating a method of cryptographic operation according to some embodiments of the present disclosure. As shown in fig. 3, the encryption operation method 300 includes steps 310, 320, 330, 340 and 350, and at least steps 320, 330, 340 and 350 correspond to the operation of executing the encryption program P1. For clarity, the following encryption operation method 300 is described in conjunction with the embodiments shown in fig. 1 and 2, but the encryption operation method 300 is not limited to the embodiments shown in fig. 1 and 2.

First, in step 310, the encryption program is accessed. For example, as shown in fig. 1 and 2, the second processor 120 can access the encrypted program P1 in the second memory 140 and execute the encrypted program P1 for performing the corresponding subsequent encryption operation.

Next, in step 320, a feature value (pattern) corresponding to the execution file E1 is generated. For example, as shown in fig. 1 and 2, the second processor 120 executes the encryption program P1 to perform an encryption algorithm (such as the above-mentioned feature extraction algorithm), thereby extracting the feature value of the executable file E1 and generating the feature value corresponding to the executable file E1.

Next, in step 330, a corresponding hash value is generated. For example, as shown in fig. 1 and 2, the second processor 120 executes the encryption program P1 to perform an encryption algorithm (such as the hash algorithm described above) according to the hash table H, thereby calculating the feature value corresponding to the executable file E1 and generating a corresponding hash value.

Furthermore, in step 340, a key corresponding to the executable file E1 is generated. For example, as shown in fig. 1 and 2, the second processor 120 executes the encryption program P1 to perform an encryption algorithm (such as the hash algorithm described above) according to the hash table H, thereby generating the key corresponding to the executable file E1.

In some embodiments, the characteristic value, the hash value and the key are data corresponding to the executable file E1, wherein the hash value and the key calculated by the hash algorithm are data calculated irreversibly, thereby providing high data protection.

In some embodiments, the data format of at least one of the characteristic value, the hash value and the key is a string. In other embodiments, the data format of at least one of the characteristic value, the hash value and the key is a plurality of groups of strings with different lengths. The data format of the characteristic value, the hash value and the key are not limited herein.

In some embodiments, the data format of the hash table H is a two-dimensional array or a three-dimensional array, and the memory capacity of the eigenvalues is greater than 512 bytes (bytes). In this way, for a plurality of different executions E1, the probability that the hash values calculated by the encryption program P1 are all the same (i.e., collision) is very low, and the probability that the keys corresponding to different executions E1 are the same is reduced, thereby improving data security.

Then, in step 350, an encrypted execution file is generated. For example, as shown in fig. 1 and 2, the second processor 120 executes the encryption program P1 to perform an encryption algorithm according to the generated key to encrypt the executable file E1, thereby generating an encrypted executable file E2. The encrypted executable E2 is then transferred from the second device D2 to the first device D1, and the encrypted executable E2 is decrypted by the first device D1.

The encrypted executable E2 cannot be read and/or executed normally as compared to the original executable E1, and therefore requires an additional decryption operation for the encrypted executable E2, as described below with reference to fig. 4A and 4B.

It should be noted that, in some embodiments, a section of program code for decryption is added to the program code of the encrypted execution file E2, and in some embodiments, the aforementioned program code for decryption is also referred to as appended program code (appended code). The additional program code is additional program code P2 (FIG. 2) that can be executed by the specific hardware, and additional program code P2 is generated during the encryption process for the purpose of performing the decryption operation subsequently. In some embodiments, the add-on P2 is also referred to as add-on code or an add-on section (appended section). The additional program P2 does not include the key generated in the encryption process and is independent from the key, thereby achieving a good protection effect. In addition, in some embodiments, the additional program P2 includes a section of code for address pointing, which is also referred to as a nexus instruction in some embodiments (described in more detail below with respect to FIGS. 4A-5).

Based on the above, the execution file E1 can be encrypted into the encrypted execution file E2 with high protectiveness through the encryption flow.

Fig. 4A and 4B are schematic diagrams illustrating a decryption process according to some embodiments of the disclosure. The following embodiments shown in fig. 4A and 4B are described by taking the first device D1 shown in fig. 1 as an example, but not limited thereto, and any device capable of performing the decryption process shown in fig. 4A and 4B is within the scope of the present disclosure.

As shown in fig. 1, fig. 4A and fig. 4B, the first processor 110 and the first memory 130 are cooperatively operable to execute the decryption operation, wherein the first memory 130 is used to store the encrypted execution file E2, the decryption program P3 and the hash table H.

In some embodiments, as shown in fig. 4A and 4B, the first memory 130 is used for storing a plurality of execution environments, which may also be referred to as operating environments, and mainly refers to a general term for hardware and software, including a corresponding memory, a processor, and an operating system and a program … stored in the memory.

In some embodiments, as shown in FIG. 4A, the execution environment includes a common execution environment (REE) 410 (also known as rich world) associated with the first operating system. In addition, as shown in fig. 4B, the execution environment includes a Trusted Execution Environment (TEE) 440 (also called secure world) associated with a second operating system, which is different from the first operating system. The normal execution environment 410 and the trusted execution environment 440 are independent operating environments, and can communicate/transfer or exchange data through respective cores (e.g., core drivers), but are isolated from each other when performing respective operations. It is also understood that based on this memory, multiple independent operating systems are constructed, including a normal operating system (normal execution environment 410) and a trusted operating system (trusted execution environment 440). In some embodiments, the first operating system and the second operating system are respectively one of a Windows operating system (Microsoft Windows) or a Linux operating system.

In some embodiments, the trusted execution environment 440 has a first security level (security level) for performing operations that require privacy, such as authentication of identity or decryption operations in embodiments of the present disclosure. The normal execution environment 410 has a second security level, which is less secure than the first security level, for performing other operations, such as functions of a general application.

In some embodiments, in the trusted execution environment 440, the operations performed are passively performed by the normal execution environment 410 upon an indication or request input by the normal execution environment 410, and each operation and corresponding data or program code is independent of the normal execution environment 410. On the other hand, in the normal execution environment 410, an instruction or a request may be input to the trusted execution environment 440 to cause the program in the trusted execution environment 440 to perform a corresponding operation, but no access to the program code or data of the trusted execution environment 440 may be required.

In some embodiments, the common execution environment 410 is used to store general applications (e.g., the encrypted execution file E2 and the hash table), an Application Programming Interface (API) 415, a developer API 420, a client API 425, a storage unit 430, and a common driver 435.

Integration application interface 415 is used to integrate development side application interface 420 and client side application interface 425. The client api 425 includes at least one executable function, such as calling, paying, or browsing, for requesting access to the data in the storage unit 430 to execute the corresponding executable function. The developer api 420 includes at least one program function for communicating with the core (not shown) of the execution environment 410 to exchange data.

The storage unit 430 is used for storing data of the core of the common execution environment 410, so that the development-side api 420 or the client-side api 425 can access or exchange data therein by using a system call (system call).

In some embodiments, the storage unit 430 is implemented as a playback protected memory block (RPMB) and is used to store a hash table required for the decryption operation. In some embodiments, the storage unit 430 is stored in a kernel mode of the trusted execution environment 440 (not shown in this embodiment).

The generic driver 435 is used to be executed to cause the program codes or instructions of the client api 425 or the developer api 420 to be executed accordingly, thereby communicating with the core of the generic execution environment 410. In addition, the generic driver 435 can also be executed to further communicate with the core of the trusted execution environment 440 as an intermediary between the generic execution environment 410 and the trusted execution environment 440. In some embodiments, the generic driver 435 refers to a kernel driver that is executed to enable data to be passed between the respective kernels of the generic execution environment 410 and the trusted execution environment 440.

In addition, in various embodiments, the additional program P2 shown in FIG. 2 includes a region for pointing to a specific address in the program code, such as: the address of the generic driver 435, the address of the hash table, the address of a region in the encrypted executable E2, …, etc. Thus, the add-on program P2 is also referred to as a link instruction or a secure instruction (secure lib) in some embodiments.

In some embodiments, the "user mode" (user mode) and the "kernel mode" (kernel mode) shown in FIGS. 4A and 4B are associated with the permission capability to access the operating system. For example, a "user mode" refers to a mode where the program executing therein has low system access rights and can perform normal operations, but needs to communicate with the kernel mode by way of a system call through an application program interface (e.g., client api 425) between the user mode and the kernel mode if core data or instructions need to be accessed. On the other hand, "kernel mode" means that the program executed therein has high system access rights and can execute special instructions or operations, including memory management, run-length management, and the like. For example, the encrypted execution file E2 may be restricted from accessing data in the core of the normal execution environment 410.

As shown in FIG. 4B, trusted execution environment 440 is configured to store a plurality of applications that handle secure data, trusted application interface 455, trusted core 460, trusted function library/trusted link library 465, Hardware Abstraction Layer (HAL) 470, and hardware 475. In some embodiments, the applications that process the secure data may include, for example, decryption program P3, payment authentication program 445, and enterprise confidential program 450.

In some embodiments, the trusted application interface 455 includes at least one executable function and/or at least one program function for communicating with the core (i.e., the trusted core 460) of the trusted execution environment 440 to exchange data. In addition, applications in the generic execution environment 410 may exchange data (e.g., network protocol addresses) with applications in the trusted execution environment 440 (e.g., the payment authority 445) via the trusted application interface 455.

In some embodiments, the trust core 460 is used to control or manage resources, such as a bus (bus), a processor or a library of trust functions/trust link 465, etc., used to execute operations or functions corresponding to the trusted execution environment 440. In addition, in various embodiments, the trust core 460 is further configured to communicate with the common execution environment 410 to exchange data.

In some embodiments, the library of trusted functions/library of trusted links 465 includes at least one of a function, a library of static links, or a library of sinks to store corresponding data.

In some embodiments, the hardware abstraction layer 470 is used to directly access the data of the hardware 475, wherein the hardware 475 is used to store the data required for the decryption operation, including the hash table described above.

In some embodiments, the first memory 130 and the first processor 110 for performing the decryption operation are implemented by a Trust Zone architecture designed by ARM architecture, and are divided into a normal world (or rich world) and a secure world (secure world), which correspond to the normal execution environment 410 and the trusted execution environment 440 in the embodiments, respectively. In various embodiments, the first memory 130 and the first processor 110 for performing the decryption operation are implemented in a software guard extensions (SGX) architecture designed by the Intel architecture, and include an address space (enclave), which corresponds to the trusted execution environment 440. In some embodiments of the disclosure, the ARM Trust Zone is used as an architecture for illustration, but not limited thereto.

Fig. 5 is a flow chart of a method of operation of decryption shown in accordance with some embodiments of the present disclosure. As shown in fig. 5, the decryption operation method 500 includes steps 510, 515, 520, 525, 530, 535, 540 and 545, and at least steps 510, 515, 520, 525, 530, 535, 540 and 545 correspond to an operation of executing the decryption program P3. For clarity, the following decryption operation method 500 is described in conjunction with the embodiments shown in fig. 1, 4A and 4B, but the decryption operation method 500 is not limited to be applied to the embodiments shown in fig. 1, 4A and 4B.

In some embodiments, as shown in fig. 1 and fig. 2, the first processor 110 executes the additional program P2 and the decryption program P3 in the encrypted executable file E2 stored in the first memory 130 to perform the decryption operation method 500 described below.

First, in step 510, an add-on is accessed to send a link instruction to the trusted execution environment. For example, as shown in fig. 1, 4A and 4B, in the user mode of the normal execution environment 410, the first processor 110 executes the additional program P2 in the second memory 140, thereby sending a link instruction to the kernel mode of the trusted execution environment 440 via the client api 425 and the normal driver 435. In some embodiments, the first processor 110 executes the additional program P2 to send the link instruction directly to the trusted execution environment 440 via the generic driver 435.

Next, in step 515, the decryption process is accessed to receive the link instruction. For example, as shown in fig. 1, 4A and 4B, in the kernel mode of the trusted execution environment 440, the first processor 110 executes the decryption program P3 in the first memory 130, thereby sending a link instruction to the decryption program P3 through the trusted application interface 455, so that the decryption program P3 receives the link instruction.

Next, in step 520, the linking instruction is executed to generate a feature value corresponding to the encrypted execution file. For example, as shown in fig. 1, 4A and 4B, in the user mode of the trusted execution environment 440, the first processor 110 executes the decryption program P3 in the first memory 130, thereby executing the link instruction through the decryption program P3, and generating the feature value corresponding to the encrypted executable file E2 according to the link instruction.

Next, in step 525, the corresponding hash value is generated. For example, as shown in fig. 1, 4A and 4B, in the user mode of the trusted execution environment 440, the first processor 110 executes the decryption program P3 in the first memory 130, thereby calculating the feature value corresponding to the encrypted executable file E2 by the decryption program P3 according to a hash table executing a decryption algorithm (e.g., a hash algorithm) and generating a corresponding hash value.

Further, in step 530, a key corresponding to the encrypted execution file is generated. For example, as shown in fig. 1, 4A and 4B, in the user mode of the trusted execution environment 440, the first processor 110 executes the decryption program P3 in the first memory 130, thereby executing a decryption algorithm (e.g., a hash algorithm) to calculate a hash value in step 525 according to the feature value of the encrypted execution file E2 and the hash table through the decryption program P3, and generating a key corresponding to the encrypted execution file E2.

In some embodiments, the hash table stored in the memory for the decryption operation is the same as the hash table stored in the memory for the encryption operation. Therefore, the key generated by the decryption operation is identical to the key generated by the encryption operation.

It should be noted that, in some embodiments, the memory for storing the hash table, such as the storage unit 430 or the hardware 475 in the foregoing embodiments, the second memory 140 for performing the encryption operation, and the like, is a non-volatile memory. Therefore, the probability of randomly reading the hash table can be reduced, and the protection of the program code is further improved.

Further, in step 535, the key is sent to the normal execution environment. For example, as shown in fig. 1, 4A and 4B, in the kernel mode of the trusted execution environment 440, the first processor 110 executes the decryption program P3 in the first memory 130, thereby sending the key to the trusted core 460 through the trusted application interface 455 and sending the key to the normal execution environment 410 through the trusted core 460.

Next, in step 540, the key is transmitted to the encrypted execution file. For example, as shown in fig. 1, 4A and 4B, in the user mode of the normal execution environment 410, the first processor 110 executes the decryption program P3 in the first memory 130, thereby receiving the key through the normal driver 435 and sending the key to the encrypted execution file E2 through the client api 425.

Then, in step 545, the decryption reverts to the execution file. For example, as shown in fig. 1, 4A and 4B, in the user mode of the normal execution environment 410, the first processor 110 executes the decryption program P3 in the first memory 130, thereby executing the decryption algorithm to decrypt the encrypted execution file E2 and decrypt the encrypted execution file E1 (shown in fig. 2) according to the received key through the decryption program P3.

In some embodiments, the computer program code in the first memory 130 is further configured to implement Arm Trusted Firmware (ATF) for performing security checks and for accessing the decryption program P3 for performing environment checks. Some examples of security checks include access permission checks, root permission checks, etc. of the trusted execution environment 440. Therefore, the software protection system can be prevented from being cracked by a dynamic analysis method.

In summary, the key in the encryption or decryption operation is only used in the steps of generating the encrypted execution file or decrypting the encrypted execution file and restoring the encrypted execution file, and the key can be automatically calculated without the user inputting any authentication data or additional connecting hardware (such as a dongle). In particular, in the decryption step, the data generated or required by the operation process is executed in the trusted execution environment, thereby achieving a high security of key protection.

Although the present disclosure has been described with reference to the above embodiments, it should be understood that various changes and modifications can be made therein by those skilled in the art without departing from the spirit and scope of the disclosure, and therefore, the scope of the disclosure should be determined by that of the appended claims.