CN117992173A

CN117992173A - Function protection method and device

Info

Publication number: CN117992173A
Application number: CN202211350634.0A
Authority: CN
Inventors: 李小伟; 汤战勇; 王梓旭; 陈谋
Original assignee: NORTHWEST UNIVERSITY; Huawei Technologies Co Ltd
Current assignee: NORTHWEST UNIVERSITY; Huawei Technologies Co Ltd
Priority date: 2022-10-31
Filing date: 2022-10-31
Publication date: 2024-05-07
Also published as: WO2024093687A1

Abstract

The application provides a function protection method and device. The method comprises the following steps: the first function to be protected corresponds to a first virtual instruction and a second virtual instruction; executing, by a first dispatcher, the first virtual instruction; executing the second virtual instruction by a second dispatcher; wherein the first dispatcher and the second dispatcher are different. According to the method, the internal structures of the virtual machines are enriched (namely, a plurality of dispatchers are preset in one virtual machine), the jump flow in the virtual machine is enriched, the convergence points are scattered, the difficulty of reverse analysis and attack is improved, and therefore the safety of virtualization protection is improved.

Description

Function protection method and device

Technical Field

The present application relates to the field of virtual machine technologies, and in particular, to a function protection method and apparatus.

Background

Today software is an important component in life, and aspects of life are related to software. However, with the rapid development of the software industry, software data security is also becoming more and more important. For a user, the software data security relates to personal information security and property security; for software developers, the software developers consume a great deal of manpower and material resources to develop the software, and if the software is easily stolen and put on the market, huge losses are caused to the software developers. Software protection, software security, is a well-established area of concern.

There are many methods for protecting software, wherein the virtualized protection is a protection method with stronger protection capability in the software protection. The virtualization protection is to integrate a large number of virtual machine interpretation and execution logic in the protected program, and an attacker needs to reversely analyze the execution logic in the virtual machine first and then can further restore the original program semantics.

However, the scheduling structure inside the virtual machine is single at present, which becomes a weak point for an attacker to reversely analyze, and further causes the reduction of the virtualization protection intensity. How to further improve the intensity of virtual machine virtualization protection needs to be further studied.

Disclosure of Invention

The application provides a function protection method and a function protection device, which realize enriching the internal structure of a virtual machine (namely, a plurality of dispatchers are preset in one virtual machine), enriching the jump flow in the virtual machine, dispersing convergence points, and improving the difficulty of reverse analysis and attack, thereby improving the safety of virtualization protection.

In a first aspect, the present application provides a function protection method, including: acquiring a first function to be protected, and acquiring a first virtual instruction and a second virtual instruction based on the first function to be protected; executing, by the first dispatcher, the first virtual instruction; executing, by the second dispatcher, the second virtual instruction; wherein the first dispatcher and the second dispatcher are different.

The first function to be protected is a function in the first program code. The first program code has a plurality of functions, and a function capable of realizing a preset function can be selected from the plurality of functions as a function to be protected, or a function with a preset name can be selected from the plurality of functions as the function to be protected. When executing the function to be protected in the first program code, the method provided by the application can complicate the execution logic of the function to be protected, so that an attacker is difficult to crack the execution logic of the function to be protected, and the purpose of protecting the function to be protected is achieved.

The partial functions in the first program code may be used as functions to be protected, or all the functions in the first program code may be used as functions to be protected, which is not limited in the present application.

By the method, the internal structure of the virtual machine is enriched (namely a plurality of dispatchers are preset in one virtual machine), the jump flow in the virtual machine is enriched, the convergence points are scattered, the difficulty of reverse analysis and attack is improved, and therefore the safety of function protection is improved.

With reference to the first aspect, in one possible implementation manner, the first dispatcher is a dispatcher in the first virtual machine, and the second dispatcher is also a dispatcher in the first virtual machine. In this way, the same function may be protected by the same virtual machine.

With reference to the first aspect, in one possible implementation manner, the first dispatcher is a dispatcher in a first virtual machine, and the second dispatcher is a dispatcher in a second virtual machine. In this way, the same function may be protected by different virtual machines. Further increasing the complex structure inside the virtual machine.

With reference to the first aspect, in one possible implementation manner, after the obtaining the first function to be protected, the method further includes: acquiring a third virtual instruction based on the first function to be protected; after executing the first virtual instruction by the first dispatcher, the method further comprises: and calling a third virtual instruction through the first virtual instruction, and executing the third virtual instruction. In this way, the virtual instructions can be directly mutually scheduled and executed, and the cost of scheduling the virtual instructions by the dispatcher is reduced. Further increasing the complex execution structure inside the virtual machine.

With reference to the first aspect, in one possible implementation manner, the number of the first virtual instructions is a plurality; executing, by the first dispatcher, a first virtual instruction, including: executing a first virtual instruction appearing for the first time in a first function to be protected through a first dispatcher; after executing the first virtual instruction by the first dispatcher, the method further comprises: executing a first virtual instruction appearing for the second time in the first function to be protected through a third dispatcher; wherein the first dispatcher and the third dispatcher are different. Thus, the same virtual instruction in the same function to be protected may appear multiple times. The same virtual instruction that appears multiple times may also be executed by different dispatchers.

Alternatively, the first dispatcher and the third dispatcher may be the same, i.e., the same virtual instruction that appears multiple times may also be executed by the same dispatcher. The application is not limited in this regard.

With reference to the first aspect, in one possible implementation manner, a second function to be protected is obtained, and a fourth virtual instruction is obtained based on the second function to be protected; executing the fourth virtual instruction by the fourth dispatcher; the fourth dispatcher is a dispatcher in the first virtual machine or a dispatcher in the second virtual machine.

The second function to be protected is a function in the second program code. The second program code may be the same as the first program code, and the second program code may be different from the first program code.

Thus, different functions to be protected can be protected by the same virtual machine or different virtual machines.

With reference to the first aspect, in one possible implementation manner, after the first virtual instruction is acquired, before the first virtual instruction is executed by the first dispatcher, the method further includes: generating a plurality of bytecodes based on the first virtual instruction, each bytecode of the plurality of bytecodes consisting of the first virtual instruction and an identity of the dispatcher; selecting a first byte code from a plurality of byte codes, wherein the first byte code consists of a first virtual instruction and an identifier of a first dispatcher; executing, by the first dispatcher, a first virtual instruction, including: selecting a first dispatcher from a plurality of dispatchers based on an identification of the first dispatcher in the first bytecode; the first virtual instruction is executed by the first dispatcher.

Here, the identification of the dispatcher may be an identification of the dispatcher within the first virtual machine and/or an identification of the dispatcher within the second virtual machine.

The first dispatcher is selected from a plurality of dispatchers based on an identification of the first dispatcher in the first bytecode, where randomly selected.

In this way, the virtual instruction is associated with multiple dispatchers via the bytecode.

With reference to the first aspect, in one possible implementation manner, the number of byte codes corresponding to the first virtual instruction is the same as the number of dispatchers in the first virtual machine.

In the case where the identification of the dispatcher includes only the identification of the dispatcher in the first virtual machine, the number of bytecodes corresponding to the first virtual instruction is the same as the number of dispatchers in the first virtual machine. In the case where the identification of the dispatcher includes only the identification of the dispatcher in the first virtual machine, the number of bytecodes corresponding to the first virtual instruction may be smaller than the number of dispatchers in the first virtual machine.

In the case where the identification of the dispatcher includes an identification of the dispatcher within the first virtual machine and an identification of the dispatcher within the second virtual machine, the number of bytecodes corresponding to the first virtual instruction is greater than the number of dispatchers within the first virtual machine. For example, there are a total of two virtual machines, each with 3 dispatchers encountered, then a virtual instruction may have 6 bytecodes.

With reference to the first aspect, in one possible implementation manner, the executing, by the first dispatcher, a first virtual instruction specifically includes: calling a first virtual instruction execution module to execute a first virtual instruction through a first dispatcher; executing, by the second dispatcher, a second virtual instruction, comprising: and calling a second virtual instruction execution module to execute the second virtual instruction through the second dispatcher.

In one possible implementation, the fourth virtual instruction and the first virtual instruction are virtual instructions that execute the same logic; executing a fourth virtual instruction by a fourth dispatcher, specifically including: and calling the first virtual instruction execution module to execute the fourth virtual instruction through the fourth dispatcher. Thus, for executing virtual instructions of the same logic, the same virtual instruction execution module may be scheduled to execute the virtual instructions. The virtual instruction execution module may be shared by the dispatchers within one virtual machine or within different virtual machines.

Alternatively, the dispatcher may not share a virtual instruction execution module. I.e., each dispatcher in the same virtual machine has its own virtual instruction execution module.

Alternatively, the dispatcher may share a virtual instruction execution module. I.e., each dispatcher in the same virtual machine shares the same set of virtual instruction execution modules.

Alternatively, the dispatchers within different virtual machines may also share a virtual instruction execution module.

In a second aspect, the present application provides a function protection device, the device comprising a driving data scheduling module, a dispatcher selecting module, a first dispatcher and a second dispatcher; the driving data scheduling module is used for acquiring a first function to be protected, and acquiring a first virtual instruction and a second virtual instruction based on the first function to be protected; a dispatcher selection module for executing the first virtual instruction by the first dispatcher; the dispatcher selection module is also used for executing a second virtual instruction through a second dispatcher; wherein the first dispatcher and the second dispatcher are different.

With reference to the second aspect, in one possible implementation manner, the first dispatcher is a dispatcher in the first virtual machine, and the second dispatcher is also a dispatcher in the first virtual machine.

With reference to the second aspect, in one possible implementation manner, the first dispatcher is a dispatcher in a first virtual machine, and the second dispatcher is a dispatcher in a second virtual machine.

With reference to the second aspect, in a possible implementation manner, the apparatus further includes a virtual instruction scheduling module; the driving data scheduling module is further used for acquiring a third virtual instruction based on the first function to be protected; and the virtual instruction scheduling module is used for calling a third virtual instruction through the first virtual instruction and executing the third virtual instruction.

With reference to the second aspect, in a possible implementation manner, the apparatus further includes a third dispatcher; the number of the first virtual instructions is a plurality; the dispatcher selecting module is specifically configured to: executing a first virtual instruction appearing for the first time in a first function to be protected through a first dispatcher; the dispatcher selecting module is further used for executing a first virtual instruction appearing for the second time in the first function to be protected through the third dispatcher; wherein the first dispatcher and the third dispatcher are different.

With reference to the second aspect, in a possible implementation manner, the apparatus further includes a fourth dispatcher; the driving data scheduling module is also used for acquiring a second function to be protected and acquiring a fourth virtual instruction based on the second function to be protected; the dispatcher selection module is further used for executing a fourth virtual instruction through a fourth dispatcher; the fourth dispatcher is a dispatcher in the first virtual machine or a dispatcher in the second virtual machine.

With reference to the second aspect, in a possible implementation manner, the apparatus further includes a byte code generating module; the system comprises a byte code generation module, a first virtual instruction generation module and a second virtual instruction generation module, wherein the byte code generation module is used for generating a plurality of byte codes based on the first virtual instruction, and each byte code in the plurality of byte codes consists of the first virtual instruction and the identifier of the dispatcher; the byte code generation module is further used for selecting a first byte code from a plurality of byte codes, wherein the first byte code consists of a first virtual instruction and an identifier of a first dispatcher; a dispatcher selection module, specifically configured to select a first dispatcher from a plurality of dispatchers based on an identification of the first dispatcher in the first bytecode; the first virtual instruction is executed by the first dispatcher.

With reference to the second aspect, in one possible implementation manner, the number of byte codes corresponding to the first virtual instruction is the same as the number of dispatchers in the first virtual machine.

With reference to the second aspect, in one possible implementation manner, the dispatcher selection module is specifically configured to call, by the first dispatcher, the first virtual instruction execution module to execute the first virtual instruction; the dispatcher selecting module is specifically configured to call the second virtual instruction executing module to execute the second virtual instruction through the second dispatcher.

