CN110673929A - Method for protecting abnormal mechanism, intelligent terminal and storage medium - Google Patents
Method for protecting abnormal mechanism, intelligent terminal and storage medium Download PDFInfo
- Publication number
- CN110673929A CN110673929A CN201910934611.6A CN201910934611A CN110673929A CN 110673929 A CN110673929 A CN 110673929A CN 201910934611 A CN201910934611 A CN 201910934611A CN 110673929 A CN110673929 A CN 110673929A
- Authority
- CN
- China
- Prior art keywords
- exception
- function
- virtual
- instruction
- interpreter
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45587—Isolation or security of virtual machine instances
Abstract
The invention provides a method for protecting an abnormal mechanism, an intelligent terminal and a storage medium, wherein the method comprises the following steps: acquiring a source function to be subjected to virtualization protection in a source file through a compiler, generating a first IR instruction, and translating an instruction which represents an exception in the first IR instruction into a group of virtual exception instructions; and the compiler generates a second IR instruction to replace the first IR instruction to form an interpreter entrance function, and the interpreter entrance function calls an interpreter to interpret and execute the group of virtual abnormal instructions. According to the invention, the compiler can translate the exception in the source function to be virtualized and protected into the virtual exception instruction, and then the interpreter is called to interpret and execute the virtual exception instruction, so that the code representing the exception in the source function to be virtualized and protected is protected.
Description
Technical Field
The present invention relates to the field of information security technologies, and in particular, to a method for protecting an exception mechanism, an intelligent terminal, and a storage medium.
Background
The virtual machine protection technology is a new software protection technology in the field of information security, and the protection principle is as follows: defining a set of instruction set in the virtual machine, translating the source code of the function to be protected into virtual byte codes which can not be identified by both a machine and a human, and interpreting and executing the virtual byte codes by using an interpreter in the virtual machine when a program runs.
The existing virtual machine protection technology cannot protect all source codes, for example, C + + is taken as an example, when C + + source codes are translated into virtual bytecode, codes related to exceptions in the C + + source codes are avoided, and codes related to exceptions cannot be translated into virtual bytecode, so that codes related to exceptions in the C + + source codes cannot be protected.
Therefore, the prior art has defects and needs to be improved and developed.
Disclosure of Invention
The present invention provides a method for protecting an exception mechanism, an intelligent terminal, and a storage medium, which are used to solve the above-mentioned drawbacks of the prior art, and aims to solve the problem that codes related to an exception in codes of an original function cannot be protected when the original function is protected by using a virtual machine protection technology in the prior art.
The technical scheme adopted by the invention for solving the technical problem is as follows:
a method of protecting an exception mechanism, comprising:
acquiring a source function to be subjected to virtualization protection in a source file through a compiler, generating a first IR instruction, and translating an instruction which represents an exception in the first IR instruction into a group of virtual exception instructions;
and the compiler generates a second IR instruction to replace the first IR instruction to form an interpreter entrance function, and the interpreter entrance function calls an interpreter to interpret and execute the group of virtual abnormal instructions.
Further, the method includes the steps of obtaining a source function to be subjected to virtualization protection in a source file through a compiler, generating a first IR instruction, and generating a first IR file corresponding to the first IR instruction, where the first IR file includes: a function to be protected, a non-protected function, a packing function, an abnormal type table and a packing function table; and a wrapping function is stored in the wrapping function table and used for calling a local function.
Further, while translating the instruction representing the exception in the first IR instruction into a set of virtual exception instructions, the first IR file is translated into a second IR file, the second IR file comprising: the method comprises the following steps of (1) obtaining an abnormal type table, a packing function table, a merging table of a virtual abnormal table, an index table of the virtual abnormal table and a virtual byte code table; the virtual byte code table stores virtual byte codes, and the virtual byte codes comprise a plurality of virtual abnormal instructions; a plurality of virtual exception tables are stored in the combination table of the virtual exception table.
Further, the compiler generates a second IR instruction to replace the first IR instruction, and forms an interpreter entry function, where the interpreter entry function calls an interpreter to interpret and execute the set of virtual exception instructions specifically includes:
the compiler generates a second IR instruction to replace the first IR instruction to form an interpreter entry function, the second IR instruction calls an interpreter to execute the group of virtual abnormal instructions one by one, the group of virtual abnormal instructions comprises a plurality of virtual abnormal instructions, and the interpreter calls the local function;
when the local function throws an exception, the interpreter captures the exception and executes the virtual bytecode processed by the exception.
Further, when the local function throws an exception, the interpreter captures the exception, and the virtual bytecode for executing the exception processing specifically includes:
when the local function throws an exception, the interpreter captures the exception;
checking whether the current protected function has a virtual abnormal table or not through an index table of the virtual abnormal table, and if the current protected function does not have the virtual abnormal table, the interpreter throws the abnormality again; if the virtual abnormal table exists, acquiring the virtual abnormal table of the current protected function;
checking a virtual exception table of the current protected function, and throwing the exception again when the current protected function cannot capture the exception;
when the current protected function can capture the exception, a vpc is set, the vpc is controlled to point to the virtual bytecode of exception handling to be executed after the exception is captured, and an interpreter interprets the virtual bytecode of exception handling.
Further, said re-throwing said exception comprises, after: up the chain of function calls, the interpreter continues to capture the exception.
Further, the compiler generates a second IR instruction to replace the first IR instruction, and forms an interpreter entry function, where the interpreter entry function calls an interpreter to perform interpreted execution on the set of virtual exception instructions, and the method further includes:
and converting the second IR file into a binary target file, calling a linker, and linking the binary target file with the interpreter to form a binary executable file.
Further, the source function is a C + + function.
The invention also includes an intelligent terminal, which includes a processor and a memory connected to the processor, where the memory stores a program of a method for protecting an exception mechanism, and the program of the method for protecting an exception mechanism can implement the method for protecting an exception mechanism as described above when executed by the processor.
The present invention also includes a storage medium storing a program for protecting an exception mechanism, the program being executable to implement the method for protecting an exception mechanism as described above.
The invention provides a method for protecting an abnormal mechanism, an intelligent terminal and a storage medium, wherein the method comprises the following steps: acquiring a source function to be subjected to virtualization protection in a source file through a compiler, generating a first IR instruction, and translating an instruction which represents an exception in the first IR instruction into a group of virtual exception instructions; and the compiler generates a second IR instruction to replace the first IR instruction to form an interpreter entrance function, and the interpreter entrance function calls an interpreter to interpret and execute the group of virtual abnormal instructions. According to the invention, the compiler can translate the exception in the source function to be virtualized and protected into the virtual exception instruction, and then the interpreter is called to interpret and execute the virtual exception instruction, so that the code representing the exception in the source function to be virtualized and protected is protected.
Drawings
FIG. 1 is a flow chart of a preferred embodiment of a method of protecting an exception mechanism in the present invention.
FIG. 2 is a block diagram of a virtual exception table in the preferred embodiment of the method of protecting an exception mechanism in the present invention.
FIG. 3 is a flowchart illustrating the correspondence between ExceptionTableIndexAlrray and MET in the preferred embodiment of the method for protecting an exception mechanism of the present invention.
FIG. 4 is a schematic diagram of the interpreter of the virtual exception table in handling exceptions in the preferred embodiment of the method of protecting the exception mechanism of the present invention.
FIG. 5 is a schematic diagram of a call sitetable portion of a virtual exception table in the preferred embodiment of the method of the present invention for protecting an exception mechanism.
Fig. 6 is a functional schematic diagram of a preferred embodiment of the intelligent terminal of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention clearer and clearer, the present invention is further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
The content in the invention is all exemplified by C + +, and it can be understood that the technical scheme adopted by the invention is not limited to the field of C + +, and can also be applied to the fields related to programming language programs such as C or JAVA.
The technical scheme adopted by the invention for solving the technical problem is as follows:
specifically, in the existing virtualization protection technology, a protected function is identified by a developer through virtualization protection, and the execution mode is as follows: the developer adds a virtualization protection identifier behind a function prototype to be protected, so that protected functions to be virtualized in a source file (a file storing the protected functions) can be extracted.
Further, a developer uses a customized LLVM compiler to compile (the customized LLVM compiler is the compiler described in the present invention, and is hereinafter referred to as a compiler), compiles the source file through preset compilation options, and translates the protected function into a bytecode during the compilation process, so as to implement virtualization processing of the protected function in the source file. The preset compiling option can be-mllvm-ivmp, and necessary preset parameters need to be added when the compiler compiles so as to facilitate the compiler to further perform virtualization processing on the source code to be subjected to virtualization protection on the LLVM IR layer. It can be understood that the preset parameters in the present invention are self-defined by the developer, and the developer can define the preset parameters by himself according to the needs.
The technical scheme provided by the invention supports virtualization of C + + abnormal codes, and the virtual instruction capable of representing virtualization of the abnormal codes is a virtual abnormal instruction. It can be understood that: to support virtualization of exception code, some new instructions need to be added to the existing virtual instruction set. In virtualization, the compiler translates IR instructions into virtual instructions at the IR layer. For normal IR instructions, translation may be into a set of existing virtual instructions. For IR instructions that indicate an exception, the instruction may be translated as a new instruction or a new instruction plus several original instructions. For convenience, the virtual instructions that support virtualization of exception code are referred to collectively as virtual exception instructions, whether they are native or new.
The process of the virtualization protection realized in the invention is as follows: the compiler sequentially processes different source files, when the compiler acquires a current source file, after a source code is converted into an IR (LLVM IR, LLVM IntermediatedRecompressed), IR instructions of a protected function are translated into virtual instructions, and the virtual instructions are interpreted and executed by the interpreter when a program runs. Because these virtual instructions are not public, different from any published instructions in the past, the reinforced SO file has the effects of hiding codes and data, resisting tampering, resisting Dump and the like, and can greatly increase the protection strength.
It is understood that the source code that the compiler described in the present invention can compile is not limited to C + +/C functions, and is not limited to just converting the source code into virtual bytecode. In the invention, the source function which is not identified by virtualization is not modified in the IR layer, and then is directly converted into the machine instruction, that is, the binary file generated by the compiler in the invention comprises the machine instruction and the virtual instruction, and all the modes of converting the source code into the binary file are the alternative forms of the compiler in the invention.
The specific scheme of the invention is shown in figure 1:
s100, acquiring a source function to be subjected to virtualization protection in a source file through a compiler, generating a first IR instruction, and translating an instruction which represents an exception in the first IR instruction into a group of virtual exception instructions.
Specifically, a source file is obtained through a compiler, a source function to be protected in virtualization is stored in the source file, and the source function to be protected in virtualization is a source function for which a virtualization protection identifier is preset by a developer. In a compiler, the compiler identifies the source function to be protected virtually.
It is known that a function is composed of a plurality of statements, which are codes of the function. The code of a function is a whole by taking the function as a unit in compiling. A source code corresponding to the source function to be virtually protected is arranged on an IR layer of a compiler, and an IR instruction contained in the function to be virtually protected is called a first IR instruction; in the IR layer, the compiler translates the first IR instructions into virtual instructions, wherein instructions of the first IR instructions that represent exceptions are translated into a set of virtual exception instructions. It is understood that the source function to be protected by virtualization in the present invention has exception-related code, and at the IR layer, the exception-related code is composed of an IR instruction representing an exception and a normal IR instruction. In the invention, the IR instruction representing the exception is translated into a virtual exception instruction and a common virtual instruction, and the IR instruction not representing the exception is translated into the common virtual instruction.
Further, the first IR instructions comprise: an invoke instruction and a landingpad instruction. The invoke instruction can call a function, and when the called function returns normally, the control flow is transferred to a basic block specified by the normal label; when the called function throws an exception that it cannot capture itself, the control flow is transferred to the basic block specified by the unwandlabel. The Landing pad instruction is used by the exception handling system of the LLVM to indicate that a basic block is a landing site (Landing pad), which is the place where an exception lands, matching the catch portion of try/catch in the C + + source code, where the exception object type that can be captured is declared.
Further, in step S100, while the first IR instruction is generated, a first IR file corresponding to the first IR instruction is also generated, where the first IR file includes: a function to be protected, a non-protected function, a packing function, an abnormal type table and a packing function table; and a wrapping function is stored in the wrapping function table and used for calling a local function.
Specifically, in an IR layer, an IR instruction included in the function to be protected by virtualization is referred to as a first IR instruction, and accordingly, a first IR file corresponding to the first IR instruction exists, where an exception type table and a wrapper function table are stored in the first IR file, and the exception type table corresponds to a landingpad instruction in the first IR instruction; the wrapping function table corresponds to a call instruction and an invoke instruction in the first IR instruction, the invoke instruction can call a native function, the native function is a function provided by a bottom environment, and a c/c + + function is a native function relative to a virtual bytecode. And collecting the source functions to be subjected to virtualization protection in the first IR file, and traversing each first IR instruction for each source function.
When the abnormal object type (namely the abnormal type captured by the catch part declaration in the c + + source code) appearing in the catch part in all the landingpad instructions in the first IR instruction is collected, a corresponding array is inserted into the first IR file, and the array is called an abnormal type table, and the abnormal type table stores the abnormal type captured by the catch part declaration in all the functions to be protected in the current source file to be virtualized (namely std:: type _ info, std:: type _ info can represent a type at runtime).
When a call instruction and an invoke instruction (function call instruction) in the first IR instruction are acquired, the return type and parameter type of the local function called by the call instruction determine the signature of the called function, and a wrapper function is created according to the signature of the called function in the function call instruction and inserted into the first IR file. After all call instructions and invoke instructions in the first IR instruction are processed, an array is inserted into the first IR file, the array stores addresses of all packing functions, and the array is called a packing function table.
Further, in step S100: while translating instructions of the first IR instructions representing exceptions into a set of virtual exception instructions, the first IR file is translated into a second IR file, the second IR file comprising: the method comprises the following steps of (1) obtaining an abnormal type table, a packing function table, a merging table of a virtual abnormal table, an index table of the virtual abnormal table and a virtual byte code table; the virtual byte code table stores virtual byte codes, and the virtual byte codes comprise a plurality of virtual abnormal instructions; the merging table of the virtual abnormal table stores a plurality of virtual abnormal tables, namely the virtual abnormal table is merged and stored. The index table of the virtual abnormal table stores the position and the size of each virtual abnormal table in the merging table of the virtual abnormal table. Specifically, at this stage, the first IR file is referred to as a second IR file, and the second IR file further stores a virtual byte code table and an index table (ETIA) of a virtual exception table on the basis of the first IR file.
In the IR layer, the first IR instructions further comprise: landingpad, resume, llvm. eh. typeid. for, etc. LLVMIR represents a C + + exception handling system via instructions such as invoke, landingpad, and the like. In the IR layer, the compiler translates the first IR instructions into virtual instructions, wherein instructions of the first IR instructions that represent exceptions are translated into a set of virtual exception instructions. For different abnormal IR instructions, the number of virtual instructions translated into the abnormal IR instructions is different, some of the abnormal IR instructions are translated into only one virtual abnormal instruction, and some of the abnormal IR instructions are translated into a plurality of virtual abnormal instructions.
When the first IR instruction is translated into a virtual instruction, correspondingly, a virtual byte code table is inserted into the second IR file, wherein the virtual byte code table stores virtual byte codes (the virtual byte codes are the general name of the virtual instruction), and the virtual byte codes are codes formed by the virtual instruction; and simultaneously, inserting a virtual byte code index table, wherein the virtual byte code index table stores the initial position and the length of the byte code of the function to be protected in the virtual byte code table.
A global array is inserted into the second IR file, which is denoted as an index table called a virtual exception table, denoted as ETIA (exceptindelexray), as shown in fig. 3, the number of elements of ETIA is greater than or equal to the number of elements of MET (m > ═ n), because all source functions to be protected by virtualization may not have an exception table, if the source functions to be protected by virtualization have no exception code, the source functions do not have a virtual exception table, the first member in ETIA specifies the offset of the virtual exception table of a certain function in MET, and the second member in the structure specifies the size of the virtual exception table.
When an instruction representing an exception in the first IR instruction is translated into a set of virtual exception instructions, specifically, for a protection function to be virtualized including an invoke instruction, a virtual exception instruction and a virtual exception table corresponding to the function are generated. All the virtual exception tables are merged and stored in sequence and recorded as a merged table, met (merged exception table). Specifically, when an exception code exists in the source function, a virtual exception instruction exists, and the source function and the virtual exception table are in one-to-one correspondence.
The ETIA specifies the index and size of each virtual exception table in the MET.
As shown in fig. 2, the structure diagram of the virtual exception table includes four parts, namely a header, a call site table, an action table, and a type index table, where the four parts specifically include:
the type index base offset in the header is the number of bytes occupied by the rest parts in the virtual abnormal table except the header, and is used for calculating the TIBase, and the call site table size in the header is the number of bytes occupied by the call site table immediately after the TIBase;
a call site table, which is an array with an element type of call site record, the call site record is a structure with 4 elements, the call site position indicates the offset of a virtual bytecode corresponding to an invoke statement in the LLVM IR from the start of a virtual bytecode of a source function where the virtual bytecode is located, the call site length indicates the number of virtual bytecodes (in bytes) corresponding to an invoke statement in the LLVMIR, and the landingpad position indicates the offset of a virtual bytecode corresponding to a basic block specified by an except statement in the invoke statement in the LLVMIR from the start of a virtual bytecode of a source function where the virtual bytecode is located, and the basic block is used for either processing a thrown exception or executing cleaning work; the first action is 0, which means that the landingpad corresponding to the call site record is used to execute the clear, otherwise, the first action-1 is used as the search starting point of the action table (here, the beginning of the action table is the 0 th byte in terms of byte). Refer to FIG. 5 for the call site position and landingpad position.
As shown in FIG. 5, for the virtual bytecode of function A, assuming that offset0 is the offset of the virtual bytecode translated by function A in the entire virtual bytecode area, offset1 indicates the offset of the virtual bytecode translated by the invoke instruction in LLVM IR of A in the entire virtual bytecode area, and offset2 indicates the offset of the virtual bytecode translated by the basic block specified by the except label of the invoke in the entire virtual bytecode area, then there is a CallSiteRecord in the virtual exception table of A, where
CallSitePosition＝offset1–offset0
LandingpadPosition＝offset2–offset0
The action table is an array with an element type of action record, and the action record comprises two elements.
Type filter is a positive integer starting from 1, which is the index of the Type index table. 1 is the first term before the TIBase, 2 is the second term before the TIBase, and so on. The interpreter is used for judging whether the thrown exception object type is matched with the exception type captured by the catch part declaration of the source function corresponding to the virtual exception table.
Offset to next action record is a signed number. Indicates the Offset of the next action record from this field (i.e., Offset to next action record itself), which is 0 if there is no next action record. I.e. a try has no more catch.
The action records corresponding to the catch of one try block are stored continuously in the action table, and the action records belonging to different try blocks cannot be stored alternately in the action table. However, for two adjacent action records, if the starting parts of the previous action record and the next action record are completely the same, the two action records can be stored in a combined manner, but the two action records are still conceptually.
Each item in the type index table is an index of type info table, wherein the type info table (exception type table) is an array with element type std:, type _ info (exception object type), and stores exception type captured by the catch part declaration in the current source file. the type info table exists in a data section of an executable binary file (e.g., elf file).
The std _ info class describes information of a type, which has member functions, wherein the name function returns a string representing the name of the class, and since an array of std _ info types cannot be directly stored in the virtual bytecode, the compiler generates an array type info table of std _ info type, in which pointers of all exception types declared to be captured in the catch section in the current source file are stored.
The invention designs a virtual exception table, which aims to check whether a protected function (which refers to a function to be protected in a virtualization mode, and instructions of the function are translated into byte codes after the virtualization is finished) can capture exceptions, if so, an interpreter can locate the virtual byte codes corresponding to exception handling through the virtual exception table to execute the virtual byte codes representing the exception handling.
S200, the compiler generates a second IR instruction to replace the first IR instruction to form an interpreter entry function, and the interpreter entry function calls an interpreter to interpret and execute the group of virtual abnormal instructions. Specifically, the second IR instruction is a new set of instructions generated in the interpreter, and the first IR instruction is replaced by the second IR instruction, so as to convert the source function to be protected by virtualization into an interpreter entry function; the second IR instruction pushes the parameters of the source function to be subjected to virtualization protection to a virtual stack; calling an interpreter to interpret and execute the virtual byte code (namely virtual instruction, including virtual abnormal instruction) of the source function to be virtualized and protected; and if the source function to be subjected to virtualization protection has a return value, retrieving the execution result of the interpreter from the virtual stack and returning the result. The source function to be virtually protected is thus translated into an interpreter entry function.
The step S200 specifically includes:
s210, the compiler generates a second IR instruction to replace the first IR instruction to form an interpreter entrance function, the second IR instruction calls an interpreter to execute the virtual abnormal instruction, and the interpreter calls the local function.
Specifically, when the interpreter acquires an exinvake instruction (an invoke virtualized instruction in the first IR instruction) during execution, the interpreter may take a pointer of a corresponding wrapper function through an operand of the exinvake (the operand of the exinvake is an index of a wrapper function table), and the invocation of the wrapper function is realized through the pointer of the wrapper function. And the local function is called in the wrapper function. When the interpreter interprets the virtual bytecode translated by executing the call or invoke statement, the local function is called indirectly through the wrapper function. The interpreter thus enables calls to local functions.
S220, when the local function returns normally, the interpreter executes a next virtual abnormal instruction in the group of virtual abnormal instructions, where the group of virtual abnormal instructions includes a plurality of virtual abnormal instructions, and the interpreter interprets the plurality of virtual abnormal instructions one by one.
And S230, when the local function throws the exception, capturing the exception by the interpreter, and executing the virtual bytecode processed by the exception. When the local function throws an exception (note that here, the exception is not captured by the local function itself), the normal control flow is interrupted and the interpreter needs to handle the exception.
Specifically, if the local function throws an exception, the interpreter captures the exception in the catch portion. The virtual exception table of the thrown exception object and the currently interpreted and executed protected function (referred to as the protected function herein for distinguishing the protection function to be virtualized after compilation is completed) locates the exception-handling virtual bytecode, and the interpreter executes the exception-handling virtual bytecode instead (the exception-handling bytecode refers to a bytecode translated from the basic block specified by the unwind label in the IR instruction invoke). When the exception is not caught by the protected function currently being interpreted by the interpreter, there will be no exception handling virtual bytecode for the exception.
The area where the virtual bytecode interpretation is executed is exemplified as follows:
the step S230 specifically includes:
s231, when the local function throws an exception, the interpreter captures the exception;
s232, checking whether the current protected function has a virtual abnormal table or not through an index table of the virtual abnormal table, and if the current protected function does not have the virtual abnormal table, the interpreter throws the abnormality again; and if the virtual abnormal table exists, acquiring the virtual abnormal table of the current protected function.
Specifically, searching the ETIA to see whether a virtual abnormal table of the current protected function exists, because the ETIA indicates the index and size of each virtual abnormal table in the MET, if the value indicating the size of the virtual abnormal table in the ETIA is 0, it indicates that the virtual abnormal table of the current protected function does not exist, and if the virtual abnormal table of the current protected function does not exist, the exception is thrown again; if the virtual exception table exists, the process proceeds to the next steps S233 and S234.
The current protected function refers to a protected function which is currently interpreted and executed by the interpreter when the interpreter captures an exception.
S233, acquiring a pointer of the thrown abnormal object and a pointer (std:: type _ info) representing the type of the abnormal object through C + + ABI (ABI is an application program binary interface which describes the bottom layer interface between the application program and the operating system).
S234, checking the virtual abnormal table corresponding to the abnormality, and judging whether the current protected function can capture the abnormality.
Further, the virtual exception table of the current protected function is checked, and when a virtual program counter (denoted as vpc) is located in a specified area (namely, the vpc is located in a range specified by a certain call point listed in the virtual exception table), a call site record is checked; otherwise, the exception is thrown again.
The call site table is an array with an element type of call site record, the call site record is a structure with 4 elements, and the call site record is composed of a call site position, a call site length, a landingpad position and a first action.
Specifically, the call site record of the call site table in the virtual exception table is checked, and when the virtual program counter (vpc) is located in the specified area, namely, vpc > offset for start of function + call site and vpc < offset for start of function + call site indicates that the exception is that the function called by this call site throws the exception or the function located below the call site in the call chain throws the exception.
Further, whether the landingpad position in the call site record is 0 is checked, and if not, the action in the call site record is checked; otherwise, the exception is thrown again.
Further, whether the first action in the call site record is 0 or not is checked, if the first action is 0, the current function does not capture the exception, only some cleaning work is executed (namely, a destructor C + + class object is called), a vpc is set to execute the virtual bytecode at the landingpad position, the cleaning work is executed, and then the exception is thrown out again; if the first action is not 0, then action-1 (denoted ActIndex) points to the first position in the action table where the search is started, and the ActionTable is checked.
Further, whether the exception type corresponding to the thrown exception is matched with the exception type corresponding to the exception table is checked, when the matching is successful, the current protected function can capture the exception, and the process goes to S235.
Specifically, the virtual exception table stores an exception type that can be captured by the current protected function, and if the exception type of the thrown exception is matched with the exception type that can be captured, that is, a type pointer of the current thrown exception object is matched with a pointer of the exception type that can be captured, it is indicated that the current protected function can capture the current exception; if the types do not match, an error is made and the program should exit.
Checking ActIndex bytes of an action table to obtain an index of a type index table, and then obtaining std:: type _ info in type table info, wherein if the type represented by the ActIndex bytes is matched with the type represented by the std:: type _ info obtained in the step S233, the current protected function can capture the thrown exception; if the types are not matched, finding the next action record according to the offset to next action record, and continuing to check the type matching until the value of the offset to next action record is 0, if the types are not matched at this time, making an error, and the program should exit.
Each item in the type index table is an index of a type info table, wherein the type info table is an array with elements std:: type _ info, and a pointer of a catch part abnormal type in the current source file is stored.
S235, when the current protected function can capture the exception, setting a vpc, controlling the vpc to point to the exception handling bytecode corresponding to the exception, and interpreting and executing the exception handling bytecode by the interpreter. And setting the vpc to execute the virtual byte code at the landingpadpost position and process the thrown exception. After the necessary operation of exception processing is executed, the exception processing can be recovered to a normal control flow, and a vpc is set so that the bytecode after the exception processing is executed (namely the bytecode corresponding to the code after the C + + try-catch)
Further, after the exception is re-thrown, up the chain of function calls, the exception may be re-trapped by the interpreter or by other local functions.
Specifically, after the current protected function fails to handle the exception and throws the exception again, the exception handling mechanism of C + + itself continues to perform stack unwinding (stack unwinding) up the function call chain until a function recaptures the exception. If the interpreter captures the exception (i.e., by the catch at the upper-level EXINVOKE instruction), then the exception is executed; if the local function is captured by other common local functions, the abnormal mechanism of C + + itself is used for processing. If the exception is not captured until the main function, the C + + native exception mechanism causes the program to exit.
The invention enumerates the form of the function call chain as follows for explaining the exception handling process:
Function A>interpreter entry function for B>interpreter>wrapperfunction for C>Function C>interpreter entry function for D>interpreter>wrapper function for E>Function E
function call chain: a chain formed by function calls, assuming there is a chain of function calls A- > B- > C- > D- > E in the source code, such as function A calls function B, which in turn calls function C, which in turn calls function D, which in turn calls function E, where B, D is a protected function and A, C, E is a non-protected function. When the execution is abnormal, the following processing procedures are carried out:
if the function E throws an exception, if the exception is not captured in the function E, the C + + own exception mechanism searches an exception handling capable of capturing the exception upwards along a call chain; the wrapping function of E is encountered firstly, but the wrapping function can not capture the abnormity; then, a first interpreter call (which simplifies the interpreter into a conceptual function, and is equivalent to a function call) is encountered, where the interpreter call is to interpret the virtual bytecode of the execution D, if the interpreter captures an exception, step S230 is executed to execute the exception-handling virtual bytecode, and if the interpreter fails to find a matching exception-handling virtual bytecode in the virtual exception table of the protected function D, the exception is thrown again; the interpreter entry function (i.e., the surrogate function) of D is then encountered, again this function does not capture the exception; if C is encountered, stopping searching and executing exception processing in C if C captures an exception, and continuing searching if C cannot capture the exception; then, a wrapping function of C is encountered, and the function cannot capture the exception; a second interpreter call is then encountered, where the interpreter call interprets the virtual bytecode for execution B, which handles it like the first interpreter call; if a search is needed, then the entry function of B is encountered, which does not catch the exception; if A captures the exception, the program executes exception processing in A, and if A can not capture the exception, the program continues to search; thus, until main, if main can not capture the exception, the program exits the run.
When the interpreter captures the exception again, vpc, vfp, vsp are local variables in the interpreter function, and all have been restored to the value matching the current stack frame, vfp, vsp are restored, which is equivalent to that the virtual stack is also restored.
Thus, for processing at a level up to the calling chain, if the main function cannot capture the exception, the program should exit.
300. And converting the second IR file into a binary target file, calling a linker, and linking the binary target file with the interpreter to form a binary executable file.
The interpreter is written in C + + language, the source code of the interpreter is compiled into a static library (a group of binary object files) by the compiler, the compiler converts the second IR file where the second IR instruction is located into a binary object file, and finally, a linker is called to link all the binary object files and the binary object files realizing the function of the interpreter into a binary executable file.
The present invention further provides an intelligent terminal, as shown in fig. 6, which includes a processor 10, and a memory 20 connected to the processor 10, where the memory 20 stores a program of a method for protecting an exception mechanism, and the program of the method for protecting an exception mechanism, when executed by the processor, can implement the method for protecting an exception mechanism as described above; as described above.
The present invention also provides a storage medium, wherein the storage medium stores a program for protecting an exception mechanism, the program for protecting an exception mechanism being executable for implementing the method for protecting an exception mechanism as described above; as described above.
In summary, the method for protecting an exception mechanism, the intelligent terminal and the storage medium disclosed by the present invention include: acquiring a source function to be subjected to virtualization protection in a source file through a compiler, generating a first IR instruction, and translating an instruction which represents an exception in the first IR instruction into a group of virtual exception instructions; and the compiler generates a second IR instruction to replace the first IR instruction to form an interpreter entrance function, and the interpreter entrance function calls an interpreter to interpret and execute the group of virtual abnormal instructions. According to the invention, the compiler can translate the exception in the source function to be subjected to virtualization protection into the virtual exception instruction, and then the interpreter is called to interpret and execute the virtual exception instruction, so that the code representing the exception in the source function to be subjected to virtualization protection is protected, and the source function is further protected.
It is to be understood that the invention is not limited to the examples described above, but that modifications and variations may be effected thereto by those of ordinary skill in the art in light of the foregoing description, and that all such modifications and variations are intended to be within the scope of the invention as defined by the appended claims.
Claims (10)
1. A method of protecting an exception mechanism, comprising:
acquiring a source function to be subjected to virtualization protection in a source file through a compiler, generating a first IR instruction, and translating an instruction which represents an exception in the first IR instruction into a group of virtual exception instructions;
and the compiler generates a second IR instruction to replace the first IR instruction to form an interpreter entrance function, and the interpreter entrance function calls an interpreter to interpret and execute the group of virtual abnormal instructions.
2. The method according to claim 1, wherein the first IR file corresponding to the first IR instruction is generated while the first IR instruction is generated by acquiring, by the compiler, the source function to be protected virtually in the source file, and the first IR file includes: a function to be protected, a non-protected function, a packing function, an abnormal type table and a packing function table; and a wrapping function is stored in the wrapping function table and used for calling a local function.
3. The method of claim 2, wherein said translating and translating an instruction of said first IR instruction representing an exception into a set of virtual exception instructions translates said first IR file into a second IR file, said second IR file comprising: the method comprises the following steps of (1) obtaining an abnormal type table, a packing function table, a merging table of a virtual abnormal table, an index table of the virtual abnormal table and a virtual byte code table; the virtual byte code table stores virtual byte codes, and the virtual byte codes comprise a plurality of virtual abnormal instructions; a plurality of virtual exception tables are stored in the combination table of the virtual exception table.
4. The method for protecting exception mechanisms according to claim 3, wherein said compiler generating a second IR instruction in place of said first IR instruction forms an interpreter entry function, said interpreter entry function invoking an interpreter to perform said set of virtual exception instructions specifically comprises:
the compiler generates a second IR instruction to replace the first IR instruction to form an interpreter entry function, and the second IR instruction calls an interpreter to execute the group of virtual abnormal instructions one by one; the set of virtual exception instructions includes a plurality of virtual exception instructions, the interpreter invokes the native function;
when the local function throws an exception, the interpreter captures the exception and executes the virtual bytecode processed by the exception.
5. The method according to claim 4, wherein when the local function throws an exception, the interpreter captures the exception, and the virtual bytecode for performing the exception handling specifically includes:
when the local function throws an exception, the interpreter captures the exception;
checking whether the current protected function has a virtual abnormal table or not through an index table of the virtual abnormal table, and if the current protected function does not have the virtual abnormal table, the interpreter throws the abnormality again; if the virtual abnormal table exists, acquiring the virtual abnormal table of the current protected function;
checking a virtual exception table of the current protected function, and throwing the exception again when the current protected function cannot capture the exception;
when the current protected function can capture the exception, a vpc is set, the vpc is controlled to point to the virtual bytecode of exception handling to be executed after the exception is captured, and an interpreter interprets the virtual bytecode of exception handling.
6. The method of protecting an exception mechanism according to claim 5, wherein said re-casting said exception thereafter comprises:
up the chain of function calls, the interpreter continues to capture the exception.
7. The method for protecting exception mechanisms according to claim 3, wherein said compiler generating a second IR instruction in place of said first IR instruction forms an interpreter entry function, said interpreter entry function invoking said set of virtual exception instructions to be interpreted by said interpreter further comprising:
and converting the second IR file into a binary target file, calling a linker, and linking the binary target file with the interpreter to form a binary executable file.
8. The method of protecting an exception mechanism according to claim 1, wherein said source function is a C + + function.
9. An intelligent terminal, comprising a processor and a memory connected to the processor, wherein the memory stores a program for protecting an exception mechanism, and the program for protecting an exception mechanism is capable of implementing the method for protecting an exception mechanism according to any one of claims 1 to 8 when executed by the processor.
10. A storage medium storing a program for protecting an exception mechanism, the program being executable to implement a method for protecting an exception mechanism as claimed in any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910934611.6A CN110673929B (en) | 2019-09-29 | 2019-09-29 | Method for protecting abnormal mechanism, intelligent terminal and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910934611.6A CN110673929B (en) | 2019-09-29 | 2019-09-29 | Method for protecting abnormal mechanism, intelligent terminal and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110673929A true CN110673929A (en) | 2020-01-10 |
| CN110673929B CN110673929B (en) | 2022-11-22 |
Family
ID=69080121
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910934611.6A Active CN110673929B (en) | 2019-09-29 | 2019-09-29 | Method for protecting abnormal mechanism, intelligent terminal and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110673929B (en) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112989290A (en) * | 2021-03-10 | 2021-06-18 | 四川长虹格润环保科技股份有限公司 | Multi-compatibility code reinforcing method |
| CN113626773A (en) * | 2020-05-06 | 2021-11-09 | 上海蜚语信息科技有限公司 | Code protection method based on intermediate language |
| CN113761518A (en) * | 2021-08-17 | 2021-12-07 | 中国科学院软件研究所 | Control flow hijacking attack defense method and device based on RISC-V and HW-CFI mechanism |
| CN114328168A (en) * | 2020-10-09 | 2022-04-12 | 腾讯科技（深圳）有限公司 | Anomaly detection method and device, computer equipment and storage medium |
| CN117033064A (en) * | 2023-10-10 | 2023-11-10 | 北京中电华大电子设计有限责任公司 | Method and device for processing code exception |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120084761A1 (en) * | 2010-09-30 | 2012-04-05 | Nec Laboratories America, Inc. | Interprocedural Exception Method |
| US20140068573A1 (en) * | 2012-08-28 | 2014-03-06 | Microsoft Corporation | Error-code and exception-based function dispatch tables |
| CN106960141A (en) * | 2016-01-08 | 2017-07-18 | 阿里巴巴集团控股有限公司 | Coding, coding/decoding method and the device of virtual machine instructions, virtual machine protection system |
| CN108614960A (en) * | 2018-05-11 | 2018-10-02 | 西北大学 | A kind of JavaScript virtualization guard methods based on front end bytecode technology |
| CN108932406A (en) * | 2017-05-18 | 2018-12-04 | 北京梆梆安全科技有限公司 | Virtualization software guard method and device |
| CN109684794A (en) * | 2018-12-07 | 2019-04-26 | 成都盈海益讯科技有限公司 | A kind of code protection virtual machine KVM network system realization, device, computer equipment and storage medium |
| CN109933410A (en) * | 2019-03-22 | 2019-06-25 | 北京智游网安科技有限公司 | A kind of fictitious order delivery method and system based on virtualization technology |
| CN109960511A (en) * | 2019-03-22 | 2019-07-02 | 北京智游网安科技有限公司 | Dynamic base delivery method, storage medium and intelligent terminal based on virtualization technology |
| CN110032425A (en) * | 2019-03-22 | 2019-07-19 | 北京智游网安科技有限公司 | A kind of dynamic link library file virtual method, system and storage medium |
| CN110245467A (en) * | 2019-05-13 | 2019-09-17 | 西北大学 | Android application program guard method based on Dex2C and LLVM |
-
2019
- 2019-09-29 CN CN201910934611.6A patent/CN110673929B/en active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120084761A1 (en) * | 2010-09-30 | 2012-04-05 | Nec Laboratories America, Inc. | Interprocedural Exception Method |
| US20140068573A1 (en) * | 2012-08-28 | 2014-03-06 | Microsoft Corporation | Error-code and exception-based function dispatch tables |
| CN106960141A (en) * | 2016-01-08 | 2017-07-18 | 阿里巴巴集团控股有限公司 | Coding, coding/decoding method and the device of virtual machine instructions, virtual machine protection system |
| CN108932406A (en) * | 2017-05-18 | 2018-12-04 | 北京梆梆安全科技有限公司 | Virtualization software guard method and device |
| CN108614960A (en) * | 2018-05-11 | 2018-10-02 | 西北大学 | A kind of JavaScript virtualization guard methods based on front end bytecode technology |
| CN109684794A (en) * | 2018-12-07 | 2019-04-26 | 成都盈海益讯科技有限公司 | A kind of code protection virtual machine KVM network system realization, device, computer equipment and storage medium |
| CN109933410A (en) * | 2019-03-22 | 2019-06-25 | 北京智游网安科技有限公司 | A kind of fictitious order delivery method and system based on virtualization technology |
| CN109960511A (en) * | 2019-03-22 | 2019-07-02 | 北京智游网安科技有限公司 | Dynamic base delivery method, storage medium and intelligent terminal based on virtualization technology |
| CN110032425A (en) * | 2019-03-22 | 2019-07-19 | 北京智游网安科技有限公司 | A kind of dynamic link library file virtual method, system and storage medium |
| CN110245467A (en) * | 2019-05-13 | 2019-09-17 | 西北大学 | Android application program guard method based on Dex2C and LLVM |
Non-Patent Citations (8)
| Title |
|---|
| 丁宇新等: "Java虚拟机异常处理机制的设计与实现", 《计算机研究与发展》 * |
| 刘璟，周玉龙编著: "《高级语言C++程序设计》", 30 November 2004 * |
| 孙文全等: "基于符号执行技术的C++程序静态分析", 《电子技术》 * |
| 曹志伟等: "在静态编译器中实现Java异常机制的算法", 《计算机工程》 * |
| 李晓伟等: "基于Harmony的提前编译技术", 《计算机工程》 * |
| 杜春来等: "一种基于指令虚拟化的代码保护模型", 《信息网络安全》 * |
| 汤战勇等: "一种具有指令集随机化的代码虚拟化保护系统", 《华中科技大学学报(自然科学版)》 * |
| 荣国桢等: "一种软件保护虚拟机的指令解析器方案", 《计算机与现代化》 * |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113626773A (en) * | 2020-05-06 | 2021-11-09 | 上海蜚语信息科技有限公司 | Code protection method based on intermediate language |
| CN113626773B (en) * | 2020-05-06 | 2024-04-02 | 上海蜚语信息科技有限公司 | Code protection method based on intermediate language |
| CN114328168A (en) * | 2020-10-09 | 2022-04-12 | 腾讯科技（深圳）有限公司 | Anomaly detection method and device, computer equipment and storage medium |
| CN112989290A (en) * | 2021-03-10 | 2021-06-18 | 四川长虹格润环保科技股份有限公司 | Multi-compatibility code reinforcing method |
| CN113761518A (en) * | 2021-08-17 | 2021-12-07 | 中国科学院软件研究所 | Control flow hijacking attack defense method and device based on RISC-V and HW-CFI mechanism |
| CN117033064A (en) * | 2023-10-10 | 2023-11-10 | 北京中电华大电子设计有限责任公司 | Method and device for processing code exception |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110673929B (en) | 2022-11-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110673929B (en) | Method for protecting abnormal mechanism, intelligent terminal and storage medium | |
| US6412109B1 (en) | Method for optimizing java bytecodes in the presence of try-catch blocks | |
| US6594783B1 (en) | Code verification by tree reconstruction | |
| KR101099212B1 (en) | An intermediate representation for multiple exception handling models | |
| US6067641A (en) | Demand-based generation of symbolic information | |
| US20080222616A1 (en) | Software translation | |
| US8141035B2 (en) | Method for accessing internal states of objects in object oriented programming | |
| GB2357866A (en) | Garbage collection with live memory list and leakage detection | |
| Brachthäuser et al. | Effect handlers for the masses | |
| CN103514027B (en) | Method for enhancing usability of software protection | |
| WO2008108665A1 (en) | A computer implemented translation method | |
| US7287244B2 (en) | Efficiently releasing locks when an exception occurs | |
| CN117235746B (en) | Source code safety control platform based on multidimensional AST fusion detection | |
| CN114707124B (en) | NET platform code protection method and system based on code virtualization | |
| Pusch | Proving the soundness of a Java bytecode verifier in Isabelle/HOL | |
| d’Andrea et al. | Tecnical Documentation | |
| Cui et al. | SmallRace: Static Race Detection for Dynamic Languages-A Case on Smalltalk | |
| Pool et al. | TruffleReloader: A low-overhead language-neutral reloader | |
| Negrini | A hybrid approach for automatic recognition of C++ objects in optimized binaries | |
| Turas | Gradual C Programming for Typed Lua | |
| JPH0455945A (en) | Compiled code output system for generation of nonlocal outlet function frame | |
| Engel | From Eiffel to the Java Virtual Machine | |
| JP2001014172A (en) | Program converting device | |
| Byrne et al. | GNU Smalltalk User's Guide | |
| Trinciante et al. | Choosing efficient inheritance patterns for Java generics |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20220923 Address after: F060, 7 / F, Cuilin building, 10 Kaifeng Road, Maling community, Meilin street, Futian District, Shenzhen, Guangdong 518000 Applicant after: SHENZHEN IJIAMI TECHNOLOGY CO.,LTD. Address before: 207-2, 2 / F, building 10, Zhongguancun Software Park, 8 dongbeiwangxi Road, Haidian District, Beijing (Guoyong RONGTONG building) Applicant before: BEIJING ZHIYOU WANG'AN TECHNOLOGY Co.,Ltd. |
|
| TA01 | Transfer of patent application right | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |