Malware detection method, device, electronic device and storage medium

Abstract

The application provides a malware detection method and device, electronic equipment and storage medium, effectively solves the problem that the existing UEFI boot security technology cannot accurately and efficiently identify the existence of malware. The method comprises the following steps: traversing a plurality of EFI partitions accessed by a UEFI firmware layer in a computer during booting, screening out a target EFI partition, and copying files in the target EFI partition to obtain a to-be-tested firmware; disassembling binary codes in the to-be-tested firmware to identify functions, and establishing a function topology structure of the functions; detecting the functions and the function topology structure based on multiple detection dimensions to obtain abnormal detection results corresponding to the detection dimensions; fusing the abnormal detection results corresponding to the detection dimensions to obtain an abnormal result, identifying a corresponding instruction sequence as a malicious instruction sequence based on the abnormal result, and determining that there is malware in the UEFI firmware layer based on the malicious instruction sequence.

Description

TECHNICAL FIELD

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

[0002] With the popularization of operating system and website software malicious program detection and computer security use specification, sophisticated attackers often start to expand their attack surface to more underlying systems and firmware to obtain higher control permissions and more persistent attack control. UEFI Bootkits is a kind of malware against UEFI boot platform. UEFI firmware runs in kernel layer permission, and the influence caused by UEFI vulnerability generally has the characteristics of high concealment and high threat. Once the attacker implants malicious code into the UEFI firmware by exploiting the vulnerability, it is difficult to discover and remove at the operating system level, which also makes it a potential target for malware such as UEFI bootkits.

[0003] In 2018, Liu Wenqi et al. published a research on BOOTKIT detection technology based on UEFI firmware in Journal of Electronic Science and Technology University. It involves a DXE driver named UDS through UEFI protocol, which is used to detect various key files of subsequent boot firmware and operating system boot. It designs a backup file warehouse, integrity detection, and file recovery three main modules. Through the characteristics of DXE driver running earlier than operating system boot code, it completes the integrity detection of abnormal bootkits and normal file recovery. But limited by the resource constraints of the startup stage, using signature verification is within the acceptable range in terms of startup speed, but it is very difficult to run DXE phase using technologies such as path extraction, disassembly, and stain identification that require more computing resources and more dependent libraries. This causes the phenomenon of being unable to accurately identify malware.

[0004] The existing UEFI Bootkits detection method mainly detects through two types of ways:

[0005] 1. Behavior detection: judge whether there is UEFI Bootkits through startup time, abnormal process and other ways;

[0006] 2. Firmware scanning: scan UEFI firmware and verify the hash of the firmware, determine whether the underlying firmware file has malicious changes by confirming the hash of various firmware and file systems.

[0007] For behavior detection, this method is actually a common protection means, which has a certain false positive rate (other types of malware attacks may also meet this feature); at the same time, there may be a large error according to the judgment method of the start time; and in the firmware scanning practice, it is mainly judged whether there is a UEFI Bootkits attack by modifying the time of starting the firmware bootmgfw.efi and winload.efi files. But first, the modification time and other attributes of the file system can be modified by malicious software, and the modification time is not rigorous. For verifying the file signature, frequent updates and changes may occur, making it difficult to manage, and the system is also difficult to maintain. SUMMARY

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

[0009] In a first aspect, the embodiments of the present application provide a malware detection method, which comprises:

[0010] Traverse a plurality of EFI partitions accessed by a UEFI firmware layer in a computer during startup, filter out a target EFI partition, and copy files in the target EFI partition to obtain a to-be-tested firmware; the to-be-tested firmware is in the form of a firmware image;

[0011] Disassemble binary code in the to-be-tested firmware to identify a function, and establish a function topology structure of the function based on control flow information between a plurality of basic blocks and basic blocks in the function;

[0012] Detect the function and the function topology structure based on a plurality of detection dimensions to obtain abnormal detection results corresponding to the detection dimensions; the abnormal detection results include instruction sequences corresponding to the function;

[0013] Fuse the abnormal detection results corresponding to the detection dimensions to obtain abnormal results, identify corresponding instruction sequences as malicious instruction sequences based on the abnormal results, and determine that there is malware in the UEFI firmware layer based on the malicious instruction sequences.

[0014] In combination with the first aspect, the embodiments of the present application provide a first possible implementation manner of the first aspect, wherein the detecting the function topology structure and the function based on a plurality of detection dimensions to obtain abnormal detection results corresponding to the detection dimensions comprises:

[0015] Based on the function topology structure, a plurality of detection dimensions for the function are determined; different detection dimensions correspond to different detection manners;

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

[0017] With reference to the first aspect, a second possible implementation of the first aspect is provided in the embodiments of the present application, wherein the dimensions include at least a basic block dimension.

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

[0019] The function address of the function is obtained, and the instruction sequence of the function is obtained by traversing the function address, and it is determined whether the instruction sequence satisfies a target instruction sequence condition;

[0020] If yes, the instruction sequence is labeled based on the frequency of the instruction sequence to obtain an abnormality detection result.

[0021] With reference to the first aspect, a third possible implementation of the first aspect is provided in the embodiments of the present application, wherein the dimensions include at least an execution flow dimension.

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

[0023] Based on the function topology structure, a call graph of the function is obtained, and it is determined whether the block type of the call graph satisfies a preset standard type;

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

[0025] With reference to the first aspect, a fourth possible implementation of the first aspect is provided in the embodiments of the present application, wherein the dimensions include at least a code dimension.

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

[0027] The function is traversed, a target code segment in the function is located, and a first function signature processed by the target code segment is extracted;

[0028] A cross reference of the function is checked and a second function signature is restored, and an abnormality detection result is obtained based on the first function signature and the second function signature.

[0029] With reference to the first aspect, embodiments of the present application provide a sixth possible implementation of the first aspect, and the method further comprises:

[0030] obtaining the to-be-tested BCD file and the NVRAM configuration variable of the UEFI firmware layer at the start time, and processing the to-be-tested BCD file and the NVRAM configuration variable based on different state processing dimensions respectively to obtain corresponding state results;

[0031] based on the state results, identifying a malicious instruction sequence existing in the to-be-tested BCD file in the UEFI firmware layer, determining the existence of malware based on the malicious instruction sequence, and determining the existence of malware.

[0032] With reference to the first aspect, embodiments of the present application provide a sixth possible implementation of the first aspect, and the method further comprises:

[0033] based on the to-be-tested BCD file and the NVRAM configuration variable, setting different state processing dimensions, and setting corresponding processing manners;

[0034] processing the to-be-tested BCD file and the NVRAM configuration variable respectively according to the corresponding processing manners.

[0035] The second aspect, embodiments of the present application provide a malware detection device, the device comprises:

[0036] a screening module configured to traverse a plurality of EFI partitions accessed by a UEFI firmware layer in a computer at a start time, screen a target EFI partition, and copy files in the target EFI partition to obtain a to-be-tested firmware; the to-be-tested firmware is in the form of a firmware image;

[0037] a building module configured to disassemble binary codes in the to-be-tested firmware to identify functions, and build a function topology structure of the functions based on a plurality of basic blocks in the functions and control flow information between the basic blocks;

[0038] a detection module configured to detect the functions and the function topology structure based on a plurality of detection dimensions to obtain abnormal detection results of corresponding detection dimensions; the abnormal detection results include instruction sequences corresponding to the functions;

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

[0040] In a third aspect, an electronic device is provided, comprising a processor, a memory, and a bus, the memory storing machine readable instructions executable by the processor, when the electronic device is running, the processor and the memory communicate through the bus, the machine readable instructions are executed by the processor to perform the steps of any one of the malware detection methods.

[0041] In a fourth aspect, a computer readable storage medium is provided, the computer readable storage medium storing a computer program, when the computer program is run by a processor, the steps of any one of the malware detection methods are performed.

