A virus program reverse analysis method and device

Abstract

The present invention discloses a method and device for reverse analysis of a virus program, the method comprising: reverse debugging the virus program, determining a first memory address where the core data of the virus program is located; based on a function VirtualProtect(), setting the first memory address as invalid memory; executing the assembly code of the virus program line by line, and based on a VEH exception handling function, obtaining a target assembly code and a second memory address of the target assembly code when an operation exception occurs; based on the second memory address, obtaining module information of a module where the target assembly code is located; saving the target assembly code and the module information of the module where the target assembly code is located to a preset module file; based on a function VirtualProtect(), setting the first memory address as valid memory, and executing a target assembly instruction; based on a function VirtualProtect(), setting the first memory address as invalid memory, and executing the assembly code of the next virus program. The present invention can automatically obtain assembly code and module information, thereby improving analysis efficiency.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a virus program reverse analysis method and device. Background Art

[0002] When reverse-analyzing and debugging a virus program, the virus program usually decrypts the core data and then uses or encrypts the data for reporting. This prevents the original data from being analyzed clearly. In addition, due to the particularity of the virus program, it does not use various traditional formal encryption algorithms to encrypt and decrypt data, such as AES (Advanced Encryption Standard), DES (Data Encryption Standard) and other standard algorithms. It will modify the existing encryption algorithm and then encrypt it, or it will use its own encryption algorithm for encryption. As a result, even if the analyst gets the secret key, he cannot encrypt or decrypt before obtaining the encryption algorithm.

[0003] The existing reverse analysis scheme is to debug the encrypted data step by step and copy the instructions one by one to a notepad or other document to record all the operation instructions, and also record all the modules and other information. Although the current scheme can perform reverse analysis of virus programs, it cannot realize automatic recording, which is time-consuming and laborious. Summary of the invention

[0004] In view of the above problems, the present invention proposes a virus program reverse analysis method and device, which can realize the automatic control of the program reverse analysis process, can automatically obtain assembly code and module information to form a module file, and does not require manual copying operations, thereby improving analysis efficiency.

[0005] In the first aspect, the present application provides the following technical solutions through an embodiment of the present application:

[0006] A virus program reverse analysis method, comprising:

[0007] Reverse debugging the virus program to determine a first memory address where the core data of the virus program is located;

[0008] Based on the function VirtualProtect(address, size, PAGE_NOACCESS, & OldProtect), the first memory address is set as invalid memory; wherein address is the memory start address of the first memory address, and size is the size of the first memory address; PAGE_NOACCESS is used to set the first memory address to be inaccessible; OldProtect is used to save the property of the first memory address before;

[0009] Execute the assembly code of the virus program line by line, and based on the VEH exception handling function, obtain the target assembly code and the second memory address of the target assembly code when an operation exception occurs; wherein the target assembly code is the currently executed assembly code, the second memory address is the memory address of the target assembly code, and the operation exception is triggered when the target assembly code accesses the first memory address;

[0010] Based on the second memory address, obtaining module information of the module where the target assembly code is located;

[0011] Saving the target assembly code and the module information of the module where the target assembly code is located in a preset module file;

[0012] Based on the function VirtualProtect(address, size, PAGE_READWRITE, &OldProtect), the first memory address is set as valid memory, and the execution of the target assembly instruction is completed; wherein PAGE_READWRITE is used to set the first memory address to be accessible;

[0013] Based on the function VirtualProtect(address, size, PAGE_NOACCESS, &OldProtect), the first memory address is set as invalid memory to continue executing the next assembly code of the virus program.

[0014] Optionally, when an operation exception occurs based on the VEH exception handling function, obtaining the target assembly code and the second memory address of the target assembly code includes:

[0015] Based on the function AddVectoredExceptionHandler(0, VectoredHandler), the operation exception of the target assembly code is captured, and the target assembly code and the second memory address are obtained; wherein 0 indicates that the operation exception is processed first, and VectoredHandler is used to obtain the second memory address;

[0016] The module information includes a module name; and obtaining the module information of the module where the target assembly code is located based on the second memory address includes:

[0017] Based on the second memory address, the module name is obtained using the interface getModuleName().

[0018] Optionally, before saving the target assembly code and the module information of the module where the target assembly code is located in a preset module file, the method further includes:

[0019] Calculate the crc32hash of the module name to obtain the calculation result;

[0020] Determine a first target byte from the calculation result, and determine the file name of the module file based on the first target byte; the first target byte is any byte in the calculation result;

[0021] The determining of the file name of the module file comprises: determining whether there is a file name identical to the first target byte in the module file; if so, determining a second target byte different from the first target byte from the calculation result, and determining the file name of the module file based on the second target byte;

[0022] After the single byte in the calculation result is judged, a first combination byte is determined from the calculation result; the first combination byte is any two bytes in the calculation result and increases in sequence; and the file name of the module file is judged based on the second target byte;

[0023] Repeat the file name determination of the module file until non-repeated bytes are obtained;

[0024] The non-repeated bytes are used as the file name of the module file.

[0025] Optionally, before obtaining the module name based on the second memory address and using the interface getModuleName(), the method further includes:

[0026] Determine whether the preset static variables are assigned;

[0027] If not, traverse the modules of the virus program, and assign the module name, the starting address, and the ending address of each module to the static variables;

[0028] The method of obtaining the module name based on the second memory address and using the interface getModuleName() includes:

[0029] Based on the second memory address, the module name is queried in the static variable using the interface getModuleName().

[0030] Optionally, after assigning the module name, the starting address, and the ending address of each module to the static variable, the method further includes:

[0031] Hooking the module loading function and the module unloading function in the system where the virus program is running, so as to monitor the module loading or unloading of the virus program;

[0032] When the module of the virus program is loaded or unloaded, the module of the virus program is traversed and the static variable is reassigned.

[0033] Optionally, the module information includes: a module offset; and obtaining the module information of the module where the target assembly code is located based on the second memory address includes:

[0034] Based on the offset between the second memory address and the starting address of the module, obtaining the module offset of the module where the target assembly code is located;

[0035] The step of saving the target assembly code and the module information of the module where the target assembly code is located into a preset module file includes:

[0036] The target assembly code and the module information of the module where the target assembly code is located are saved in an intermediate file; wherein the intermediate file is a temporary file;

[0037] Based on the module offset of the module where the target assembly code is located, determining whether the module information is complete;

[0038] Based on the format of the target assembly code, determining whether the content of the target assembly code itself is complete;

[0039] If the module information and the contents of the target assembly code are both complete, the intermediate file is saved in a preset module file.

[0040] In the second aspect, based on the same inventive concept, the present application provides the following technical solution through an embodiment of the present application:

[0041] A virus program reverse analysis device, comprising:

[0042] A determination module, used for reverse debugging the virus program and determining a first memory address where the core data of the virus program is located;

[0043] A first setting module is used to set the first memory address as invalid memory based on the function VirtualProtect(address, size, PAGE_NOACCESS, & OldProtect); wherein address is the memory start address of the first memory address, and size is the size of the first memory address; PAGE_NOACCESS is used to set the first memory address to be inaccessible; and OldProtect is used to save the property of the first memory address before;

[0044] A first acquisition module is used to execute the assembly code of the virus program line by line, and based on the VEH exception handling function, acquire the target assembly code and the second memory address of the target assembly code when an operation exception occurs; wherein the target assembly code is the currently executed assembly code, the second memory address is the memory address of the target assembly code, and the operation exception is triggered when the target assembly code accesses the first memory address;

[0045] A second acquisition module, used for acquiring module information of the module where the target assembly code is located based on the second memory address;

[0046] A saving module, used for saving the target assembly code and the module information of the module where the target assembly code is located into a preset module file;

[0047] A second setting module is used to set the first memory address as valid memory based on the function VirtualProtect(address, size, PAGE_READWRITE, &OldProtect), and complete the execution of the target assembly instruction; wherein PAGE_READWRITE is used to set the first memory address to be accessible;

[0048] The third setting module is used to set the first memory address as invalid memory based on the function VirtualProtect (address, size, PAGE_NOACCESS, & OldProtect) to continue executing the next assembly code of the virus program.

[0049] Optionally, the first acquisition module is further used to:

[0050] Based on the function AddVectoredExceptionHandler(0, VectoredHandler), the operation exception of the target assembly code is captured, and the target assembly code and the second memory address are obtained; wherein 0 indicates that the operation exception is processed first, and VectoredHandler is used to obtain the second memory address;

[0051] The module information includes a module name; and obtaining the module information of the module where the target assembly code is located based on the second memory address includes:

[0052] Based on the second memory address, the module name is obtained using the interface getModuleName().

[0053] In the third aspect, based on the same inventive concept, the present application provides the following technical solution through an embodiment of the present application:

[0054] A virus program reverse analysis device comprises a processor and a memory, wherein the memory is coupled to the processor and stores instructions, and when the instructions are executed by the processor, the user terminal executes the steps of any one of the methods described in the first aspect.

[0055] In the fourth aspect, based on the same inventive concept, the present application provides the following technical solution through an embodiment of the present application:

[0056] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of any one of the methods described in the first aspect above.

[0057] A virus program reverse analysis method and device provided by an embodiment of the present invention determines a first memory address where core data of the virus program is located by reverse debugging the virus program; then, based on the function VirtualProtect(address, size, PAGE_NOACCESS, &OldProtect), the first memory address is set to invalid memory, so that an operation exception occurs when the assembly code of the virus program accesses the core data in the first memory address. Furthermore, the assembly code of the virus program is executed line by line, and based on the VEH exception handling function, the target assembly code and the second memory address of the target assembly code are obtained when an operation exception occurs; the target assembly code is the currently executed assembly code, the second memory address is the memory address of the target assembly code, and the operation exception is triggered when the target assembly code accesses the first memory address; based on the second memory address, the module information of the module where the target assembly code is located is obtained; further, the target assembly code and the module information of the module where the target assembly code is located are saved in a preset module file, thereby realizing the analysis and storage of the target assembly code; finally, based on the function VirtualProtect(address, size, PAGE_READWRITE, &OldProtect), the first memory address is set as valid memory, and the execution of the target assembly instruction is completed. After completing the execution of the target assembly instruction, the first memory address is set to invalid memory based on the function VirtualProtect (address, size, PAGE_NOACCESS, & OldProtect) to continue to execute the next assembly code of the virus program, ensure the cyclic execution of the assembly instruction of the virus program, continuously trigger the operation exception and obtain the module information and assembly code. The present invention sets invalid memory for the first memory address where the core data is located, and automatically obtains the target assembly code and its module information when the operation exception is triggered. After the acquisition is completed, the first memory address is set to valid, so that this section of the target assembly code completes the access to the core data. Repeatedly setting the first memory address invalid and executing the next section of the assembly code until the execution of all the assembly codes is completed, the entire analysis process is automatically controlled, and the assembly code and module information can be automatically obtained to form a module file without manual copying operations, thereby improving the analysis efficiency.

[0058] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. Moreover, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0060] Figure 1 A flowchart of a virus program reverse analysis method provided by the first embodiment of the present invention is shown;

[0061] Figure 2 A schematic diagram of the structure of a virus program reverse analysis device provided by the second embodiment of the present invention is shown. DETAILED DESCRIPTION

[0062] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0063] First embodiment

[0064] See also Figure 1 , shows a flow chart of a method for reverse analysis of a virus program. The steps of the method are as follows:

[0065] Step S10: reverse debugging the virus program to determine the first memory address where the core data of the virus program is located.

[0066] In step S10, the virus program can be debugged and analyzed by a debugging tool to find the first memory address where the corresponding core data is located. For example, the virus program collects the user's account information and password information, and encrypts and reports these data to the server of the virus program. Then the account information and password information are the core data. The first memory address of the memory where these data are located and the data length of these data can be found. Specifically, in this embodiment, reverse debugging tools such as windbg (a tool software) and ollydbg (a tool software) can be used without limitation.

[0067] Step S20: Based on the function VirtualProtect(address, size, PAGE_NOACCESS, & OldProtect), the first memory address is set as invalid memory; wherein address is the memory starting address of the first memory address, and size is the size of the first memory address; PAGE_NOACCESS is used to set the first memory address inaccessible; and OldProtect is used to save the properties of the previous first memory address.

[0068] In the existing technical solutions, the memory where the core data is located is a normal and valid memory. When analyzing the virus program, the reverse analysis tool is used to execute the assembly code step by step to analyze the operation of the core data in the first memory address. Finally, the assembly code of the corresponding operation is recorded. This method cannot realize automatic processing and requires manual operation one by one, which is time-consuming and laborious.

[0069] In this regard, in step S20, the system function VirtualProtect() is used to set the first memory address where the core data is located as invalid memory, so that when the assembly code of the virus program reads and writes the data in the memory segment, an operation exception will be triggered. When the exception is triggered, the assembly code that generates the operation exception can be determined. Step S30 is further executed.

[0070] Step S30: Execute the assembly code of the virus program line by line, and based on the VEH exception handling function, obtain the target assembly code and the second memory address of the target assembly code when an operation exception occurs; wherein the target assembly code is the currently executed assembly code, the second memory address is the memory address of the target assembly code, and the operation exception is triggered when the target assembly code accesses the first memory address.

[0071] In step S30, when an operation exception occurs, the first memory address is accessed for the currently executed target assembly code. For example, the core data is encrypted, decrypted, copied, sent, etc. More specifically, the specific method of obtaining the second memory address of the target assembly code through the VEH exception handling function can be as follows:

[0072] Based on the function AddVectoredExceptionHandler(0, VectoredHandler), the operation exception of the target assembly code is captured and the second memory address is obtained; wherein, the first parameter in the function AddVectoredExceptionHandler() indicates the order of exception handling, 0 indicates that the operation exception is handled first, and the function VectoredHandler is used to obtain the second memory address. Specifically, through ExceptionInfo->ExceptionRecord->ExceptionCode==STATUS_ACCESS_VIOLATION, the target assembly code during execution protection can be obtained; further, through ExceptionInfo->ExceptionRecord->ExceptionAddress, the second memory address when the operation exception occurs can be determined, which corresponds to the target assembly code for the operation of the first memory address. The automatic acquisition of the target assembly code and the second memory address is realized.

[0073] Step S40: Based on the second memory address, the module information of the module where the target assembly code is located is obtained.

[0074] In step S40, the module information may include the module name. The module information can be obtained by querying the module name through the interface function string name = getModuleName (ExceptionAddress). However, since it is necessary to record each assembly code that operates on the core data. In the virus program, in order to increase the complexity of the program, the virus program may use multiple modules to encrypt and decrypt the core data, thereby increasing the complexity of the data operation. Therefore, the above-mentioned recorded assembly codes may belong to different modules. In order to facilitate the subsequent restoration algorithm, it is necessary to know the module to which each assembly code belongs. In this embodiment, a secondary interface is provided to query the module to which each assembly code belongs. The specific implementation is as follows:

[0075] String getModuleName(uint64_t address); where address is the second memory address where the assembly code is located, and the return value uint64_t is the module name where this assembly code is located. Furthermore, although the above interface can implement the query operation, querying this interface will query each assembly code. This is a very frequent operation, which will seriously affect the performance of the execution system and is inefficient. In this regard, in this embodiment, static variables are defined before step S40. For example, through Static map<string,moduleinfo> mapModule, define a static variable mapModule to save module information. Before querying, you can judge the static variable to confirm whether the static variable is assigned; for example, judge by If(mapModule.empty()). If the static variable is not assigned, traverse the modules of the virus program, and assign the module name, module start address, and module end address of each module to the static variable. When querying the module name, you can query in the static variable without traversing the module again. Only when the module changes, traverse the module again to assign the static variable. Specifically: Hook the module loading function and unloading function in the system where the virus program is running to monitor the module loading or unloading of the virus program; when the module of the virus program is loaded or unloaded, traverse the module of the virus program and reassign the static variable.

[0076] For example:

[0077] HANDLE hSnapshot = CreateToolhelp32Snapshot (TH32CS_SNAPMODULE, 0); Get the module snapshot information, and then traverse all modules in the snapshot.

[0078] BOOL bRet=Module32First(hSnapshot,&mi);

[0079] while(bRet){bRet=Module32Next(hSnapshot,&mi);

[0080] mi contains the module name, the starting address of the module in memory and the size of the module.

[0081] mapModule[mi.szModule]=moduleinfo(mi.baseaddr,mi.baseaddr+mi.size);

[0082] Among them, mi.szModule is the module name of the module, mi.baseaddr is the starting address of the module, and mi.baseaddr + mi.size is the ending address of the module. Then, for each assembly code query, it traverses the module information of the static variable mapModule to check the second memory address address of this assembly code. If address > mi.baseaddr and address < mi.baseaddr + mi.size, it means that this address belongs to the mi.szModule module.

[0083] In this embodiment, each assembly code will query this interface. To improve the query efficiency, traversing all modules each time to obtain module information will cause performance lag. To ensure the accuracy of the data in the static variable mapModule, in this embodiment, the system's module loading function LoadLibrary and module unloading function FreeLibrary are hooked. Once a module of a virus program is loaded or unloaded, it traverses all modules of the virus program again to update mapModule to ensure that the data in the static variable is the latest.

[0084] The module information also includes: module offset. Step S40 includes: obtaining the module offset of the module where the target assembly code is located based on the offset between the second memory address and the starting address of the module. After the virus program is closed or crashes and restarts, the second memory address will be reloaded to other memory locations. At this time, only the module offset remains unchanged, and it can be determined whether the target assembly code has been obtained and saved through the module offset.

[0085] Step S50: Save the target assembly code and the module information of the module where the target assembly code is located to a preset module file.

[0086] In step S50, since the target assembly code is the executed assembly code, each assembly code in the virus program will be executed. Therefore, the relevant information of all assembly codes accessing the first memory will be recorded. And the operations on the above core data may belong to different modules and may also exist in different threads. Therefore, in this embodiment, a general file directory can be designed to store the storage file information of the general module information. The operations of each module on the core data belong to each module, so the assembly codes of each module need to be stored together. The general directory file stores the file information of each module. In this embodiment, the module file is used to store the file information of each module.

[0087] Each module is independent and may perform encryption and decryption operations on core data, while the assembly code in a module is a whole. When writing a program, a function is used as a unit, not an assembly code. Therefore, in order to distinguish the assembly code of each module, the assembly code of each module can be saved in an independent module file corresponding to each module, so that the assembly code is easy to read. Further, considering that the name of each module in the virus program is unique, and because the length of the module name is different, and the number of modules is limited. In this embodiment, a hash algorithm can be used to determine an integer for naming the module file. In a preferred implementation, a crc32hash (cyclic redundancy check 32hash) is calculated for the module name to obtain a calculation result, which is an integer, and this integer is used to name the module file.

[0088] Among them, the purpose of using crc32hash is: this algorithm is faster than other hash algorithms such as md5, and the result that can be obtained is a 4-byte integer, while other algorithms such as md5 are a number of more than 16 bytes. Using crc32hash will increase the search speed and occupy less byte data. At the same time, the module names in this article are limited and hash collisions are not easy to occur. Then the name of the module file that saves the assembly code of each module is Filename = crc32hash (modleName). In order to further improve the search speed and reduce the size of the memory occupied, we can select the first byte of the crc32hash result, and pre-calculate the crc32hash values ​​of all module names for all modules in advance to see if there are 2 different module names. If the corresponding byte selected in the calculation result is not repeated, directly select the currently determined byte. If there is a repetition, try to select the second byte. If there is no repetition, the second byte shall prevail. And so on, select the third byte and the fourth byte. If any byte is repeated, then we select 2 bytes, such as selecting the first and second bytes as the final result, and use the above judgment process again. And so on, if there are repetitions, select 3 bytes or 4 bytes.

[0089] Specifically, the module name is calculated with crc32hash to obtain a calculation result; a first target byte is determined from the calculation result, and a file name of the module file is determined based on the first target byte; the first target byte is any byte in the calculation result; the file name determination of the module file includes: determining whether there is a file name identical to the first target byte in the module file; if so, determining a second target byte different from the first target byte from the calculation result, and a file name determination of the module file is performed based on the second target byte; after a single byte in the calculation result is determined, a first combination byte is determined from the calculation result; the first combination byte is any two bytes in the calculation result and increases in sequence; and the file name of the module file is determined based on the second target byte; the file name determination of the module file is repeated until non-repeated bytes are obtained; and the non-repeated bytes are used as the file name of the module file.

[0090] This further improves the search speed and reduces the size of the memory occupied.

[0091] Furthermore, in order to better distinguish and identify the module name, in this embodiment, the squared value of the data obtained after calculating the crc32hash of the module name can be used as the name of the module file.

[0092] Regarding the storage format of the file content, each assembly code in this embodiment can be stored as one line of the module file, and multiple assembly codes form a function, and each function has a function header and a function tail.

[0093] The first thing stored in each row is the module offset of the target assembly code in the module to which it belongs, that is, the relative address of the target assembly code in the module. The specific formula algorithm is: module offset of target assembly code = address of assembly code in memory - starting address of module in memory.

[0094] When the compiler compiles a function, each function header operates on the stack of the current function, and the function tail restores the stack, so we can analyze whether each assembly code is a function header or a function tail. If it is a function tail, we write only the function length information, and the assembly code of the next function starts at a new line number, thus separating each function for easy reading. A line of the module file content is as follows:

[0095] INT, interrupt instruction, is a specific assembly instruction. It is used to mark this file as an assembly code storage file. Because there is no INT instruction in normal assembly code, each file storing assembly instructions is marked with INT at the beginning. It is mainly to prevent users or other program files from modifying the module file and thus not being an assembly code file.

[0096] Modulename, module name. One function is to prevent the directory file from being lost and to rebuild the directory file by this name. At the same time, it can also be used to know which module the assembly instructions of this file are.

[0097] Offset time, Offset is the module offset of the target assembly code. Each function starts with the memory offset of the first assembly instruction and is named after the offset. The time field is the moment of the target assembly code, so the operation order of the function can be sorted based on time.

[0098] Offset code asm, Offset is the module offset of the target assembly code, code is the machine code of the target assembly code, and asm is the readable target assembly code. Since the assembly code is a series of hexadecimals, if it needs to be readable by humans, it needs to be decoded into readable assembly code asm. Specifically, code can be translated into asm code by using an assembly engine.

[0099] Num Len, Num is the number of instructions. Len = the offset of the last instruction - the offset of the first instruction at the beginning + the length of the last instruction. The number of instructions and the total memory size of this function are stored at the end of each function.

[0100] Since the offset of each module loaded into memory is different each time, only relative offsets can be stored. Therefore, the next time the program is started, the address of the module loaded into memory may be different, so the absolute memory address of each assembly code is different. Therefore, using the module offset of the assembly code in the module can ensure that the module offset is the same each time. If the program crashes, we will read this file every time and read the information corresponding to each assembly code to avoid writing duplicate data into the file. The memory address and module offset can be used to distinguish whether the data content corresponding to a certain assembly code has been written into the file.

[0101] Since the virus program may crash at any time, if we write a file, it may cause the program to crash halfway through writing, resulting in problems with the program data. This embodiment provides a solution: before saving the target assembly code and the module information of the module where the target assembly code is located into a preset module file, it also includes: saving the target assembly code and the module information of the module where the target assembly code is located into an intermediate file; the intermediate file is a temporary file; based on the module offset of the module where the target assembly code is located, judging whether the module information is complete; based on the format of the target assembly code, judging whether the content of the target assembly code itself is complete; if the module information and the content of the target assembly code itself are complete, then saving the intermediate file into the preset module file.

[0102] For example, each time you write a file, you can first write a temporary file. The name of the temporary file needs to be the same as the name of the formal file. You can add a temp as the end of the file to indicate that it is a temporary file. At the same time, after reading the temporary file, you can determine whether each piece of data is complete by calculating the module offset of the assembly code. At the same time, you can determine whether the assembly code is complete by the format of the assembly code. Finally, verify whether the content of the temporary file is complete. Then write to the temp file, that is, the temporary file. When the temp file is complete, replace the formal file, that is, save the temporary file to the formal module file. Because temp is written to the file, its content is the latest. This can encode the loss of analysis data after the virus program crashes. The analysis can continue the next time the virus program is started.

[0103] Step S60: Based on the function VirtualProtect(address, size, PAGE_READWRITE, &OldProtect), the first memory address is set as valid memory, and the execution of the target assembly instruction is completed; wherein PAGE_READWRITE is used to set the first memory address to be accessible.

[0104] By ensuring that the first memory address is accessible through step S60, the target assembly instruction can be executed completely.

[0105] Step S70: Based on the function VirtualProtect (address, size, PAGE_NOACCESS, & OldProtect), the first memory address is set to invalid memory to continue executing the next assembly code of the virus program.

[0106] In step S70, the next assembly code is executed, that is, steps S30-S70 are repeated until all assembly codes in the virus program are executed, thereby realizing automatic acquisition of each assembly code and corresponding module information without manual copying operations, thereby improving efficiency.

[0107] At this time, in the process of repeatedly executing steps S30-S70, each time a module file corresponding to a module is completed, the module file can be saved to the general directory until the module files of all modules are saved to the general directory. This is to facilitate the query of the corresponding files and the overall management of the assembly code problems of each module. At the same time, it can also check whether each file is damaged, and delete the damaged files. Similarly, since the file is written, the file may be damaged when the virus program crashes. Therefore, a backup strategy for the general directory file is required here. As follows:

[0108] Similarly, the general directory file contains two files. One is a formal file and the other is a temporary file. When writing data, the temporary file is written first. After writing the temporary file corresponding to a module, the temporary file is saved as a formal file and stored under the general directory file. The general directory file and the module files corresponding to the assembly code of each module are all in the same directory.

[0109] The format of the general directory file is as follows:

[0110] INTO is the overflow interrupt instruction. This instruction will not appear in normal assembly code. This time it is used to mark a general directory file.

[0111] The next step is to record the module file name and file size of each module.

[0112] FileName size moduleName; where FileName is the name of the module file, size is the file size of the module file, and moduleName is the module name of the corresponding module.

[0113] Each module's module file has an entry in this general directory file to store the file's information.

[0114] At the same time, the operations of each module on the core data are recorded, and only the module name is recorded for each operation, so that there will be a module operation sequence in the file. Furthermore, the order of all modules' operations on the core data can be sorted based on the time after the function in each module, so that a complete function operation sequence for the core data operation can be obtained. This file will be read when the virus program is started to avoid repeated analysis; and this file will be created at the end of the virus program to improve the efficiency of browsing and searching.

[0115] The specific implementation is as follows:

[0116] Among them, define struct Info{size_t size; string moduleName} to contain data information; use a list to store all info information, specifically, list <info>IList;.

[0117] hashMap<std::string,IList::iterator> IMap; indicates that a hashmap is used to store the mapping relationship between files and information. Among them, std::string is the key value, which is used for searching and corresponds to the name FileName of the above module file; IList::iterator is the iterator corresponding to the info information in the list.

[0118] The structure of the above general directory file can not only facilitate us to quickly add and delete information in the list, but also use hashmap to cooperate with the search when searching, which can greatly improve the search speed.

[0119] List <string>FList; List is used to record the operation sequence of each module on the core data, so that we can know which module has operated on the core data several times and the operation order of each module. When storing module names, this linked list will only record the records when the module is switched. Because a large amount of assembly code of the same module will operate data. For example, module A has been operated 10 times, we only record module A once; when module B starts to operate the core data, we record module B again, so as to only record the records when the module is switched.

[0120] Furthermore, when the virus program is executed, its corresponding assembly code will search for module information and write it into the corresponding module file. Under normal circumstances, assembly code execution is sequential and continuous, so if an assembly code is executed in a module. Then most of the subsequent assembly codes are in this module until the last assembly code is completed, and then it will switch to other modules. Therefore, when writing, it can be designed that when writing the first assembly code, the module file corresponding to the assembly code is adjusted from the position in IList to the front of IList, so that when the next assembly instruction is written, it is directly in the IList header, which can greatly improve the speed of writing data.

[0121] In this embodiment, an interface get can be used for querying info operation when writing assembly code, specifically Info get (const std:: string & key).

[0122] IListMap::Iterator it = lMap.find(key); first search through lMap.

[0123] if(it!=lMap.end()){if found

[0124] Info=*(it->second); read info information and save it into info variable.

[0125] lList.erase(it->second); and delete it from Ilist at the same time.

[0126] lList.push_front(Info); Since info has just been accessed, it is very likely that the subsequent assembly code will need to access it, so we put it at the front of IList to increase the access speed.

[0127] it->second = lList.begin(); and update the key value variable in IMap.

[0128] return Info; returns the found info data.

[0129] When the virus program is initialized, it will also read the general directory file. First, read the specific assembly code in the file header to determine whether the file is valid. If it is invalid, rebuild the general directory file through the assembly code module file to read the information of each entry. And determine whether each module file storing the assembly code exists, and verify whether the file size storing the assembly code is consistent through the stored size information. If it is inconsistent, it means that the file is damaged, and the file will be lost and rebuilt later.

[0130] If the directory file does not exist, we will recreate a general directory file. The content of the general directory file is constructed by reading all the module files in the same directory. All module files have file names, file sizes, and module names. After reading all the module files, the general directory file can be rebuilt.

[0131] The present embodiment provides a method for reverse analysis of a virus program, which determines a first memory address where the core data of the virus program is located by reverse debugging the virus program; then, based on the function VirtualProtect(address, size, PAGE_NOACCESS, &OldProtect), sets the first memory address to invalid memory, so that an operation exception occurs when the assembly code of the virus program accesses the core data in the first memory address. Furthermore, the assembly code of the virus program is executed line by line, and based on the VEH exception handling function, the target assembly code and the second memory address of the target assembly code are obtained when an operation exception occurs; the target assembly code is the currently executed assembly code, the second memory address is the memory address of the target assembly code, and the operation exception is triggered when the target assembly code accesses the first memory address; based on the second memory address, the module information of the module where the target assembly code is located is obtained; further, the target assembly code and the module information of the module where the target assembly code is located are saved in a preset module file, thereby realizing the analysis and storage of the target assembly code; finally, based on the function VirtualProtect(address, size, PAGE_READWRITE, &OldProtect), the first memory address is set as valid memory, and the execution of the target assembly instruction is completed. After completing the execution of the target assembly instruction, the first memory address is set to invalid memory based on the function VirtualProtect (address, size, PAGE_NOACCESS, & OldProtect) to continue to execute the next assembly code of the virus program, ensuring the loop execution of the assembly instructions of the virus program, constantly triggering operation exceptions and obtaining module information and assembly code. The method of this embodiment sets invalid memory for the first memory address where the core data is located, and automatically obtains the target assembly code and its module information when the operation exception is triggered. After the acquisition is completed, the first memory address is set to valid, so that this section of the target assembly code completes the access to the core data. Repeatedly setting the first memory address invalid and executing the next section of assembly code until the execution of all assembly codes is completed, the entire analysis process is automatically controlled, and the assembly code and module information can be automatically obtained to form a module file without manual copying operations, thereby improving the analysis efficiency.

[0132] Second embodiment

[0133] See also Figure 2 Based on the same inventive concept, the second embodiment of the present invention provides a virus program reverse analysis device 300. The virus program reverse analysis device 300 includes:

[0134] A determination module 301 is used to reverse debug the virus program and determine a first memory address where the core data of the virus program is located;

[0135] The first setting module 302 is used to set the first memory address as invalid memory based on the function VirtualProtect(address, size, PAGE_NOACCESS, & OldProtect); wherein address is the memory start address of the first memory address, and size is the size of the first memory address; PAGE_NOACCESS is used to set the first memory address to be inaccessible; and OldProtect is used to save the property of the first memory address before;

[0136] The first acquisition module 303 is used to execute the assembly code of the virus program line by line, and based on the VEH exception handling function, acquire the target assembly code and the second memory address of the target assembly code when an operation exception occurs; wherein the target assembly code is the currently executed assembly code, the second memory address is the memory address of the target assembly code, and the operation exception is triggered when the target assembly code accesses the first memory address;

[0137] A second acquisition module 304 is used to acquire module information of the module where the target assembly code is located based on the second memory address;

[0138] A saving module 305 is used to save the target assembly code and the module information of the module where the target assembly code is located into a preset module file;

[0139] The second setting module 306 is used to set the first memory address as valid memory based on the function VirtualProtect(address, size, PAGE_READWRITE, &OldProtect), and complete the execution of the target assembly instruction; wherein PAGE_READWRITE is used to set the first memory address to be accessible;

[0140] The third setting module 307 is used to set the first memory address as invalid memory based on the function VirtualProtect (address, size, PAGE_NOACCESS, & OldProtect) to continue executing the next assembly code of the virus program.

[0141] As an optional implementation manner, the first acquisition module 303 is further configured to:

[0142] Based on the function AddVectoredExceptionHandler(0, VectoredHandler), the operation exception of the target assembly code is captured, and the target assembly code and the second memory address are obtained; wherein 0 indicates that the operation exception is processed first, and VectoredHandler is used to obtain the second memory address;

[0143] The module information includes a module name; and obtaining the module information of the module where the target assembly code is located based on the second memory address includes:

[0144] Based on the second memory address, the module name is obtained using the interface getModuleName().

[0145] It should be noted that the specific implementation and technical effects of a virus program reverse analysis device 300 provided in an embodiment of the present invention are the same as those of the aforementioned method embodiment. For the sake of brief description, for matters not mentioned in the device embodiment, reference may be made to the corresponding contents in the aforementioned method embodiment.

[0146] Third embodiment

[0147] Based on the same inventive concept, the third embodiment of the present invention provides a virus program reverse analysis device. The virus program reverse analysis device comprises: a processor and a memory, the memory is coupled to the processor, the memory stores instructions, and when the instructions are executed by the processor, the user terminal executes the steps of any method in the first embodiment.

[0148] The embodiment of the present invention provides a virus program reverse analysis device, and its specific implementation and technical effects are the same as those of the aforementioned method embodiment. For the sake of brief description, for matters not mentioned in the device embodiment, reference can be made to the corresponding contents in the aforementioned method embodiment.

[0149] If the functional module integrated in the device provided by the present invention is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present invention implements all or part of the processes in the method of the above embodiment, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0150] The algorithm and display provided herein are not inherently related to any particular computer, virtual system or other device. Various general purpose systems can also be used together with the teachings based on this. According to the above description, it is obvious that the structure required for constructing such systems. In addition, the present invention is not directed to any specific programming language either. It should be understood that various programming languages ​​can be utilized to realize the content of the present invention described herein, and the description of the above specific languages ​​is for disclosing the best mode of the present invention.

[0151] In the description provided herein, a large number of specific details are described. However, it is understood that embodiments of the present invention can be practiced without these specific details. In some instances, well-known methods, structures and techniques are not shown in detail so as not to obscure the understanding of this description.

[0152] Similarly, it should be understood that in order to streamline the present disclosure and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of the present invention, various features of the present invention are sometimes grouped together into a single embodiment, figure, or description thereof. However, this disclosed method should not be interpreted as reflecting the intention that the claimed invention requires more features than those explicitly recited in each claim. More specifically, as reflected in the claims below, inventive aspects lie in less than all the features of the individual embodiments disclosed above. Therefore, the claims that follow the specific embodiment are hereby expressly incorporated into the specific embodiment, with each claim itself serving as a separate embodiment of the present invention.

[0153] Those skilled in the art will appreciate that the modules in the devices in the embodiments may be adaptively changed and arranged in one or more devices different from the embodiments. The modules or units or components in the embodiments may be combined into one module or unit or component, and in addition they may be divided into a plurality of submodules or subunits or subcomponents. Except that at least some of such features and / or processes or units are mutually exclusive, all features disclosed in this specification (including the accompanying claims, abstracts and drawings) and all processes or units of any method or device disclosed in this manner may be combined in any combination. Unless otherwise expressly stated, each feature disclosed in this specification (including the accompanying claims, abstracts and drawings) may be replaced by an alternative feature providing the same, equivalent or similar purpose.

[0154] In addition, those skilled in the art will appreciate that, although some embodiments herein include certain features included in other embodiments but not other features, the combination of features of different embodiments is meant to be within the scope of the present invention and form different embodiments. For example, in the claims below, any one of the claimed embodiments may be used in any combination.

[0155] The various component embodiments of the present invention may be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. It should be understood by those skilled in the art that a microprocessor or digital signal processor (DSP) may be used in practice to implement some or all of the functions of some or all of the components in the apparatus according to an embodiment of the present invention. The present invention may also be implemented as a device or device program (e.g., a computer program and a computer program product) for executing part or all of the methods described herein. Such a program implementing the present invention may be stored on a computer-readable medium, or may have the form of one or more signals. Such a signal may be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.

[0156] It should be noted that the above embodiments illustrate the present invention rather than limit it, and that those skilled in the art may devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference symbol between brackets shall not be construed as a limitation on the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "one" or "an" preceding an element does not exclude the presence of a plurality of such elements. The present invention may be implemented by means of hardware comprising a number of different elements and by means of a suitably programmed computer. In a unit claim enumerating a number of devices, several of these devices may be embodied by the same hardware item. The use of the words first, second, and third, etc., does not indicate any order. These words may be interpreted as names.< / string> < / info>

Claims

1. A virus program reverse analysis method, characterized in that: include: Reverse debugging the virus program to determine a first memory address where the core data of the virus program is located; Based on the function VirtualProtect(address, size, PAGE_NOACCESS, & OldProtect), the first memory address is set as invalid memory; wherein address is the memory start address of the first memory address, and size is the size of the first memory address; PAGE_NOACCESS is used to set the first memory address to be inaccessible; OldProtect is used to save the property of the first memory address before; Execute the assembly code of the virus program line by line, and based on the VEH exception handling function, obtain the target assembly code and the second memory address of the target assembly code when an operation exception occurs; wherein the target assembly code is the currently executed assembly code, the second memory address is the memory address of the target assembly code, and the operation exception is triggered when the target assembly code accesses the first memory address; Based on the second memory address, obtaining module information of the module where the target assembly code is located; Saving the target assembly code and the module information of the module where the target assembly code is located in a preset module file; Based on the function VirtualProtect(address, size, PAGE_READWRITE, &OldProtect), the first memory address is set as valid memory, and the execution of the target assembly instruction is completed; wherein PAGE_READWRITE is used to set the first memory address to be accessible; Based on the function VirtualProtect(address, size, PAGE_NOACCESS, &OldProtect), the first memory address is set as invalid memory to continue executing the next assembly code of the virus program.

2. The method according to claim 1, characterized in that The method of obtaining the target assembly code and the second memory address of the target assembly code based on the VEH exception handling function when an operation exception occurs includes: Based on the function AddVectoredExceptionHandler(0, VectoredHandler), the operation exception of the target assembly code is captured, and the target assembly code and the second memory address are obtained; wherein 0 indicates that the operation exception is processed first, and VectoredHandler is used to obtain the second memory address; The module information includes a module name; and obtaining the module information of the module where the target assembly code is located based on the second memory address includes: Based on the second memory address, the module name is obtained using the interface getModuleName().

3. The method according to claim 2, characterized in that Before the target assembly code and the module information of the module where the target assembly code is located are saved in a preset module file, the method further includes: Calculate the crc32hash of the module name to obtain the calculation result; Determine a first target byte from the calculation result, and determine the file name of the module file based on the first target byte; the first target byte is any byte in the calculation result; The determining of the file name of the module file comprises: determining whether there is a file name identical to the first target byte in the module file; if so, determining a second target byte different from the first target byte from the calculation result, and determining the file name of the module file based on the second target byte; After the single byte in the calculation result is judged, a first combination byte is determined from the calculation result; the first combination byte is any two bytes in the calculation result and increases in sequence; and the file name of the module file is judged based on the second target byte; Repeat the file name determination of the module file until non-repeated bytes are obtained; The non-repeated bytes are used as the file name of the module file.

4. The method according to claim 2, characterized in that: Before obtaining the module name based on the second memory address and using the interface getModuleName(), the method further includes: Determine whether the preset static variables are assigned; If not, traverse the modules of the virus program, and assign the module name, the starting address, and the ending address of each module to the static variables; The method of obtaining the module name based on the second memory address and using the interface getModuleName() includes: Based on the second memory address, the module name is queried in the static variable using the interface getModuleName().

5. The method according to claim 4, characterized in that After assigning the module name, the starting address and the ending address of each module to the static variables, the method further includes: Hooking the module loading function and the module unloading function in the system where the virus program is running, so as to monitor the module loading or unloading of the virus program; When the module of the virus program is loaded or unloaded, the module of the virus program is traversed and the static variable is reassigned.

6. The method according to claim 1, characterized in that The module information includes: module offset; the obtaining the module information of the module where the target assembly code is located based on the second memory address includes: Based on the offset between the second memory address and the starting address of the module, obtaining the module offset of the module where the target assembly code is located; The step of saving the target assembly code and the module information of the module where the target assembly code is located into a preset module file includes: The target assembly code and the module information of the module where the target assembly code is located are saved in an intermediate file; wherein the intermediate file is a temporary file; Based on the module offset of the module where the target assembly code is located, determining whether the module information is complete; Based on the format of the target assembly code, determining whether the content of the target assembly code itself is complete; If the module information and the contents of the target assembly code are both complete, the intermediate file is saved in a preset module file.

7. A virus program reverse analysis device, characterized in that: include: A determination module, used for reverse debugging the virus program and determining a first memory address where the core data of the virus program is located; A first setting module is used to set the first memory address as invalid memory based on the function VirtualProtect(address, size, PAGE_NOACCESS, & OldProtect); wherein address is the memory start address of the first memory address, and size is the size of the first memory address; PAGE_NOACCESS is used to set the first memory address to be inaccessible; and OldProtect is used to save the property of the first memory address before; A first acquisition module is used to execute the assembly code of the virus program line by line, and based on the VEH exception handling function, acquire the target assembly code and the second memory address of the target assembly code when an operation exception occurs; wherein the target assembly code is the currently executed assembly code, the second memory address is the memory address of the target assembly code, and the operation exception is triggered when the target assembly code accesses the first memory address; A second acquisition module, used for acquiring module information of the module where the target assembly code is located based on the second memory address; A saving module, used for saving the target assembly code and the module information of the module where the target assembly code is located into a preset module file; A second setting module is used to set the first memory address as valid memory based on the function VirtualProtect(address, size, PAGE_READWRITE, &OldProtect), and complete the execution of the target assembly instruction; wherein PAGE_READWRITE is used to set the first memory address to be accessible; The third setting module is used to set the first memory address as invalid memory based on the function VirtualProtect (address, size, PAGE_NOACCESS, & OldProtect) to continue executing the next assembly code of the virus program.

8. The device according to claim 7, characterized in that The first acquisition module is further used for: Based on the function AddVectoredExceptionHandler(0, VectoredHandler), the operation exception of the target assembly code is captured, and the target assembly code and the second memory address are obtained; wherein 0 indicates that the operation exception is processed first, and VectoredHandler is used to obtain the second memory address; The module information includes a module name; and obtaining the module information of the module where the target assembly code is located based on the second memory address includes: Based on the second memory address, the module name is obtained using the interface getModuleName().

9. A virus program reverse analysis device, characterized in that: The invention comprises a processor and a memory, wherein the memory is coupled to the processor and stores instructions, and when the instructions are executed by the processor, the user terminal executes the steps of the method according to any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the method described in any one of claims 1 to 6 are implemented.

Images