With reference to the second aspect, in one possible implementation manner, the fourth virtual instruction and the first virtual instruction are virtual instructions with the same execution logic; the dispatcher selecting module is specifically configured to call the first virtual instruction executing module to execute the fourth virtual instruction through the fourth dispatcher.

In a third aspect, the present application provides a function protection device, the device comprising a processor and a memory; the memory is coupled to the processor for storing computer program code comprising computer instructions that the processor invokes to perform a function protection method provided in any one of the possible implementations of the above aspect.

In a fourth aspect, the present application provides a computer readable storage medium storing computer instructions that, when run on a computer, cause the computer to perform a method of function protection provided in any one of the possible implementations of the above.

In a fifth aspect, the application provides a computer program product for, when run on a computer, causing the computer to perform a function protection method as provided in any one of the possible implementations of the above.

For the beneficial effects of the second aspect to the fifth aspect, please refer to the description of the beneficial effects of the first aspect, and the disclosure is not repeated herein.

Drawings

Fig. 1 and fig. 2 are schematic diagrams of a method for executing a virtual instruction according to an embodiment of the present application;

FIG. 3 is a schematic diagram of a correspondence between virtual instructions and byte codes according to an embodiment of the present application;

fig. 4 to fig. 6 are corresponding relations between virtual instructions and a dispatcher in a function to be protected according to an embodiment of the present application;

FIG. 7 is a schematic diagram of executing virtual instructions according to an embodiment of the present application;

FIG. 8 is a schematic diagram illustrating a first virtual instruction according to an embodiment of the present application;

FIG. 9 is a schematic diagram of executing a second virtual instruction according to an embodiment of the present application;

FIG. 10 is a schematic diagram of another embodiment of executing virtual instructions;

FIG. 11 is a schematic diagram of another embodiment of executing a first virtual instruction;

the bolded portion of FIG. 12 is a schematic illustration of another embodiment of executing a second virtual instruction;

FIG. 13 is a schematic diagram of a method for a virtual instruction execution module to call the virtual instruction execution module according to an embodiment of the present application;

FIG. 14 is a flowchart of a virtual instruction execution method according to an embodiment of the present application;

FIG. 15 is a flowchart of a function protection method according to an embodiment of the present application;

FIG. 16 is a schematic flow chart of a function protection device according to an embodiment of the present application;

fig. 17 is a schematic diagram of an apparatus 1700 according to an embodiment of the present application.

Detailed Description

The technical solutions of the embodiments of the present application will be clearly and thoroughly described below with reference to the accompanying drawings. Wherein, in the description of the embodiments of the present application, unless otherwise indicated, "/" means or, for example, a/B may represent a or B; the text "and/or" is merely an association relation describing the associated object, and indicates that three relations may exist, for example, a and/or B may indicate: the three cases where a exists alone, a and B exist together, and B exists alone, and furthermore, in the description of the embodiments of the present application, "plural" means two or more than two.

The terms "first," "second," and the like, are used below for descriptive purposes only and are not to be construed as implying or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature, and in the description of embodiments of the application, unless otherwise indicated, the meaning of "a plurality" is two or more.

Before describing the embodiments of the present application, the technical terms described in the embodiments of the present application will be explained first.

1. Virtual Machine (VM) and dispatcher

Virtual machines refer to complete computer systems that run in a completely isolated environment with complete hardware system functionality through software emulation.

The virtual machine provides a method for software protection. For example, when the program code needs to be protected, a virtual machine can be created, complex execution logic in the virtual machine is added in the program code to be protected, and the program code to be protected is converted into corresponding virtual instructions based on the complex execution logic. When the original program code is executed, only virtual instructions corresponding to the program code to be protected are needed to be executed, so that the execution logic of the original program code is realized.

The dispatcher is a virtual instruction execution engine in the virtual machine. When the original program code needs to be executed, the dispatcher can call a virtual instruction corresponding to the original program code and execute the virtual instruction to realize the execution logic of the original program code.

2. Virtual instructions, bytecodes, and drive data

The virtual instructions are preset, for example, there are 63 preset virtual instructions, when the virtual machine is created, the preset 63 virtual instructions need to be loaded into the virtual machine, and each virtual machine is correspondingly provided with the preset 63 virtual instructions. When the program code to be protected is virtualized, one or more virtual instructions corresponding to the execution logic of the program code to be protected can be found out from the preset 63 virtual instructions, so that virtual virtualization of the program code to be protected is realized.

The drive data is derived based on virtual instructions. The drive data is data related to the execution logic of the program code to be protected.

When generating the driving data, firstly, a virtual instruction is obtained based on the program code to be protected, and the virtual instruction can be composed of one or more byte codes, and the corresponding relation between the virtual instruction and the byte codes is related to the number of dispatchers in the virtual machine. If the number of dispatchers in the virtual machine is one, one virtual instruction corresponds to one byte code. If the number of dispatchers in the virtual machine is n, one virtual instruction corresponds to n byte codes. Any one byte code is selected from a plurality of byte codes, and the one byte code and the operand of the virtual instruction are used as the driving data of the virtual instruction.

Alternatively, the program code to be protected may correspond to one or more functions to be protected, one function to be protected may correspond to a plurality of instructions, one instruction may correspond to one or more virtual instructions, and one virtual instruction may be composed of one or more bytecodes. The drive data of the program code to be protected may thus comprise one or more bytecodes and operands corresponding to the one or more bytecodes.

When the program code to be protected is executed, one or more virtual instructions corresponding to the program code to be protected are acquired first, when one virtual instruction is executed, one byte code and one operand corresponding to the one virtual instruction are acquired from the driving data, and then the one byte code and the one operand are executed until the one or more virtual instructions corresponding to the program code to be protected are executed.

Fig. 1 and 2 show a schematic diagram of a method of virtual instruction execution.

As shown in fig. 1, the virtual instruction execution includes three steps, namely, firstly, reading the byte code corresponding to the virtual instruction, then analyzing the execution logic corresponding to the byte code, and finally loading the corresponding virtual instruction execution module based on the execution logic of the byte code, wherein a plurality of virtual instruction execution modules (handers), such as hander 1 (x, y), hander 2 (x, y), hander 3 (x, y), hander 4 (x, y), …, handlern (x, y), and the like, may be included in the virtual machine, and one virtual instruction execution module is selected from the plurality of virtual instruction execution modules to execute the byte code.

As shown in fig. 2, a dispatcher is configured within the virtual machine. The virtual machine is integrated with a plurality of different virtual instruction execution modules (handles), and when the byte codes corresponding to the virtual instructions are executed, the dispatcher calls the corresponding virtual instruction execution modules to execute the byte codes.

For example, when executing a virtual instruction, the virtual machine is first entered, and the corresponding bytecode one of the virtual instruction is obtained. The dispatcher selects a virtual instruction execution module corresponding to the first byte code from the plurality of virtual instruction execution modules, and executes the first byte code through the virtual instruction execution module. After the execution of the first byte code is completed, a next virtual instruction, such as a second virtual instruction, is executed, and the second byte code corresponding to the second virtual instruction is obtained.

Similarly, the dispatcher selects a virtual instruction execution module corresponding to the second byte code from the plurality of virtual instruction execution modules, and executes the second byte code through the virtual instruction execution module. Until all the virtual instructions are executed.

As can be seen from the above execution process, the structure inside the virtual machine is relatively single, and scheduling the virtual instruction execution module by a single dispatcher results in the occurrence of a convergence point in the virtual machine, i.e. the convergence point is the single dispatcher. An attacker can easily perform reverse analysis through one convergence point of a single dispatcher, so that the realization logic of the program code to be protected corresponding to the virtual instruction is restored, and the virtualization protection intensity is reduced.

Based on this, the embodiment of the application provides a virtual instruction running method, which includes the following steps:

Step one, a first function to be protected is obtained, and a first virtual instruction and a second virtual instruction are generated based on the first function to be protected.

And step two, executing a first virtual instruction through a first dispatcher in the first virtual machine, and executing a second virtual instruction through a second dispatcher in the first virtual machine.

Optionally, in some embodiments, different protection functions may also be protected by different virtual machines. Specifically, a first virtual instruction is executed by a first dispatcher in a first virtual machine, and a second virtual instruction is executed by a second dispatcher in a second virtual machine. In this way, complex execution logic within the virtual machine may be increased.

Optionally, a plurality of virtual instruction execution modules are correspondingly arranged in the virtual machine, and the virtual instruction execution modules are used for executing virtual instructions. That is, the first virtual instruction execution module may be invoked to execute the first virtual instruction by a first dispatcher in the first virtual machine, and the second virtual instruction execution module may be invoked to execute the second virtual instruction by a second dispatcher in the first virtual machine.

Optionally, in some embodiments, the first function to be protected acquires the first virtual instruction and the second virtual instruction, and also acquires the third virtual instruction. The third virtual instruction execution module can be directly called through the first virtual instruction execution module or the second virtual instruction execution module, and the third virtual instruction is executed through the third virtual instruction execution module. In this way, the virtual instruction execution module can be invoked by the virtual instruction execution module to execute the virtual instruction, reducing the overhead of invoking the virtual instruction execution module by the dispatcher.

According to the method, the internal structures of the virtual machines are enriched (namely, a plurality of dispatchers are preset in one virtual machine), the jump flow in the virtual machine is enriched, the convergence points are scattered, the difficulty of reverse analysis and attack is improved, and therefore the safety of virtualization protection is improved.

As can be seen from the above analysis, the dispatcher in the virtual machine is single, and the virtual instruction execution module is dispatched by the single dispatcher, so that the attacker can easily obtain the convergence point, and the security is low. Based on the above, in order to enrich the internal structure of the virtual machine and reduce the occurrence of convergence points, the application can preset a plurality of dispatchers in one virtual machine, and when executing virtual instructions, one dispatcher is randomly allocated from the plurality of dispatchers to execute the virtual instructions. In this way, different virtual instructions may be executed by different dispatchers. The aggregation points on each dispatcher are reduced, and the difficulty of finding the aggregation points by an attacker to reversely analyze is improved.

Alternatively, the number of virtual machines may be multiple, one virtual machine may protect m functions to be protected, and one function to be protected may generate one or more virtual instructions. If one program code to be protected has a plurality of functions to be protected, the functions to be protected can be protected by different virtual machines. In the case where a function to be protected may generate multiple virtual instructions, in one possible implementation, the multiple virtual instructions may be executed by different dispatchers within the same virtual machine, and in other possible implementations, the multiple virtual instructions may also be executed by different dispatchers within different virtual machines. In this manner, the convergence point on a dispatcher can be reduced.

Illustratively, one virtual machine may protect 6 functions to be protected. When the number of functions to be protected in the program code to be protected is more than 6, then another virtual machine needs to be created. For example, when the number of functions to be protected in the program code to be protected is 5, only one virtual machine needs to be created, and the 5 functions to be protected are deprotected by the one virtual machine. When the number of the functions to be protected in the program code to be protected is 7, two virtual machines are needed to be created, 6 functions to be protected are deprotected through the first virtual machine, and the other 1 functions to be protected are deprotected through the second virtual machine.

Before the virtual machine is created, a plurality of preset virtual instructions are loaded, so that one or more virtual instructions corresponding to the function to be protected are generated when the function to be protected is protected later. For example, before the first virtual machine is created, the preset virtual instruction needs to be loaded into the first virtual machine. Before the second virtual machine is created, the preset virtual instruction needs to be loaded into the second virtual machine. For example, the number of preset virtual instructions may be 63. When the virtual machine is created, the virtual machine is created by only screening virtual instructions needed by the function to be protected based on the preset 63 instructions.

One function to be protected may generate one or more virtual instructions, the number of which is related to the execution logic of the function to be protected. If the execution logic of the function to be protected is simple, the number of virtual instructions generated based on the function to be protected is small, and if the execution logic of the function to be protected is complex, the number of virtual instructions generated based on the function to be protected is large.

One virtual instruction may correspond to one or more bytecodes, the number of bytecodes being related to the number of dispatchers within the virtual machine. For example, if the first function to be protected is protected by the first virtual machine, the first function to be protected corresponds to the first virtual instruction, and if three dispatchers are preset in the first virtual machine, the first virtual instruction corresponds to three byte codes. If four dispatchers are preset in the first virtual machine, the first virtual instruction corresponds to four byte codes. The greater the number of dispatchers within the virtual machine, the greater the number of bytecodes corresponding to the virtual instructions. When executing the virtual instruction, one byte code is arbitrarily selected from a plurality of byte codes to execute, so that the randomness of the execution of the virtual instruction by which dispatcher is stronger. The security of the virtual instruction is improved.

Alternatively, in some embodiments, the number of bytecodes corresponding to one virtual instruction may be the same as the number of dispatchers in the virtual machine, the number of bytecodes corresponding to one virtual instruction may be smaller than the number of dispatchers in the virtual machine, and the number of bytecodes corresponding to one virtual instruction may be larger than the number of dispatchers in the virtual machine.

Fig. 3 is a schematic diagram illustrating a correspondence between virtual instructions and byte codes.

Illustratively, the number of dispatchers within one virtual machine is 3. The virtual instruction may be VLCONST.

The bytecode consists of the identity of the dispatcher and the virtual instructions.

As shown in fig. 3, virtual instruction VLCONST may correspond to 3 bytecodes.

The byte code consists of 64 bits, wherein 0-31 bits represent virtual instructions, and 32-63 bits represent the identification of the dispatcher to which the byte code corresponds.

Alternatively, the bytecode is composed of 64 bits, wherein bits 0-31 represent the identification of the dispatcher to which the bytecode corresponds, and bits 32-63 represent the virtual instruction.

The 0-31 bits of the first bytecode are filled with virtual instructions VLCONST and the 32-63 bits of the first bytecode are filled with the identification of the dispatcher to which the bytecode corresponds, e.g., 01. The identity 01 of the dispatcher indicates the first dispatcher.

The 0-31 bits of the second bytecode are filled with virtual instructions VLCONST and the 32-63 bits of the second bytecode are filled with the identification of the dispatcher to which the bytecode corresponds, e.g., 02. The identity 02 of the dispatcher represents a second dispatcher.

The 0-31 bits of the third bytecode are filled with virtual instructions VLCONST and the 32-63 bits of the third bytecode are filled with the identification of the dispatcher to which the bytecode corresponds, e.g., 11. The identifier 11 of the dispatcher indicates the third dispatcher.

Thus, through the byte code, the corresponding relation between the virtual instruction and the dispatcher is established. When executing the virtual instruction VLCONST, one byte code is arbitrarily selected from the three byte codes and executed, i.e., it is achieved that one of the three dispatchers is arbitrarily selected to execute the virtual instruction VLCONST. Therefore, when the virtual instruction is executed, the virtual instruction is executed through any dispatcher at random, the aggregation point of each dispatcher is reduced, and the security of virtual instruction protection is improved.

According to the method shown in fig. 3, a corresponding relationship between each virtual instruction in the function to be protected and a plurality of dispatchers can be established, and when executing the virtual instruction corresponding to the function to be protected, one dispatcher is selected from the plurality of dispatchers to execute the virtual instruction.

For example, the program code to be protected has a first function to be protected and a second function to be protected, where the first function to be protected and the second function to be protected may be protected by the same virtual machine, for example, both are protected by the first virtual machine.

The first function to be protected corresponds to a first virtual instruction, a second virtual instruction and a third virtual instruction, if three dispatchers are preset in the first virtual machine, the first virtual instruction corresponds to three byte codes, the second virtual instruction can also correspond to three byte codes, and the third virtual instruction can also correspond to three byte codes.

The second function to be protected corresponds to a fourth virtual instruction, which may correspond to three bytecodes.

TABLE 1

As shown in table 1, the first function to be protected and the second function to be protected are protected by the first virtual machine.

Table 1 shows the correspondence of each virtual instruction to the dispatcher in the case where the first function to be protected corresponds to three virtual instructions. For example, the first function to be protected corresponds to a first virtual instruction, a second virtual instruction and a third virtual instruction, and the first virtual instruction may generate a first byte code, a second byte code and a third byte code, where the identifier of the dispatcher corresponding to the first byte code is 01, the identifier of the dispatcher corresponding to the second byte code is 10, and the identifier of the dispatcher corresponding to the third byte code is 11. It can also be said that the execution logic of the first virtual instruction may be executed by any one of a first bytecode, a second bytecode, and a third bytecode, the first bytecode being executed by the first dispatcher, the second bytecode being executed by the second dispatcher, the third bytecode being executed by the third dispatcher.

The second virtual instruction may generate a fourth byte code, a fifth byte code, and a sixth byte code, wherein the identifier of the dispatcher corresponding to the fourth byte code is 01, the identifier of the dispatcher corresponding to the fifth byte code is 10, and the identifier of the dispatcher corresponding to the sixth byte code is 11. It can also be said that the execution logic of the second virtual instruction may be executed by any one of a fourth byte code, a fifth byte code, and a sixth byte code, the fourth byte code being executed by the first dispatcher, the fifth byte code being executed by the second dispatcher, the sixth byte code being executed by the third dispatcher.

The third virtual instruction may generate a seventh byte code, an eighth byte code, and a ninth byte code, wherein the identifier of the dispatcher corresponding to the seventh byte code is 01, the identifier of the dispatcher corresponding to the eighth byte code is 10, and the identifier of the dispatcher corresponding to the ninth byte code is 11. It can also be said that the execution logic of the third virtual instruction may be executed by any one of a seventh bytecode, an eighth bytecode, and a ninth bytecode, the seventh bytecode being executed by the first dispatcher, the eighth bytecode being executed by the second dispatcher, the ninth bytecode being executed by the third dispatcher.

The fourth virtual instruction may generate a thirteenth byte code, a fourteenth byte code, and a fifteenth byte code, wherein the thirteenth byte code corresponds to a dispatcher with an identification of 01, the fourteenth byte code corresponds to a dispatcher with an identification of 10, and the fifteenth byte code corresponds to a dispatcher with an identification of 11. It can also be said that the execution logic of the fourth virtual instruction may be executed by any one of thirteenth, fourteenth and fifteenth bytecodes, the thirteenth bytecode being executed by the first dispatcher, the fourteenth bytecode being executed by the second dispatcher, the thirteenth bytecode being executed by the third dispatcher.

The second function to be protected corresponds to a fourth virtual instruction and a fifth virtual instruction. The fourth virtual instruction may generate a tenth byte code, an eleventh byte code, and a twelfth byte code, wherein the identifier of the dispatcher corresponding to the tenth byte code is 01, the identifier of the dispatcher corresponding to the eleventh byte code is 10, and the identifier of the dispatcher corresponding to the twelfth byte code is 11. It can also be said that the execution logic of the fourth virtual instruction may be executed by any one of a tenth byte code, an eleventh byte code, and a twelfth byte code, the tenth byte code being executed by the first dispatcher, the eleventh byte code being executed by the second dispatcher, the twelfth byte code being executed by the third dispatcher.

The fifth virtual instruction may generate a sixteenth byte code, a seventeenth byte code, and an eighteenth byte code, wherein the sixteenth byte code corresponds to a dispatcher with an identifier of 01, the seventeenth byte code corresponds to a dispatcher with an identifier of 10, and the eighteenth byte code corresponds to a dispatcher with an identifier of 11. It can also be said that the execution logic of the fifth virtual instruction may be executed by any one of a sixteenth byte code executed by the first dispatcher, a seventeenth byte code executed by the second dispatcher, and an eighteenth byte code executed by the third dispatcher.

For another example, the program code to be protected has a first function to be protected and a second function to be protected, where the first function to be protected and the third function to be protected may be protected by different virtual machines, for example, the first function to be protected is protected by a first virtual machine, and the second function to be protected is protected by a second virtual machine.

The second function to be protected corresponds to a fourth virtual instruction, and if three dispatchers are preset in the first virtual machine, the fourth virtual instruction can correspond to three byte codes.

It should be noted that the number of allocators in different virtual machines may be the same or different, which is not limited by the embodiment of the present application.

TABLE 2

As shown in table 2, the first function to be protected is protected by the first virtual machine, and the second function to be protected is protected by the second virtual machine.

Table 2 shows the correspondence of each virtual instruction to the dispatcher in the case where the first function to be protected corresponds to three virtual instructions. For example, the first function to be protected corresponds to a first virtual instruction, a second virtual instruction, a third virtual instruction and a fourth virtual instruction, and the first virtual instruction may generate a first byte code, a second byte code and a third byte code, where the identifier of the dispatcher corresponding to the first byte code is 01, the identifier of the dispatcher corresponding to the second byte code is 10, and the identifier of the dispatcher corresponding to the third byte code is 11. It can also be said that the execution logic of the first virtual instruction may be executed by any one of a first bytecode, a second bytecode, and a third bytecode, the first bytecode being executed by a first dispatcher in the first virtual machine, the second bytecode being executed by a second dispatcher in the first virtual machine, the third bytecode being executed by a third dispatcher in the first virtual machine.

The second virtual instruction may generate a fourth byte code, a fifth byte code, and a sixth byte code, wherein the identifier of the dispatcher corresponding to the fourth byte code is 01, the identifier of the dispatcher corresponding to the fifth byte code is 10, and the identifier of the dispatcher corresponding to the sixth byte code is 11. It can also be said that the execution logic of the second virtual instruction may be executed by any one of a fourth byte code, a fifth byte code, and a sixth byte code, the fourth byte code being executed by the first dispatcher in the first virtual machine, the fifth byte code being executed by the second dispatcher in the first virtual machine, the sixth byte code being executed by the third dispatcher in the first virtual machine.

The third virtual instruction may generate a seventh byte code, an eighth byte code, and a ninth byte code, wherein the identifier of the dispatcher corresponding to the seventh byte code is 01, the identifier of the dispatcher corresponding to the eighth byte code is 10, and the identifier of the dispatcher corresponding to the ninth byte code is 11. It can also be said that the execution logic of the third virtual instruction may be executed by any one of a seventh bytecode, an eighth bytecode, and a ninth bytecode, the seventh bytecode being executed by a first dispatcher in the first virtual machine, the eighth bytecode being executed by a second dispatcher in the first virtual machine, and the ninth bytecode being executed by a third dispatcher in the first virtual machine.

The second function to be protected corresponds to a fourth virtual instruction and a fifth virtual log. The fourth virtual instruction may generate a tenth byte code, an eleventh byte code, and a twelfth byte code, wherein the identifier of the dispatcher corresponding to the tenth byte code is 01, the identifier of the dispatcher corresponding to the eleventh byte code is 10, and the identifier of the dispatcher corresponding to the twelfth byte code is 11. It can also be said that the execution logic of the fourth virtual instruction may be executed by any one of a tenth byte code, an eleventh byte code, and a twelfth byte code, the tenth byte code being executed by the first dispatcher in the second virtual machine, the eleventh byte code being executed by the second dispatcher in the second virtual machine, the twelfth byte code being executed by the third dispatcher in the second virtual machine.

It should be noted that the first dispatcher in the first virtual machine and the first dispatcher in the second virtual machine are not the same dispatcher, the second dispatcher in the first virtual machine and the second dispatcher in the second virtual machine are not the same dispatcher, and the third dispatcher in the first virtual machine and the third dispatcher in the second virtual machine are not the same dispatcher.

Optionally, after generating the byte code based on the virtual instruction, driving data is further generated, where the driving data records the execution logic of the function to be protected. When executing the function to be protected, the virtual machine may schedule the virtual instruction execution module to execute one or more virtual instructions corresponding to the function to be protected based on data recorded in the driving data.

One function to be protected may correspond to one driving data. If there are multiple functions to be protected, there are multiple driving data.

As can be seen from the foregoing analysis, one function to be protected corresponds to one or more virtual instructions, one virtual instruction corresponds to a plurality of byte codes, and when generating the driving data of the function to be protected, one byte code can be selected from the plurality of byte codes to be stored in the driving data of the function to be protected, and meanwhile, the operand of the function to be protected needs to be stored in the driving data. In this way, where multiple dispatchers are included within the virtual machine, it is also confirmed which dispatcher each virtual instruction is executed by.

Alternatively, one byte code may be randomly selected from a plurality of byte codes to be stored in the driving data of the function to be protected.

Optionally, the number of times the virtual machine executes each dispatcher may be recorded, and the dispatcher that subsequently executes each virtual instruction may be determined based on the frequency of use of each dispatcher in the virtual machine. For example, a first dispatcher, a second dispatcher, and a third dispatcher within a first virtual machine. The first dispatcher has a small number of uses, and the second dispatcher and the third dispatcher have a large number of uses. Then when the dispatcher executing other virtual instructions is dispatched subsequently, the dispatcher executing other virtual instructions is directly designated as the first dispatcher, and the mode of randomly distributing the dispatcher is not adopted any more, so that the utilization rate of the first dispatcher can be improved. The aggregation points on the second dispatcher and the third dispatcher are prevented from increasing.

For example, for the first function to be protected, when determining that the dispatcher executing the first virtual instruction in the first function to be protected has a small number of times of use of the first dispatcher, and the second dispatcher and the third dispatcher have a large number of times of use, the first byte code may be directly selected from the plurality of byte codes corresponding to the first virtual instruction, so that it is determined that the dispatcher executing the first virtual instruction is the first dispatcher.

It should be noted that, a byte code corresponding to the virtual instruction may also be determined based on other manners, which is not limited in the embodiment of the present application.

TABLE 3 Table 3

Table 3 shows that both the first function to be protected and the second function to be protected are protected by the first virtual machine. And determining a unique byte code from a plurality of byte codes corresponding to each virtual instruction aiming at the first function to be protected. The first function to be protected is illustratively associated with a first virtual instruction, a second virtual instruction, a third virtual instruction, and a fourth virtual instruction. And determining the byte code corresponding to the first virtual instruction as the first byte code. The byte code corresponding to the second virtual instruction is a fifth byte code. The byte code corresponding to the third virtual instruction is a ninth byte code, and the byte code corresponding to the fourth virtual instruction is a thirteenth byte code. And determining a unique byte code from a plurality of byte codes corresponding to each virtual instruction aiming at the second function to be protected. The second function to be protected is exemplified by a fourth virtual instruction and a fifth virtual instruction, the byte code corresponding to the fourth virtual instruction is a tenth byte code, and the byte code corresponding to the fifth virtual instruction is an eighteenth byte code.

TABLE 4 Table 4

Table 4 shows that the first function to be protected and the second function to be protected are protected by different virtual machines. The first function to be protected is protected by the first virtual machine, and a unique byte code is determined from a plurality of byte codes corresponding to each virtual instruction aiming at the first function to be protected. The first function to be protected is illustratively associated with a first virtual instruction, a second virtual instruction, a third virtual instruction, and a fourth virtual instruction. And determining the byte code corresponding to the first virtual instruction as the first byte code. The byte code corresponding to the second virtual instruction is a fifth byte code. The byte code corresponding to the third virtual instruction is a ninth byte code. The byte code corresponding to the fourth virtual instruction is thirteenth byte code.

The second function to be protected is protected by a second virtual machine, and a unique byte code is determined from a plurality of byte codes corresponding to each virtual instruction aiming at the second function to be protected. The second function to be protected is exemplified by a fourth virtual instruction and a fifth virtual instruction, the byte code corresponding to the fourth virtual instruction is a tenth byte code, and the byte code corresponding to the fifth virtual instruction is an eighteenth byte code.

After determining each corresponding bytecode to be protected, it is determined which of the dispatchers to execute the function to be protected. Based on this, the driving data of each function to be protected can be generated.

TABLE 5

Table 5 shows that the first function to be protected and the second function to be protected are protected by the same virtual machine, e.g. both protected by the first virtual machine. The first function to be protected corresponds to first driving data, and the second function to be protected corresponds to second driving data. The first drive data and the second drive data are both invoked by the first virtual machine.

The first driving data includes an operand having a first byte code and a first virtual instruction, an operand having a fifth byte code and a second virtual instruction, an operand having a ninth byte code and a third virtual instruction, and an operand having a thirteenth byte code and a fourth virtual instruction. The first bytecode is comprised of an identification of a first dispatcher in the first virtual machine and a first virtual instruction. The fifth bytecode is comprised of an identification of a second dispatcher in the first virtual machine and a second virtual instruction. The ninth bytecode is comprised of an identification of a third dispatcher in the first virtual machine and the first virtual instruction. The thirteenth bytecode is composed of an identification of the first dispatcher in the first virtual machine and a fourth virtual instruction. The first driving data indicates that the first virtual instruction is executed by a first dispatcher in the first virtual machine, the second virtual instruction is executed by a second dispatcher in the first virtual machine, and the third virtual instruction is executed by a third dispatcher in the first virtual machine. The fourth virtual instruction is executed by a first dispatcher in the first virtual machine. I.e. the first function to be protected is executed by the first dispatcher, the second dispatcher and the third dispatcher in the first virtual machine, respectively.

The second driving data includes operands of tenth byte code and fourth virtual instruction, eighteenth byte code and fifth virtual instruction. The tenth bytecode is composed of an identification of the first dispatcher in the first virtual machine and a fourth virtual instruction. The eighteenth bytecode is composed of an identification of the third dispatcher in the first virtual machine and a fifth virtual instruction. The second driving data indicates that the fourth virtual instruction is executed by the first dispatcher in the first virtual machine, and the fifth virtual instruction is executed by the third dispatcher in the first virtual machine. I.e. the second function to be protected is executed by the first dispatcher in the first virtual machine and the third dispatcher in the first virtual machine.

TABLE 6

Table 6 shows that the first function to be protected and the second function to be protected are protected by different virtual machines, for example, the first function to be protected is protected by the first virtual machine and the second function to be protected is protected by the second virtual machine. The first function to be protected corresponds to first driving data, and the second function to be protected corresponds to second driving data. The first drive data is invoked by the first virtual machine and the second drive data is invoked by the second virtual machine.

The first driving data includes an operand having a first byte code and a first virtual instruction, an operand having a fifth byte code and a second virtual instruction, an operand having a ninth byte code and a third virtual instruction, and an operand having a thirteenth byte code and a fourth virtual instruction. The first bytecode is comprised of an identification of a first dispatcher in the first virtual machine and a first virtual instruction. The fifth bytecode is comprised of an identification of a second dispatcher in the first virtual machine and a second virtual instruction. The ninth bytecode is composed of an identification of the third dispatcher in the first virtual machine and the first virtual instruction, and the thirteenth bytecode is composed of an identification of the first dispatcher in the first virtual machine and the fourth virtual instruction. The first driving data indicates that the first virtual instruction is executed by a first dispatcher in the first virtual machine, the second virtual instruction is executed by a second dispatcher in the first virtual machine, and the third virtual instruction is executed by a third dispatcher in the first virtual machine. The fourth virtual instruction is executed by a first dispatcher in the first virtual machine. I.e. the first function to be protected is executed by the first dispatcher, the second dispatcher and the third dispatcher in the first virtual machine, respectively.

The second driving data includes operands of tenth byte code and fourth virtual instruction, eighteenth byte code and fifth virtual instruction. The tenth bytecode is composed of an identification of the first dispatcher in the second virtual machine and a fourth virtual instruction. The eighteenth bytecode is composed of an identification of the third dispatcher in the second virtual machine and a fifth virtual instruction. The second driving data indicates that the fourth virtual instruction is executed by the first dispatcher in the second virtual machine, and the fifth virtual instruction is executed by the third dispatcher in the second virtual machine. I.e. the second function to be protected is executed by the first dispatcher in the second virtual machine and the third dispatcher in the second virtual machine.

After the driving data is generated, a virtual machine may be created based on the driving data.

Creating the virtual machine may include the steps of: counting virtual instructions to be used, creating a virtual instruction execution module, and constructing a complicated jump execution flow in the virtual machine.

1. Counting virtual instructions to be used

One virtual machine can protect m functions to be protected. If one program code to be protected has a plurality of functions to be protected, the functions to be protected can be protected by different virtual machines.

When creating virtual machines, the types of virtual instructions required by m functions to be protected under each virtual machine are counted. Because the system has realized that the preset virtual instructions are 63, when each virtual machine is created, the virtual instructions needed by the m functions to be protected are selected from the preset 63 virtual instructions, and the virtual instructions needed by the m functions to be protected are loaded into the virtual machine. That is, only the virtual instructions that are used will be used to build the virtual machine.

TABLE 7

Table 7 shows a virtual instruction that needs to be used when creating a virtual machine. For example, the first virtual machine is created by using a first virtual instruction, a second virtual instruction, a third virtual instruction, a fourth virtual instruction, and a fifth virtual instruction.

TABLE 8

Table 8 shows another virtual instruction that needs to be used when creating a virtual machine. For example, the first virtual instruction, the second virtual instruction, the third virtual instruction, and the fourth virtual instruction are used when creating the first virtual machine, and the fourth virtual instruction and the fifth virtual instruction are used when creating the second virtual machine.

It should be noted that, table 7 and table 8 are merely exemplary, and in other embodiments, when creating the first virtual machine and the second virtual machine, more or fewer virtual instructions may be used, which is not limited by the embodiments of the present application.

Not only the first virtual machine and the second virtual machine may be created, but also other virtual machines may be created, which is not limited in the embodiment of the present application.

2. Creating virtual instruction execution modules

The virtual instruction execution module represents the execution logic of the virtual instruction. One virtual instruction may correspond to one virtual instruction execution module, and one virtual instruction may correspond to a plurality of virtual instruction execution modules whose execution logic is identical.

For the same virtual instruction executed by different dispatchers, different dispatchers may share the same virtual instruction execution module, or may use different virtual instruction execution modules, which is not limited in the embodiment of the present application.

Alternatively, a virtual instruction may correspond to a virtual instruction execution module, in which case different dispatchers may share the same virtual instruction execution module when they call the same virtual instruction. One virtual instruction may also correspond to a plurality of virtual instruction execution modules. The execution logic of the plurality of virtual instruction execution modules corresponding to the same virtual instruction is the same. In this case, different virtual instruction execution modules are used when different dispatchers call the same virtual instruction.

For the sake of understanding the present application, the following embodiments of the present application will be described by taking a virtual instruction as an example when different dispatchers call the same virtual instruction, but should not be construed as limiting.

TABLE 9

Table 9 shows a plurality of virtual instruction execution modules corresponding to the first virtual machine created when the first virtual machine is created. For example, the virtual instruction execution module corresponding to the first virtual instruction in the first virtual machine is the first virtual instruction execution module. The virtual instruction execution module corresponding to the second virtual instruction in the first virtual machine is the second virtual instruction execution module. The virtual instruction execution module corresponding to the third virtual instruction in the first virtual machine is the third virtual instruction execution module. The virtual instruction execution module corresponding to the fourth virtual instruction in the first virtual machine is a fourth virtual instruction execution module. The virtual instruction execution module corresponding to the fifth virtual instruction in the first virtual machine is the fifth virtual instruction execution module.

Table 10

Table 10 shows a plurality of virtual instruction execution modules corresponding to the first virtual machine and the second virtual machine are created when the first virtual machine and the second virtual machine are created. For example, the virtual instruction execution module corresponding to the first virtual instruction in the first virtual machine is the first virtual instruction execution module. The virtual instruction execution module corresponding to the second virtual instruction in the first virtual machine is the second virtual instruction execution module. The virtual instruction execution module corresponding to the third virtual instruction in the first virtual machine is the third virtual instruction execution module. The virtual instruction execution module corresponding to the fourth virtual instruction in the first virtual machine is a fourth virtual instruction execution module.

The virtual instruction execution module corresponding to the fourth virtual instruction in the second virtual machine is a fifth virtual instruction execution module. The virtual instruction execution module corresponding to the fifth virtual instruction in the second virtual machine is a sixth virtual instruction execution module.

Optionally, in some embodiments, the same virtual instruction in the function to be protected may appear multiple times, and when the virtual instruction selects the bytecode, the bytecode selected by the same virtual instruction may be different, and the bytecode contains the identifier of the dispatcher, so that the same virtual instruction appearing multiple times can be divided into different dispatchers to execute, thereby further reducing the occurrence of convergence points in the virtual machine.

For example, a first virtual instruction in a first function to be protected may appear twice, and the two appearing first virtual instructions may be executed by different dispatchers.

Illustratively, the first virtual instruction may be the VLCONST instruction shown in FIG. 3, and the VLCONST instruction may correspond to 3 bytecodes. Both of the two-occurrence VLCONST instructions in the first function to be protected may correspond to the 3 bytecodes shown in fig. 3. When selecting only one byte code from the plurality of byte codes, for example, the first-appearing VLCONST instruction in the first function to be protected may be the selected first byte code, and the second-appearing VLCONST instruction in the second function to be protected may be the selected second byte code. Based on the first and second bytecodes, it may be determined that the first-occurring VLCONST instructions in the first function to be protected are executed by a first dispatcher in the first virtual machine. The second-occurring VLCONST instructions in the first function to be protected are executed by a second dispatcher in the first virtual machine. Therefore, the same virtual instruction which appears for many times is divided into different dispatchers to be executed, and the appearance of convergence points in the virtual machine is further reduced.

Alternatively, the same virtual instruction that appears multiple times in the function to be protected may also be executed by the same dispatcher, which is not limited in the embodiment of the present application.

Alternatively, in some embodiments, execution within a virtual machine may be performed by multiple dispatchers, e.g., 3 dispatchers within a virtual machine. The number of dispatchers may be the same or different in different virtual machines, which is not limited in this embodiment of the present application.

As described above, the same virtual instruction that appears multiple times in the function to be protected may be executed by different dispatchers. When the virtual machine executes the same virtual instruction which appears many times, the dispatcher essentially calls the virtual instruction execution module corresponding to the virtual instruction to execute the virtual instruction.

For example, a first virtual instruction in a first function to be protected may appear twice, the first virtual instruction appearing first is executed by a first dispatcher, and the first virtual instruction appearing second is executed by a second dispatcher. When the first dispatcher executes a first virtual instruction which appears for the first time, the first dispatcher needs to call a first virtual instruction execution module corresponding to the first virtual instruction to execute the first virtual instruction. When the second dispatcher executes the first virtual instruction appearing for the second time, the second dispatcher also needs to call the first virtual instruction execution module corresponding to the first virtual instruction to execute the second virtual instruction. In one possible implementation, the first virtual instruction execution module called by the first dispatcher and the first virtual instruction execution module called by the second dispatcher may be the same virtual instruction execution module, that is, for the same virtual instruction, only one virtual instruction execution module needs to be created in the virtual, and different dispatchers may share the virtual instruction execution module. In other possible implementations, the first virtual instruction execution module called by the first dispatcher and the first virtual instruction execution module called by the second dispatcher may be different virtual instruction execution modules, i.e., different dispatcher calls different virtual instruction execution modules for the same virtual instruction. The number of first virtual instruction execution modules corresponding to the created first virtual instruction is related to the number of dispatchers that call the first virtual instruction.

Optionally, in some embodiments, the virtual instruction execution modules corresponding to the first virtual instructions invoked by the first dispatcher and the second dispatcher are the same virtual instruction execution module, and the third dispatcher is different from the virtual instruction execution modules corresponding to the first virtual instructions invoked by the first dispatcher and the second dispatcher. That is, for the same virtual instruction that appears multiple times, it may be that part of the dispatchers share the virtual instruction execution module corresponding to the virtual instruction.

For example, as shown in fig. 4, the first function to be protected is protected by a first virtual machine, where there are a first dispatcher, a second dispatcher, and a third dispatcher, and the first function to be protected includes a first virtual instruction, a second virtual instruction, a third virtual instruction, and a fourth virtual instruction, where the first virtual instruction appears three times in the first function to be protected. Wherein the first virtual instruction and the fourth virtual instruction that occur for the first time are executed by the first dispatcher. The first dispatcher calls the first virtual instruction execution module to execute the first virtual instruction appearing for the first time, and the first dispatcher calls the fourth virtual instruction execution module to execute the fourth virtual instruction. The second occurrence of the first virtual instruction and the second virtual instruction is executed by the second dispatcher. The second dispatcher calls the first virtual instruction execution module to execute the first virtual instruction appearing for the second time, and the second dispatcher calls the second virtual instruction execution module to execute the second virtual instruction. The third occurrence of the first virtual instruction and the third virtual instruction is executed by the third dispatcher. The third dispatcher calls the first virtual instruction execution module to execute the first virtual instruction appearing for the third time, and the third dispatcher calls the third virtual instruction execution module to execute the third virtual instruction. That is, the first virtual instruction execution module called by the first dispatcher, the first virtual instruction execution module called by the second dispatcher, and the first virtual instruction execution module called by the third dispatcher are the same virtual instruction execution module, that is, the same virtual instruction execution module.

As another example, as shown in fig. 5, fig. 5 is different from fig. 4 in that, in fig. 5, when a first virtual instruction appearing for the first time is executed, a first dispatcher calls a first virtual instruction execution module to execute the first virtual instruction appearing for the first time. In FIG. 5, the seventh virtual instruction execution module is invoked by the second dispatcher to execute the second appearing first virtual instruction while executing the second appearing first virtual instruction. In FIG. 5, the third-occurring first virtual instruction is executed by the third dispatcher invoking the eighth virtual instruction execution module. The first virtual instruction execution module, the seventh virtual instruction execution module, and the eighth virtual instruction execution module are different from one another. That is, the first virtual instruction execution module called by the first dispatcher, the first virtual instruction execution module called by the second dispatcher, and the first virtual instruction execution module called by the third dispatcher are different from each other, that is, are not the same virtual instruction execution module.

As another example, as shown in fig. 6, fig. 6 is different from fig. 4 in that, in fig. 6, when the first virtual instruction appearing for the first time is executed, the first dispatcher calls the first virtual instruction execution module to execute the first virtual instruction appearing for the first time. In FIG. 6, the second dispatcher calls the first virtual instruction execution module to execute the second appearing first virtual instruction when executing the second appearing first virtual instruction. In FIG. 6, the third dispatcher invokes the seventh virtual instruction execution module to execute the third appearing first virtual instruction when executing the third appearing first virtual instruction. That is, the first virtual instruction execution module called by the first dispatcher and the first virtual instruction execution module called by the second dispatcher are the same virtual instruction execution module, and the first virtual instruction execution module called by the third dispatcher and the first virtual instruction execution module called by the first dispatcher are not the same virtual instruction execution module.

Optionally, in some embodiments, for different virtual instructions, different dispatchers may share a virtual instruction execution module corresponding to the same virtual instruction, or may call different virtual instruction execution modules corresponding to the same virtual instruction, which is not limited in the embodiments of the present application. For example, for a first virtual instruction, different dispatchers may share a virtual instruction execution module corresponding to the first virtual instruction. For the second virtual instruction, different dispatchers call different virtual instruction execution modules corresponding to the first virtual instruction. The following embodiments of the present application are described with reference to the same virtual instruction, and different dispatchers share the virtual instruction execution module corresponding to the same virtual instruction. And are not to be construed as limiting.

3. Building intricate jump execution flow in virtual machine

An intricate jump execution flow in the virtual machine is constructed, firstly, one or more virtual instructions in each function to be protected are distributed to different dispatchers for execution.

When the driving data is generated, a first virtual instruction, a second virtual instruction and a third virtual instruction are corresponding to a first function to be protected and a second function to be protected in the program to be protected. The second function to be protected corresponds to a fourth virtual instruction. As can be seen from table 3 or table 4, for the first function to be protected, it is determined that the byte code corresponding to the first virtual instruction is the first byte code, the byte code corresponding to the second virtual instruction is the fifth byte code, and the byte code corresponding to the third virtual instruction is the ninth byte code. And determining that the byte code corresponding to the fourth virtual instruction is a third byte code for the second function to be protected. As can be seen from tables 8 and 9, when the virtual machine is created, a virtual instruction execution module corresponding to the virtual instruction has been created.

After the virtual instruction execution module corresponding to the virtual instruction is created, the corresponding relation between the virtual instruction module and the dispatcher is required to be established.

As can be seen from table 3 or table 4, the unique byte code corresponding to each virtual instruction in the function to be protected is determined, and after the virtual instruction execution module corresponding to the virtual instruction is created, the one-to-one correspondence between the byte code and the virtual instruction execution module is confirmed.

TABLE 11

Table 11 shows a one-to-one correspondence of virtual instructions, bytecodes, virtual instruction execution modules, and dispatchers. The first function to be protected is protected through the first virtual machine, and the second function to be protected is protected through the first virtual machine. The first function to be protected corresponds to a first virtual instruction, a second virtual instruction, a third virtual instruction and a fourth virtual instruction. The first virtual instruction corresponds to a first byte code, the identification of a dispatcher in the first byte code is "01", and the first virtual instruction is executed by a first virtual instruction execution module in the first virtual machine. The byte code corresponding to the second virtual instruction is a fifth byte code, the identifier of the dispatcher in the fifth byte code is '10', and the second virtual instruction is executed by a second virtual instruction execution module in the first virtual machine. The byte code corresponding to the third virtual instruction is a ninth byte code, the identifier of the dispatcher in the ninth byte code is 11, and the third virtual instruction is executed by a third virtual instruction execution module in the first virtual machine. The byte code corresponding to the fourth virtual instruction is thirteenth byte code, the identifier of the dispatcher in the thirteenth byte code is "01", and the fourth virtual instruction is executed by a fourth virtual instruction execution module in the first virtual machine.

The second function to be protected corresponds to a fourth virtual instruction and a fifth virtual instruction. The byte code corresponding to the fourth virtual instruction is a third joint code, the identifier of the dispatcher in the third joint code is "01", and the fourth virtual instruction is executed by a fifth virtual instruction execution module in the second virtual machine. The byte code corresponding to the fifth virtual instruction is an eighteenth byte code, the identifier of the dispatcher in the eighteenth byte code is 11, and the fifth virtual instruction is executed by a sixth virtual instruction execution module in the second virtual machine.

Table 12

Table 12 shows another one-to-one correspondence of virtual instructions, bytecodes, virtual instruction execution modules, and dispatchers. The first function to be protected and the second function to be protected are protected through the first virtual machine. The first function to be protected corresponds to a first virtual instruction, a second virtual instruction, a third virtual instruction and a fourth virtual instruction. The first virtual instruction corresponds to a first byte code, the identification of a dispatcher in the first byte code is "01", and the first virtual instruction is executed by a first virtual instruction execution module in the first virtual machine. The byte code corresponding to the second virtual instruction is a fifth byte code, the identifier of the dispatcher in the fifth byte code is '10', and the second virtual instruction is executed by a second virtual instruction execution module in the first virtual machine. The byte code corresponding to the third virtual instruction is a ninth byte code, the identifier of the dispatcher in the ninth byte code is 11, and the third virtual instruction is executed by a third virtual instruction execution module in the first virtual machine. The byte code corresponding to the fourth virtual instruction is thirteenth byte code, the identifier of the dispatcher in the thirteenth byte code is "01", and the fourth virtual instruction is executed by a fourth virtual instruction execution module in the first virtual machine.

The second function to be protected corresponds to a fourth virtual instruction and a fifth virtual instruction. The byte code corresponding to the fourth virtual instruction is a third joint code, the identifier of the dispatcher in the third joint code is "01", and the fourth virtual instruction is executed by a fourth virtual instruction execution module in the first virtual machine. The byte code corresponding to the fifth virtual instruction is an eighteenth byte code, the identifier of the dispatcher in the eighteenth byte code is 11, and the fifth virtual instruction is executed by a sixth virtual instruction execution module in the first virtual machine.

Based on the one-to-one correspondence of the virtual instructions, the byte codes, the virtual instruction execution modules and the dispatcher shown in the table 11 or the table 12, complex jump logic in the virtual machine can be established, and the occurrence of convergence points in the virtual machine is reduced.

When executing the function to be protected, for example, when executing the first function to be protected, the first function to be protected includes a first virtual instruction, a second virtual instruction, a third virtual instruction, and a fourth virtual instruction. Executing a first function to be protected in the virtual machine essentially calls a dispatcher in the virtual machine to execute a first virtual instruction, a second virtual instruction, a third virtual instruction, and a fourth virtual instruction. The first virtual instruction is executed by a first dispatcher in the first virtual machine calling a first virtual instruction execution module, the second virtual instruction is executed by a second dispatcher in the first virtual machine calling a second virtual instruction execution module, the third virtual instruction is executed by a third dispatcher in the first virtual machine calling a third virtual instruction execution module, and the fourth virtual instruction is also executed by the first dispatcher in the first virtual machine calling a fourth virtual instruction execution module.

The first virtual instruction and the second virtual instruction in the first function to be protected are taken as an example for explanation. The first virtual instruction corresponds to a first byte code, and the second virtual instruction corresponds to a fifth byte code.

Fig. 7 is a schematic diagram of executing a virtual instruction according to an embodiment of the present application.

The functional modules shown in fig. 7 include a first virtual machine portal, a drive data scheduling module, a dispatcher selection module, a plurality of dispatchers, a plurality of virtual instruction execution modules.

The driving data scheduling module is used for judging whether all virtual instructions in the driving data are executed completely or not. If the execution is not completed, the bytecodes corresponding to the virtual instructions are sequentially executed based on the execution logic described in the drive data.

The dispatcher selection module is used for selecting a corresponding dispatcher for the byte code based on the identification of the dispatcher in the byte code.

The dispatcher is used for selecting a corresponding virtual instruction execution module from a plurality of virtual instruction execution modules to execute the virtual instruction based on the virtual instruction in the byte code.

After the dispatcher completes execution of the virtual instruction based on the corresponding virtual instruction execution module, the drive data scheduling module will acquire the next bytecode and select the corresponding dispatcher for the bytecode based on the identification of the dispatcher in the next bytecode. To execute the next bytecode.

The following describes how to execute the first virtual instruction and to execute the second virtual instruction.

Fig. 8 is a schematic diagram of executing a first virtual instruction according to an embodiment of the present application.

The bolded portion of fig. 8 is a flow of executing the first virtual instruction.

And entering a first virtual machine when the first function to be protected is executed. A drive data scheduling module in the first virtual machine determines a first virtual instruction executing a first function to be protected, and the first virtual instruction corresponds to a first byte code. The first bytecode has an identification of a first dispatcher and a first virtual instruction. The drive data dispatch module sends the first byte code to the dispatcher selection module. The dispatcher selection module, upon receiving the first bytecode, will select a first dispatcher from a plurality of dispatchers based on an identification of the first dispatcher as recited in the first bytecode. The first dispatcher selects a first virtual instruction execution module from a plurality of virtual instruction execution modules to execute a first virtual instruction. After the first virtual instruction is executed, the process jumps to the driving data scheduling module, so that the driving data scheduling module can execute the next virtual instruction of the first function to be protected.

Fig. 9 is a schematic diagram of executing a second virtual instruction according to an embodiment of the present application.

The bolded portion of fig. 9 is a flow of executing the second virtual instruction.

After the first virtual instruction is executed, the driving data scheduling module judges whether the virtual instruction in the first function to be protected is completely executed. If not, then the next byte code recorded in the drive data is acquired. For example, the drive data dispatch module obtains the fifth bytecode. The fifth byte code has an identification of the second dispatcher and a second virtual instruction therein. The drive data dispatch module sends the fifth byte code to the dispatcher selection module. The dispatcher selection module, upon receiving the fifth byte code, will select a second dispatcher from the plurality of dispatchers based on the identification of the second dispatcher as recited in the fifth byte code. The second dispatcher selects a second virtual instruction execution module from the plurality of virtual instruction execution modules to execute the second virtual instruction. After the second virtual instruction is executed, the process jumps to the driving data scheduling module, so that the driving data scheduling module can execute the next virtual instruction of the first function to be protected.

The execution flow of other virtual instructions in the first function to be protected may refer to the embodiments shown in fig. 8 and fig. 9, and the embodiments of the present application are not described herein again.

As can be seen from fig. 8 and 9, multiple virtual instructions in the same function to be protected can be executed by different dispatchers, reducing the convergence point on each dispatcher.

Alternatively, as can be seen from fig. 8 and 9, after each virtual instruction is executed, the control module jumps to the drive data scheduling module. The convergence point on the drive data dispatch module increases. In order to reduce the convergence point on the driving data scheduling module, a judging module is added before the jump to the driving data scheduling module after the virtual instruction is executed, and the judging module is used for judging whether the flow is to jump to the driving data scheduling module or the dispatcher selecting module. In this way, the convergence point on the drive data scheduling module can be reduced.

Fig. 10 is a schematic diagram of another embodiment of executing virtual instructions.

Fig. 10 is similar to fig. 7, except that in fig. 10, two judgment modules, one being VMReturnToDis pool and the other being VMTail pool, are added between the virtual instruction execution module and the drive data scheduling module. The VMReturnToDis pool is used for directly jumping the flow to the corresponding dispatcher after the virtual instruction is executed. And the VMTail pool is used for jumping the flow to the driving data scheduling module after the virtual instruction is executed. Thus, after the virtual instruction is executed, the flow can be randomly jumped to the dispatcher selection module or the driving data scheduling module. In this way, the convergence point on the drive data scheduling module can be reduced.

Fig. 11 is a schematic diagram of another embodiment of executing a first virtual instruction.

The bolded portion of fig. 11 is another flow of executing the first virtual instruction.

And entering a first virtual machine when the first function to be protected is executed. A drive data scheduling module in the first virtual machine determines a first virtual instruction executing a first function to be protected, and the first virtual instruction corresponds to a first byte code. The first bytecode has an identification of a first dispatcher and a first virtual instruction. The drive data dispatch module sends the first byte code to the dispatcher selection module. The dispatcher selection module, upon receiving the first bytecode, will select a first dispatcher from a plurality of dispatchers based on an identification of the first dispatcher as recited in the first bytecode. The first dispatcher selects a first virtual instruction execution module from a plurality of virtual instruction execution modules to execute a first virtual instruction. After the first virtual instruction is executed, the first virtual instruction execution module selects one module from the VMReturnToDis pool and the VMTail pool to determine the jump position. For example, the first virtual instruction execution module may select VMTail pool, then VMTail pool jumps execution flow to the drive data dispatch module. So that the drive data schedule can execute the next virtual instruction of the first function to be protected.

The bolded portion of FIG. 12 is another illustration of executing a second virtual instruction.

After the first virtual instruction is executed, the first virtual instruction execution module selects one module from the VMReturnToDis pool and the VMTail pool to determine the location of the jump. For example, the first virtual instruction execution module may select VMReturnToDis pool, VMReturnToDis pool, which determines that the next bytecode to execute is the fifth bytecode. The fifth byte code has an identification of the second dispatcher and a second virtual instruction therein. The VMReturnToDis pool selects a second dispatcher from the plurality of dispatchers based on the identification of the second dispatcher as described in the fifth bytecode. The VMReturnToDis pool jumps the flow directly to the second dispatcher. The second dispatcher selects a second virtual instruction execution module from the plurality of virtual instruction execution modules to execute the second virtual instruction. After the second virtual instruction is executed, the second virtual instruction execution module selects one module from the VMReturnToDis pool and the VMTail pool to determine the jump position. For example, the second virtual instruction execution module may select VMReturnToDis pool, then VMReturnToDis pool jumps execution flow to the next dispatcher.

The execution flow of other virtual instructions in the first function to be protected may refer to the embodiments shown in fig. 11 and fig. 12, and the embodiments of the present application are not described herein again.

As can be seen from fig. 11 and fig. 12, the multiple virtual instructions in the same function to be protected can be executed by different dispatchers, so that the convergence point on each dispatcher is reduced, and the flow can be randomly jumped to the driving data dispatching module or the dispatcher selecting module, so that the convergence point on the driving data dispatching module is reduced.

To further reduce the convergence point on the dispatcher, a jump between virtual instruction execution modules and virtual instruction execution modules may be implemented based on the embodiments shown in fig. 8 and 9, or the embodiments shown in fig. 11 and 12, without going through the complex flow of specifying the dispatcher as shown in the embodiments shown in fig. 8 and 9, or the embodiments shown in fig. 11 and 12. Therefore, on one hand, the convergence point on the dispatcher can be reduced, on the other hand, the overhead for executing the virtual instruction can be reduced, and the virtual instruction execution efficiency is improved.

Optionally, the first virtual instruction execution module may directly call the second virtual instruction execution module when the first virtual instruction and the second virtual instruction satisfy a certain condition. If the first virtual instruction and the second virtual instruction do not satisfy the condition, a virtual instruction execution module executes the second virtual instruction based on the embodiment shown in fig. 9 or the embodiment shown in fig. 12 after the execution is completed.

The first condition may be that the first virtual instruction and the second virtual instruction satisfy any one of the following correspondence.

1. The first virtual instruction is VLCONST instructions and the second virtual instruction is VALLOCAJ instructions.

2. The first virtual instruction is VLLOAD instructions and the second virtual instruction is VLCONST instructions.

3. The first virtual instruction is VLLOAD instructions and the second virtual instruction is VLLOAD instructions.

4. The first virtual instruction is VLLOAD instructions and the second virtual instruction is VLOADJ instructions.

Wherein the VLCONST instruction functions as a constant value push. The VALLOCAJ instruction functions to read the top of the stack and allocate a corresponding size of space in the stack. The VLLOAD instruction functions to read values from the local variable table and push the stack. The VLOADJ instruction functions to read the variable address from the stack and find the value of the variable to push onto the stack.

That is, in the call relationship between the groups of virtual instructions, the probability of occurrence between the groups of virtual instructions is high, and the virtual instructions can be set to be directly called with each other, so as to reduce the execution overhead of the virtual instructions.

The method is not limited to the corresponding relation of the virtual instructions directly called by the groups of virtual instructions, but also can directly call the corresponding relation of the virtual instructions by other virtual instructions, and the embodiment of the application is not limited to the method.

Fig. 13 is a schematic diagram of a method for calling a virtual instruction execution module by the virtual instruction execution module according to an embodiment of the present application.

The bold in fig. 13 is the process by which the virtual instruction execution module is directly invoked by the pseudo instruction execution module.

When executing the first virtual instruction, the first virtual instruction corresponds to a first byte code. The first bytecode has an identification of a first dispatcher and a first virtual instruction. The dispatcher selection module, upon receiving the first bytecode, will select a first dispatcher from a plurality of dispatchers based on an identification of the first dispatcher as recited in the first bytecode. The first dispatcher selects a first virtual instruction execution module from a plurality of virtual instruction execution modules to execute a first virtual instruction. After the first virtual instruction is executed, if the first virtual instruction and the second virtual instruction meet the first condition and the second virtual instruction is executed by the second virtual instruction execution module, the first virtual instruction execution module can directly call the second virtual instruction execution module, and the fifth byte code corresponding to the second virtual instruction is executed by the second virtual instruction execution module. Without having to execute a second virtual instruction based on the embodiment shown in fig. 9 or the embodiment shown in fig. 12 after the first virtual instruction has been executed. The second virtual instruction execution module may be invoked directly by the first virtual instruction execution module. Therefore, on one hand, the convergence point on the dispatcher can be reduced, and on the other hand, the overhead for executing the second virtual instruction can be reduced, and the execution efficiency of the second virtual instruction is improved.

After the second virtual instruction is executed, the third virtual instruction may be executed based on the embodiment shown in fig. 9 or the embodiment shown in fig. 12, or may be executed based on the embodiment shown in fig. 13, which is not limited by the embodiment of the present application.

Fig. 14 is a flowchart of a virtual instruction execution method according to an embodiment of the present application.

S1401, reading the program code to be protected.

S1402, traversing the functions in the program code to be protected.

S1403, whether all functions are traversed.

If all the functions have been traversed, then S1404 is performed. If all the functions have not been traversed, S1401 is executed until all the functions in the program code to be protected are acquired.

S1404, obtaining a function to be protected.

Alternatively, a string matching strategy may be used to locate the function to be protected. The function to be protected may also be marked with a test key. Such as use case (a).

Use case (a):

the function test () in use case (a) implements a simple addition operation.

Alternatively, a front-end compiler may be used to generate the IR file to be protected based on the function to be protected. As in case (b).

Use case (b):

The use case (a) is converted into IR code via a front-end compiler. In the case (b), the declaration mode is only different for the function names, the character strings of the function names are not changed, the IR file compiled at the front end is read for analysis, all functions in the IR file are traversed according to the character string matching method, and after the function names contain marks, all instructions in the functions are analyzed.

Optionally, a part of functions may be screened from all functions in the program code to be protected for protection, or all functions in the program code to be protected may be protected, which is not limited in the embodiment of the present application.

S1405, determining the number of created virtual machines based on the number of functions to be protected, and determining the functions to be protected of each virtual machine. The m functions to be protected are protected through one virtual machine.

Illustratively, m may be 6, and one virtual machine may protect 6 functions to be protected. When the number of functions to be protected in the program code to be protected is more than 6, then another virtual machine needs to be created. For example, when the number of functions to be protected in the program code to be protected is 5, only one virtual machine needs to be created, and the 5 functions to be protected are deprotected by the one virtual machine. When the number of the functions to be protected in the program code to be protected is 7, two virtual machines are needed to be created, 6 functions to be protected are deprotected through the first virtual machine, and the other 1 functions to be protected are deprotected through the second virtual machine.

S1406, generating a virtual instruction of the function to be protected, and generating byte codes based on the virtual instruction.

After determining which virtual machine is used for protecting the function to be protected, loading a virtual instruction preset by the system into the virtual machine. For example, the system has 63 preset virtual instructions, and the 63 virtual instructions are loaded into each virtual machine before the virtual machine is created.

After determining the function to be protected of each virtual machine, each instruction in each function to be protected can be traversed, and a virtual instruction matched with each instruction in the function to be protected is selected from the preset 63 virtual instructions to generate the virtual instruction of each function to be protected.

Each virtual machine has a predetermined dispatcher. The number of dispatchers in different virtual machines may be the same, and the number of dispatchers in different virtual machines may also be different.

One function to be protected may generate one or more virtual instructions.

For how the pseudo-instruction generates the bytecode, reference may be made to the description in the embodiment of fig. 3, and the description of the embodiment of the present application is omitted here.

S1407, generating driving data of each function to be protected based on the byte codes corresponding to each virtual instruction in each function to be protected.

The execution logic of the function to be protected is described in the driving data. One to-be-protected function corresponds to one driving data. If there are multiple functions to be protected, there are multiple driving data.

One function to be protected corresponds to one or more virtual instructions, one virtual instruction corresponds to a plurality of byte codes, when the driving data of the function to be protected is generated, one byte code can be selected from the plurality of byte codes to be stored in the driving data of the function to be protected, and meanwhile, the operand of the function to be protected is required to be stored in the driving data. In this way, where multiple dispatchers are included within the virtual machine, it is also confirmed which dispatcher each virtual instruction is executed by.

When executing the function to be protected, the driving data of the function to be protected is called to execute the execution logic of the corresponding function to be protected.

As shown in use case (c), for a certain function to be protected, the length of the driving data is 51, and the driving data consists of byte codes and operands in 64-bit integer.

Use case (c):

@test_VMDATA＝global[51xi64][i64 5888101999,i64 1,i64 9619962993,i64 0,i64 10183069295,i64 1,i64 13914930289,i64 1,i64 5888101999,i64 1,i64 5324995697,i64 2,i64 9847072831,i64 0,i64 14664271503,i64 100,i64 10385268069,i64 13613956790,i64 1,i64 12,i64 10385268069,i64 5552105535,i64 0,i64 13437273553,i64 5324995697,i64 3,i64 5552105535,i64 1,i64 13437273553,i64 13914930289,i64 4,i64 5552105535,i64 3,i64 5552105535,i64 4,i64 8990371371,i64 13359468707,i64 79,i64 13914930289,i64 5,i64 9847072831,i64 2,i64 5552105535,i64 5,i64 6090300773,i64 5552105535,i64 2,i64 9142306257,i64 5324995697,i64 6,i64 9697336863].

S1408, counting the virtual instruction categories used in every m functions to be protected.

One virtual machine can protect m functions to be protected. When creating virtual machines, the types of virtual instructions required by m functions to be protected under each virtual machine are counted. Because the system has realized that the preset virtual instructions are 63, when each virtual machine is created, the virtual instructions needed by the m functions to be protected are selected from the preset 63 virtual instructions, and the virtual instructions needed by the m functions to be protected are loaded into the virtual machine. That is, only the virtual instructions that are used will be used to build the virtual machine. Unused virtual instructions are not used to build virtual machines.

S1409, constructing different virtual machines.

The essence of constructing different virtual machines is to construct a complicated jump execution flow in the virtual machine based on one or more virtual instructions in each function to be protected, so as to reduce the occurrence of convergence points.

The virtual machine is constructed based on the driving data generated in S1407. If one virtual machine can protect m functions to be protected, m driving data are needed to construct the virtual machine when the virtual machine is created.

Creating the virtual machine may include the steps of: counting virtual instructions to be used, creating a virtual instruction execution module, and constructing a complicated jump execution flow in the virtual machine. In particular, reference may be made to the specific description of creating the virtual machine in the foregoing embodiments, and the embodiments of the present application are not described herein again.

Use case (d):

VMDispatcher0:

preds＝％VMReturnToDisOrHandler2,％VMReturnToDisOrHandler1,％VMReturnToDisOrHandler0,％VMSelect

％130＝load i64,i64*％l_vmDataIndex

％131＝getelementptr i64,i64*％l_gvar_vmDataLocal,i64％130

％132＝load i64,i64*％131

％133＝load i64,i64*％10

％134＝sub i64％132,％133

switch i64％134,label％VMDefault

[

i64 1795333477,label％VSTOREIJ

i64 1257138239,label％VLLOAD

i64 1030028401,label％VLSTORE

i64 1593134703,label％VALLOCA_ONE

]

use case (e):

VMDispatcher1:

％143＝load i64,i64*％l_vmDataIndex

％144＝getelementptr i64,i64*％l_gvar_vmDataLocal,i64％143

％145＝load i64,i64*％144

％146＝load i64,i64*％10

％147＝sub i64％145,％146

switch i64％147,label％VMDefault

[

i64 1107402271,label％VEXIT

i64 552371665,label％VLOADJ

i64 400436779,label％VLADD

i64 1795333477,label％VSTOREIJ

i64 1257138239,label％VLLOAD

i64 1593134703,label％VALLOCA_ONE

i64 1030028401,label％VLSTORE31

]

Case (d) and user (e) are virtual instruction execution logic corresponding to case (b). In the case (b), since a plurality of alloca instructions exist, the bytecode of a plurality of virtual instructions VALLOCA _one is converted when the drive data is generated. For both dispatchers VMDISPATCHER and VMDISPATCHER1, VALLOCA _one can be scheduled for execution, so VALLOCA _one is an instruction that is commonly scheduled by both dispatchers. And the other virtual instructions without repetition are the virtual instructions independently scheduled by each dispatcher.

Use case (f):

％25＝call i64@VMInterpreter(i64*％11,i64*％12,i64*％16,i64*％17,i64*％22,i64*％18,i64 51,i64*％24,i64*getelementptr inbounds([51x i64],[51x i64]*@test_VMDATA,i64 0,i64 0)).

as shown in use case (f), there are multiple actions of entering and exiting the virtual machine after a protected test () function is summarized, and when the virtual machine is entered, use case (f) is executed.

S1410, reconstructing a primitive function.

As can be seen from S1404, the function to be protected can be marked with a test key. The function that does not use the test key label is an unprotected function. All the functions to be protected with the test key marks and the functions without using the test key marks are rewritten into a protected IR file, and then the protected IR file is delivered to the back end of the LLVM for compiling. And in the protected IR file, the virtual machine interpreter function is also written into the protected IR file, because the protected test () function needs to call the virtual machine interpreter function to execute the original logic. There are three parts in the protected IR file: protected test () function, unprotected function, and virtual machine interpreter function. The protected IR file may be switched between execution in the original environment and the virtual machine environment. When the protected test () function is executed, the protected test () function is executed in the virtual machine environment, and when the unprotected function is executed, the protected test () function is executed in the original environment.

For the function to be protected, only the more common virtual instructions in 63, such as a memory operation instruction, an arithmetic instruction, a logic operation instruction, a comparison instruction, a combination instruction of a small part of instructions and a special instruction for enriching the internal jump flow of the virtual machine, are realized in the virtualization protection. All instructions in the function to be protected may not be covered, so instructions that are not protected are encountered, may be marked with special instructions and stuffed into vmdata. When the virtual machine executes and encounters a special instruction, the virtual machine is exited and the virtual machine is executed in the original environment. The context switch between the original environment and the virtual machine environment is referred to herein.

Fig. 15 is a flow chart of a function protection method according to an embodiment of the present application.

S1501, a first function to be protected is obtained, and a first virtual instruction and a second virtual instruction are obtained based on the first function to be protected.

S1502, executing a first virtual instruction through a first dispatcher; executing, by the second dispatcher, the second virtual instruction; wherein the first dispatcher and the second dispatcher are different.

In one possible implementation, the first dispatcher is a dispatcher in the first virtual machine and the second dispatcher is a dispatcher in the first virtual machine. In this way, the same function may be protected by the same virtual machine.

In one possible implementation, the first dispatcher is a dispatcher in a first virtual machine and the second dispatcher is a dispatcher in a second virtual machine. In this way, the same function may be protected by different virtual machines. Further increasing the complex structure inside the virtual machine.

In one possible implementation manner, after the first function to be protected is acquired, the method further includes: acquiring a third virtual instruction based on the first function to be protected; after executing the first virtual instruction by the first dispatcher, the method further comprises: and calling a third virtual instruction through the first virtual instruction, and executing the third virtual instruction. In this way, the virtual instructions can be directly mutually scheduled and executed, and the cost of scheduling the virtual instructions by the dispatcher is reduced. Further increasing the complex execution structure inside the virtual machine.

In one possible implementation, the number of first virtual instructions is a plurality; executing, by the first dispatcher, a first virtual instruction, including: executing a first virtual instruction appearing for the first time in a first function to be protected through a first dispatcher; after executing the first virtual instruction by the first dispatcher, the method further comprises: executing a first virtual instruction appearing for the second time in the first function to be protected through a third dispatcher; wherein the first dispatcher and the third dispatcher are different. Thus, the same virtual instruction in the same function to be protected may appear multiple times. The same virtual instruction that appears multiple times may also be executed by different dispatchers.

In one possible implementation manner, a second function to be protected is obtained, and a fourth virtual instruction is obtained based on the second function to be protected; executing the fourth virtual instruction by the fourth dispatcher; the fourth dispatcher is a dispatcher in the first virtual machine or a dispatcher in the second virtual machine.

Thus, different functions to be protected can be protected by the same virtual machine or different virtual machines. In one possible implementation, after the first virtual instruction is obtained, before the first virtual instruction is executed by the first dispatcher, the method further includes: generating a plurality of bytecodes based on the first virtual instruction, each bytecode of the plurality of bytecodes consisting of the first virtual instruction and an identity of the dispatcher; selecting a first byte code from a plurality of byte codes, wherein the first byte code consists of a first virtual instruction and an identifier of a first dispatcher; executing, by the first dispatcher, a first virtual instruction, including: selecting a first dispatcher from a plurality of dispatchers based on an identification of the first dispatcher in the first bytecode; the first virtual instruction is executed by the first dispatcher.

In one possible implementation, the number of bytecodes corresponding to the first virtual instruction is the same as the number of dispatchers within the first virtual machine.

In one possible implementation manner, the executing, by the first dispatcher, the first virtual instruction specifically includes: calling a first virtual instruction execution module to execute a first virtual instruction through a first dispatcher; executing, by the second dispatcher, a second virtual instruction, comprising: and calling a second virtual instruction execution module to execute the second virtual instruction through the second dispatcher.

Fig. 16 is a schematic flow chart of a function protection device according to an embodiment of the present application.

In one possible implementation, the apparatus 1600 may include a bytecode generation module 1601, a drive data scheduling module 1602, a dispatcher selection module 1603, a virtual instruction scheduling module 1604, a first dispatcher 1605, a second dispatcher 1606, a third dispatcher 1607, and a fourth dispatcher 1608. The apparatus 1600 may be used to perform a function protection method as shown in the embodiment of fig. 15.

The driving data scheduling module 1602 is configured to obtain a first function to be protected, and obtain a first virtual instruction and a second virtual instruction based on the first function to be protected.

The dispatcher selection module 1603 is configured to execute the first virtual instruction via the first dispatcher 1605.

Dispatcher selection module 1603, further for executing a second virtual instruction via second dispatcher 1606;

Wherein the first dispatcher 1605 and the second dispatcher 1606 are different.

In one possible implementation, the driving data scheduling module 1602 is further configured to obtain a third virtual instruction based on the first function to be protected.

The virtual instruction scheduling module 1604 is configured to call a third virtual instruction through the first virtual instruction, and execute the third virtual instruction.

In one possible implementation, the number of first virtual instructions is a plurality; the dispatcher selection module 1603 is specifically configured to: the first virtual instruction that first appears in the first function to be protected is executed by the first dispatcher 1605.

The dispatcher selection module 1603 is further configured to execute, via the third dispatcher 1607, a first virtual instruction that appears for a second time in the first function to be protected; wherein the first dispatcher 1605 and the third dispatcher 1607 are different.

In one possible implementation, the driving data scheduling module 1602 is further configured to obtain a second function to be protected, and obtain a fourth virtual instruction based on the second function to be protected.

A dispatcher selection module 1603 for executing a fourth virtual instruction via a fourth dispatcher 1608; wherein the fourth dispatcher 1608 is a dispatcher in the first virtual machine or a dispatcher in the second virtual machine.

In one possible implementation, the bytecode generation module 1601 is configured to generate a plurality of bytecodes based on the first virtual instruction, where each of the plurality of bytecodes is composed of the first virtual instruction and an identification of the dispatcher.

The byte code generation module 1601 is further configured to select a first byte code from the plurality of byte codes, where the first byte code is composed of the first virtual instruction and an identification of the first dispatcher 1605.

A dispatcher selection module 1603, specifically for selecting a first dispatcher 1605 from a plurality of dispatchers based on the identification of the first dispatcher 1605 in the first bytecode; the first virtual instruction is executed by the first dispatcher 1605.

In one possible implementation, the dispatcher selection module 1603 is specifically configured to invoke the first virtual instruction execution module to execute the first virtual instruction via the first dispatcher 1605.

The dispatcher selection module 1603 is specifically configured to call the second virtual instruction execution module to execute the second virtual instruction through the second dispatcher 1606.

In one possible implementation, the fourth virtual instruction and the first virtual instruction are virtual instructions that execute the same logic; the dispatcher selection module 1603 is specifically configured to invoke the first virtual instruction execution module to execute the fourth virtual instruction via the fourth dispatcher 1608.

As shown in fig. 17, the apparatus includes a processor 1701 and a memory 1702. The apparatus 1700 may be used to perform a function protection method as shown in the embodiment of fig. 16.

The processor 1701 is coupled to the memory 1702, the memory 1702 for storing computer program code comprising computer instructions that the processor 1701 invokes to perform a function protection method as described above in connection with the fig. 17 embodiment.

The embodiments of the present application may be arbitrarily combined to achieve different technical effects.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions in accordance with the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Drive (SSD)), etc.

Those of ordinary skill in the art will appreciate that implementing all or part of the above-described method embodiments may be accomplished by a computer program to instruct related hardware, the program may be stored in a computer readable storage medium, and the program may include the above-described method embodiments when executed. And the aforementioned storage medium includes: ROM or random access memory RAM, magnetic or optical disk, etc.

In summary, the foregoing description is only exemplary embodiments of the present invention and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, improvement, etc. made according to the disclosure of the present invention should be included in the protection scope of the present invention.

Claims

1. A method of function protection, the method comprising:

Acquiring a first function to be protected, and acquiring a first virtual instruction and a second virtual instruction based on the first function to be protected;

executing, by a first dispatcher, the first virtual instruction;

Executing the second virtual instruction by a second dispatcher;

Wherein the first dispatcher and the second dispatcher are different.

2. The method of claim 1, wherein the first dispatcher is a dispatcher in a first virtual machine and the second dispatcher is also a dispatcher in the first virtual machine.

3. The method of claim 1, wherein the first dispatcher is a dispatcher in a first virtual machine and the second dispatcher is a dispatcher in a second virtual machine.

4. A method according to any one of claims 1-3, characterized in that after the acquisition of the first function to be protected, the method further comprises:

acquiring a third virtual instruction based on the first function to be protected;

after the executing the first virtual instruction by the first dispatcher, the method further comprises:

and calling the third virtual instruction through the first virtual instruction, and executing the third virtual instruction.

5. The method of any of claims 1-4, wherein the number of first virtual instructions is a plurality; executing the first virtual instruction through a first dispatcher, specifically including:

Executing, by the first dispatcher, the first virtual instruction that first appears in the first function to be protected;

Executing, by a third dispatcher, the first virtual instruction that appears a second time in the first function to be protected;

wherein the first dispatcher and the third dispatcher are different.

6. A method according to claim 2 or 3, characterized in that the method further comprises:

acquiring a second function to be protected, and acquiring a fourth virtual instruction based on the second function to be protected;

Executing, by a fourth dispatcher, the fourth virtual instruction;

wherein the fourth dispatcher is a dispatcher in the first virtual machine or a dispatcher in the second virtual machine.

7. The method of any of claims 1-6, wherein after the first virtual instruction is fetched, before the first virtual instruction is executed by the first dispatcher, the method further comprising:

generating a plurality of byte codes based on the first virtual instruction, each byte code of the plurality of byte codes consisting of the first virtual instruction and an identification of a dispatcher;

selecting a first bytecode from the plurality of bytecodes, the first bytecode consisting of the first virtual instruction and an identification of the first dispatcher;

the executing, by the first dispatcher, the first virtual instruction specifically includes:

Selecting the first dispatcher from a plurality of dispatchers based on an identification of the first dispatcher in the first bytecode;

Executing, by the first dispatcher, the first virtual instruction.

8. The method of claim 7, wherein the number of bytecodes corresponding to the first virtual instruction is the same as the number of dispatchers within the first virtual machine.

9. The method of claim 6, wherein the executing, by the first dispatcher, the first virtual instruction, comprises:

Invoking a first virtual instruction execution module to execute the first virtual instruction by the first dispatcher;

the executing, by the second dispatcher, the second virtual instruction specifically includes:

and calling a second virtual instruction execution module to execute the second virtual instruction through the second dispatcher.

10. The method of claim 9, wherein the fourth virtual instruction and the first virtual instruction are virtual instructions that execute logically the same; the executing, by the fourth dispatcher, the fourth virtual instruction specifically includes:

The first virtual instruction execution module is invoked by the fourth dispatcher to execute the fourth virtual instruction.

11. A function protection device, comprising a drive data scheduling module, a dispatcher selection module, a first dispatcher and a second dispatcher; wherein,

The driving data scheduling module is used for acquiring a first function to be protected, and acquiring a first virtual instruction and a second virtual instruction based on the first function to be protected;

The dispatcher selection module is used for executing the first virtual instruction through the first dispatcher;

the dispatcher selection module is further configured to execute the second virtual instruction through a second dispatcher;

Wherein the first dispatcher and the second dispatcher are different.

12. The apparatus of claim 11, wherein the first dispatcher is a dispatcher in a first virtual machine and the second dispatcher is also a dispatcher in the first virtual machine.

13. The apparatus of claim 11, wherein the first dispatcher is a dispatcher in a first virtual machine and the second dispatcher is a dispatcher in a second virtual machine.

14. The apparatus of any one of claims 11-13, wherein the apparatus further comprises a virtual instruction scheduling module;

the driving data scheduling module is further configured to obtain a third virtual instruction based on the first function to be protected;

the virtual instruction scheduling module is used for calling the third virtual instruction through the first virtual instruction and executing the third virtual instruction.

15. The apparatus of any one of claims 11-14, further comprising a third dispatcher; the number of the first virtual instructions is a plurality;

the dispatcher selecting module is specifically configured to: executing, by the first dispatcher, the first virtual instruction that first appears in the first function to be protected;

the dispatcher selecting module is further configured to execute, by the third dispatcher, the first virtual instruction that appears for the second time in the first function to be protected;

wherein the first dispatcher and the third dispatcher are different.

16. The apparatus according to claim 12 or 13, further comprising a fourth dispatcher;

the driving data scheduling module is further configured to obtain a second function to be protected, and obtain a fourth virtual instruction based on the second function to be protected;

the dispatcher selection module is further configured to execute the fourth virtual instruction through the fourth dispatcher;

17. The apparatus according to any one of claims 11-16, wherein the apparatus further comprises a byte code generation module;

The byte code generation module is used for generating a plurality of byte codes based on the first virtual instruction, and each byte code in the plurality of byte codes consists of the first virtual instruction and the identifier of the dispatcher;

the byte code generation module is further configured to select a first byte code from the plurality of byte codes, where the first byte code is composed of the first virtual instruction and an identifier of the first dispatcher;

the dispatcher selection module is specifically configured to select the first dispatcher from a plurality of dispatchers based on an identification of the first dispatcher in the first byte code;

Executing, by the first dispatcher, the first virtual instruction.

18. The apparatus of claim 17, wherein a first virtual instruction corresponds to a same number of bytecodes as the number of dispatchers in the first virtual machine.

19. A function protection device, the device comprising a processor and a memory; the memory is coupled to the processor for storing computer program code comprising computer instructions that the processor invokes to perform the method of any of the preceding claims 1-10.

20. A computer readable storage medium storing computer instructions which, when run on a computer, cause the computer to perform the method of any one of the preceding claims 1-10.

21. A computer program product, characterized in that the computer program product, when run on a computer, causes the computer to perform the method of any of the preceding claims 1-10.