Malicious software detection method and device, electronic equipment and storage medium

Abstract

The invention provides a malicious software detection method and device, electronic equipment and a storage medium. The problem that malicious software cannot be accurately and efficiently recognized in an existing UEFI starting security technology is effectively solved. The method comprises the following steps: traversing a plurality of EFI partitions accessed by a UEFI firmware layer in a computer during starting, screening out a target EFI partition, and copying a file in the target EFI partition to obtain firmware to be tested; disassembling a binary code in the firmware to be tested to identify a function, and establishing a function topological structure of the function; detecting the function and the function topological structure based on a plurality of detection dimensions to obtain an anomaly detection result corresponding to the detection dimensions; and fusing the exception detection result of the corresponding detection dimension to obtain an exception result, identifying that the corresponding instruction sequence is a malicious instruction sequence based on the exception result, and determining that malicious software exists in the UEFI firmware layer based on the malicious instruction sequence.

Description

Technical Field

[0001] The present application relates to the field of computer security technology, and in particular to a malware detection method, device, electronic device and storage medium. Background Art

[0002] With the popularization of malware detection in operating systems and website software and computer security usage specifications, sophisticated attackers often begin to expand their attack surface to lower-level systems and firmware to obtain higher control privileges and more persistent attack control. UEFI Bootkits is a type of malware targeting the UEFI boot platform. The overall UEFI firmware runs under kernel layer privileges, and the impact caused by UEFI vulnerabilities is generally highly concealed and threatening. Once an attacker uses a vulnerability to implant malicious code into the UEFI firmware, it is difficult to detect and remove it at the operating system level, which makes it a potential target for malware such as UEFI bootkits.

[0003] In 2018, Liu Wenqi and other scholars published a study on BOOTKIT detection technology based on UEFI firmware in the Journal of University of Electronic Science and Technology of China. Through the UEFI protocol, a DXE driver named UDS was involved to detect various key files of subsequent boot firmware and operating system boot. The research designed a backup file warehouse, integrity detection, and file recovery. Through the feature that the DXE driver runs earlier than the operating system boot code, the integrity detection of abnormal bootkits and normal file recovery are completed. However, due to the resource constraints of the boot phase, although the use of signature verification is within an acceptable range in terms of boot speed, it is very difficult to use technologies such as path extraction, disassembly, and taint identification that require more computing resources and more library dependencies in the DXE phase. This results in the inability to accurately identify malware.

[0004] The existing UEFI Bootkits detection methods are mainly detected in two ways:

[0005] 1. Behavior detection: determine whether there are UEFI Bootkits by boot time, abnormal processes, etc.

[0006] Firmware Scan: Scans UEFI firmware and verifies the firmware hash. By confirming the hashes of various firmware and file systems, it determines whether the underlying firmware files have been maliciously modified.

[0007] For behavior detection, this method is actually a relatively conventional means of protection, which has a certain false alarm rate (other types of malware attacks may also meet this feature); at the same time, there may be large errors in the judgment method based on the boot time and other methods. In the practice of firmware scanning, it is mainly based on the modification time of boot firmware bootmgfw.efi and winload.efi to determine whether there is a UEFI Bootkits attack. But first of all, the modification time and other attributes of the file system can be modified by malware, and judging by the modification time is not rigorous. For verifying file signatures, frequent updates and changes may make it difficult to manage, and the system is also difficult to maintain. Summary of the invention

[0008] In view of this, the purpose of the present application is to provide a malware detection method, device, electronic device and storage medium, which effectively solves the problem that the existing UEFI boot security technology cannot accurately and efficiently identify the existence of malware.

[0009] In a first aspect, an embodiment of the present application provides a malware detection method, the method comprising:

[0010] Traversing multiple EFI partitions accessed by the UEFI firmware layer in the computer at startup, filtering out a target EFI partition, and copying files in the target EFI partition to obtain a firmware to be tested; the firmware to be tested is in the form of a firmware image;

[0011] Disassembling the binary code in the firmware to be tested to identify the function, and establishing the function topology structure of the function based on the control flow information between the basic blocks in the function;

[0012] Detect the function and the function topology based on multiple detection dimensions to obtain anomaly detection results corresponding to the detection dimensions; the anomaly detection results include an instruction sequence corresponding to the function;

[0013] The abnormal detection results of the corresponding detection dimensions are integrated to obtain an abnormal result, so as to identify the corresponding instruction sequence as a malicious instruction sequence based on the abnormal result, so as to determine the presence of malware in the UEFI firmware layer based on the malicious instruction sequence.

[0014] In combination with the first aspect, an embodiment of the present application provides a first possible implementation of the first aspect, wherein the function topology structure and the function are detected based on multiple detection dimensions to obtain anomaly detection results of corresponding detection dimensions, including:

[0015] Based on the function topology structure, determining multiple detection dimensions for the function; different detection dimensions correspond to different detection methods;

[0016] The detection method corresponding to the detection dimension is called to detect the function and the function topology structure to obtain an abnormal detection result.

[0017] In combination with the first aspect, the embodiment of the present application provides a second possible implementation of the first aspect, wherein the dimension at least includes a basic block dimension;

[0018] The calling of the detection method corresponding to the detection dimension to detect the function and the function topology structure to obtain an abnormality detection result includes:

[0019] Obtaining a function address of the function, traversing the function address to obtain an instruction sequence of the function, and determining whether the instruction sequence meets a target instruction sequence condition;

[0020] If so, based on the frequency of the instruction sequence, the instruction sequence is marked and an anomaly detection result is obtained.

[0021] In combination with the first aspect, the embodiment of the present application provides a third possible implementation of the first aspect, wherein the dimension at least includes an execution flow dimension;

[0022] The calling of the detection method corresponding to the detection dimension to detect the function and the function topology structure to obtain an abnormality detection result includes:

[0023] Acquire a call graph of the function based on the function topology structure, and determine whether a block type of the call graph meets a preset standard type;

[0024] If so, the abnormality detection result is obtained, and the address of the function is input into the target address library.

[0025] In combination with the first aspect, the embodiment of the present application provides a fourth possible implementation of the first aspect, wherein the dimension at least includes a code dimension;

[0026] The calling of the detection method corresponding to the detection dimension to detect the function and the function topology structure to obtain an abnormality detection result includes:

[0027] Traversing the function, locating a target code segment within the function, and extracting a first function signature processed by the target code segment;

[0028] The cross-reference of the function is checked and restored to obtain a second function signature, and an anomaly detection result is obtained based on the first function signature and the second function signature.

[0029] In combination with the first aspect, the embodiment of the present application provides a fifth possible implementation of the first aspect, wherein the method further includes:

[0030] Obtain the BCD file to be tested and the NVRAM configuration variables of the UEFI firmware layer when it is started, and process the BCD file to be tested and the NVRAM configuration variables respectively based on different state processing dimensions to obtain corresponding state results;

[0031] Based on the status result, a malicious instruction sequence existing in the BCD file to be tested in the UEFI firmware layer is identified to determine the existence of malware based on the malicious instruction sequence, and determine that the malware exists.

[0032] In combination with the first aspect, an embodiment of the present application provides a sixth possible implementation of the first aspect, wherein the processing of the BCD file to be tested and the NVRAM configuration variable based on different state dimensions respectively includes:

[0033] Setting different state processing dimensions based on the BCD file to be tested and the NVRAM configuration variables, and setting corresponding processing methods;

[0034] According to the corresponding processing methods, the BCD file to be tested and the NVRAM configuration variables are processed respectively.

[0035] In a second aspect, an embodiment of the present application provides a malware detection device, the device comprising:

[0036] A screening module is used to traverse multiple EFI partitions accessed by the UEFI firmware layer in the computer when starting up, screen out a target EFI partition, and copy files in the target EFI partition to obtain a firmware to be tested; the firmware to be tested is in the form of a firmware image;

[0037] An establishment module is used to disassemble the binary code in the firmware to be tested to identify the function, and establish a function topology structure of the function based on the control flow information between multiple basic blocks and basic blocks in the function;

[0038] A detection module, configured to detect the function and the function topology based on multiple detection dimensions, and obtain an abnormality detection result corresponding to the detection dimension; the abnormality detection result includes an instruction sequence corresponding to the function;

[0039] A fusion module is used to fuse the abnormal detection results of the corresponding detection dimensions to obtain an abnormal result, so as to identify the corresponding instruction sequence as a malicious instruction sequence based on the abnormal result, so as to determine the presence of malware in the UEFI firmware layer based on the malicious instruction sequence.

[0040] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor and the memory communicate through the bus, and when the machine-readable instructions are executed by the processor, the steps of any one of the malware detection methods described are performed.

[0041] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of any one of the malware detection methods are executed.

[0042] An embodiment of the present application provides a malware detection method, the method first traverses multiple EFI partitions accessed by the UEFI firmware layer in the computer at startup, filters out the target EFI partition, and copies the files in the target EFI partition to obtain the firmware to be tested; the firmware to be tested is in the form of a firmware image; secondly, the binary code in the firmware to be tested is disassembled to identify the function, and the function topology structure of the function is established based on the control flow information between the multiple basic blocks and the basic blocks in the function; then the function and the function topology structure are detected based on multiple detection dimensions to obtain an abnormal detection result of the corresponding detection dimension; the abnormal detection result includes the instruction sequence corresponding to the function; finally, the abnormal detection results of the corresponding detection dimensions are integrated to obtain an abnormal result, so as to identify the corresponding instruction sequence as a malicious instruction sequence based on the abnormal result, and determine the presence of malware in the UEFI firmware layer based on the malicious instruction sequence shown, which effectively solves the problem that the existing UEFI startup security technology cannot accurately and efficiently identify the presence of malware, and also avoids the use of resources during the computer startup phase, thereby avoiding the limitation of computer resources and improving the detection of malware UEFI The accuracy and comprehensiveness of Bootkits identification also reduces the amount of data calculation. This application combines the inspection of trampoline hook features and call graph value matching features instead of using hash signature verification to detect malicious programs, so that it can also detect new malicious UEFI Bootkits with similar behaviors. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0044] Figure 1A schematic diagram of a process of a first malware detection method provided in an embodiment of the present application is shown;

[0045] Figure 2 A schematic diagram of a process for obtaining files in a target EFI partition provided by an embodiment of the present application is shown;

[0046] Figure 3 A schematic diagram of a process for obtaining basic block dimensions provided by an embodiment of the present application is shown;

[0047] Figure 4 A schematic diagram of a process for obtaining execution flow dimensions provided in an embodiment of the present application is shown;

[0048] Figure 5 A schematic diagram of a process for obtaining code dimensions provided in an embodiment of the present application is shown;

[0049] Figure 6 A schematic diagram of a process of another malware detection method provided in an embodiment of the present application is shown;

[0050] Figure 7 A structural block diagram of a first malware detection device provided in an embodiment of the present application is shown;

[0051] Figure 8 A structural block diagram of an electronic device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0052] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the drawings in the present application only serve the purpose of explanation and description and are not used to limit the scope of protection of the present application. In addition, it should be understood that the schematic drawings are not drawn in real proportion. The flowchart used in this application shows the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flowchart can be implemented out of sequence, and the steps without logical context can be reversed in order or implemented simultaneously. In addition, those skilled in the art can add one or more other operations to the flowchart under the guidance of the content of the present application, or remove one or more operations from the flowchart.

[0053] In addition, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present application.

[0054] It should be noted that the term "comprising" will be used in the embodiments of the present application to indicate the existence of the features declared thereafter, but does not exclude the addition of other features.

[0055] The existing UEFI Bootkits detection methods are mainly carried out through two types of methods: behavior detection and firmware scanning. For behavior detection, this method is actually a relatively conventional protection method, which has a certain false alarm rate (other types of malware attacks may also meet this feature); at the same time, there may be large errors in the judgment method based on the boot time and other methods. In practice, firmware scanning mainly judges whether there is a UEFI Bootkits attack by the modification time of boot firmware files such as bootmgfw.efi and winload.efi. But first of all, the modification time and other attributes of the file system can be modified by malware, and judging by the modification time is not rigorous. For verifying file signatures, frequent updates and changes may occur, making it difficult to manage, and the system is also difficult to maintain.

[0056] Based on this, the embodiments of the present application provide a malware detection method, device, electronic device and storage medium, which are described below through embodiments.

[0057] Example 1

[0058] To facilitate understanding of this embodiment, a malware detection method disclosed in the embodiment of this application is first described in detail. Figure 1 The flowchart of a malware detection method shown in the figure, a malware detection method provided by the present application, the method comprising:

[0059] S101, traversing multiple EFI partitions accessed by the UEFI firmware layer in the computer at startup, filtering out a target EFI partition, and copying files in the target EFI partition to obtain a firmware to be tested; the firmware to be tested is in the form of a firmware image;

[0060] S102, disassembling the binary code in the firmware to be tested to identify a function, and establishing a function topology structure of the function based on control flow information between multiple basic blocks in the function;

[0061] S103, detecting the function and the function topology structure based on multiple detection dimensions, and obtaining anomaly detection results corresponding to the detection dimensions; the anomaly detection results include an instruction sequence corresponding to the function;

[0062] S104. An abnormal result is obtained by fusing the abnormal detection results of the corresponding detection dimensions, so as to identify the corresponding instruction sequence as a malicious instruction sequence based on the abnormal result, and to determine the presence of malware in the UEFI firmware layer based on the malicious instruction sequence.

[0063] In step S101, Figure 2As shown, when the UEFI firmware layer in the computer is started, the LocateHandleBuffer function in the globalboot service (abbreviated as Gbs) service obtains the gEfiSimpleFileSystemProtocol protocol contained in the UEFI firmware layer, which is used to access the EFI partition file system of the computer, that is, each file device is checked through EFI_FILE_IO_INTERFACE. If the file device contains EFI firmware features, then this file device is the target EFI partition, then all files in the target EFI partition are copied and stored as EFI files, and the above content is repeated, thereby traversing multiple EFI partitions accessed by the UEFI firmware layer in the computer when starting, and also filtering out the target EFI partition based on the partition information of each partition. The partition information of the target partition is "system" and is a partition in FAT32 format, that is, the firmware extraction method described in the present application is applicable to the target EFI partition, and all files in the target EFI partition are copied to obtain the firmware to be tested, and the firmware to be tested is a file with a dot efi as a suffix and a TE (Terse Executable) format, all the files include files with permission to copy and files without permission to copy, the files with permission to copy also copy file attributes such as modification time, creation time, etc. when being copied; the files without permission to copy are BCD files, which are parsed using the BCDEDIT tool and saved in text form for subsequent detection, and the firmware to be tested is obtained after all the files are copied, and the copied files enter the static analysis phase of the UEFI firmware image in the form of firmware image. After all the file devices are traversed, the NVRAM variables are obtained through the service gRT->GetVariable function, and the NVRAM variables are stored in the EFI file storage and the NVRAM file storage respectively. For the EFI file storage, the BCD configuration file is searched, the BCD configuration file is parsed using BCDEDIT, and the BCD configuration file is parsed based on BCDEDIT, that is, the files without permission to copy are copied and stored, which is different from the traditional computer resources that detect various files in the EFI partition, and the various anti-debugging and anti-detection methods of UEFI Bootkits cause troubles.

[0064] In step S102, after obtaining the firmware to be tested, the firmware to be tested is input into a pre-selected disassembly tool, that is, the disassembly tool is pre-selected, the disassembly tool is a recursive disassembly engine, and the firmware to be tested is loaded into the selected disassembly tool, so as to disassemble the binary code in the firmware to be tested to obtain the assembly code, and identify the start and end positions of the function by statically analyzing the assembly code, so as to identify the function, which usually involves finding a specific function signature, calling convention, stack operation, etc., and dividing the function, finding branch instructions (such as jumps, conditional jumps) and loop structures by traversing the assembly code, identifying all basic blocks Basic Block, and obtaining the control flow information between the basic blocks based on the jump relationship between the basic blocks, and establishing a control flow graph CFG based on the control flow information, and establishing a function topology structure of the function based on the basic blocks and the control flow graph.

[0065] In step S103, after identifying the function and establishing the function topological structure of the function, the present application obtains the instruction sequence corresponding to the function, that is, the function may include multiple instruction sequences, multiple detection dimensions are set for the function, and different detection methods are set based on different detection dimensions. The detection methods corresponding to the multiple detection dimensions detect the function and the function topological structure to obtain abnormal detection results of the corresponding detection dimensions; the abnormal detection results include abnormal and normal, that is, according to the detection method corresponding to the detection dimension, if the function and the function topological structure meet the preset conditions of each dimension, then the abnormal detection result is abnormal, and on this basis, it also includes the instruction sequence corresponding to the function.

[0066] In the specific implementation process of step S103, there is an embodiment in which: the function topology structure and the function are detected based on multiple detection dimensions to obtain anomaly detection results of corresponding detection dimensions, including:

[0067] S1031. Determine multiple detection dimensions for the function based on the function topology structure; different detection dimensions correspond to different detection methods;

[0068] S1032. Call the detection method corresponding to the detection dimension to detect the function and the function topology structure to obtain an abnormality detection result.

[0069] In steps S1031-S1032, based on the function topology structure, multiple detection dimensions for the function are determined. For example, the detection dimension can be based on the basic block itself included in the function, that is, the basic block dimension, or the execution flow dimension between the basic blocks included in the function, or the code of the function itself, that is, the code dimension. The detection network shown in formula (1) is an overall algorithm based on the trampoline hook behavior feature, and different detection methods are set for different detection dimensions:

[0070]

[0071] Among them, the objective function f belongs to the set of all functions F of the firmware to be tested, and f is a single objective function to be tested. Then, the function and the function topology structure are respectively input into the detection network shown in the formula (1) to obtain the corresponding abnormality detection result.

[0072] In the specific implementation process of step S1032, there is an embodiment in which: the dimension at least includes a basic block dimension;

[0073] The calling of the detection method corresponding to the detection dimension to detect the function and the function topology structure to obtain an abnormality detection result includes:

[0074] S103211. Acquire the function address of the function, traverse the function address to obtain the instruction sequence of the function, and determine whether the instruction sequence meets the target instruction sequence condition;

[0075] S103212. If yes, then based on the frequency of the instruction sequence, mark the instruction sequence and obtain an abnormality detection result.

[0076] In steps S103211-S103212, the present application uses the basic block dimension as follows: Figure 3As shown, the abnormal pattern matching algorithm AMP in formula (1) is used to identify suspicious target function location behavior. First, all function addresses of the function are obtained through the FuncItems(func_ea) function of idautils, and then the function addresses are traversed. The instruction sequence of the function is obtained through idc.print_operand, and it is judged whether the instruction sequence meets the target instruction sequence condition. The target instruction sequence condition is that the instruction sequence has a regular distribution of malicious instruction sequences and function addresses. Usually, the malicious instruction sequence consists of the regular distribution of traversal-related sub, mov, and jnz instructions and the loc_ function address, where the An instruction sequence of arithmetic operation instructions ADD / SUB / XOR or comparison instruction CMP followed by an indirect jump JMP[REG] is often used to dynamically calculate the entry address of malicious code. If the target instruction sequence condition is met, the frequency of occurrence of this type of instruction sequence that loops through consecutive addresses is counted on this basis. When the frequency meets the preset frequency threshold, the anomaly detection result is abnormal. The anomaly detection result marks the corresponding instruction sequence as a potential malicious instruction sequence. The preset frequency threshold can be three times, and can also be set specifically according to actual conditions. The function containing the instruction sequence is marked as an abnormal pattern matching positive function and stored in the abnormal pattern matching positive function address library.

[0077] In the practice of malware detection of UEFI bootkits, traditional detection methods based on code signatures or behavioral heuristics have gradually shown their limitations because it is difficult to capture the deep logical association between malicious code and legitimate components. There are two main reasons why traditional malware call graph matching performs poorly in UEFI security practice. First, due to hardware adaptation and version differences, the implementation of the same function of the UEFI module may have significantly different call graph structures, resulting in an increase in the false alarm rate of exact matching; secondly, attackers can use control flow flattening or indirect call obfuscation to jump through function pointer arrays and destroy the local topological characteristics of the call graph. However, in the practice of UEFI Bootkits detection, this application found that although UEFI Bootkits currently have obfuscation and encryption and decryption operations during the attack process to release subsequent malicious payloads layer by layer, there is no obfuscation and deep hiding behavior when attacking the bottom-level initial code bootx64.efi and bootmgfw.efi of the UEFI boot firmware.

[0078] Therefore, in the specific implementation process of step S1032, there is another embodiment: the dimension at least includes the execution flow dimension;

[0079] The calling of the detection method corresponding to the detection dimension to detect the function and the function topology structure to obtain an abnormality detection result includes:

[0080] S103221. Obtain a call graph of the function based on the function topology structure, and determine whether a block type of the call graph meets a preset standard type;

[0081] S103222. If yes, obtain the exception detection result and input the address of the function into the target address library.

[0082] In steps S103221-S103222, the present application performs flow dimension, such as Figure 4 As shown, the execution flow verification algorithm CGM using the call graph matching in formula (1) is mainly used to identify the coverage and jump behavior of malicious trampoline hooks, that is, to detect the abnormal detection results between basic blocks, by traversing the function and using idaapi.FlowChart(func) to obtain the control flow graph and the call graph, and storing the call graph and the control flow graph in a variable named loop_blocks, to determine whether the block type of the call graph meets the preset standard type, the preset standard type is that there is a suspicious call graph block of the "loop block + long jump" type on the call graph generated between the basic blocks, that is, to detect whether there is a suspicious call graph block of the "loop block + long jump" type in the call graph. When there is more than one suspicious call graph block in the call graph corresponding to the function, that is, at least two suspicious call graph blocks, the abnormal detection result is abnormal, and the abnormal detection result also includes the instruction sequence corresponding to the call graph block of the "loop block + long jump" type, the judgment function is based on the call graph matching positive function, and its address is stored in the target address library, the target address library is the call graph matching positive function address library.

[0083] In the specific implementation process of step S1032, there is also an embodiment in which: the dimension at least includes a code dimension;

[0084] The calling of the detection method corresponding to the detection dimension to detect the function and the function topology structure to obtain an abnormality detection result includes:

[0085] S103231. Traverse the function, locate the target code segment in the function, and extract the first function signature processed by the target code segment;

[0086] S103232. Check the cross-reference of the function and restore it to obtain a second function signature, and obtain an anomaly detection result based on the first function signature and the second function signature.

[0087] In steps S103231-S103232, the present application is in the code dimension, such as Figure 5 As shown, the hook target identification algorithm HTI in formula (1) is used to identify whether there are sensitive function targets in the suspicious loop, and analyze functions such as the vulnerable function signature of ImgArchStartBootApplication. First, based on whether the idautils Functions() function traversal is completed, if completed, the target code segment in the function, that is, the suspicious loop code segment, is located, and the first function signature in the suspicious loop is extracted, that is, the first function signature is the suspicious function signature at this time, and is saved in the pre-established signature list to be tested; secondly, the cross-reference restoration function signature is checked, that is, the function context is analyzed, and its data segment parameter reference is restored. If its If the reference is a vulnerable function signature, the vulnerable function signature is used as the second function signature and saved in the signature list to be tested; finally, if the first function signature and the second function signature in the signature list to be tested have function signatures corresponding to the vulnerable signature in the pre-established sensitive function signature library, the hook target is determined to be a sensitive function signature, and the anomaly detection result obtained at this time is abnormal. The anomaly detection result also includes the corresponding instruction sequence, and the first function signature or the second function signature, which is the sensitive function signature at this time, is saved in the call graph matching positive function address library. This hook target recognition algorithm HTI can identify the target of the trampoline hook through context association analysis, effectively avoiding false positives in the hook recognition process.

[0088] In step S104, after respectively detecting the function and the function topology structure based on the above three detection dimensions to obtain corresponding abnormality detection results, the abnormality detection results of the corresponding dimensions are fused to obtain the abnormality detection results. After the three abnormality detection results are all yes and include the corresponding instruction sequence, a preset fusion method is called. The fusion method is to take the union of the abnormality detection results corresponding to the three detection dimensions, that is, to compare the abnormality detection results corresponding to the three detection dimensions. If the instruction sequences corresponding to the abnormality detection results corresponding to the three detection dimensions are the same, the fusion ends, and it is determined that the instruction sequence corresponding to the abnormality detection result at this time is a malicious instruction sequence, and is identified as the UEFI based on the malicious instruction sequence. If there is malware in the firmware layer, it needs to be processed. The alarm can be set in a pre-set alarm mode, such as automatically sending emails or SMS notifications to the relevant responsible persons, thereby ensuring the computer startup security, that is, the corresponding instruction sequence is identified as a malicious instruction sequence based on the abnormal result, and the number of malicious instruction sequences that need to be processed is reduced, thereby reducing the consumption of computer resources. After the abnormal detection results corresponding to the three detection dimensions form a closed-loop verification, it can be confirmed that the function has the complete attack chain characteristics of "target function positioning-instruction coverage-jump construction", so as to determine it as a maliciously implanted trampoline hook with a high degree of confidence, effectively avoiding the high false alarm rate caused by the single-dimensional verification of traditional detection methods. This judgment mechanism realizes the accurate identification of Bootkits hook behavior at the UEFI firmware layer through a multi-feature cross-validation strategy.

[0089] The security of the UEFI boot process also depends highly on the correctness of the configuration files, among which the boot configuration database BCD (Boot Configuration Data) and the boot variables in the non-volatile random access memory NVRAM are the key tampering targets of UEFI Bootkits. Malware UEFI Bootkits can hijack the control flow or bypass the security mechanism Secure Boot in the early stage of system startup by tampering with the boot entries of BCD or injecting illegal NVRAM variables. BCD, as the core configuration file for Windows system startup, defines the loading parameters, kernel debugging options, device paths and other information of the boot manager bootmgfw.efi. Attackers can implement tampering in the following ways: 1. Insert malicious startup items \EFI\malware.efi, use the bcdedit tool or directly modify the BCD storage file; 2. Enable high-risk debugging flags bootdebug or testsigning to reduce the system security policy; 3. Modify the default or displayorder field to force the priority execution of malicious boot programs. The UEFI variables Boot#### and BootOrder in NVRAM control the boot device order at the firmware level. An attacker can hijack the boot at the firmware level by writing illegal variables or forging Boot0001 to point to a malicious image or tampering with variable properties to change NV+BS to NV for persistence.

[0090] Based on this, the present application provides Example 2, which is used to describe a malware detection method provided by the present application from another aspect.

[0091] Example 2

[0092] To facilitate understanding of this embodiment, a malware detection method disclosed in Embodiment 2 is first described in detail. Figure 6 The flowchart of a malware detection method shown in the figure, a malware detection method provided by the present application, the method further includes:

[0093] S201, obtaining a BCD file to be tested and an NVRAM configuration variable of the UEFI firmware layer when it is started, and processing the BCD file to be tested and the NVRAM configuration variable respectively based on different state processing dimensions to obtain corresponding state results;

[0094] S202: Based on the status result, identify a malicious instruction sequence existing in the BCD file to be tested in the UEFI firmware layer, so as to determine the existence of malware based on the malicious instruction sequence.

[0095] In steps S201-S202, the UEFI firmware usually loads a BCD file when it is started. The file contains the startup configuration information. The BCD file can be obtained through the UEFI firmware interface or directly read from the disk. Various configuration variables of the UEFI firmware, including startup options, security settings, etc., are stored in the NVRAM. These variables can be accessed through the interface provided by the UEFI Runtime Services, and a special parsing tool or parsing code is used to read the content of the BCD file to extract the startup configuration information. The configuration variables in the NVRAM are read through the UEFI Runtime Services interface and their values ​​are parsed. Different state processing dimensions are set for the BCD file to be tested and the NVRAM configuration variables. The state processing dimension for the BCD file to be tested is a static compliance verification state processing dimension, and the state processing dimension for the NVRAM configuration variables is a dynamic timing monitoring state processing dimension. Based on these two state processing dimensions, the BCD file to be tested and the NVRAM configuration are respectively processed accordingly to obtain corresponding state results. Based on the state results of the corresponding dimensions, the instruction sequence corresponding to the malicious instruction sequence is determined to be a malicious instruction sequence, and the existence of malware is determined based on the malicious instruction sequence, thereby avoiding the malicious element boot configuration database BCD (Boot Configuration Data) and non-volatile random access memory to perform boot hijacking, thereby ensuring the secure boot of the UEFI firmware layer.

[0096] In the specific implementation process of step S201, there is an embodiment in which the BCD file to be tested and the NVRAM configuration variable are processed separately based on different state dimensions, including:

[0097] S2011, setting different state processing dimensions based on the BCD file to be tested and the NVRAM configuration variables, and setting corresponding processing methods;

[0098] S2012. According to the corresponding processing methods, process the BCD file to be tested and the NVRAM configuration variables respectively.

[0099] In steps S2011-S2012, in the state processing dimension of the static compliance verification of the BCD file to be tested, a legal BCD file is predefined, which is expressed by formula (2):

[0100] B valid =<Entries,Options,Constraints> (2);

[0101] Among them, Entries is a set of allowed startup items, including {winload, memtest}, Options is a parameter nointegritychecks=0 allowed by the security policy, and Constraints is a constraint condition debugging option that only allows specific signature certificates. First, the BCD file to be tested is preprocessed. The specific method of the preprocessing is to parse the BCD file to be tested into a tree structure Btarget, and verify it with formula (2) to obtain a verification result, as shown in formula (3):

[0102]

[0103] If the verification result indicates that there are unverified startup items or high-risk parameters in the BCD file to be tested, such as testsigning=1, the corresponding status result is abnormal and marked as a configuration violation. Then, an alarm can be issued according to the pre-set alarm method, such as automatically sending an email or SMS notification to the relevant responsible person, thereby ensuring the startup safety of the computer;

[0104] According to the state processing dimension of the dynamic timing monitoring of the NVRAM configuration variable, the NVRAM configuration variable is subjected to an attribute matching check to obtain a matching result. A plurality of variable legal modes are pre-defined for the NVRAM configuration variable. The variable legal mode is the mode of the NVRAM attribute legal variable. If the matching result shows that the NVRAM configuration variable does not match any variable legal mode, the state result is abnormal. At the same time, the target type variable is screened out from the NVRAM configuration variable. The target type variable is the Boot#### class variable Boot0001. The correctness is verified based on the target type variable to obtain a verification result. The final notification result is generated based on the state result and the verification result. If any one of the state result and the verification result exists or both exist at the same time, the notification result is obtained. Then, an alarm can be issued according to a preset alarm method based on the notification result, such as automatically sending an email or SMS notification to the relevant responsible person, thereby ensuring the startup safety of the computer. The specific verification method is to verify the continuity of the hexadecimal index to prevent the attacker from inserting a forged high index item BootFFFF, as shown in formula (4):

[0105] Pattern={Boot[0-9A-F]{4}, Vendor\_[a-zA-Z]+\_Boot} (4);

[0106] Among them, Boot represents the boot number, and Vendor represents different computer manufacturers.

[0107] Example 2

[0108] The present application also provides a malware detection device, such as Figure 7 The block diagram of a malware detection device is shown. The functions implemented by the malware detection device correspond to the steps of executing a malware detection method on a terminal device. The device can be understood as a component of a server including a processor. The malware detection device described in the present application includes:

[0109] The screening module 701 is used to traverse multiple EFI partitions accessed by the UEFI firmware layer in the computer when starting, screen out the target EFI partition, and copy the files in the target EFI partition to obtain the firmware to be tested; the firmware to be tested is in the form of a firmware image;

[0110] Establishing module 702, used for disassembling the binary code in the firmware to be tested to identify the function, and establishing the function topology structure of the function based on the control flow information between the basic blocks in the function;

[0111] A detection module 703 is used to detect the function and the function topology structure based on multiple detection dimensions to obtain an abnormality detection result corresponding to the detection dimension; the abnormality detection result includes an instruction sequence corresponding to the function;

[0112] The fusion module 704 is used to fuse the abnormal detection results of the corresponding detection dimensions to obtain abnormal results, so as to identify the corresponding instruction sequence as a malicious instruction sequence based on the abnormal results, and to determine the presence of malware in the UEFI firmware layer based on the malicious instruction sequence.

[0113] In a feasible implementation, the detection module includes:

[0114] A determination module, used to determine multiple detection dimensions for the function based on the function topology structure; different detection dimensions correspond to different detection methods;

[0115] A calling module is used to call the detection method corresponding to the detection dimension to detect the function and the function topology structure to obtain an abnormal detection result.

[0116] In a feasible implementation manner, the detection module further includes:

[0117] A traversal module, used to obtain the function address of the function, traverse the function address to obtain the instruction sequence of the function, and determine whether the instruction sequence meets the target instruction sequence condition;

[0118] The marking module is used to mark the instruction sequence and obtain an abnormality detection result based on the frequency of the instruction sequence.

[0119] In a feasible implementation, the detection module also includes:

[0120] A judgment module, used for obtaining a call graph of the function based on the function topology structure, and judging whether a block type of the call graph meets a preset standard type;

[0121] An input module is used to obtain the abnormality detection result if yes, and input the address of the function into the target address library.

[0122] In a feasible implementation manner, the detection module further includes:

[0123] A positioning module, used for traversing the function, locating the target code segment in the function, and extracting the first function signature processed by the target code segment;

[0124] A restoration module is used to check the cross-reference of the function and restore to obtain a second function signature, and obtain an anomaly detection result based on the first function signature and the second function signature.

[0125] In a feasible implementation manner, the device further includes:

[0126] An acquisition module is used to acquire the BCD file to be tested and the NVRAM configuration variables when the UEFI firmware layer is started, and process the BCD file to be tested and the NVRAM configuration variables respectively based on different state processing dimensions to obtain corresponding state results;

[0127] An identification module is used to identify a malicious instruction sequence existing in the BCD file to be tested in the UEFI firmware layer based on the status result, so as to determine the existence of malware based on the malicious instruction sequence and determine the existence of malware.

[0128] In a feasible implementation, the fusion module includes:

[0129] A setting module, used to set different state processing dimensions based on the BCD file to be tested and the NVRAM configuration variables, and set corresponding processing methods;

[0130] The processing module is used to process the BCD file to be tested and the NVRAM configuration variable respectively according to the corresponding processing method.

[0131] Example 3

[0132] The present application also provides an electronic device, such as Figure 8As shown, it includes: a processor 801, a memory 802 and a bus 803, the memory 802 stores machine-readable instructions executable by the processor 801, when the electronic device is running, the processor 801 communicates with the memory 802 through the bus 803, and when the machine-readable instructions are executed by the processor 801, any one of the steps of the malware detection method is performed.

[0133] Example 4

[0134] The present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of any one of the malware detection methods are executed.

[0135] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, the specific working process of the system and device described above can refer to the corresponding process in the method embodiment, and will not be repeated in this application. In the several embodiments provided in this application, it should be understood that the disclosed system, device and method can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation. For example, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0136] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0137] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0138] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium that is executable by a processor. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a platform server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard drives, ROM, RAM, magnetic disks, or optical disks.

[0139] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A malware detection method, characterized in that: The method comprises: Traversing multiple EFI partitions accessed by the UEFI firmware layer in the computer at startup, filtering out a target EFI partition, and copying files in the target EFI partition to obtain a firmware to be tested; the firmware to be tested is in the form of a firmware image; Disassembling the binary code in the firmware to be tested to identify the function, and establishing the function topology structure of the function based on the control flow information between the basic blocks in the function; Detect the function and the function topology based on multiple detection dimensions to obtain anomaly detection results corresponding to the detection dimensions; the anomaly detection results include an instruction sequence corresponding to the function; The abnormal detection results of the corresponding detection dimensions are integrated to obtain an abnormal result, so as to identify the corresponding instruction sequence as a malicious instruction sequence based on the abnormal result, so as to determine the presence of malware in the UEFI firmware layer based on the malicious instruction sequence.

2. The method according to claim 1, characterized in that The detecting the function topology structure and the function based on multiple detection dimensions to obtain anomaly detection results of corresponding detection dimensions includes: Based on the function topology structure, determining multiple detection dimensions for the function; different detection dimensions correspond to different detection methods; The detection method corresponding to the detection dimension is called to detect the function and the function topology structure to obtain an abnormal detection result.

3. The method according to claim 2, characterized in that The dimensions include at least basic block dimensions; The calling of the detection method corresponding to the detection dimension to detect the function and the function topology structure to obtain an abnormality detection result includes: Obtaining a function address of the function, traversing the function address to obtain an instruction sequence of the function, and determining whether the instruction sequence meets a target instruction sequence condition; If so, based on the frequency of the instruction sequence, the instruction sequence is marked and an anomaly detection result is obtained.

4. The method according to claim 2, characterized in that: The dimensions include at least an execution flow dimension; The calling of the detection method corresponding to the detection dimension to detect the function and the function topology structure to obtain an abnormality detection result includes: Acquire a call graph of the function based on the function topology structure, and determine whether a block type of the call graph meets a preset standard type; If so, the abnormality detection result is obtained, and the address of the function is input into the target address library.

5. The method according to claim 1, characterized in that The dimension at least includes a code dimension; The calling of the detection method corresponding to the detection dimension to detect the function and the function topology structure to obtain an abnormality detection result includes: Traversing the function, locating a target code segment within the function, and extracting a first function signature processed by the target code segment; The cross-reference of the function is checked and restored to obtain a second function signature, and an anomaly detection result is obtained based on the first function signature and the second function signature.

6. The method according to claim 1, characterized in that The method further comprises: Obtain the BCD file to be tested and the NVRAM configuration variables of the UEFI firmware layer when it is started, and process the BCD file to be tested and the NVRAM configuration variables respectively based on different state processing dimensions to obtain corresponding state results; Based on the status result, a malicious instruction sequence existing in the BCD file to be tested in the UEFI firmware layer is identified to determine the existence of malware based on the malicious instruction sequence, and determine that the malware exists.

7. The method according to claim 6, characterized in that The processing of the BCD file to be tested and the NVRAM configuration variables based on different state dimensions respectively includes: Setting different state processing dimensions based on the BCD file to be tested and the NVRAM configuration variables, and setting corresponding processing methods; According to the corresponding processing methods, the BCD file to be tested and the NVRAM configuration variables are processed respectively.

8. A malware detection device, characterized in that: The device comprises: A screening module is used to traverse multiple EFI partitions accessed by the UEFI firmware layer in the computer at startup, screen out a target EFI partition, and copy files in the target EFI partition to obtain a firmware to be tested; the firmware to be tested is in the form of a firmware image; An establishment module is used to disassemble the binary code in the firmware to be tested to identify the function, and establish a function topology structure of the function based on the control flow information between multiple basic blocks and basic blocks in the function; A detection module, configured to detect the function and the function topology based on multiple detection dimensions, and obtain an abnormality detection result corresponding to the detection dimension; the abnormality detection result includes an instruction sequence corresponding to the function; A fusion module is used to fuse the abnormal detection results of the corresponding detection dimensions to obtain an abnormal result, so as to identify the corresponding instruction sequence as a malicious instruction sequence based on the abnormal result, so as to determine the presence of malware in the UEFI firmware layer based on the malicious instruction sequence.

9. An electronic device, characterized in that: include: A processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor and the memory communicate via the bus, and when the machine-readable instructions are executed by the processor, the steps of a malware detection method as described in any one of claims 1 to 7 are performed.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of a malware detection method as described in any one of claims 1 to 7 are executed.

Images