# Research on the Construction of Malware Variant Datasets and Their Detection Method
## 3 Construction of the Malware Variant and Its API Call Sequence Dataset
### Construction of Malware Variants  
At present, the construction methods of malware variants include packing, encryption, instruction insertion/replacement/disorder, etc. A commonly used packing scheme is to implant a piece of code in the PE program, and the implanted code will be run first at runtime, which is equivalent to hiding the real OEP entry point of the program. Then, the control is returned to the original code so that the original instruction information can be affected, and the malware variant samples can be obtained. Instruction replacement usually refers to the equivalent replacement of instructions, that is, replacing one or more instructions with one or more equivalent instructions. During replacement, it also needs to ensure that it does not affect the normal logic of the program. In this way, it can interfere with the detection scheme and obtain malware variant samples. The packing scheme usually does not affect the effect of dynamic detection. The malware variant scheme for dynamic detection is more complex, in which the function reference of the IAT table, exception handling during function call and stack balance during API call need to be considered. To construct a runnable malware variant sample, in this paper, we used x86 disassembly to reverse the target malware, convert the machine code into assembly language, insert the API call sequence into the assembly code, complete the binary rewriting of the PE file, and then obtain the obfuscated sample. This obfuscation scheme maintained the original code execution structure by inserting code rather than obfuscation by inserting after extracting the API sequence so that each malware can be used as a variant of the original malware, which is more in line with the actual application scenario. Specifically, a binary rewriting obfuscation scheme for the PE program was designed and implemented. The scheme flow is shown in Figure 1. First, a certain number of malware samples were collected through VirusShare [28]. During statistics, it was found that the dataset contained a large number of PDF, HTML and other files. Python-magic was used to filter out the files with PE32 characteristics. After filtering, some C/C++ compiled exec files and some C# compiled exec files could be obtained. For C/C++ compiled samples, they first require preprocessing. If the malware has a shell, it needs to be unpacked. If ASLR is enabled in the PE file header, DYNAMIC_BASE needs to be disabled to avoid processing relocations, and NX_COMPAT protection needs to be disabled. This step can be performed using Python's lief library [29] or dnSpy. After that, a new 00 code segment needs to be added by modifying the PE header or using the existing 00 code segment. Usually, a 00 segment of a part of the area will be reserved after each code segment in the PE file. After finding the 00 segment that can be written, one must give RWX permission in this part of the code segment. Through the preprocessing of the PE sample, a segment 00 with executable permission can be obtained, and the assembly code can be written in this part to realize the hook. Since the goal to be achieved is to achieve random calls, it is not guaranteed that these are all the functions that need to be introduced in the IAT table, as well as enough address space for writing, so in this paper we built a general externally imported dll. A function called random API in this dll file was built. RegOpenKeyEx, RegCreateKeyEx, etc., were selected in the API sequence to be inserted. When calling these APIs, it was necessary not to affect the operation of the original program. By dynamically loading this dll into the assembly code, it can prevent the need to rebuild the IAT table to realize dynamic import because there is no relevant API introduced and the number of rewriting 00 segments in the original malware sample is reduced. The functions related to dynamically loading dll are in KERNEL32.dll, which is a dll file that must be referenced to build an application. You only need to use KERNEL32.dll.