CN111222103A

CN111222103A - Software protection method based on vectorization exception handling

Info

Publication number: CN111222103A
Application number: CN201911402482.2A
Authority: CN
Inventors: 赵康; 范渊
Original assignee: DBAPPSecurity Co Ltd
Current assignee: DBAPPSecurity Co Ltd
Priority date: 2019-12-31
Filing date: 2019-12-31
Publication date: 2020-06-02
Anticipated expiration: 2039-12-31
Also published as: CN111222103B

Abstract

The invention provides a software protection method based on vectorization exception handling, which comprises the following steps: firstly, adding a shell to an executable file; secondly, loading an executable file; and thirdly, if vectorization exception occurs, vectorization exception processing is carried out. The invention provides a method for encrypting and decrypting data in blocks without changing original program codes and memory positions. By modifying the memory protection attribute, a certain page of memory is made inaccessible, and an exception is generated when a program jumps to an address in the memory page or accesses data in the memory page. The method enables the shell code to control both program execution and data access without changing the memory address of the code and data.

Description

Software protection method based on vectorization exception handling

Technical Field

The invention relates to a software protection method, in particular to a software protection method based on vectorization exception handling.

Background

When a general shell adding method is used for protecting software, all executable file data are always treated as a whole in order to ensure that an original program operates normally. Either fully encrypted or fully decrypted. This is because the functional codes within the program call each other, and the timing and location of accessing the data are uncertain. The shell code must decrypt the original program completely before returning the program control to the original program, which makes a good intervention for shell removal.

The invention controls the whole process of program operation through a vectorization exception handling mechanism. The exception handling code obtains control right when each memory page of the original program is executed or data is accessed, and related data is encrypted and decrypted timely, so that the integral decryption of the original program is avoided. Thus, the memory data obtained by the process memory dump at any time is mostly encrypted.

One of the various software protection methods is to shell an executable file. The body of the executable file code after the shell is morphed, compressed or encrypted and a piece of code (i.e., shell code) is added at the beginning of the program code. The first execution when the software runs is the shell code. The shell code restores the code body through a relatively complicated decryption process, and then jumps to execute the real function code.

This software protection method has a drawback that the protection of the code is only performed at the early stage of the software operation. When the shell program of the software is completely operated, the original code is completely exposed in the memory. At this time, the unprotected software code can be obtained by technical means of process memory dump and executable file image repair and the like. The process of removing the protection is known as shelling.

Most software is limited to the specification constraints of compiler and CPU architecture, and the code of the program entry point has certain characteristics. This feature can be used to determine whether the software being shelled has run to the original code. The common shelling method usually has a corresponding shelling tool, and shelling can be automatically realized on software protected by various shelling methods. The existence of the universal shelling method greatly reduces the protection effect of the added shells on the software.

To prevent automated shelling by a shelling tool, there is an improved method of adding shells by transferring a portion of the software code into the shell code. And a jump instruction is inserted at the position of the original code, so that the program execution jumps to the shell to run. And when the execution of the transferred code is finished, jumping to a subsequent code at the original position to continue running. The shell and the software main body are combined together and are difficult to separate by repeatedly jumping between the original program and the shell code, so that the shell is prevented from being automatically removed by a shelling tool.

The implementation of code migration is based on a detailed analysis of the original program code. When software is added with a shell, all jump instructions and memory access instructions in a program are mastered through a disassembling technology. Then it is possible to move the location of the code without changing the flow of the program and the execution results of the instructions. That is, the moved part of the code is ensured not to jump out of the self range in the middle, the external memory is not accessed, and other codes are not directly jumped to the moved code. If such a jump or memory access inevitably exists, the relevant instruction needs to be modified, and the destination address of the jump and the memory addressing address need to be changed, so that the finally executed logic remains unchanged.

The key technical point of the shell adding method for realizing code transfer is instruction analysis. However, the execution flow of many software is complicated, and especially for instructions using registers for indirect jump and indirect addressing, it is difficult to accurately predict the destination addresses of jump and addressing. Even the well-known disassembly engines and large reverse analysis tools are not completely reliable in solving these problems. Thus, the migration of code into the shell creates potential compatibility issues. If code which cannot be moved is transferred, the software operation is abnormal.

Generally only program code can be transferred into the shell. It is very difficult to transfer data (resources) of the software into the shell. This is because the analysis instruction often only gets the starting address of the data it accesses, and the length of the data is uncertain and dynamically changing. For data protection, it is common practice to encrypt all data in place (without changing memory addresses) when the shell is added. Before executing the program main body, the shell code completely decrypts the data in the memory. I.e. the data can only be protected in place as a whole. Such protection is weak, and all data can be obtained by process memory dump.

For those programs that modify their own code during execution, the execution logic of the modified code cannot be determined and therefore cannot be transferred to the shell.

Accordingly, there is a need for improvements in the art.

Disclosure of Invention

The invention aims to provide an efficient software protection method based on vectorization exception handling.

In order to solve the above technical problem, the present invention provides a software protection method based on vectorization exception handling, which comprises the following steps:

firstly, adding a shell to an executable file;

secondly, loading an executable file;

and thirdly, if vectorization exception occurs, vectorization exception processing is carried out.

As an improvement of the software protection method based on vectorization exception handling of the invention:

the first step comprises the following steps:

1) analyzing the original executable file to obtain data needing to be processed; executing the step 2;

2) generating a new executable file header according to the data needing to be processed obtained in the step 1;

3) modifying the first section table entry of the new executable file head obtained in the step 2 to generate a section for mapping the original executable file;

the section is an empty section without content, and the size of the mapping space of the loaded section in the memory is equal to the sum of the sizes of the memory mapping spaces of all the sections of the original executable file;

4) forming an encryption and decryption function code according to the original executable file;

5) generating a vectorization exception handling process code;

6) generating an executable file loading process code,

7) generating shell code sections; the shell code section includes three part codes: executable file loading process codes, vectorization exception handling process codes and encryption and decryption function codes;

8) encrypting the original executable file to obtain encrypted data of the original executable file;

9) obtaining a key table according to the executable file encrypted in the step 5;

10) generating an import function address table according to the shell code;

11) generating a shell data section according to the imported function address table, the key table and the encrypted data of the original executable file;

12) combining the new executable file header obtained in the step 2, the section for mapping the original executable file obtained in the step 3, the shell code section obtained in the step 7 and the shell data section obtained in the step 11 into a new executable file;

13) and correcting the memory mapping size value and the section table content of the head part of the new executable file according to the actual size and the address of each section.

As a further improvement of the software protection method based on vectorization exception handling of the invention:

the second step comprises the following steps:

2.1), decrypting the head of the encrypted data of the original executable file in the final executable file, and covering the head of the current executable file;

2.2) decrypting an import function address table of the encrypted data of the original executable file in the final executable file, and storing the import function address table to a corresponding position of a mapping target code section;

2.3), traversing and importing a function address table, loading a required dynamic link library, and filling a function address;

2.4) if the original executable file contains the exception handling table, decrypting the table to a corresponding position;

2.5), if the original executable file contains a Thread Local Storage (TLS) table, decrypting the table to a corresponding position;

2.6), if the original executable file contains the relocation table, decrypting the table to a corresponding position;

2.7), registering a vectorization exception handling process with the system;

2.8), setting the memory protection attribute mapping the original executable file section as inaccessible;

2.9), if the exception handling table is decrypted in the step 2.4, adding the exception handling table into a dynamic function table of the system;

2.10), if the Thread Local Storage (TLS) table is decrypted in the step 2.5, calling a TLS callback function;

2.11), the program jumps to the entry address of the original executable file.

the third step comprises:

3.1), calculating a memory page base address corresponding to the abnormal address in the abnormal processing process;

3.2) adding the base address of the memory into an address list protected by a global mutual exclusion lock, so that the exception handling function monopolizes the processing of the page at the moment;

3.3), for a multi-thread program, other threads may trigger exceptions at the same address at this time; then the global mutual exclusion lock is used for synchronization, and other threads wait for the completion of the current exception handling and then process the exception;

3.4), setting the page protection attribute of the abnormal memory to be readable and writable, so that the content of the page can be modified in the abnormal processing process;

3.5) for a multi-thread program, if the trigger exception is a data access instruction, setting the memory protection attribute to be readable and writable and cannot prevent other threads from accessing the page being modified, so that the operation of other threads must be suspended;

3.6) if the address is abnormal for the first time, decrypting the encrypted data of the original executable file obtained in the step 8 to the page; otherwise, the page content is decrypted in situ if the page has the encrypted content;

3.7) for the dynamically linked library and the process which enables the address space randomization, the first decrypted code needs to be processed for relocation; correcting the decrypted code according to the relocation table;

3.8), initializing uninitialized data decrypted for the first time by using a zero value;

3.9) setting corresponding page protection attributes according to the section attributes corresponding to the page; for example, the data segment is set to be readable and writable; for the code segment, the code segment is set to be readable and executable;

3.10), adding the page address into a decrypted address list;

3.11), removing the page base address from the global mutual exclusion lock, and canceling the monopoly of the page;

3.12), if the exception is an instruction execution exception and the address of the exception is close to the lower boundary of the memory page, specifically, is smaller than the length of the exception instruction, the next page must be decrypted; taking the initial address of the next page as an abnormal address, and returning to the step 3.4 for continuous processing;

3.13), if other threads are suspended at step 3.5, then those threads are resumed;

3.14), completing exception processing, and returning the program to the original address to continue executing.

in step 2: the new executable file header remains the same size as the original executable file header;

the header is generated by copying the header of the target executable file, setting the number of sections to 3, setting section and section data to null values, and leaving the other contents unchanged.

in step 4:

and N encryption and decryption algorithms jointly form an encryption and decryption function code in a shellcode mode, and the code size of the encryption and decryption function code is obtained, wherein the value of N is equal to the number of sections in the original executable file.

in step 9:

the key table includes three entries: memory page Relative Virtual Address (RVA), algorithm identification, and key value.

in step 11:

the way of generating the section is to modify the third section table entry of the new executable file head, and then store the imported function address table, the key table and the data generated by the encrypted data of the original executable file in the section in sequence.

in step 3.10:

judging whether the number of list items exceeds a certain limit or not; if the limit is exceeded, the page that was added to the list earliest is removed from the list, the contents of the removed page are re-encrypted, and the page protection attribute is set to inaccessible.

The software protection method based on vectorization exception handling has the technical advantages that:

the invention provides a method for encrypting and decrypting data in blocks without changing original program codes and memory positions.

By modifying the memory protection attribute, a certain page of memory is made inaccessible, and an exception is generated when a program jumps to an address in the memory page or accesses data in the memory page. The method enables the shell code to control both program execution and data access without changing the memory address of the code and data.

By registering the vectorized exception handling process, program control is preemptively obtained prior to the structured exception handling process of the program. The vectorization exception handling process encrypts and decrypts data by using the memory page as a unit, so that the whole program cannot lose protection at the same time.

And after the exception processing is finished, the program is recovered to be normally operated. The exception handling mechanism is independent of the code of the original program itself, and even if the original program modifies the code of the original program in the process of running, the execution logic of the original program is not influenced.

The invention increases the protection strength of the added shell to the software, prevents the protection from being removed through process memory dump and an automatic unshelling tool, and still ensures the compatibility of the software after the added shell.

Drawings

The following describes embodiments of the present invention in further detail with reference to the accompanying drawings.

FIG. 1 is a block diagram of a software protection method based on vectorization exception handling according to the present invention;

FIG. 2 is a block diagram of a shelled executable file;

FIG. 3 is a flowchart illustrating a software protection method based on vectorization exception handling according to the present invention;

FIG. 4 is a diagram illustrating the generation of an import function address table;

fig. 5 is a schematic diagram of a protected address list.

Detailed Description

The invention will be further described with reference to specific examples, but the scope of the invention is not limited thereto.

Embodiment 1, a software protection method based on vectorized exception handling, as shown in fig. 1 to 4, includes the following steps:

firstly, adding a shell;

step one illustrates how to apply protection to the software (executable file), which is a process of assembling code, namely assembling the shell code, exception handling code, encryption and decryption functions and keys used in the following steps, and the original software code and the like according to a format required by a normal executable file, and ensuring that the shell code is firstly operated. The sections obtained in this step, and the executable file composed of the sections, are all for the operating system to normally execute the software.

Secondly, the concrete realization of the loading process of the executable file;

step two describes how the executable file is loaded from the file to the memory after the software runs. The loading process is first the work of the operating system and then the behavior of the shell code. The shell code does some initialization work for the software. For an executable file without a shell, initialization work is directly completed by an operating system, and some initialization work must be done by a shell code instead of the system due to the change of the format of the executable file after the shell is added. In addition, the shell code also makes environmental preparation for the following exception handling, namely registering the vectorization exception handling process and setting the memory protection attribute. The result of this step is a distribution of data and code in memory that underlies the ability of software to behave in its native logic. The function of this step is to try to restore the original state of the software, except that the data is encrypted.

If vectorization exception occurs, performing vectorization exception processing:

step three is a key step, except the point that the data is encrypted, other differences with the original software are restored in step two, and step three is to restore the data in real time and in blocks in the running process of the software.

The shell adding method specifically comprises the following steps:

1, analyzing an original executable file to obtain data needing to be processed;

the processed data includes information such as the number, size, and memory protection attributes of the sections, and the correspondence between the memory mapping address of each section and the file offset.

2, generating a new executable file header according to the data needing to be processed obtained in the step 1;

the new executable header remains the same size as the original executable header.

3, generating a section for mapping the original executable file;

this section is an empty section without content, and its mapped space size in memory after loading is equal to the sum of the memory mapped space sizes of all sections of the original executable file.

The section's memory protection attributes are readable and writable.

The section is generated by modifying the first section entry of the new executable file header obtained in step 2 and setting the size and attribute of the section to the required values.

4, generating an encryption and decryption function code;

n encryption and decryption function codes are randomly selected from a plurality of pre-prepared implementation codes of encryption and decryption algorithms (such as an AES algorithm, an RC4 algorithm, SM4 in a quotient secret algorithm and the like), and are jointly formed into an encryption and decryption function code in a shellcode mode, and the code size of the encryption and decryption function code is obtained. Where the value of N is equal to the number of sections in the original executable file.

The encryption algorithm is added into the executable file in a form of 'precompiled shellcode', and the following exception handling process and executable file loading code are all described as shellcode because shellcode is a code with irrelevant memory location and can normally run no matter being placed there. This provides great convenience for assembling the code and is also common practice for various shelled protection mechanisms. The relationship between these shellcodes is equivalent to the relationship between functions in a program, i.e., mutual calling. The shell code shellcode calls an original code, the original code runs to trigger exception, the shellcode enters exception processing, and the exception processing calls encryption and decryption shellcode.

The specific method for forming the encryption and decryption function code by the N encryption and decryption algorithms is as follows:

n shellcodes are stored together end-to-end in series, and the "start address" of each shellcode (i.e., RVA as described herein) and the "start address" of the section corresponding to this shellcode and the length of the section (it has been assumed that an encryption/decryption function corresponds to one section previously) are recorded as an "encryption/decryption function entry address offset table". The table is stored at the top of shellcode. These components together form what is called an encryption/decryption function.

Encryption and decryption function entry address offset table
	Encryption and decryption algorithm shellcode1
Encryption and decryption algorithm shellcode2
	Encryption and decryption algorithm shellcode3
…………

For example. After an executable file is loaded, the memory address starts from 0x100000, the shellcode code length of the first encryption algorithm is 0x2000, and the offset is 0x12345, so that when the first encryption function is finally called, the first encryption function should be called by 0x100000+0x12345 ═ 0x 112345. The second encryption algorithm shellcode, following the first shellcode, has a starting offset of 0x12345+0x 2000-0 x 14345. The second encryption function is called using the actual address 0x 114345. And so on.

Finally, when the exception handling function needs to call the encryption and decryption functions, firstly, the 'encryption and decryption function entry address offset table' is checked. For example, to encrypt and decrypt the second section, the RVA of shellcode2 is added to the actual memory address of the executable file according to the encryption and decryption algorithm to obtain the real address of shellcode2, which is then called.

5, generating vectorization exception handling process codes;

the code of the vectorized exception handling process is a pre-compiled shellcode. At the end of which is the encryption/decryption function entry address offset table. Each entry of the offset table corresponds to an offset of an entry address of an encryption/decryption function from a starting address of the shellcode.

Encryption and decryption function entry address: the shellcode is stored sequentially, with the start of the previous shellcode, plus its length (i.e., the size of the code), being the start of the next shellcode.

The pre-compiled shellcode is the exception handling code itself.

The results after code combining are as follows:

exception handling shellcode
	Encryption and decryption function entry address offset table
Encryption and decryption algorithm shellcode1
	Encryption and decryption algorithm shellcode2
Encryption and decryption algorithm shellcode3
	…………

After the encryption and decryption functions and their code sizes are determined in step 4, the address offsets of these functions are also determined. The address offset table is populated with the actual offsets of the functions.

6, generating executable file loading process codes;

the executable file loader code is a pre-compiled shellcode that includes the Relative Virtual Address (RVA) of the vectorized exception handling function entry. The loading process obtains the entry address of the vectorized exception handling function by adding the RVA value to the base address of the memory image of the new executable file (determined by the operating system).

In the initial state, the value of RVA is uncertain and is present in shellcode as a unique value, e.g., 0x 12345678. In the case of a 64-bit executable file, the length of the unique value is 64 bits, e.g., 0x1234567890 ABCDEF.

When the executable file is generated, the Relative Virtual Address (RVA) of the vectorized exception handling function entry is finalized. The unique value is replaced by the actual RVA value by means of a lookup and replacement.

Determining the Relative Virtual Address (RVA) of a function entry is the logic: the RVA of the section in which the function code is located is first determined. The vectorization exception handling function is in a shell code section, two pieces of data are arranged in front of the shell code section, namely an executable file head and an original executable file memory mapping section, the sizes of the two pieces of data are related to the size of an original file, and the sizes of the two pieces of data are described in steps 2 and 3. The RVA of a shell code section is the sum of the two data sizes:

RVA of a shell code section is the executable header size + original executable memory map section size

Then, the vectorized exception handling function and the encryption and decryption codes are shellcode, which are stored in the sections in sequence, and their code sizes are known, so that their offsets from the beginning of the section are also determined, i.e., the first one is 0, and the latter one is the previous offset plus the previous one. Finally, the RVA of a section plus the offset of the shellcode from the beginning of the section is the RVA of the shellcode. Here, the vectorized exception handling function is the first shellcode arranged in a section, so its RVA is equal to the RVA of the section:

RVA of shell code section for vectorized exception handling function entry

The vectoring exception handling function is followed by an encryption/decryption function, then its RVA is the RVA of the section plus the size of the vectoring exception handling function. The RVA of each encryption and decryption function is calculated in turn to obtain:

the encryption and decryption function RVA ═ the new executable header obtained in step 2 + the section size obtained in step 3 for mapping the original executable.

7, generating shell code sections;

the shell code section includes three part codes: executable file loading process code, vectorized exception handling process code, and encryption and decryption function code.

The section is generated by modifying the second section entry of the new executable file header to a size that can accommodate the code (the size is equal to the sum of the sizes of the codes obtained in steps 4, 5 and 6), and setting the memory protection attribute of the section to be readable and executable.

And then the codes generated in the step 6, the step 5 and the step 4 are sequentially stored in the sections.

8, encrypting the original executable file to obtain original executable file encrypted data;

the original executable file is loaded in the form of a memory map, and the memory map is sequentially encrypted in units of the size (4KB) of the memory page.

In step 4, several encryption algorithms equal to the number of sections of the original executable file are selected, one for each section. The encryption algorithm for the executable header is the same as for the first section.

And encrypting the memory mapping of the original executable file to obtain data, namely the encrypted data of the original executable file. The latter is also in units of memory page size (4 KB). The 4KB data on the file corresponds to a memory page data in the memory. So the two are in one-to-one correspondence. How many pages there are in the original executable file, and how many pages there are in the encrypted memory. And calculating one page when the data end is less than one page.

9, generating a key table;

each memory page encrypted in step 8 uses a different randomly generated key. All keys and the algorithm identifications of the corresponding sections form a key table. The key table includes three entries: memory page Relative Virtual Address (RVA), algorithm identification, and key value.

10, generating an import function address table;

and generating an import function address table in a standard format of an executable file according to an external function (API) used by the shell code.

An external function (API) is determined according to the function of the shell code. For example, the shell code needs to modify the memory protection attribute, register a vectorized exception handling function, and add a dynamic function table list instead of the operating system, which are all implemented by calling corresponding APIs.

The external function is converted into a standard format, and specifically, an address table of the import function is generated. The format of this table is canonical. As depicted in fig. 4;

the IMPORT function address table is generated, and only the IMAGE _ IMPORT _ describe table and the IMAGE _ IMPORT _ BY _ NAME table in the figure and the IMAGE _ count _ DATA structure corresponding to each function need to be constructed according to the external function NAME (for example, ReadFile) and the NAME of the dynamic library (for example, kernell 32. dll). Others are fixed or may be calculated. When the executable file is loaded by the operating system, the operating system is responsible for handling the import address table)