[0042] The malware detection method provided by the embodiments of the present application firstly traverses a plurality of EFI partitions accessed by a UEFI firmware layer in a computer at startup, screens a target EFI partition, and copies 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; secondly, binary codes in the firmware to be tested are disassembled to identify functions, and a function topology structure of the functions is established based on control flow information between a plurality of basic blocks in the functions and the basic blocks; then, the functions and the function topology structure are detected based on a plurality of detection dimensions to obtain abnormal detection results corresponding to the detection dimensions; the abnormal detection results include instruction sequences corresponding to the functions; finally, the abnormal detection results corresponding to the detection dimensions are fused to obtain an abnormal result, to identify corresponding instruction sequences as malicious instruction sequences based on the abnormal result, to determine that there is malware in the UEFI firmware layer based on the malicious instruction sequences, effectively solve the problem that in the existing UEFI startup security technology, the presence of malware cannot be accurately and efficiently identified, avoid the use of resources during the startup stage of the computer, thereby avoiding the limitation of computer resources, improve the accuracy and comprehensiveness of identifying malicious software UEFI Bootkits, and reduce the amount of data calculation. The present application combines the check of the trampoline hook feature and the call graph value matching feature, rather than using the hash signature verification method to detect malicious programs, so that it also has the ability to detect new malicious UEFI Bootkits with similar behaviors. BRIEF DESCRIPTION OF DRAWINGS

[0043] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed in the embodiments. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can also be obtained without creative labor.

[0044] Figure 1A flowchart of a first malware detection method provided by an embodiment of the present application is shown;

[0045] Figure 2 A flowchart of obtaining a file in a target EFI partition provided by an embodiment of the present application is shown;

[0046] Figure 3 A flowchart of obtaining a basic block dimension provided by an embodiment of the present application is shown;

[0047] Figure 4 A flowchart of obtaining an execution flow dimension provided by an embodiment of the present application is shown;

[0048] Figure 5 A flowchart of obtaining a code dimension provided by an embodiment of the present application is shown;

[0049] Figure 6 A flowchart of another malware detection method provided by an embodiment of the present application is shown;

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

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

[0052] To make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to 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 illustration 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 according to the actual proportions. The flowcharts show the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flowcharts can not be implemented in sequence, and the steps without logical context relationship can be reversed in sequence or implemented simultaneously. In addition, one or more other operations can be added to the flowcharts or one or more operations can be removed from the flowcharts under the guidance of the content of the present application.

[0053] In addition, the described embodiments are only some of the embodiments of the present application, not all the embodiments. The components of the embodiments of the present application described and shown in the drawings herein can be arranged and designed in various different 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 claimed application, but only represents 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 creative labor are within 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 presence of the features declared thereafter, but does not exclude the addition of other features.

[0055] The existing UEFI Bootkits detection method mainly detects through two types of behavior detection and firmware scanning. For behavior detection, this method is actually a conventional protection method, which has a certain false positive rate (other types of malicious software attacks may also meet this feature); at the same time, there may be a large error according to the judgment method of the startup time. The firmware scanning is mainly to judge whether there is a UEFI Bootkits attack by modifying the time of the startup firmware bootmgfw.efi and winload.efi files in practice. But first, the modification time and other attributes of the file system can be modified by malicious software, and the modification time is not strict. For verifying the file signature, there may be frequent updates and changes that make 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 equipment and storage medium, which are described below through embodiments.

[0057] Embodiment 1

[0058] In order to facilitate the understanding of the present embodiment, first, a kind of malware detection method disclosed in the embodiments of the present application is introduced in detail. As shown in the flow chart of a kind of malware detection method, the present application provides a kind of malware detection method, the method comprises: Figure 1

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

[0060] S102, disassemble the binary code in the firmware to be tested to identify the function, and establish the function topology structure of the function based on the control flow information between the multiple basic blocks and the basic blocks in the function.​

[0061] S103, detecting the function and the function topology based on multiple detection dimensions, to obtain an abnormality detection result corresponding to a detection dimension; the abnormality detection result includes an instruction sequence corresponding to the function;

[0062] S104, fusing the abnormality detection result corresponding to the detection dimension to obtain an abnormal result, to identify that a corresponding instruction sequence is a malicious instruction sequence based on the abnormal result, and to determine that malicious software exists in the UEFI firmware layer based on the malicious instruction sequence.

[0063] In step S101, as Figure 2As shown, the UEFI firmware layer in the computer, at startup, obtains the gEfiSimpleFileSystemProtocol protocol contained in the UEFI firmware layer through the LocateHandleBuffer function in the globalboot service (abbreviated as Gbs) service, for accessing the EFI partition file system of the computer, that is, checking each file device through the EFI_FILE_IO_INTERFACE, if the file device contains the EFI firmware feature, the file device is the target EFI partition, then copying all files in the target EFI partition and storing them as EFI files, and repeating the above, so as to traverse multiple EFI partitions accessed by the UEFI firmware layer in the computer at startup, and also to filter out the target EFI partition based on the partition information of each partition, the partition information of the target partition is a partition with "system" and FAT32 format, that is, the firmware extraction method described in the 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, the firmware to be tested is in the format of TE (Terse Executable) with the suffix of point efi, all the files include files that can be copied with permission and files that cannot be copied with permission, the files that can be copied with permission are also copied with file attributes such as modification time and creation time when being copied; the files that cannot be copied with permission are BCD files, which are parsed using the BCDEDIT tool and saved in text form for subsequent detection, after all the files are copied, the firmware to be tested is obtained, and the copied files are entered into the UEFI firmware image in the form of a firmware image for static analysis. After all the file devices are traversed, the NVRAM variable is obtained through the gRT->GetVariable function, and then the NVRAM variable is stored in the EFI file storage and the NVRAM file storage, respectively, for the EFI file storage, the BCD configuration file is found, the BCD configuration file is parsed using the BCDEDIT, and the BCD configuration file is parsed based on the BCDEDIT, that is, the copying and storage of the files that cannot be copied with permission are completed, which is different from the traditional computer resource detection method of various files in the EFI partition, and the various anti-debugging and anti-detection means of the UEFI Bootkits bring troubles.

[0064] In step S102, after obtaining the to-be-tested firmware, the to-be-tested firmware is input into a pre-selected disassembling tool, i.e., a pre-selected disassembling tool, the disassembling tool is a recursive disassembling engine, and the to-be-tested firmware is loaded into the selected disassembling tool, so as to disassemble the binary code in the to-be-tested firmware to obtain assembly code, and by statically analyzing the assembly code, the start and end positions of the function are identified, so as to identify the function, which usually involves searching for a specific function signature, a call convention, a stack operation, etc., and the function is divided, the branch instructions (such as jump, conditional jump) and loop structures are searched by traversing the assembly code, all basic blocks are identified, the control flow information between the basic blocks is obtained based on the jump relationship between the basic blocks, the control flow graph CFG is established based on the control flow information, and the function topology structure of the function is established based on the basic blocks and the control flow graph.

[0065] In step S103, after identifying the function and establishing the function topology structure of the function, the present application obtains the instruction sequence corresponding to the function, i.e., the function may include multiple instruction sequences, multiple detection dimensions are set for the function, different detection methods are set based on different detection dimensions, then the detection methods corresponding to the multiple detection dimensions detect the function and the function topology structure to obtain abnormal detection results corresponding to the detection dimensions; the abnormal detection results include abnormality and normality, i.e., according to the detection method corresponding to the detection dimension, it is detected that the function and the function topology structure satisfy the pre-set condition of each dimension, then the abnormal detection result is abnormal, on this basis, the instruction sequence corresponding to the function is also included.

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

[0067] S1031, based on the function topology structure, multiple detection dimensions for the function are determined; different detection dimensions correspond to different detection methods;

[0068] S1032, the detection method corresponding to the detection dimension is called to detect the function and the function topology structure to obtain abnormal detection results.

[0069] In steps S1031-S1032, based on the function topology, a plurality of detection dimensions for the function are determined. The detection dimensions can be based on the basic blocks themselves, i.e., basic block dimensions, based on the basic blocks included in the function, i.e., execution flow dimensions, or based on the code of the function itself, i.e., code dimensions. For example, the detection network shown in formula (1) is a total algorithm based on trampoline hook behavior characteristics, and different detection methods are set for different detection dimensions.

[0070]

[0071] wherein the target function f belongs to a set of all functions F to be tested, and f is a single target function to be tested. The function and the function topology are input into the detection network shown in formula (1) respectively, so as to obtain corresponding anomaly detection results.

[0072] In the specific implementation process of step S1032, there is an embodiment that the dimensions at least include basic block dimensions.

[0073] The detection method corresponding to the detection dimension is called to detect the function and the function topology to obtain anomaly detection results, including:

[0074] S103211, 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;

[0075] S103212, if yes, based on a frequency of the instruction sequence, labeling the instruction sequence to obtain anomaly detection results.

[0076] In steps S103211-S103212, in the basic block dimensions, for example, Figure 3As shown, the abnormal pattern matching algorithm AMP in formula (1) is used to identify suspicious target function positioning behaviors. First, the function address of the function is obtained by the FuncItems (func_ea) function of idautils, and then the function address is traversed, the instruction sequence of the function is obtained by idc.print_operand, and it is judged whether the instruction sequence meets the target instruction sequence condition, that is, the regular distribution of the malicious instruction sequence in the instruction sequence and the function address. The malicious instruction sequence is usually composed of the regular distribution of the sub, mov, jnz instructions and the loc_function address, wherein the instruction sequence of the continuous arithmetic operation instruction ADD / SUB / XOR or the comparison instruction CMP followed by the indirect jump JMP[REG] instruction sequence is often used to dynamically calculate the malicious code entry address. If the target instruction sequence condition is met, the frequency of the occurrence of the instruction sequence of the loop traversal continuous address is counted on this basis. When the frequency meets the preset frequency threshold, the abnormal detection result is abnormal. The corresponding instruction sequence is marked as a potential malicious instruction sequence, and the preset frequency threshold can be three times or can be set according to the actual situation. The function containing the instruction sequence is marked as an abnormal pattern matching positive function, and is stored in the abnormal pattern matching positive function address library.

[0077] In the practice of UEFI bootkit malware detection, the traditional code signature or behavior heuristic-based detection method gradually shows limitations because it is difficult to capture the deep logical association between malicious code and legal components. There are two main reasons why traditional malware call graph matching performs poorly in UEFI security practices. First, due to hardware adaptation and version differences, the implementation of the same function may have significantly different call graph structures, leading to an increase in false positive rates for accurate matching. Second, attackers can control flow flattening or indirect call obfuscation through function pointer arrays to jump, destroying the local topological features of the call graph. However, in the practice of UEFI Bootkits detection, it is found that UEFI Bootkits currently appear to have obfuscation and encryption operations during the attack process to release the malicious payload layer by layer, but there is no obfuscation and deep hiding behavior for the initial code bootx64.efi and bootmgfw.efi at the bottom layer of the attack UEFI boot firmware.

[0078] Therefore, in the implementation process of step S1032, there is another embodiment that the dimensions at least include an 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 abnormality detection result and input the address of the function into the target address library.

[0082] In steps S103221-S103222, the present application executes the flow dimension, such as Figure 4 As shown, the execution flow verification algorithm CGM using 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 call graph, and storing the call graph and the control flow graph in a variable named loop_blocks, it is judged 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. The abnormal detection result also includes the instruction sequence corresponding to the call graph block of the "loop block + long jump" type. This judgment function is based on the call graph matching positive function, and its address is stored in the target address library, which 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, the traversal of the Functions() function of idautils is completed. If it is 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 will be 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 signatures 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 the function and the function topology are detected based on the above three detection dimensions respectively to obtain corresponding anomaly detection results, the anomaly detection results of the corresponding dimensions are fused to obtain an anomaly detection result. When the three anomaly detection results are all yes and include corresponding instruction sequences, a preset fusion mode is called. The fusion mode is to take the union of the anomaly detection results of the three detection dimensions, that is, to compare the anomaly detection results of the three detection dimensions. If the instruction sequences corresponding to the anomaly detection results of the three detection dimensions are the same, the fusion ends. It is determined that the instruction sequence corresponding to the anomaly detection result at this time is a malicious instruction sequence, and it is determined based on the malicious instruction sequence that there is malicious software in the UEFI firmware layer, which needs to be processed. The alarm mode can be set in advance, such as automatically sending an email or a short message to the relevant person in charge, thereby ensuring the safety of the computer startup, that is, achieving the effect of identifying the corresponding instruction sequence as a malicious instruction sequence based on the anomaly result, and reducing the number of malicious instruction sequences that need to be processed, thereby reducing the consumption of computer resources. After the anomaly detection results of 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", thereby determining it as a malicious implanted trampoline hook with high confidence, effectively avoiding the high false positive rate caused by single dimension verification in the traditional detection method. The determination mechanism realizes accurate identification of the Bootkits hook behavior in the UEFI firmware layer through the multi-feature cross-verification strategy.

[0089] The security of the UEFI boot flow is highly dependent on the correctness of the configuration file, wherein the boot configuration database (BCD) and the boot variable in the non-volatile random access memory (NVRAM) are key tampering targets of the UEFI Bootkits. The malicious UEFI Bootkits can hijack the control flow or bypass the secure boot mechanism at an early stage of system boot by tampering with the boot entries of the BCD or injecting illegal NVRAM variables. The BCD, as the core configuration file of the Windows system boot, defines the loading parameters of the boot manager bootmgfw.efi, the kernel debugging options, and the device path information. Attackers can tamper with the BCD in the following ways: 1. inserting a malicious boot item \EFI\malware.efi through the bcdedit tool or directly modifying the BCD storage file; 2. enabling the high-risk debugging flags bootdebug or testsigning to reduce the system security policy; and 3. modifying the default or displayorder field to force the execution of the malicious boot program in priority. The UEFI variables Boot#### and BootOrder in the NVRAM control the boot device sequence at the firmware layer. Attackers can achieve boot hijacking at the firmware level by writing illegal variables or malicious images pointed to by the fake Boot0001 or by changing the variable attribute to NV to persist the NV+BS.

[0090] Based on this, the embodiment 2 is provided to express the malware detection method provided by the application from another aspect.

[0091] Embodiment 2

[0092] In order to facilitate the understanding of the embodiment, first, a malware detection method disclosed by the embodiment 2 is introduced in detail. As shown in a flow chart of a malware detection method, the malware detection method provided by the application comprises the following steps. Figure 6

[0093] S201, obtaining a to-be-tested BCD file and NVRAM configuration variable at the boot time of the UEFI firmware layer, and processing the to-be-tested BCD file and NVRAM configuration variable based on different state processing dimensions to obtain corresponding state results;

[0094] S202, based on the state results, identifying a malicious instruction sequence existing in the to-be-tested BCD file in the UEFI firmware layer, to determine the existence of the malware based on the malicious instruction sequence.

[0095] ​In steps S201-S202, the UEFI firmware usually loads the BCD file containing the startup configuration information at startup, the BCD file can be obtained by UEFI firmware interface or directly read from the disk, the NVRAM stores various configuration variables of the UEFI firmware, including startup options, security settings, etc., these variables can be accessed through the interface provided by the UEFI Runtime Services, and the content of the BCD file can be read by using a special parsing tool or writing a parsing code to extract the startup configuration information, the configuration variables in the NVRAM are read through the UEFI Runtime Services interface, and the values are parsed, and different state processing dimensions are set for the to-be-tested BCD file and the NVRAM configuration variable, for the state processing dimension of the to-be-tested BCD file for static compliance verification, for the state processing dimension of the NVRAM configuration variable for dynamic timing monitoring, then based on the two state processing dimensions, the to-be-tested BCD file and the NVRAM configuration are processed respectively to obtain corresponding state results, and the instruction sequence corresponding to the state result of the corresponding dimension is a malicious instruction sequence, and the existence of malicious software is determined based on the malicious instruction sequence, avoiding startup hijacking of the malicious element startup configuration database BCD (Boot Configuration Data) and the non-volatile random access memory, thereby ensuring the safe startup of the UEFI firmware layer.

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

[0097] S2011, different state processing dimensions are set for the to-be-tested BCD file and the NVRAM configuration variable, and a corresponding processing mode is set;

[0098] S2012, the to-be-tested BCD file and the NVRAM configuration variable are processed respectively according to the corresponding processing mode.

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

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

[0101] Wherein, 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 that the debugging option only allows a specific signature certificate. First, the BCD file to be tested is preprocessed, and the specific way of 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 is an unverified startup item or a high-risk parameter such as testsigning = 1 in the BCD file to be tested, the corresponding state result is abnormal at this time, and is marked as a configuration violation. Then, an alarm can be given according to the pre-set alarm mode, such as automatically sending an email or an SMS message to the relevant person in charge, thereby ensuring the safety of the computer startup;

[0104] For the state processing dimension of dynamic timing monitoring of the NVRAM configuration variable, attribute matching checking is performed on the NVRAM configuration variable to obtain a matching result. A plurality of variable legal modes are defined in advance for the NVRAM configuration variable. The variable legal mode is the mode of a legal NVRAM attribute variable. If the matching result indicates that the configuration variable of the NVRAM does not match any variable legal mode, the state result is abnormal at this time. Meanwhile, a target type variable is screened out from the NVRAM configuration variable, which is a Boot#### class variable Boot0001. Based on the target type variable, correctness verification is performed to obtain a verification result. Based on the state result and the verification result, a final notification result is generated. If either the state result or the verification result exists or both exist at the same time, the notification result is obtained. Then, an alarm can be given according to the pre-set alarm mode based on the notification result, such as automatically sending an email or an SMS message to the relevant person in charge, thereby ensuring the safety of the computer startup. The specific verification method is to verify the continuity of the hexadecimal index to prevent attackers from inserting a fake high-index item BootFFFF. The specific verification method is shown in formula (4):

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

[0106] Wherein, Boot represents the startup number, and Vendor represents different computer manufacturers.

[0107] Embodiment 2

[0108] The application further provides a malware detection device, such as Figure 7 Fig. 1 shows a block diagram of a malware detection device, the functions implemented by the device correspond to the steps of the method for performing malware detection 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 application, the device includes:

[0109] The screening module 701 is configured to traverse a plurality of EFI partitions accessed by the UEFI firmware layer in the computer during startup, screen a target EFI partition, and copy files in the target EFI partition to obtain a to-be-tested firmware; the to-be-tested firmware is in the form of a firmware image.

[0110] The establishing module 702 is configured to identify a function by disassembling binary code in the to-be-tested firmware, and establish a function topology structure of the function based on a plurality of basic blocks in the function and control flow information between the basic blocks.

[0111] The detection module 703 is configured to detect the function and the function topology structure based on a plurality of detection dimensions, to obtain abnormal detection results corresponding to the detection dimensions; the abnormal detection results include an instruction sequence corresponding to the function.

[0112] The fusion module 704 is configured to fuse the abnormal detection results corresponding to the detection dimensions to obtain abnormal results, to identify a corresponding instruction sequence as a malicious instruction sequence based on the abnormal results, and to determine that malicious software exists in the UEFI firmware layer based on the malicious instruction sequence.

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

[0114] The determining module is configured to determine a plurality of detection dimensions for the function based on the function topology structure; different detection dimensions correspond to different detection manners.

[0115] The calling module is configured to call a detection manner corresponding to the detection dimension to detect the function and the function topology structure to obtain abnormal detection results.

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

[0117] The traversal module is configured to obtain a function address of the function, traverse the function address to obtain an instruction sequence of the function, and determine whether the instruction sequence meets a target instruction sequence condition.

[0118] The labeling module is configured to, if yes, label the instruction sequence based on a frequency of the instruction sequence to obtain abnormal detection results.

[0119] In an implementation, the detecting module further comprises:

[0120] The judging module is configured to 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.

[0121] The input module is configured to, if yes, obtain the abnormality detection result, and input an address of the function into a target address library.

[0122] In an implementation, the detecting module further comprises:

[0123] The positioning module is configured to traverse the function, locate a target code segment in the function, and extract a first function signature processed by the target code segment.

[0124] The restoring module is configured to check cross-references of the function, and restore a second function signature to obtain an abnormality detection result based on the first function signature and the second function signature.

[0125] In an implementation, the apparatus further comprises:

[0126] The obtaining module is configured to obtain a to-be-tested BCD file and an NVRAM configuration variable of a UEFI firmware layer at startup, and process the to-be-tested BCD file and the NVRAM configuration variable based on different state processing dimensions respectively to obtain corresponding state results.

[0127] The identifying module is configured to identify a malicious instruction sequence existing in the to-be-tested BCD file in the UEFI firmware layer based on the state results, determine existence of malicious software based on the malicious instruction sequence, and determine existence of malicious software.

[0128] In an implementation, the fusing module comprises:

[0129] The setting module is configured to set different state processing dimensions based on the to-be-tested BCD file and the NVRAM configuration variable, and set corresponding processing manners.

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

[0131] Embodiment 3

[0132] The application further provides an electronic device, such as Figure 8As shown, the electronic device comprises: 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 and the memory 802 communicate through the bus 803, the machine readable instructions are executed by the processor 801 to perform the steps of any one of the malware detection methods.

[0133] Embodiment 4

[0134] The application further provides a computer readable storage medium, the computer readable storage medium stores a computer program, the computer program is executed by a processor to perform the steps of any one of the malware detection methods.

[0135] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working process of the above-described system and device can refer to the corresponding process in the method embodiment, and will not be repeated in the application. In the several embodiments provided in the application, it should be understood that the disclosed system, device and method can be implemented by other ways. The above-described device embodiments are only schematic, for example, the division of the modules is only a logical function division, and actual implementation can have another division manner, for example, a plurality of modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed mutual elements can be indirect coupling or communication connection through some communication interface, device or module, which can be electrical, mechanical or other forms.

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

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

[0138] If the functions are implemented in the form of software function units and sold or used as independent products, they can be stored in a nonvolatile computer readable storage medium executable by a processor. Based on this understanding, the technical solutions of the present application essentially or the parts that contribute to the prior art or parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a platform server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a ROM, a RAM, a magnetic disk or an optical disk, and various media that can store program codes.

[0139] The above is merely a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to 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 a function, and establishing a function topology structure of the function based on control flow information between multiple basic blocks in the function; Detecting 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, 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.

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 corresponding to the detection dimensions includes: Based on the function topology, 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 abnormality 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 the 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 2, characterized in that The dimension includes at least 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 at startup, 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 presence 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 variable 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 configured 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 in the function; a detection module, configured to detect the function and the function topology based on multiple detection dimensions, and obtain an anomaly detection result corresponding to the detection dimension; the anomaly 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, and 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. When the electronic device is running, the processor and the memory communicate via the bus. When the machine-readable instructions are executed by the processor, the steps of a malware detection method according to 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, which, when executed by a processor, executes the steps of a malware detection method according to any one of claims 1 to 7.

Images