CN108932406B

CN108932406B - Virtualization software protection method and device

Info

Publication number: CN108932406B
Application number: CN201710353209.XA
Authority: CN
Inventors: 阚志刚; 陈彪; 王卫民; 卢佐华; 方宁
Original assignee: Beijing Bangcle Technology Co ltd
Current assignee: Beijing Bangcle Technology Co ltd
Priority date: 2017-05-18
Filing date: 2017-05-18
Publication date: 2021-12-17
Anticipated expiration: 2037-05-18
Also published as: CN108932406A

Abstract

The application discloses a method and a device for protecting virtualized software, wherein the method comprises the following steps: converting a function of a first attribute to be protected in an original installation package of protected software into a function of a second attribute; converting, with a virtualization instruction conversion engine, a first bytecode of at least a portion of a function of the first attribute into a second bytecode in a custom format; and generating a new installation package of the protected software for execution on a virtual machine according to the function of the second attribute, the second bytecode, and a custom virtual machine interpreter; and the custom virtual machine interpreter is used for reading the second byte code when executing the new installation package and performing interpretation execution according to the semantic meaning of the second byte code. According to the scheme of the application, the safety of the protected software can be effectively guaranteed.

Description

Virtualization software protection method and device

Technical Field

The present disclosure relates generally to the field of computer technologies, and in particular, to a method and an apparatus for protecting virtualized software.

Background

The Android platform is developed by adopting Java (Java) language, the Java language is a cross-platform and interpretative language, Java source codes are compiled into intermediate codes in a byte code form, and the byte codes retain much source code information such as method names, variable names and the like, so that the decompiling of Java byte codes becomes very easy. In order to protect application copyright and the like of the Android program, the application program needs to be protected.

The traditional software code protection technology on the Android platform mainly comprises two technologies of code obfuscation and software shell adding.

Code obfuscation refers to the act of transforming the code of a program into a functionally equivalent, but difficult to read and understand, form.

Software shelling is another software protection technique that is extremely common to applications. The "shell" is a layer of code wrapped outside the program, which is executed before the protected code, executes operations such as decryption code and anti-debugging, and then transfers the execution right to the target code after completing these tasks.

Currently, software shell adding mainly comprises two generations of technologies: the first generation technology is protected based on a java class loading technology, and the second generation technology is realized by adopting a method code extraction encryption mode. The class loading technology provided by java itself is used in the first generation technology, and the executable file class. And modifying the program entry during running, decrypting the encrypted classes in the memory, and loading and executing the virtual machine. The second generation technology extracts the codes of all methods in the original APK, encrypts the codes independently, when a virtual machine needs to execute a certain method, the reinforcing engine decrypts the method and sends the decrypted codes to an execution engine of the virtual machine for execution.

However, the existing code confusion and software shell protection software code have the problem of insufficient protection, and the security of the software code needs to be further improved.

Disclosure of Invention

In view of the above-mentioned drawbacks and deficiencies of the prior art, it is desirable to provide a protection scheme that can effectively secure software code.

In a first aspect, an embodiment of the present application provides a virtualized software protection method, including:

converting a function of a first attribute to be protected in an original installation package of protected software into a function of a second attribute;

converting, with a virtualization instruction conversion engine, a first bytecode of at least a portion of a function of the first attribute into a second bytecode in a custom format; and

generating a new installation package of the protected software for execution on a virtual machine according to the function of the second attribute, the second bytecode and a custom virtual machine interpreter;

the function of the first attribute is a java function, and the function of the second attribute is a native function;

and the custom virtual machine interpreter is used for reading the second byte codes when executing a new installation package through a Java native interface JNI function and performing interpretation and execution according to the semantics of the second byte codes.

In a second aspect, an embodiment of the present application further provides a virtualized software protection device, where the device includes:

the function conversion unit is configured to convert a function of a first attribute to be protected in the original installation package of the protected software into a function of a second attribute;

a bytecode conversion unit configured to convert a first bytecode of at least a part of the function of the first attribute into a second bytecode of a custom format using a virtualization instruction conversion engine; and

and the software protection unit is configured to generate a new installation package of the protected software for executing on the virtual machine according to the function of the second attribute, the second bytecode and the custom virtual machine interpreter.

In a third aspect, embodiments of the present application further provide a computer device including one or more processors and a memory, where the memory contains instructions executable by the processors to cause the processors to execute the virtualization software protection method.

In a fourth aspect, the present application further provides a computer-readable storage medium storing a computer program, where the computer program makes a computer execute the virtualization software protection method.

In the scheme provided by the embodiment of the application, a function of a first attribute in a protected software installation package is converted into a function of a second attribute; converting, with a virtualization instruction conversion engine, a first bytecode of at least a portion of a function of the first attribute into a second bytecode in a custom format; and generating a new installation package of the protected software for execution on the virtual machine according to a function of the second attribute, the second bytecode, and a custom virtual machine interpreter. Therefore, by changing the code expression form of part of the content (such as a subfunction) of the function in the program and customizing the virtual machine interpreter, the difficulty of reverse analysis and the difficulty of code restoration are increased, so that the protected software is safer.

Drawings

Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:

FIG. 1 illustrates an exemplary flow chart of a virtualized software protection method according to an embodiment of the application;

FIG. 2 illustrates an exemplary block diagram of a virtualized software protection appliance, according to one embodiment of the present application;

FIG. 3 is a block diagram of an exemplary configuration of a virtualized software protection appliance according to another embodiment of the present application; and

FIG. 4 is a block diagram of an exemplary architecture of a software protection unit according to one embodiment of the present application;

FIG. 5 illustrates an exemplary block diagram of a computing device, according to one embodiment of the present application.

Detailed Description

The present application will be described in further detail with reference to the following drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant invention and not restrictive of the invention. It should be noted that, for convenience of description, only the portions related to the present invention are shown in the drawings.

It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The present application will be described in detail below with reference to the embodiments with reference to the attached drawings.

As mentioned in the background art, the code obfuscation and software shell protection techniques adopted in the prior art have the problem of insufficient protection. The inventor of the invention finds that code obfuscation cannot really prevent reverse engineering, but only increases the difficulty of understanding. Software shelling can effectively prevent static analysis, but dynamic analysis is difficult to prevent, because the final decrypted code is finally executed in a memory, and shelling is easy as long as a cracker can find the address of the decrypted code in the memory.

For example, the first and second generation technologies of software shell addition both need to decrypt the protected code and then send it to the execution engine of the virtual machine for execution, but the protection granularities of the two are different, and the final protected code can be backed up by intercepting the first generation in the class loading module of the virtual machine. The second generation needs to go further into the virtual machine, and the block of the virtual machine execution engine is intercepted, so that the decrypted code can be backed up. Essentially, the software shell technology of the first generation and the second generation is a hiding technology of codes, and the final codes are executed through a virtual machine. Therefore, a cracker can shell the protection scheme by constructing a virtual machine modified by the cracker.

In view of the foregoing defects in the prior art, embodiments of the present application provide a software protection scheme, in which a function of a first attribute to be protected is converted into a function of a second attribute at a first attribute level; performing randomized virtualized instruction conversion on at least one part of byte codes of the function with the first attribute to be protected, and converting the byte codes into a new byte code format; therefore, when the protected software is installed subsequently, the new bytecode converted by the virtualization instruction can be read in through the converted function of the second attribute, and the converted bytecode is interpreted and executed, so that the installation of the protected software is completed. The difficulty of reverse analysis and code restoration of protected software can be increased by changing the code expression form at a level less than a function level (for example, a subfunction level) in a program and the difficulty of cracking a custom virtual machine interpreter, so that the protected software is safer.

In the embodiment of the application, a function to be protected in an original installation package of protected software is called a function with a first attribute; and performing attribute conversion on the function to be protected in the original installation package to obtain a function called as a second attribute function. In the following description, a software protection scheme according to an embodiment of the present application will be described by taking one of the parts (e.g., one of the sub-functions) of the function of the first attribute as an example. The division or selection of the portions of the function may be based on a variety of rules. In some embodiments, when the function includes a plurality of sub-functions, the division or selection may be based on the sub-functions. In other embodiments, the functions may be arbitrarily divided or selected. It will be appreciated that the following description of one part of the function for the first attribute may be extended to other parts of the function, each of which may be translated using the same or different virtualisation instruction engine, thereby increasing protection of the software. It is noted that in some embodiments, at least two different virtualization instruction translation engines are applied when there are multiple portions of the function of the first attribute that need to be translated.

The scheme is suitable for protecting virtualization software on an Android platform, and the scheme can be described in detail by taking a java (java) function as a function of a first attribute and a native (native) function as a function of a second attribute as examples.

Of course, in practical application, the function of the first attribute is not limited to java function; the function of the second attribute is not limited to a native function.

An APK (Android Package) is an executable program on an Android platform, and mainly includes the following files: dex, a dynamic library file so file, Android manifest xml, other resource files (e.g., pictures, xml, etc.).