11, generating a shell data section;

the shell data section includes three parts of data: and importing a function address table, a key table and the encrypted data of the original executable file.

The section is generated by modifying the third section table entry of the new executable file header to make the size of the third section table entry capable of accommodating the data, and setting the memory protection attribute of the section to be readable and writable.

And then the data generated in the step 10, the step 9 and the step 8 are sequentially stored in the section.

12, generating a new executable file;

the new executable file comprises four main parts, namely an executable file head part, a mapping target code section, a shell code section and a shell data section in sequence from low to high according to the memory address. There are two optional parts after the main part: resource section and additional data area.

And combining the contents generated in the steps 2, 3, 7 and 11 into an executable file in sequence.

If the original executable file contains resources and additional data that must be kept in the clear. They are added to the resource section and the additional data area and the number of sections in the file header is increased.

And 13, repairing the executable file to obtain a final executable file.

And correcting the memory image size value and the section table content of the head part of the new executable file according to the actual size and address of each section.

The entry address is directed to an entry of the executable file loading process.

The specific implementation of the loading process of the executable file is as follows:

the executable file loading process is responsible for reading and decrypting some of the contents of the original executable file, initializing the contents of the sections of the original executable file that are mapped, and registering the vectorized exception handling process with the system. The method comprises the following specific steps:

and 1, decrypting the head of the encrypted data of the original executable file in the final executable file, and covering the head of the current executable file.

And 2, decrypting the import function address table of the encrypted data of the original executable file in the final executable file, and storing the import function address table to the corresponding position of the mapping target code section. The location is calculated from the section table and directory table of the header.

And 3, traversing the imported function address table, loading the required dynamic link library and filling the function address.

And 4, if the original executable file contains the exception handling table, decrypting the table to the corresponding position.

If the original executable contains a Thread Local Store (TLS) table, then the table is decrypted to the corresponding location.

6, if the original executable file contains the relocation table, decrypting the table to the corresponding location.

And recording the specific positions of the exception handling table, the thread local storage table and the relocation table in the executable file head of the original executable file. Step 3 has generated the size of the section used to map the original executable file, this section being the same size as the original executable file. Therefore, all data in the original executable file have the same offset location in this section. "decrypting the table to the corresponding location" means that the data is decrypted and stored in the same location as the original offset of the data in the section mapping the original executable file.

And 7, registering a vectorized exception handling process with the system, so that the vectorized exception handling process can be called by an operating system when the exception occurs in the program execution and is used for solving the exception, wherein the code of the vectorized exception handling process is generated in the step 5 of the shell adding method.

And 8, setting the memory protection attribute mapping the original executable file section as inaccessible.

9, if the exception handling table is decrypted in step 4, adding the exception handling table to a dynamic function table (dynamic function table) of the system.

10, if the TLS table is decrypted in step 5, calling the TLS callback function.

11, the program jumps to the entry address of the original executable file.

An exception may occur when the program jumps to the entry address of the original executable file, after which the program enters a vectorized exception handling process.

The vectorization exception handling process is implemented specifically as follows:

1, calculating a memory page base address corresponding to the abnormal address in the exception handling process.

2, adding the base address of the memory into an address list protected by a global mutual exclusion lock, so that the exception handling function monopolizes the processing of the page at the moment.

The mutex lock is a synchronous mechanism when operating shared data, and when one thread occupies the mutex lock, other competitors cannot operate data. The protected address list is a list of entries that can be added and deleted. Each entry represents a memory page, and the contents of the entry include a memory page starting address and a list of threads waiting to process the page of memory. As shown in fig. 5;

assume that an exception occurs at address 0x112233, the base address of this address is 0x 112000. Attempting to acquire the mutex until successful, traverse the "protected address list" to see if there is 0x112000 in it. If there is no 0x112000 in the protected address list, then 0x112000 is added to the protected address list, and the mutex is released and the exception is handled. If there is already 0x112000 in the list, the current thread is added to the waiting thread list of 0x112000 this entry, then the mutex lock is released and the current thread's execution is suspended.

After exception handling is complete, an attempt is made to acquire the mutex until it is successful, find the 0x112000 entry, if the waiting thread list is not empty, indicating that there are other threads waiting to process the page, move the first thread in the thread list out of the list and wake it up, and then release the mutex. If the waiting thread list is empty, then 0x112000 of this entry is deleted, releasing the mutex lock. And ending the exception handling.

When the previously suspended thread is awakened, the thread continues to handle the exception. Then, the mutex lock is seized and the next waiting thread is awakened. If there is no next waiting thread, then 0x112000 of this entry is deleted. And finally, releasing the mutual exclusion lock and ending the exception handling.

3, for a multi-threaded program, there may be other threads that trigger exceptions at the same address at this time. Then the global mutex lock is used for synchronization, and other threads wait for the completion of the current exception handling and then handle the exception handling.

And 4, setting the page protection attribute of the abnormal memory to be readable and writable, so that the content of the page can be modified in the abnormal processing process.

For a multi-threaded program, if the exception is triggered by a data access instruction, the memory protection attribute is set to read-writable and cannot prevent other threads from accessing the page being modified, so that the other threads must be suspended.

And 6, if the address is abnormal for the first time, decrypting the encrypted data of the original executable file obtained in the step 8 to the page. Otherwise, the page content is decrypted in situ.

"original content" refers to "encrypted data of the original executable file" obtained by "encrypting the original executable file" in the previous step 8. This "original content" is originally stored in the area of the "original executable encrypted data" inside the "shell section" (i.e., step 11, the shell section is generated). When the exception occurs for the first time, the exception handling process decrypts the data into the memory mapping section of the original executable file. This subsequent processing (encryption and decryption) of the page of data occurs in the "original executable memory map section" and only for the first time is it necessary to obtain the data from the "original executable encrypted data".

For dynamically linked libraries and processes that enable address space randomization, the first decrypted code needs to handle relocation. And correcting the decrypted code according to the relocation table.

And 8, initializing with a zero value for the uninitialized data decrypted for the first time.

And 9, setting a corresponding page protection attribute according to the section attribute corresponding to the page. Such as for data segments, are arranged to be readable and writable. The code segment is arranged to be readable and executable.

10, adding the page address into the decrypted address list. It is determined whether the number of list items exceeds a certain limit. This limit may be one percent of the total number of pages mapped in the executable file. If the limit is exceeded, the page that was added to the list earliest is removed from the list, the contents of the removed page are re-encrypted, and the page protection attribute is set to inaccessible.

And 11, removing the page base address from the global exclusive lock, and canceling the exclusive ownership of the page.

If the exception that occurs is an instruction execution exception and the address of the exception is adjacent to the lower boundary of the memory page, specifically less than the length of the excepting instruction, then the next page must also be decrypted. The next page start address is regarded as the abnormal address, and the process returns to the step 4 to continue processing.

13 if other threads are suspended at step 3.5, those threads are resumed at this point.

And 14, completing exception processing, and returning the program to the original address to continue execution.

Finally, it is also noted that the above-mentioned lists merely illustrate a few specific embodiments of the invention. It is obvious that the invention is not limited to the above embodiments, but that many variations are possible. All modifications which can be derived or suggested by a person skilled in the art from the disclosure of the present invention are to be considered within the scope of the invention.

Claims

1. The software protection method based on vectorization exception handling is characterized in that: the method comprises the following steps:

firstly, adding a shell to an executable file;

secondly, loading an executable file;

2. The vectorized exception handling based software protection method according to claim 1, further comprising:

the first step comprises the following steps:

5) generating a vectorization exception handling process code;

6) generating an executable file loading process code,

10) generating an import function address table according to the shell code;

3. The vectorized exception handling based software protection method according to claim 2, characterized in that:

the second step comprises the following steps:

2.7), registering a vectorization exception handling process with the system;

2.11), the program jumps to the entry address of the original executable file.

4. The vectorized exception handling based software protection method according to claim 3, further comprising:

the third step comprises:

3.10), adding the page address into a decrypted address list;

5. The vectorized exception handling based software protection method according to claim 4, wherein:

6. The vectorized exception handling based software protection method according to claim 5, further comprising:

in step 4:

7. The vectorized exception handling based software protection method according to claim 6, further comprising:

in step 9:

8. The vectorized exception handling based software protection method according to claim 7, further comprising:

in step 11:

9. The vectorized exception handling based software protection method according to claim 8, further comprising:

in step 3.10: