Detection method and product for normal program code with malicious code

Abstract

The invention provides a detection method and product for a normal program code with a malicious code, and the method comprises the steps: judging whether access to a target register exists or not for the normal program code; when the access to the target register exists, judging whether the target register accesses the process environment block or not; when the target register accesses the process environment block, judging whether to access the loader data table or not; and when the loader data table is accessed, judging that the normal program code carries the malicious code. According to the method and the device, malicious codes can be effectively detected before the program runs, so that faster and more accurate threat protection is realized.

Description

Technical Field

[0001] This application belongs to the technical field of code detection, specifically relating to a method and product for detecting normal program code containing malicious code; wherein, the product includes a detection device for normal program code containing malicious code, an electronic device, and a computer-readable storage medium. Background Technology

[0002] In today's information security field, the methods of spreading Trojans and malicious code are becoming increasingly complex, especially with the emergence of numerous antivirus software evasion techniques. Existing detection technologies mainly rely on traditional signature matching, behavioral analysis, and static scanning, but they often prove inadequate when dealing with advanced threats. Summary of the Invention

[0003] In view of the above problems, a method and product for detecting normal program code containing malicious code is proposed to overcome or at least partially solve the above problems, including: A method for detecting normal program code containing malicious code, the method comprising: For the normal program code, determine whether there is any access to the target register; When there is an access to the target register, determine whether the target register accesses the process environment block; When the target register accesses the process environment block, it is determined whether to access the loader data table; When accessing the loader data table, it is determined that the normal program code contains malicious code.

[0004] In some embodiments, determining whether there is access to the target register includes: The normal program code is disassembled to obtain multiple instructions; Based on the multiple instructions, determine whether the normal program code accesses the target register.

[0005] In some embodiments, determining whether the normal program code accesses the target register based on the plurality of instructions includes: Perform a linear scan of the instruction list corresponding to each function, and analyze the opcode and operands of each instruction one by one; Based on the analysis of the opcode and operands of the instruction, it is determined whether the normal program code accesses the target register.

[0006] In some embodiments, determining whether the normal program code accesses the target register based on the analysis of the opcode and operands of the instruction includes: When the instruction type of the instruction is direct data transfer or zero-extended data transfer, and the operand includes the target register, it is determined that the normal program code has access to the target register.

[0007] In some embodiments, the method further includes: When the operand contains the first operand and there are subsequent instructions, it is determined that the normal program code has access to the target register; When the operand contains a second operand, it is determined that the normal program code accesses the target register.

[0008] In some embodiments, determining that the normal program code contains malicious code when accessing the loader data table includes: Determine whether there is an instruction to access the loader data table via the target method; When an instruction exists that accesses the loader data table through the target method, it is determined that the normal program code contains malicious code.

[0009] In some embodiments, determining whether there is an instruction to access the loader data table via a targeted method includes: Determine whether the instruction meets the target conditions; When the instruction satisfies the target condition, it is determined that there is an instruction that accesses the loader data table through the target method.

[0010] In some embodiments, the target conditions include: The instruction type is direct data transfer or zero-extended data transfer; The base address register of the instruction is a register that accesses the process environment block; The offset of the instruction is the target offset.

[0011] In some embodiments, the method further includes: When determining that the normal program code contains malicious code, the application programming interface (API) call information of the malicious code is determined; The malicious code is analyzed based on the application interface call information.

[0012] In some embodiments, determining the application interface call information of the malicious code includes: Based on the malicious code, the target control transfer instruction is determined; The target address is determined based on the target control transfer instruction; Based on the target address, determine the application interface call information.

[0013] In some embodiments, determining the application interface call information based on the target address includes: From the portable executable file, determine the application interface identifier and instruction address that match the target address; The application interface call information is determined based on the application interface identifier and the instruction address.

[0014] In some embodiments, the disassembly of the normal program code to obtain multiple instructions includes: Determine the function information in the normal program code; the function information includes the function's start address, end address, and size; The function information is disassembled to obtain multiple instructions.

[0015] This application embodiment also provides a detection device for normal program code containing malicious code, the device comprising: The first judgment module is used to determine whether there is an access to the target register for the normal program code; The second judgment module is used to determine whether the target register accesses the process environment block when there is access to the target register. The third judgment module is used to determine whether to access the loader data table when the target register accesses the process environment block; The detection module is used to determine whether the normal program code contains malicious code when accessing the loader data table.

[0016] This application also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the above-described method for detecting normal program code containing malicious code.

[0017] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described method for detecting normal program code containing malicious code.

[0018] The embodiments of this application have the following advantages: In this embodiment, for normal program code, it is determined whether there is access to the target register; when there is access to the target register, it is determined whether the target register accesses the process environment block; when the target register accesses the process environment block, it is determined whether it accesses the loader data table; when the loader data table is accessed, it is determined that the normal program code contains malicious code. This application can effectively detect malicious code before the program runs, thereby achieving faster and more accurate threat protection. Attached Figure Description

[0019] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a flowchart illustrating the steps of a method for detecting normal program code containing malicious code, according to an embodiment of this application. Figure 2 This is a flowchart illustrating another method for detecting normal program code containing malicious code, according to an embodiment of this application. Figure 3 This is a flowchart illustrating the steps of another method for detecting normal program code containing malicious code, according to an embodiment of this application. Figure 4 This is a schematic diagram of the structure of a detection device for normal program code containing malicious code, according to an embodiment of this application. Detailed Implementation

[0020] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] In recent years, "patch evasion" technology (also known as "white-and-black" attack; a malicious code hiding technique that embeds malicious code into legitimate programs, making the entire file appear to behave like a normal program, thus evading traditional static signature matching detection. Malicious code is injected into legitimate programs in the form of patches, usually only decrypted and triggered at runtime) has gradually become a new trend in malicious attacks. This technique injects malicious code (shellcode, a small and independent piece of machine code, a sequence of instructions directly executable by the processor) into legitimate programs (white files), using the structure and behavior of legitimate programs to disguise malicious intent, thus significantly increasing the difficulty of detection. Shellcode is typically injected into the target process through specific vulnerabilities to perform malicious operations specified by advanced attackers, such as dynamically loading modules or executing system calls. Its characteristics include being streamlined, highly optimized, and dynamically resolving API addresses (APIs are a set of functions, methods, or tools defined by the operating system or library modules for developers to call to implement system functions or services. In the Windows environment, APIs are usually exported by system DLLs (such as kernel32.dll, ntdll.dll), providing services such as file operations, thread management, and memory allocation)). Because malicious code is integrated with legitimate programs, traditional antivirus software struggles to effectively identify it using conventional feature matching methods.

[0022] Taking current antivirus software's common detection methods as an example, hash-based detection relies on calculating the unique hash value of a file and comparing it with a signature database. However, the "white-and-black" technique easily circumvents the limitations of this detection method by combining malicious code with legitimate code. Single-signature and multi-signature detections rely on specific byte sequences in a file, but the "white-and-black" technique typically contains only a small segment of malicious shellcode, with the rest being completely legitimate program code, making it difficult to pinpoint the malicious signature.

[0023] Furthermore, while heuristic detection methods (such as extracting strings and import tables) and dynamic behavior analysis (such as simulating API calls; dynamic behavior analysis detects potential malicious activities by running the target program and monitoring its behavior in real or simulated environments (such as API calls, memory allocation, file operations, network communication, etc.). Dynamic behavior analysis can capture runtime characteristics, but is limited by execution paths and environmental dependencies) have certain analytical capabilities, malicious code typically exhibits malicious behavior only at runtime through dynamic decryption, code obfuscation (obfuscation is a technique that aims to complicate, encrypt, or otherwise transform program code to make it more difficult to understand semantically and structurally. This technique is often used to hide the true intent of malicious code and prevent it from being reverse engineered and analyzed.), or self-modification. This makes it difficult for static analysis methods (static analysis is an analytical method that determines the functionality and potential malicious behavior of a target program by examining its binary files, code structure, instruction sequences, and other static characteristics without executing the target program. The advantage of static analysis is comprehensive code coverage, but its effectiveness against dynamically decrypted or obfuscated code is limited) to effectively intercept it.

[0024] In summary, apart from detection methods based on dynamic analysis, there is currently a lack of effective static detection solutions for "white-and-black" evasion techniques. However, if problems cannot be detected before the malicious program runs, it will be difficult to prevent it from launching its attack in the first instance.

[0025] Therefore, this application proposes a static identification method for "white-and-black" anti-virus evasion techniques, which can effectively detect malicious code before the program runs, thereby achieving faster and more accurate threat protection.

[0026] For details, please refer to Figure 1 , Figure 1 The flowchart illustrates the steps of a method for detecting normal program code containing malicious code, according to an embodiment of this application.

[0027] like Figure 1 As shown, the detection method for normal program code containing malicious code may include the following steps: Step 101: For normal program code, determine whether there is any access to the target register.

[0028] In this embodiment of the application, when a normal program (not containing malicious code) accesses the Windows API (Application Programming Interface), it can do so in the following way: 1. API calls in the program will be marked as external functions.

[0029] 2. The linker fills the program's Import Address Table (IAT) with the necessary APIs. The IAT is part of the PE file and stores the addresses of external functions or modules that the program declares to call during compilation. When the PE file is loaded into memory, the operating system's dynamic linker resolves these external functions and fills their absolute addresses into the IAT for the program to call at runtime.

[0030] 3. When the operating system loads the program, it will automatically parse the IAT, find the API address, and fill it into the table.

[0031] When a legitimate program containing malicious code accesses an API, the shellcode (i.e., the malicious code) needs to dynamically resolve the API address. Dynamic API resolution means that the program manually finds and resolves the address of the target module or function at runtime by accessing data structures in system memory (such as PEB and LDR), rather than through compile-time binding or static linker declaration of the API address. This method is often used to circumvent static analyzers and improve the program's stealth.

[0032] This resolution process is typically achieved by accessing the Process Environment Block (PEB), specifically: 1. Use the GS register to read the TEB (Thread Environment Block) address (in a 64-bit system, GS:[0x30] points to the PEB). The TEB is a special data structure maintained by each thread in the Windows operating system, storing thread-related metadata. The TEB contains the thread ID, stack information, exception handling chain, and a pointer to the process environment block (PEB). The base address of the TEB can be accessed through a specific offset in the GS register.

[0033] 2. Locate the LDR (Loader DataTable Entry) in the PEB (Process Environment Block), which contains information about all loaded modules in the current process.

[0034] 3. Traverse the module list in LDR to find the target module (such as kernel32.dll).

[0035] 4. Locate the target API address by parsing the target module's export table. The export table, a part of the PE file, contains the addresses of functions, variables, or resources exported by the module. The export table informs other modules how to access specific functionalities or resources of the current module.

[0036] A PE (Portable Executable) file is an executable file format for the Windows operating system that defines the structure of executable files, DLLs, object files, and other file types. A PE file organizes object code, data, resources, and dynamic linking information. Its main parts include a file header, segment table, sections (such as .text and .data sections), import table, and export table, which support the loading and execution of the file.

[0037] Based on this distinction, this application embodiment analyzes the normal program code of the "normal program" to determine whether it accesses PEB and PEB→LDR through the GS register, thereby determining whether the normal program code contains malicious code. This enables effective detection of malicious code before program execution, thus achieving faster and more accurate threat protection.

[0038] In some embodiments, normal program code to be detected can be analyzed first to determine whether it accesses a target register; the target register can be the GS register; the GS register is a segment register in the x86-64 architecture, mainly used to store segment selectors. In the Windows operating system, the GS register usually points to the base address of the thread context block (TEB), and by accessing the GS register, thread context information, such as the stack pointer and exception chain, can be obtained.

[0039] Step 102: When there is an access to the target register, determine whether the target register accesses the process environment block.

[0040] If it is determined that normal program code does not access the target register, it can be directly concluded that the normal program code does not contain malicious code; conversely, if it is determined that normal program code does access the target register, it can be further determined whether the target register accesses the process environment block under the normal program code's access to the target register.

[0041] The Process Environment Block (PEB) is a data structure unique to each process in the Windows operating system, containing information related to the process's global state. The PEB stores loaded module information, environment variable tables, memory debug flags, process startup parameters, and more. Attackers often access the Loader Data (LDR) in the PEB to dynamically resolve module addresses and exported function addresses.

[0042] Step 103: When the target register accesses the process environment block, determine whether to access the loader data table.

[0043] If the target register is determined not to access the process environment block, it can be directly concluded that the normal program code does not contain malicious code. Conversely, if the target register is determined to access the process environment block, it can be further determined whether the normal program code accesses the loader data table. The loader data table is a member structure in the PEB (Process Environment Block) used to manage the list of modules loaded in the current process. The LDR (Loading Order List) contains three linked lists: the loading order list, the memory order list, and the initialization order list. These lists point to all modules loaded by the process (such as kernel32.dll, ntdll.dll), and are an important data source for dynamically resolving API addresses.

[0044] Step 104: When accessing the loader data table, determine that normal program code contains malicious code.

[0045] If it is determined that the normal program code does not access the loader data table, then it can be determined that the normal program code does not contain malicious code; conversely, if it is determined that the loader data table is accessed, then it can be determined that the normal program code contains malicious code.

[0046] Malicious code refers to any software that attempts to harm computer systems, steal confidential information, or perform other illegal operations. Types of malicious code include viruses, worms, Trojans, ransomware, etc., and their characteristics include stealth, destructiveness, and propagation.

[0047] In this embodiment, for normal program code, it is determined whether there is access to the target register; when there is access to the target register, it is determined whether the target register accesses the process environment block; when the target register accesses the process environment block, it is determined whether it accesses the loader data table; when the loader data table is accessed, it is determined that the normal program code contains malicious code. This application can effectively detect malicious code before the program runs, thereby achieving faster and more accurate threat protection.

[0048] Reference Figure 2 The diagram illustrates a flowchart of another method for detecting normal program code containing malicious code, according to an embodiment of this application. The method may include the following steps: Step 201: For normal program code, disassemble the normal program code to obtain multiple instructions.

[0049] In some embodiments, the normal program code that needs to be detected can be analyzed first; specifically, the normal program code can be disassembled first to obtain the instructions of each function in the normal program code.

[0050] Disassembly is the process of translating machine code (binary instructions) back into assembly language so that the program's operational logic can be read and understood by humans. Disassembly is an important technique in reverse engineering and a fundamental tool for analyzing the behavior of malicious code.

[0051] In some embodiments of this application, step 201 can be implemented by the following sub-steps: Sub-step 11: Determine the function information in the normal program code; the function information includes the function's start address, end address, and size.

[0052] In some embodiments, normal program code can be analyzed first to determine the function information therein; for example, the function information may include the start address, end address, and size of the function.

[0053] Sub-step 12: Disassemble the function information to obtain multiple instructions.

[0054] After obtaining the function information from the normal program code, it can be disassembled, and the instructions obtained from disassembling each code segment can be saved.

[0055] Step 202: Based on multiple instructions, determine whether the normal program code accesses the target register.

[0056] After receiving multiple instructions, these instructions can be analyzed to determine whether the normal program code accesses the target register; specifically, based on these instructions, it can be determined whether the normal program code accesses the GS register.

[0057] In some embodiments of this application, step 202 can be implemented by the following sub-steps: Sub-step 21: Perform a linear scan of the instruction list corresponding to each function, and analyze the opcode and operands of each instruction one by one.

[0058] In some embodiments, after receiving multiple instructions, a linear scan can be performed on the instruction list corresponding to each function of the normal program code, and the opcode and operands of each instruction can be analyzed to determine whether the normal program code accesses the target register.

[0059] An instruction list is a sequence of assembly instructions generated during the disassembly process, representing the logic of a specific section of code in a program. Instruction lists are typically used to analyze program behavior and identify specific patterns (such as API calls, loop structures, etc.).

[0060] Sub-step 22: Based on the analysis of the opcode and operands of the instruction, determine whether the normal program code accesses the target register.

[0061] After analyzing the opcode and operands of each instruction, the results of the analysis can be used to determine whether normal program code accesses the target register.

[0062] In some embodiments of this application, sub-step 22 can be implemented in the following manner: When the instruction type is direct data transfer or zero-extended data transfer, and the operands include the destination register, it is determined that the normal program code has accessed the destination register.

[0063] In some embodiments of this application, if the instruction type of the instruction corresponding to the function is direct data transfer or zero-extended data transfer, it can be further determined whether the operand includes the destination register.

[0064] For example, the direct data transfer (MOV, Move) instruction is a data transfer instruction in the x86 architecture used to move (copy) data from a source location to a destination location. The operands of the MOV instruction can be immediate values, registers, or memory locations.

[0065] For example, `mov eax, [gs:0x30]` means loading the value at offset 0x30 of the GS segment into the EAX register.

[0066] Operands, also called immediate numbers (IMM), are operands used in assembly instructions to specify fixed constant values. Immediate numbers are directly embedded in the instruction without requiring additional register or memory access. For example, in the instruction moveax, 5, 5 is an immediate number.

[0067] If the operands also include the destination register, then it can be determined that the normal program code accesses the destination register.

[0068] In some embodiments of this application, the above method may further include the following steps: If the operand contains the first operand and there is a subsequent instruction, it is determined that the normal program code has accessed the target register; if the operand contains the second operand, it is determined that the normal program code has accessed the target register.

[0069] In some embodiments, if the operand contains a first operand and the instruction has subsequent instructions, it can be determined that normal program code accesses the destination register. The first operand can be 0x30.

[0070] In other embodiments, if the operand contains a second operand, it can be directly determined that normal program code accesses the target register. The second operand can be 0x60.

[0071] Step 203: When there is an access to the target register, determine whether the target register accesses the process environment block.

[0072] If it is determined that normal program code does not access the target register, it can be directly concluded that the normal program code does not contain malicious code; conversely, if it is determined that normal program code does access the target register, it can be further determined whether the target register accesses the process environment block under the normal program code's access to the target register.

[0073] Step 204: When the target register accesses the process environment block, determine whether to access the loader data table.

[0074] If it is determined that the target register does not access the process environment block, it can be directly determined that the normal program code does not contain malicious code; conversely, if it is determined that the target register accesses the process environment block, it can be further determined whether the normal program code accesses the loader data table.

[0075] Step 205: Determine if there is an instruction that accesses the loader data table via the target method.

[0076] If it is determined that the normal program code does not access the loader data table, then it can be determined that the normal program code does not contain malicious code; conversely, if it is determined that the loader data table is accessed, it can be further determined whether the instruction accessing the loader data table is through a target method; where target method can refer to the PEB+0x18 method.

[0077] For example, it can be determined whether there is an instruction that accesses PEB->LDR via PEB+0x18.

[0078] In some embodiments of this application, step 205 can be implemented by the following sub-steps: Sub-step 31: Determine whether the instruction meets the target conditions; In some embodiments, it can be first determined whether the instruction meets the target conditions; for example, the target conditions may include one or more of the following: The instruction type is either direct data transfer or zero-extended data transfer; The base address register of the instruction is a register that accesses the process environment block; The offset of the instruction is the target offset.

[0079] Sub-step 32: When the instruction meets the target condition, determine that there is an instruction that accesses the loader data table through the target method.

[0080] If the instruction meets the target conditions, it can be further determined that there is an instruction that accesses the loader data table through the target method.

[0081] Conversely, if the instruction does not meet the target conditions, it can be determined that there is no instruction that accesses the loader data table through the target method; at this time, it can be determined that the normal program code does not contain malicious code.

[0082] Step 206: When there is an instruction that accesses the loader data table through the target method, it is determined that the normal program code contains malicious code.

[0083] If it is determined that there are no instructions to access the loader data table through a target method, then the normal program code can be determined to be free of malicious code; conversely, if it is determined that there are instructions to access the loader data table through a target method, then the normal program code contains malicious code, and this "normal program" is actually a malicious program.

[0084] In some embodiments of this application, the above method may further include the following steps: When determining that normal program code contains malicious code, the application interface call information of the malicious code is determined; based on the application interface call information, the malicious code is analyzed.

[0085] In some embodiments, when it is determined that normal program code contains malicious code, the malicious code contained in the normal program code can be analyzed to determine the calls to its application programming interfaces (APIs), and then to determine the API call information of the APIs it calls.

[0086] After determining the application interface call information, the malicious code can be analyzed based on the application interface call information to determine what the malicious code did.

[0087] In some embodiments of this application, application programming interface (API) call information can be determined in the following ways: Based on the malicious code, determine the target control transfer instructions; based on the target control transfer instructions, determine the target address; based on the target address, determine the application programming interface (API) call information.

[0088] In some embodiments, after determining that malicious code exists in normal program code, the instruction list of the malicious code's functions can be scanned, checking line by line for target control transfer instructions. If present, the target control transfer instructions can be parsed to obtain the target address.

[0089] After obtaining the target address, the application interface call information can be determined based on the target address.

[0090] In some embodiments of this application, application programming interface (API) call information can be determined based on the target address in the following manner: From the portable executable file, determine the application interface identifier and instruction address that match the target address; based on the application interface identifier and instruction address, determine the application interface call information.

[0091] In some embodiments, the addresses and names of all known external functions (typically Windows APIs) can be extracted from the portable executable file first.

[0092] Then, the target address of the target control transfer instruction can be compared with the address in the import table of the portable executable file; if a match is found, the application interface identifier of the call is recorded, as well as the corresponding instruction address; then, application interface call information can be generated based on the application interface identifier and the instruction address.

[0093] Conversely, if a match fails, it is marked as an "unresolved call".

[0094] In this embodiment, normal program code is disassembled to obtain multiple instructions. Based on these instructions, it is determined whether the normal program code accesses a target register. If an access to the target register is found, it is determined whether the target register accesses the process environment block. If the target register accesses the process environment block, it is determined whether it accesses the loader data table. It is then determined whether there are instructions that access the loader data table via a target method. If there are instructions that access the loader data table via a target method, it is determined that the normal program code contains malicious code. Through this embodiment, hidden small segments of malicious code can be efficiently and accurately located and identified from normal programs, effectively solving the detection blind spots and shortcomings of traditional static analysis techniques when facing "white-and-black" attack methods.

[0095] Reference Figure 3 The following is a flowchart illustrating the steps of another method for detecting normal program code containing malicious code, according to an embodiment of this application: This application aims to provide a static identification method for malware evasion techniques such as "white-and-black" attacks. This method can efficiently and accurately locate and identify small segments of hidden malicious code within normal program code, effectively addressing the detection blind spots and shortcomings of traditional static analysis techniques when facing "white-and-black" attack methods. Specifically: GS register → TEB\PEB → LDR Step 1: Detect the entry and exit points of all functions in a normal program. The prologue (function entry point) is the beginning of a function, typically consisting of a specific set of instructions at the assembly level. It sets up the function's stack frame to manage local variables, parameters, and return addresses. For example, the instructions `pushrbp` and `movrbp,rsp` are typical function prologues. The epilogue (function exit) is the end of a function, corresponding to the prologue. At the assembly level, the epilogue is usually used to restore the state of the call stack and return to the caller. For example, the instructions `movrsp,rbp`, `poprbp`, and `ret` are typical epilogue sequences.

[0096] Step 1.1: Extract the .text segment of the PE file to obtain its machine code start address and size. The ".text segment" is a section in a PE file used to store the program's machine instructions (executable code). The .text segment is usually read-only and is directly executed by the processor after being loaded into memory. This segment contains the main logic code of the program.

[0097] Step 1.2: Call the disassembler to convert the machine code into a sequence of assembly instructions.

[0098] Step 1.3: Traverse the instructions in the instruction sequence, detect function boundaries, and determine whether a Prologue and Epilogue are matched: Detection function entry point (Prologue): Traverse the instruction stream, attempt to match the following instruction sequence, and mark the start of the function if it has not yet been entered: a. pushhrbp; b. Immediately following movrbp,rsp; Epilogue of the detection function: Traverse the instruction stream, identify any of the following exit instructions, and mark the end of a function if the current function has been entered: a、ret; b. retn (with a return value); Step 1.4: Save the detected function information to the results list.

[0099] Step 1.5: Return a list containing information about all functions, including the start address, end address, and size of each function.

[0100] Step 2: Disassemble each function code segment and save the instructions obtained from disassembling each code segment; Step 2.1: Disassemble the specified code segment using a disassembler: Input: starting address, length.

[0101] Base address: Pass 0 (because virtual memory address is not relied upon here).

[0102] Maximum number of disassembly instructions: 0 (no limit on the number of instructions).

[0103] Output: The return value is the number of instructions obtained from the disassembly. An instruction array; containing all instructions obtained from disassembly.

[0104] Step 3: Check if the function accesses the GS register, thus tracing whether it accesses PEB and PEB->Ldr. If there is no access to the GS register, skip the current function.

[0105] Step 3.1: Perform a linear scan of the instruction list for each function, analyzing the opcode and operands of each instruction to check for any access to the GS segment register. Instructions matching the following conditions are identified: The instruction type is MOV (direct data transfer) or MOVZX (zero-extended data transfer).

[0106] Operands include the GS segment register (usually in the form of gs:[offset]).

[0107] The offset of the GS segment register is 0x30 or 0x60.

[0108] If the above command is matched, record the following information: Offset: 0x30 indicates accessing the TEB, 0x60 indicates accessing the PEB.

[0109] Target register: Used to store the value corresponding to the GS address.

[0110] Step 3.2: Detect access to TEB and PEB: If the GS offset is 0x30: Check for subsequent instructions and indirectly access the PEB by reading TEB+0x60.

[0111] Record the target register accessed in the PEB.

[0112] If the GS offset is 0x60: It was directly determined that the PEB had been accessed.

[0113] Record the target register accessed in the PEB.

[0114] Step 3.3: Detect PEB→Ldr access: After confirming access to PEB, further check for the existence of instructions accessing PEB->Ldr via PEB+0x18. Matching conditions include: The instruction type is MOV or MOVZX; The base address register is the register for accessing the PEB; The offset is PEB+0x18.

[0115] If the above conditions are matched, it is determined that PEB→Ldr has been accessed, and thus this function can be identified as Shellcode.

[0116] Step 4: Detect API calls in Shellcode functions: Step 4.1: Detect the CALL instruction. The CALL instruction is a control transfer instruction in the x86 architecture, indicating a subroutine call. The CALL instruction pushes the return address of the current instruction onto the stack and then jumps to the target address to execute the subroutine. The CALL instruction supports direct calls (target address is an immediate value) and indirect calls (target address is a register or memory address).

[0117] Scan the instruction list of the shellcode functions and check each one for the existence of a CALL instruction: a. The instruction type is CALL.

[0118] b. The operand contains a target address.

[0119] Step 4.2: Resolve the target address: For each CALL instruction, parse its target address: Direct call (immediate value IMM): If the target address is a fixed immediate value, the target address is directly extracted.

[0120] Step 4.3: Match with the imported table: Extract the addresses and names of all known external functions (usually Windows APIs) from the import table of the PE file.

[0121] Compare the target address of the CALL instruction with the address in the import table: If a match is found, record the name of the API that was called.

[0122] If no match is found, it is marked as "unresolved call".

[0123] Step 4.4: Record API call information: For each function, record the following information: The name of the API being called.

[0124] The address of the instruction being called.

[0125] The above methods can effectively detect whether there is any behavior in the code that accesses PEB and PEB→Ldr through the GS register, and can basically determine what malicious code does by using the API of function calls.

[0126] This application identifies the entry and exit points of all functions in a program by extracting the .text segment of a PE file and disassembling its machine code. Function entry points are marked by specific assembly instruction sequences (such as pushhrbp and movrbp,rsp). Function exit points are marked by ret or retn instructions. This method effectively segments the program logic, determines the scope of each function, and facilitates subsequent analysis.

[0127] This application also detects the existence of access operations to the GS segment registers by scanning the instruction list of the function: matching specific instruction types (such as MOV, MOVZX) and operands (such as gs:[offset]). An offset of 0x30 indicates access to the Thread Environment Block (TEB), and an offset of 0x60 indicates access to the Process Environment Block (PEB). Further analysis is performed to determine if there is any indirect access to the PEB via TEB+0x60, and the target register of the accessed PEB is recorded.

[0128] This application further checks for the presence of instructions that access PEB via PEB+0x18 after confirming that the function accesses PEB->Ldr. It matches specific instruction types (such as MOV, MOVZX) and verifies whether the base address register and offset correspond to PEB and PEB->Ldr. If such access is found, the function is considered potentially malicious code (such as shellcode), as this operation is often used to enumerate a list of modules to load additional malicious modules.

[0129] Furthermore, this application analyzes the detected potentially malicious functions to determine if they contain API calls: It scans the function instruction list, searches for CALL instructions, and resolves their target addresses. If the target address is a direct call (Immediate Value, IMM), its call address is extracted. The target address is matched against the import table of the PE file to resolve the called API name. Unresolved calls (e.g., dynamically loaded or undeclared calls) are recorded for further analysis. The API name and its call address are output for each function.

[0130] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0131] Reference Figure 4 The diagram illustrates a structural schematic of a device for detecting normal program code containing malicious code, according to an embodiment of this application. The device may include the following modules: The first judgment module 401 is used to determine whether there is an access to the target register for normal program code; The second judgment module 402 is used to determine whether the target register accesses the process environment block when there is access to the target register. The third judgment module 403 is used to determine whether to access the loader data table when the target register accesses the process environment block; The detection module 404 is used to determine whether normal program code contains malicious code when accessing the loader data table.

[0132] In one optional embodiment of this application, the first judgment module 401 is used to disassemble the normal program code to obtain multiple instructions; and to determine whether the normal program code accesses the target register based on the multiple instructions.

[0133] In one optional embodiment of this application, the first judgment module 401 is used to perform a linear scan of the instruction list corresponding to each function, analyze the opcode and operand of each instruction one by one, and determine whether the normal program code accesses the target register based on the analysis of the opcode and operand of the instruction.

[0134] In an optional embodiment of this application, the first judgment module 401 is used to determine that normal program code has access to the target register when the instruction type of the instruction is direct data transfer or zero extended data transfer and the operand includes the target register.

[0135] In an optional embodiment of this application, the first determination module 401 is further configured to determine that normal program code accesses the target register when the operand contains the first operand and there is a subsequent instruction; and to determine that normal program code accesses the target register when the operand contains the second operand.

[0136] In one optional embodiment of this application, the detection module 404 is used to determine whether there is an instruction to access the loader data table in a targeted manner; when there is an instruction to access the loader data table in a targeted manner, it is determined that the normal program code contains malicious code.

[0137] In an optional embodiment of this application, the detection module 404 is used to determine whether the instruction meets the target conditions; when the instruction meets the target conditions, it is determined that there is an instruction that accesses the loader data table through the target method.

[0138] In one optional embodiment of this application, the target conditions include: The instruction type is either direct data transfer or zero-extended data transfer; The base address register of the instruction is a register that accesses the process environment block; The offset of the instruction is the target offset.

[0139] In an optional embodiment of this application, the detection module 404 is further configured to determine the application interface call information of the malicious code when it is determined that normal program code contains malicious code; and to analyze the malicious code based on the application interface call information.

[0140] In one optional embodiment of this application, the detection module 404 is configured to determine the target control transfer instruction based on the malicious code; determine the target address based on the target control transfer instruction; and determine the application programming interface (API) call information based on the target address.

[0141] In one optional embodiment of this application, the detection module 404 is used to determine the application interface identifier and instruction address that match the target address from the portable executable file; and to determine the application interface call information based on the application interface identifier and instruction address.

[0142] In one optional embodiment of this application, the first judgment module 401 is used to determine function information in normal program code; the function information includes the start address, end address and size of the function; the function information is disassembled to obtain multiple instructions.

[0143] In this embodiment, for normal program code, it is determined whether there is access to the target register; when there is access to the target register, it is determined whether the target register accesses the process environment block; when the target register accesses the process environment block, it is determined whether it accesses the loader data table; when the loader data table is accessed, it is determined that the normal program code contains malicious code. This application can effectively detect malicious code before the program runs, thereby achieving faster and more accurate threat protection.

[0144] This application also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the above-described method for detecting normal program code containing malicious code.

[0145] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described method for detecting normal program code containing malicious code.

[0146] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0147] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0148] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0149] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0150] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0151] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0152] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0153] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0154] The above provides a detailed description of a method and product for detecting normal program code containing malicious code. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for detecting normal program code containing malicious code, characterized in that, The method includes: For the normal program code, determine whether there is any access to the target register; When there is an access to the target register, determine whether the target register accesses the process environment block; When the target register accesses the process environment block, it is determined whether to access the loader data table; When accessing the loader data table, it is determined that the normal program code contains malicious code.

2. The method according to claim 1, characterized in that, The determination of whether there is an access to the target register includes: The normal program code is disassembled to obtain multiple instructions; Based on the multiple instructions, determine whether the normal program code accesses the target register.

3. The method according to claim 2, characterized in that, The step of determining whether the normal program code accesses the target register based on the plurality of instructions includes: Perform a linear scan of the instruction list corresponding to each function, and analyze the opcode and operands of each instruction one by one; Based on the analysis of the opcode and operands of the instruction, it is determined whether the normal program code accesses the target register.

4. The method according to claim 3, characterized in that, The step of determining whether the normal program code accesses the target register based on the analysis of the instruction's opcode and operands includes: When the instruction type of the instruction is direct data transfer or zero-extended data transfer, and the operand includes the target register, it is determined that the normal program code has access to the target register.

5. The method according to claim 4, characterized in that, The method further includes: When the operand contains the first operand and there are subsequent instructions, it is determined that the normal program code has access to the target register; When the operand contains a second operand, it is determined that the normal program code accesses the target register.

6. The method according to claim 1, characterized in that, The step of determining whether the normal program code contains malicious code when accessing the loader data table includes: Determine whether there is an instruction to access the loader data table via the target method; When an instruction exists that accesses the loader data table through the target method, it is determined that the normal program code contains malicious code.

7. The method according to claim 6, characterized in that, The determination of whether there is an instruction to access the loader data table through the target method includes: Determine whether the instruction meets the target conditions; When the instruction satisfies the target condition, it is determined that there is an instruction that accesses the loader data table through the target method.

8. The method according to claim 7, characterized in that, The target conditions include: The instruction type is direct data transfer or zero-extended data transfer; The base address register of the instruction is a register that accesses the process environment block; The offset of the instruction is the target offset.

9. The method according to claim 1, characterized in that, The method further includes: When determining that the normal program code contains malicious code, the application programming interface (API) call information of the malicious code is determined; The malicious code is analyzed based on the application interface call information.

10. The method according to claim 9, characterized in that, The determination of the application interface call information of the malicious code includes: Based on the malicious code, the target control transfer instruction is determined; The target address is determined based on the target control transfer instruction; Based on the target address, determine the application interface call information.

11. The method according to claim 10, characterized in that, The step of determining the application interface call information based on the target address includes: From the portable executable file, determine the application interface identifier and instruction address that match the target address; The application interface call information is determined based on the application interface identifier and the instruction address.

12. The method according to claim 2, characterized in that, The disassembly of the normal program code yields multiple instructions, including: Determine the function information in the normal program code; the function information includes the function's start address, end address, and size; The function information is disassembled to obtain multiple instructions.

13. A detection device for normal program code containing malicious code, characterized in that, The device includes: The first judgment module is used to determine whether there is an access to the target register for the normal program code; The second judgment module is used to determine whether the target register accesses the process environment block when there is access to the target register. The third judgment module is used to determine whether to access the loader data table when the target register accesses the process environment block; The detection module is used to determine whether the normal program code contains malicious code when accessing the loader data table.

14. An electronic device, characterized in that, The method includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the detection method for normal program code containing malicious code as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the detection method for normal program code containing malicious code as described in any one of claims 1 to 12.

Images