Dex stores byte codes of compiled java source codes of all protected software. On an Android platform, Java source codes are compiled into class files (standard Java byte codes) through a Java compiler, and then a plurality of class files are converted into a dex file by using a tool dx provided by the Android.

The Dex file mainly consists of several parts, a Header (Dex Header), various tables (Table), and a Data Section (Data Section). The header contains the size and offset information of each region; the various tables contain various data, such as character string tables, class name tables, function tables and the like, and the byte codes are coded by the indexes of the tables; the data segment includes information such as byte codes.

For example: the following sentence

“100b64:1a01 9408|0002:const-string v1,"Hello world"//string@0894”

Where 1a 019408 is the true Raw bytecode, 1a indicates the operand opcode indicates const-string, 01 indicates register v1, and 9408 indicates the 894 th entry in the string table.

And besides the Java platform, the Android platform also allows mixed programming by using C/C + + language. And a JNI (Java native interface, Java native local interface) is also provided. The JNI interface provides a series of interfaces that allow objects in Java language to be manipulated from C/C + + language, such as setting a Field (Field) of a Java object, calling a function (method) in Java, etc. The source code written in C/C + + is compiled into a dynamic base so file through an Android NDK (Native Development Kit).

Based on the foregoing, the method of the embodiment of the present application will be described below with reference to the flowchart.

FIG. 1 illustrates an exemplary flow diagram of a virtualized software protection method according to an embodiment of the application.

As shown in fig. 1, the virtualized software protection method according to the embodiment of the present application includes the following steps:

step 110, converting the function of the first attribute to be protected in the original installation package of the protected software into the function of the second attribute.

Step 120, utilizing the virtualization instruction conversion engine to convert the first bytecode of at least a part of the function of the first attribute into a second bytecode of a custom format.

And step 130, generating a new installation package of the protected software for executing on the virtual machine according to the function of the second attribute, the second bytecode and the custom virtual machine interpreter.

Specifically, in step 130, the first bytecode converted from the function with the first attribute in the function with the second attribute may be deleted, and the second bytecode is stored in the function with the second attribute, so as to generate a new executable file; compiling the self-defined virtual machine interpreter and a function containing a second attribute of a second byte code to generate a new dynamic library file; and generating a new installation package of the protected software for execution on the virtual machine based on the new executable program file and the dynamic library file.

And the custom virtual machine interpreter is used for reading the second byte code when executing the new installation package and performing interpretation execution according to the semantic meaning of the second byte code. In practical application, the custom virtual machine interpreter is usually constructed by adopting a standard JNI function, the JNI function is a standard specification of Java, and the Android virtual machine can realize the function interface no matter how the Dalvik virtual machine or the ART virtual machine is realized, so that the custom virtual machine interpreter is independent of how the specific virtual machine is realized and has backward compatibility.

In the embodiment of the application, all functions in the original installation package APK of the protected software can be scanned in advance, and a function (which may be called a demo function) needing protection is determined from the functions; acquiring a function source code of a first attribute of the demo function; and compiling the function source code of the first attribute to generate a corresponding byte code. The bytecode generated by compiling the function source code of the first attribute may be referred to as a first bytecode. As mentioned above, the part of the function of the first attribute that needs to be subjected to the bytecode conversion may be selected or divided based on the sub-functions, or may be arbitrarily selected or divided. The selection or division may be performed for source code or for compiled bytecode. In the scheme provided by the embodiment of the application, a user can flexibly select certain key function parts to perform virtualization protection, so that the balance between performance and safety is conveniently achieved.

Take the case that the function of the first attribute is java function and the function of the second attribute is native function. In step 110, for a function to be protected in the original APK of the protected software, the attribute of the function may be modified to native, and the corresponding native function is obtained through conversion.

Next, the first bytecode of the portion to be converted can be extracted from the original executable file classes.

In step 120, the first bytecode extracted may be converted into a new and customized bytecode format by performing instruction mapping using a virtualized instruction conversion engine. The bytecode obtained by converting the first bytecode into the custom bytecode format is referred to as a second bytecode herein. It is to be understood that "second bytecode" herein refers to the converted bytecode only in a general way to describe it differently from the bytecode before conversion, and different portions of the function have different second bytecode.

In practical application, the virtualized instruction conversion engine may generate a mapping table of opcode (operand) randomly, and then map the original first bytecode according to the mapping table to generate a new second bytecode in a custom format.

As mentioned previously, embodiments of the present application may perform transformations based on a portion of a function. When the function comprises a plurality of parts to be converted, at least two different virtualization instruction conversion engines are used, and the safety of software protection is further improved.

For example, assuming that there are 3 parts of the a function of the first attribute that need to be converted, in one embodiment, 2 different virtualization instruction conversion engines may be used, specifically, any 2 parts of the a function of the first attribute are converted by one virtualization instruction conversion engine, and the other 1 part is converted by another virtualization instruction conversion engine; in another embodiment, 3 different virtualization instruction transformation engines may be used to separately transform 3 portions of the A-function for the first attribute.

In step 130, the converted first bytecode of the java function in the native function obtained through the conversion in step 110 may be deleted, and the second bytecode obtained through the conversion in step 120 may be stored in the native function, so as to generate a new executable file.

In practical applications, the operation of deleting the converted first bytecode in the native function may be executed while the native function is obtained through conversion in step 110.

And finally, compiling the self-defined virtual machine interpreter and the native function containing the second byte codes to generate a dynamic library file. The main work of the custom virtual machine interpreter is to read the custom second bytecode and then interpret and execute according to the semantics of the second bytecode. Specifically, a custom virtual machine interpreter and a native function containing a second bytecode can be compiled by adopting an NDK (named data link) of an Android platform to generate a new dynamic library so file.

Then, a new installation package of the protected software for execution on the virtual machine is generated from the new executable program file and the dynamic library file. Specifically, the generated new executable program file can replace the executable file in the original APK; and inserting the new dynamic library file into the original APK to obtain the final protected new APK.

In practical applications, in order to subsequently execute a new installation package of the protected software on the virtual machine, in the embodiment of the present application, a function having a second attribute of the second bytecode may be further registered in the virtual machine; reading the new installation package by using the virtual machine; and executing the second bytecode via the custom virtual machine interpreter.

It is contemplated that the bytecode of the virtual machine is a register-based instruction set. Therefore, the custom virtual machine interpreter also needs to configure a register array that allocates a section of memory for runtime use. Wherein the register array may be constructed with reference to a maximum number of registers required by the virtual machine for each method indicated by the method.

In the embodiment of the application, in order to execute the second bytecode, the custom virtual machine interpreter allocates a memory as a register array required by the operation; pointing a computer PC pointer to a first address of a coding buffer area codebuf; and entering an infinite loop, analyzing the opcode (operand) of each instruction in the second byte code in the loop, then executing the semantic meaning of the opcode, reading the next instruction in the codebuf after the execution is finished, and assigning the next instruction to the PC; if there are no instructions, the infinite loop is exited.

Take the case that the function of the first attribute is java function and the function of the second attribute is native function. After the second bytecode is saved in the native function, the native function including the second bytecode may be registered in the virtual machine. In the registration process, a registration relation is established between the function of the C/C + + level and the java function. Thus, when the java function of the protected software is called, the virtual machine actually calls the function at the C/C + + level. Specifically, a virtual machine is used for reading a new installation package of protected software; and executing the second bytecode by the custom virtual machine interpreter to complete the native function realization of the protected software.

In practical applications, the key of the custom virtual machine interpreter in executing the second bytecode is how to implement the semantics of each opcode.

The bytecode of the Android platform can be divided into two types: 1) basic operations that do not involve Java semantics; 2) operations involving Java semantics.

Operations that do not involve java semantics include at least one of:

arithmetic operation, register assignment operation, conditional jump, return operation.

The operation related to the java semantics comprises at least one of the following:

the method comprises the following steps of generating an object, reading an object domain, generating an array, reading and writing, calling a function, locking and exception handling.

In this embodiment of the application, if an instruction of an operation that does not relate to java semantics exists in the second bytecode, the custom virtual machine interpreter may execute the operation corresponding to the instruction on the register.

If an instruction related to the operation of java semantics exists in the second byte code, the custom virtual machine interpreter can execute the operation corresponding to the instruction through the calling of the JNI function.

Further, considering that a large number of temporary Java objects (j objects) are generated during the execution of the custom virtual machine interpreter, in the specification of the Android JNI, a native function can only refer to 512 Java objects at most, and if the number of Java objects exceeds 512, a "JNI ERROR (app bug): local reference table overflow (max ═ 512)" ERROR is reported, so that the custom virtual machine interpreter needs to handle such a situation.

Since the JNI interface provides Delete Local Ref to manually Delete references that no longer use the jobject. Therefore, in the embodiment of the present application, this situation can be handled in a manner similar to garbage collection. The idea is that during the execution of the custom virtual machine interpreter, if a jobject is not in the current register array, it can be safely deleted. Specifically, whether the referenced java object exceeds a set threshold value is detected; if yes, calling to Delete java objects which do not exist in the Local reference Delete Local Ref function Delete register array.

It should be noted that while the operations of the method of the present invention are depicted in the drawings in a particular order, this does not require or imply that the operations must be performed in this particular order, or that all of the illustrated operations must be performed, to achieve desirable results. Rather, the steps depicted in the flowcharts may change the order of execution. For example, step 110 and step 120 in embodiment 1 may be performed in an alternating order or simultaneously. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions. For example, the step 130 may be decomposed, and the execution order of the decomposed steps and the

steps

110 and 120 may be adaptively adjusted.

As can be seen from the above description, in some embodiments of the present application, a protection scheme based on a smaller level than a function and a translation of the bytecode representation is proposed for the protection problem of the protected software. The bytecode of the protected software is converted into a custom bytecode format, and for a cracker, even if the content of the custom bytecode is taken in a memory, the cracker needs to analyze and understand the custom bytecode format, so that the cracker needs to spend a lot of time reversely customizing the virtual machine interpretation engine. And virtualization protection based on conversion at a level (e.g., sub-function level) smaller than that of the function can construct a plurality of sets of different virtualized interpretation engines, and different function parts or sub-functions adopt different custom bytecodes, so that the security can be further improved.

The following will illustrate how the custom virtual machine interpreter implements the semantics of different opcodes.

One, basic operation not involving java semantics

1) Basic arithmetic operations

Since such operations include addition, subtraction, multiplication, division, shift operations, forced conversion operations, and the like. The basic processing mode is to analyze parameters in the instruction to obtain which registers are operated on, and then to execute corresponding operations on the registers.

For example, implementation of add-int vAA, vBB, vCC

Semantics: register [ vAA ] ═ Register [ vBB ] + Register [ vCC ]

The realization is as follows:

if OPcode is add-int:

1. acquiring a register number from vBB and vCC;

2. corresponding values are taken out from the register array according to the register numbers and are assigned to temporary variables vsrc1 and vsrc 2;

3. the temporary variable vdst is equal to the value of vsrc1+ vsrc 2;

4. obtaining vAA the register number;

5. the value in the Register array represented by the Register number vAA is set to vdst (Register vAA ═ vdst,

one instruction is fetched [ PC + length of current instruction ].

2) Basic register assignment operation

Such operations are mainly instructions prefixed with move, and the basic semantics are from assigning the value of one register to another register.

For example: move vA, vB

Semantics: register [ vA ] ═ Register [ vB ]

The realization is as follows:

if OPcode is mov:

1. acquiring register numbers from vA and vB;

2. according to the Register number vB, corresponding values are taken out from the Register array, and the corresponding values are assigned to a temporary variable vsrc (vsrc is Register [ vB ]);

3. the value in the Register array represented by the vA Register number is set to vsrc (Register [ vAA ] ═ vsrc),

one instruction is fetched [ PC + length of current instruction ].

3) Conditional jumps

This class of instructions is primarily those prefixed by IF, the main difference being that the PC value is modified IF the condition is satisfied, equal to the current PC + offset (e.g., the CCCC value below).

For example: IF-EQ vA, vB + CCCC

Semantics: IF Register [ vA ] ═ Register [ vB ] then PC ═ PC +0xCCCC else PC + current instruction length

The realization is as follows:

IF OPcode is IF-EQ:

1. acquiring register numbers from vA and vB;

2. corresponding values are taken out from the register array according to the register number vB and are assigned to temporary variables vsrc1 and vsrc 2;

3. if vsrc1 ═ vsrc2, PC ═ PC +0xCCCC,

otherwise PC equals PC + length of current instruction.

4) Return operation

This class of instructions is primarily those prefixed with RETURN, and the main task is to set the RETURN value and then RETURN it from the interpreter.

For example: return vAA

Semantics: set the return value to Register [ vAA ], and then return from the interpreter

The realization is as follows:

if OPcode is return:

1. retrieve the register number from vAA;

2. extracting a corresponding value from the register array according to the register number vAA, and assigning the value to a temporary variable vsrc;

3. a return value result is set and returned from the interpreter.

Second, basic operations involving java semantics

1) Object and array generation operations

The operation generates a new Java object or Java array, which has two instructions, new-instance and new-array.

The core of the new instance instruction implementation is to use the AllocObject function of JNI to generate new Java objects.

The core of the New-Array instruction implementation is to use different New [ type ] arrays to generate objects of corresponding types according to the parameters of the instruction, for example: NewObjectArray is used if the parameter is an object, NewBooleanArray is used if the parameter is bootean, etc.

For example: new-instance vAA, class @ BBBB

Semantics: a new object is generated with Class offset 0xBBBB in the Class Table, and the generated new object is assigned to Register [ vAA ]

The realization is as follows:

if OPcode is new-instance:

1. inquiring the offset of the Class Table to be 0xBBBB to obtain the name of the Class;

2. calling env- > FindClass (name of class) to obtain jclass clazz;

3. calling env- > AllocObject (clazz) to generate a new Java object jobject obj

4. Assigning the value of obj to Register [ vAA ];

PC-PC + length of current instruction.

2) Read operation of object domain

Such instructions are read and write operations to a domain within an object, including: iget/iput, sget/sput.

The iget/iput is a read operation on a non-static Field in an object, and this type of instruction is implemented using a JNI function Get [ type ] Field series of functions.

sget/sput is a read operation on a static Field in an object, and this type of instruction is implemented using the JNI function GetStatic [ type ] Field series of functions.

For example: iget-object vA, vB, field @ CCCC

Semantics: searching the Field Table according to 0xCCCC, extracting the Field in the object Register [ vB ], and assigning the Field to the Register [ vA ]

The realization is as follows:

if OPcode is iget-object:

1. inquiring the offset of the Field Table to be 0xBBBB to obtain the information (class name, domain name and the like) of the Field;

2. calling env- > FindClass (Field- > calalsame) to obtain jclass clazz;

3. calling env- > GetFieldID (clazz, Field- > fieldname, Field- > type) new jfield ID Field id;

4.Register[vA]＝env->GetObjectField(Register[vB],fielded)；

PC-PC + length of current instruction.

3) Array read-write operation

Such instructions read and write to an element in the array, including: the AGET/APUT series of instructions is implemented by using a series of functions such as JNI's Get [ Type ] ArrayElements.

For example: agent-object vAA, vBB, vCC

Semantics: the vCC th element in the array of Register [ vBB ] was assigned to Register [ vAA ]

The realization is as follows:

if OPcode is agent-object:

1. call env- > GetObjectArrayElement (Register [ vBB ],

register [ vCC ]) to obtain the vCC th element in the array of Register [ vBB ], and assigning a temporary variable vsrc;

2. setting the value of Register [ vAA ] to vsrc;

PC-PC + length of current instruction.

4) Function call operations

The operation mainly calls a function at the Java level to call, and comprises the following steps:

the invoke-static series of instructions call Java static functions, implemented using the CallStatic [ type ] Method series of functions in the JNI interface.

The instruction of invoke-virtual, invoke-interface series calls Java member functions, interfaces, etc., and is implemented by using Call [ type ] method series functions in JNI interfaces.

The invoke-super and invoke-direct series of instructions call Java parent class, private function, etc., and are implemented using the CallNonvirtual [ type ] Method series of functions in the JNI interface.

For example: invoke-virtual vB, { vD, vE, vF, vG, vA }, meth @ CCCC

Semantics: calling a function with the offset of 0xCCC in the Method Table, wherein the parameters are vB, { vD, vE, vF, vG, vA }

The realization is as follows:

if OPcode is invoke-virtual:

1. inquiring the position where the offset of the Method Table is 0xCCC to obtain the information (class name, function name, etc.) of the Method;

2. calling env- > FindClass (Method- > calalsame) to obtain jclass clazz;

3. calling env- > GetMethodedID (clazz, Method- > methodname, Method- > methodtypee) new jMethodedID Method;

4. judging a return value according to the Method- > Method, calling different env- > Call [ type ] methods (Method, vB, { vD, vE, vF, vG, vA }), and setting a function return value. If method returns an object, call

result.l＝env->CallObjectMethod(method,vB,{vD,vE,vF,vG,vA})；

PC-PC + length of current instruction.

5) Operation of locks

This class of instructions has mainly two Monitor-enter (entering critical section) and Monitor-exit (exiting critical section). The JNI function env- > MonitorEnter and env- > MoniterExit are adopted for realization.

6) Operation of exception handling

Java supports exception handling, such instructions include move-exception, Throw and the like, and can be realized by adopting functions of JNI such as env- > ExceptionClear, env- > ExceptionOccurred, env- > ThrowNew, env- > Throw and the like.

With further reference to fig. 2, an exemplary structural block diagram of a virtualized software protection appliance according to an embodiment of the application is shown.

As shown in fig. 2, the virtualization software protection device may include: a function conversion unit 201, a bytecode conversion unit 202, and a software protection unit 203.

The function transformation unit 201 is configured to transform a function of a first attribute to be protected in the protected software original installation package into a function of a second attribute.

The bytecode conversion unit 202 is configured to convert a first bytecode of at least a part of the function of the first attribute into a second bytecode of a custom format using the virtualization instruction conversion engine.

The software protection unit 203 is configured to generate a new installation package of the protected software for execution on the virtual machine according to the function of the second attribute, the second bytecode, and the custom virtual machine interpreter.

In some embodiments, the bytecode conversion unit 202 may be further configured to: selecting first byte codes of at least two parts in the function with the first attribute; and converting the at least two portions of the first bytecode into corresponding second bytecode using at least two different virtualization instruction conversion engines.

Preferably, fig. 3 shows an exemplary block diagram of a virtualized software protection device according to another embodiment of the present application.

As shown in fig. 3, the virtualization software protection device may include: the function conversion unit 301, the bytecode conversion unit 302, and the software protection unit 303 may further include: function registration unit 304, installation package execution unit 305.

The function transformation unit 301 is configured to transform a function of a first attribute to be protected in the original installation package of the protected software into a function of a second attribute.

The bytecode conversion unit 302 is configured to convert a first bytecode of at least a portion of a function of the first attribute into a second bytecode in a custom format using the virtualization instruction conversion engine.

The software protection unit 303 is configured to generate a new installation package for the protected software for execution on the virtual machine based on the function of the second attribute, the second bytecode, and the custom virtual machine interpreter.

The function registration unit 304 is configured to register a function containing a second attribute of the second bytecode into the virtual machine.

The installation package execution unit 305 is configured to read the new installation package using the virtual machine; the second bytecode is executed via the custom virtual machine interpreter.

Fig. 4 shows an exemplary block diagram of a software protection unit according to an embodiment of the present application.

As shown in fig. 4, the software protection unit may include: an executable file generation subunit 401, a dynamic library file generation subunit 402, and a protection installation package generation subunit 403.

The executable file generation subunit 401 is configured to delete the converted first bytecode of the function with the first attribute in the function with the second attribute, store the second bytecode in the function with the second attribute, and generate a new executable file.

The dynamic library file generation subunit 402 is configured to compile a function of the custom virtual machine interpreter and the second attribute including the second bytecode to generate a new dynamic library file.

The protected installation package generation subunit 403 is configured to generate a new installation package of the protected software for execution on the virtual machine, based on the new executable program file and the dynamic library file.

It should be understood that the units described in the virtualized software protection device shown in fig. 2 and fig. 3, and the sub-units described in the software protection unit shown in fig. 4 may refer to the steps and specific implementations of the method described in fig. 1, and are not described herein again.

Further, embodiments of the present application also provide a computing device, including one or more processors and a memory; wherein the memory contains instructions executable by the processor to cause the processor to perform the virtualized software protection method provided by the embodiment shown in figure 1.

Referring now to FIG. 5, shown is a schematic diagram of a computing device suitable for use in implementing embodiments of the present application.

As shown in fig. 5, the computing device 500 includes a Central Processing Unit (CPU)501 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)502 or a program loaded from a storage section 508 into a Random Access Memory (RAM) 503. In the RAM 503, various programs and data necessary for system operation are also stored. The CPU 501, the ROM 502, and the 5AM 703 are connected to each other by a bus 504. An input/output (I/O) interface 505 is also connected to bus 504.

The following components are connected to the I/O interface 505: an input portion 506 including a keyboard, a mouse, and the like; an output portion 507 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 508 including a hard disk and the like; and a communication section 509 including a network interface card such as a LAN card, a modem, or the like. The communication section 509 performs communication processing via a network such as the internet. The driver 510 is also connected to the I/O interface 505 as necessary. A removable medium 511 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 510 as necessary, so that a computer program read out therefrom is mounted into the storage section 508 as necessary.

In particular, the process described above with reference to fig. 1 may be implemented as a computer software program, according to an embodiment of the present disclosure. For example, embodiments of the present disclosure include a computer-readable storage medium storing a computer program that causes a computer to perform the virtualized software protection method provided by the embodiment shown in fig. 1. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 509, and/or installed from the removable medium 511.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units or modules described in the embodiments of the present application may be implemented by software or hardware. The described units or modules may also be provided in a processor. The names of these units or modules do not in some cases constitute a limitation of the unit or module itself.

As another aspect, the computer-readable storage medium storing the computer program provided by the present application may be the computer-readable storage medium included in the system in the above-described embodiment; or it may be a separate computer readable storage medium not incorporated into the device. The computer readable storage medium stores one or more programs for use by one or more processors in performing the formula input methods described herein.

The above description is only a preferred embodiment of the application and is illustrative of the principles of the technology employed. It will be appreciated by a person skilled in the art that the scope of the invention as referred to in the present application is not limited to the embodiments with a specific combination of the above-mentioned features, but also covers other embodiments with any combination of the above-mentioned features or their equivalents without departing from the inventive concept. For example, the above features may be replaced with (but not limited to) features having similar functions disclosed in the present application.

Claims

1. A virtualization software protection method, comprising:

converting a function of a first attribute to be protected in an original installation package of protected software into a function of a second attribute; converting, with a virtualization instruction conversion engine, a first bytecode of at least a portion of a function of the first attribute into a second bytecode in a custom format; and

the custom virtual machine interpreter is used for reading the second byte codes when executing a new installation package through a Java native interface JNI function and performing interpretation execution according to the semantics of the second byte codes;

generating, by the function according to the second attribute, the second bytecode, and a custom virtual machine interpreter, a new installation package of the protected software for execution on a virtual machine, including:

deleting the converted first bytecode of the function of the first attribute in the function of the second attribute, storing the second bytecode in the function of the second attribute, and generating a new executable file;

compiling the self-defined virtual machine interpreter and a function containing a second attribute of a second byte code to generate a new dynamic library file; and

and generating a new installation package of the protected software for executing on the virtual machine according to the new executable program file and the dynamic library file.

2. The protection method according to claim 1, further comprising:

registering a function containing a second attribute of a second bytecode into the virtual machine;

reading the new installation package by using the virtual machine; and

executing the second bytecode via the custom virtual machine interpreter.

3. The protection method of claim 2, wherein said executing, via the custom virtual machine interpreter, a second bytecode comprises:

allocating a memory as a register array required by operation;

pointing a computer PC pointer to a first address of a coding buffer area codebuf; and

entering an infinite loop, analyzing the operand opcode of each instruction in the second byte code in the loop, then executing the semantic meaning of the opcode, reading the next instruction in the codebuf after the execution is finished, and assigning the next instruction to a PC (personal computer); if there are no instructions, the infinite loop is exited.

4. The protection method according to claim 3,

when an instruction of an operation that does not relate to java semantics is present in the second bytecode,

the user-defined virtual machine interpreter executes the operation corresponding to the instruction on the register;

wherein the operation not related to the java semantics comprises at least one of the following:

5. The protection method according to claim 3,

when an instruction of an operation involving java semantics is present in the second bytecode,

the custom virtual machine interpreter executes the operation corresponding to the instruction through the calling of a Java native interface JNI function;

wherein the operation involving java semantics comprises at least one of:

6. The protection method of claim 5, wherein the executing the second bytecode via the custom virtual machine interpreter further comprises:

detecting whether the referenced java object exceeds a set threshold;

if yes, calling and deleting java objects which do not exist in the local reference Delete LocalRef function deletion register array.

7. The protection method according to any one of claims 1 to 6, wherein converting a first bytecode of at least a part of the function of the first attribute into a second bytecode of a custom format using a virtualization instruction conversion engine includes:

selecting first byte codes of at least two parts in the function of the first attribute; and

converting the at least two portions of the first bytecode to corresponding second bytecode using at least two different virtualization instruction conversion engines.

8. Protection method in accordance with claim 7 characterized in that the first bytecode of at least two parts of the function of the first property is chosen on the basis of sub-functions included in the function of the first property.

9. A virtualized software protection apparatus, the apparatus comprising:

the software protection unit is configured to generate a new installation package of the protected software for executing on the virtual machine according to a function of a second attribute, the second bytecode and a custom virtual machine interpreter;

the software protection unit includes:

an executable file generation subunit, configured to delete the converted first bytecode of the function of the first attribute in the function of the second attribute, store the second bytecode in the function of the second attribute, and generate a new executable file;

the dynamic library file generation subunit is configured to compile a user-defined virtual machine interpreter and a function of a second attribute containing a second bytecode to generate a new dynamic library file; and

and the protection installation package generating subunit is configured to generate a new installation package of the protected software for executing on the virtual machine according to the new executable program file and the dynamic library file.

10. The protection device of claim 9, further comprising:

a function registration unit configured to register a function containing the second attribute of the second bytecode into the virtual machine;

an installation package running unit configured to read the new installation package using the virtual machine; executing the second bytecode via the custom virtual machine interpreter.

11. The protection device according to any one of claims 9-10, wherein the bytecode conversion unit is further configured to:

12. A computer device comprising one or more processors and memory, characterized in that:

the memory contains instructions executable by the processor to cause the processor to perform the method of any of claims 1-8.

13. A computer-readable storage medium having stored thereon a computer program, the computer program causing a computer to perform the method of any one of claims 1 to 8.