Malicious file detection method, device, electronic device and storage medium
By comparing the function library files and memory module files of the input method program, and using machine code comparison to identify malicious inline hook instructions, the problem of difficult to detect malicious inline hooks in the input method program in the existing technology is solved, and effective identification and security guarantees of malicious files are achieved.
Patent Information
- Application Number
- CN202210061344.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-01-19
- Publication Date
- 2025-08-29
- Estimated Expiration
- 2042-01-19
AI Technical Summary
The prior art is difficult to effectively detect malicious inline hooks in input method programs, resulting in user operation information being listened to and stolen.
By comparing the function library files of the input method program and the module files corresponding to the memory, detecting malicious inline hooks in the module files, and using machine code comparison to identify jmp, push, pop and int3 instructions to determine whether the module file is a malicious file.
It realizes effective detection of malicious inline hooks in the input method program, avoids the shortcomings of existing detection methods, and ensures the security of user operation information.
Smart Images
Figure CN114417335B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of security detection, and in particular to a malicious file detection method, device, electronic device and storage medium. Background Art
[0002] For user convenience, input method programs are often pre-installed in operating systems. Due to their widespread popularity, malicious actors can tamper with them to monitor input method users' operations and steal their input. Specifically, malicious actors can add inline hooks to the function library files used by input method programs, using these hooks to monitor and record user operations and input. However, inline hooks are highly concealed, making them difficult to detect using standard hook detection methods.
[0003] Therefore, how to quickly and effectively detect malicious files in input method programs is a technical problem that those skilled in the art need to face. Summary of the Invention
[0004] The purpose of the present invention is to provide a malicious file detection method, device, electronic device and storage medium, which can detect malicious inline hook settings in module files by comparing function library files and their corresponding module files in memory, thereby effectively detecting malicious inline hooks in input method programs.
[0005] To solve the above technical problems, the present invention provides a malicious file detection method, comprising:
[0006] Obtaining the function library file used by the input method program and the module file corresponding to the function library file in the memory;
[0007] When it is determined that the function library file and the module file are both PE files, comparing the first code segment in the function library file with the second code segment in the module file to determine a machine code in the second code segment that is different from that in the first code segment;
[0008] When it is determined that the machine code includes a preset instruction, the module file is determined to be a malicious file; the preset instruction includes jmp, push, pop and int3.
[0009] Optionally, before determining that the function library file and the module file are both PE files, the method further includes:
[0010] Extracting a DOS header and an NT header from the function library file and the module file; the DOS header includes a first DOS header of the function library file and a second DOS header of the module file, and the NT header includes a first NT header of the function library file and a second NT header of the module file;
[0011] Determine whether both the DOS header and the NT header contain a preset PE file identifier;
[0012] If so, it is determined that the function library file and the module file are both the PE files.
[0013] Optionally, before comparing the first code segment in the function library file and the second code segment in the module file, the method further includes:
[0014] Extracting a digital signature from the first NT header, and using the digital signature to detect whether the function library file has been tampered with;
[0015] If so, repair the function library file;
[0016] If not, the process proceeds to the step of comparing the first code segment in the function library file with the second code segment in the module file.
[0017] Optionally, extracting a DOS header and an NT header from the function library file and the module file includes:
[0018] The function library file is written into the memory according to the size of the function library file, and a memory address corresponding to the function library file in the memory is obtained, and a base address of the module file in the memory is obtained;
[0019] Obtaining the first DOS header in the memory using the memory address, and obtaining the second DOS header using the base address;
[0020] The first NT header is obtained in the memory according to the offset information of the first DOS header, and the second NT header is obtained according to the offset information of the second DOS header.
[0021] Optionally, comparing the first code segment in the function library file and the second code segment in the module file includes:
[0022] Extracting a code segment section table from the function library file and the module file in the memory according to the offset information in the NT header; the code segment section table includes a first code segment section table of the function library file and a second code segment section table of the module file;
[0023] extracting the first code segment from the first code segment section table, and extracting the second code segment from the second code segment section table;
[0024] The second code segment is copied to another area of the memory, and the first code segment is compared with the copied second code segment.
[0025] Optionally, after determining that the module file is a malicious file, the method further includes:
[0026] Obtaining a base address of the module file in the memory, and using a process snapshot to obtain loading base addresses of all modules in the memory and disk paths corresponding to the modules on disk;
[0027] Matching the base address with the loading base address, and determining the target disk path of the module file according to the matching result;
[0028] The target disk path is sent to a preset system service main program, so that the preset system service main program deletes the file stored in the target disk path.
[0029] Optionally, before obtaining the function library file used by the input method program, the method further includes:
[0030] When the startup instruction sent by the preset system service main program is received, the step of obtaining the function library file used by the input method program is entered.
[0031] The present invention also provides a malicious file detection device, comprising:
[0032] An acquisition module is used to acquire the function library file used by the input method program and the module file corresponding to the function library file in the memory;
[0033] a comparison module, configured to, when it is determined that both the function library file and the module file are PE files, compare the first code segment in the function library file with the second code segment in the module file to determine a machine code in the second code segment that is different from that in the first code segment;
[0034] The malicious judgment module is used to judge that the module file is a malicious file when it is determined that the machine code contains preset instructions; the preset instructions include jmp, push, pop and int3.
[0035] The present invention further provides an electronic device, comprising:
[0036] Memory for storing computer programs;
[0037] A processor is configured to implement the steps of the malicious file detection method described above when executing the computer program.
[0038] The present invention also provides a storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the malicious file detection method as described above are implemented.
[0039] The present invention provides a malicious file detection method, comprising: obtaining a function library file used by an input method program, and a module file corresponding to the function library file in a memory; when it is determined that the function library file and the module file are both PE files, comparing a first code segment in the function library file with a second code segment in the module file, and determining a machine code in the second code segment that is different from that in the first code segment; when it is determined that the machine code includes a preset instruction, determining that the module file is a malicious file; the preset instruction includes jmp, push, pop, and int3.
[0040] As can be seen, the present invention first obtains the function library file of the input method program on the disk and the module file corresponding to the function library file in the memory, and determines whether the function library file and the module file are PE files. This is to ensure that the function library file and the module file meet the detection conditions and can use the function library file to extract the code segment with malicious added inline hooks from the module file; after determining that the function library file and the module file are both PE files, the present invention extracts the first code segment and the second code segment from the two files respectively, and compares these code segments to obtain the machine code in the second code segment that is different from the machine code in the first code segment. Then, by determining whether the machine code contains jmp, push, pop and int3, which are commonly used instructions for inline hooks, it is determined whether there are malicious inline hooks in the module file. This can effectively detect malicious files with malicious inline hooks in the input method program, and avoid the situation where existing hook detection methods cannot detect inline hooks. The present invention also provides a malicious file detection device, electronic device and storage medium, which have the above-mentioned beneficial effects. BRIEF DESCRIPTION OF THE DRAWINGS
[0041] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.
[0042] Figure 1 A flowchart of a malicious file detection method provided by an embodiment of the present invention;
[0043] Figure 2 This is a structural block diagram of a malicious file detection device provided by an embodiment of the present invention. DETAILED DESCRIPTION
[0044] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.
[0045] In the related art, malicious attackers can add inline hooks to the function library files used by the input method program, and then use the hooks to monitor and record the user's operation information and input content. However, inline hooks are highly concealed and difficult to detect using general hook detection methods. In view of this, the present invention provides a malicious file detection method, which can detect malicious inline hook settings in module files by comparing function library files and their corresponding module files in memory, thereby effectively detecting malicious inline hooks in input method programs. Please refer to Figure 1 , Figure 1 A flowchart of a malicious file detection method provided by an embodiment of the present invention may include:
[0046] S101: Acquire a function library file used by an input method program and a module file corresponding to the function library file in a memory.
[0047] It should be noted that the function library files used by different input method programs may be different. For the Microsoft input method corresponding to the Windows operating system, the core function library files used are msctf.dll and imm32.dll, wherein msctf.dll is a com component program compiled by the Microsoft input method TSF (Text Services Framework, Text Service Framework) framework code, and imm32.dll is a com component program compiled by the Microsoft input method using IME (Input Method Editors, Input Method Programming Specification) framework code. It should be noted that the function library files are stored on the disk. In addition, it is understandable that when the input method program needs to use related function functions, the function library needs to be loaded into the memory, and the file corresponding to the function library file in the memory is the module file. The embodiment of the present invention does not limit the query method of the module file, and the relevant technology of the DLL file (Dynamic Link Library, Dynamic Link Library) can be referenced.
[0048] S102: When it is determined that both the function library file and the module file are PE files, compare the first code segment in the function library file with the second code segment in the module file to determine the machine code in the second code segment that is different from that in the first code segment.
[0049] To ensure that function library and module files meet the detection requirements and can be used to extract maliciously added inline hook code segments from module files, embodiments of the present invention additionally determine whether both the function library and module files are PE files. PE (Portable Executable) files are program files on the Windows operating system. Specifically, the DOS header and NT header of the function library and module files are checked to see if they contain a preset PE file identifier. This determines whether the two files are PE files. The DOS header is used for compatibility with the MS-DOS operating system, while the NT header contains the key information of the Windows PE file.
[0050] In one possible scenario, before determining that the function library file and the module file are both PE files, the following steps may also be included:
[0051] Step 11: Extract the DOS header and NT header from the function library file and the module file; the DOS header includes the first DOS header of the function library file and the second DOS header of the module file, and the NT header includes the first NT header of the function library file and the second NT header of the module file;
[0052] Step 12: Determine whether both the DOS header and the NT header contain a preset PE file identifier; if so, proceed to step 13; if not, stop detecting;
[0053] Step 13: Make sure that both the library file and the module file are PE files.
[0054] Specifically, the first member e_magic in the DOS header definition IMAGE_DOS_HEADER is used as an identifier to determine whether it is a PE file. If the value of e_magic is not "MZ" (hexadecimal 0x5A4D), it is not a PE file. The first member Signature in the NT header definition IMAGE_NT_HEADERS32 or IMAGE_NT_HEADERS64 is used as another identifier to determine whether it is a PE file. If Signature is not "PE" (hexadecimal 0x00004550), it is not a PE file. Only when e_magic and Signature are both the default values of PE files, it is said that the file is a PE file.
[0055] Furthermore, the extraction of the DOS and NT headers must be performed in memory. Since the library files are located on disk rather than in memory, they must be loaded into memory for extraction. Furthermore, the extraction of the DOS and NT headers follows a sequential order: the DOS header is extracted first, followed by the NT header. The DOS header is typically extracted based on the file's memory address in memory, while the NT header is typically extracted based on the DOS header's offset information.
[0056] In one possible scenario, extracting DOS headers and NT headers from library files and module files may include:
[0057] Step 21: The function library file will be written into the memory according to the size of the function library file, and the memory address corresponding to the function library file in the memory is obtained, and the base address of the module file in the memory is obtained at the same time.
[0058] Specifically, you can use the API function to open the function library file and obtain the file size, then use the memory allocation function malloc to allocate a memory space of the same size as the file, and finally read the function library file into the allocated memory space; you can use the LoadLibraryA / LoadLibraryW function to obtain the base address of the module file.
[0059] Step 22: Obtain the first DOS header in the memory using the memory address, and obtain the second DOS header using the base address.
[0060] Step 23: Obtain the first NT header in the memory according to the offset information of the first DOS header, and obtain the second NT header according to the offset information of the second DOS header.
[0061] Specifically, the last member e_lfanew in the header definition IMAGE_DOS_HEADER of the DOS header is used to specify the offset of the starting position of the PE header from the file (hexadecimal 0X3C), and its value is the starting address of the NT header.
[0062] After determining that both files are PE files, code segments can be extracted from the function library file and the module file and compared. Specifically, the code segments in the PE file are usually stored in the code segment section table (.text section), so it is necessary to locate the code segment section table in the PE file before the code segments can be extracted from the section table. The embodiment of the present invention does not limit the specific method of locating the section table, and reference may be made to the relevant technology of PE files. Since the section table is usually set at the back of the NT header, the position of the code segment section table can be determined based on the offset information of the NT header.
[0063] Furthermore, after determining the section table location, in order to perform separate detection on the module file, the code segment in the module file can be saved in another location in the memory, and the code segment of the function library file can be compared with the copied code segment of the module file.
[0064] In one possible scenario, comparing the first code segment in the function library file and the second code segment in the module file may include:
[0065] Step 31: extracting a code segment section table from the function library file and the module file in the memory according to the offset information in the NT header; the code segment section table includes the first code segment section table of the function library file and the second code segment section table of the module file;
[0066] Step 32: extracting the first code segment from the first code segment section table, and extracting the second code segment from the second code segment section table;
[0067] Step 33: Copy the second code segment to another area of the memory, and compare the first code segment with the copied second code segment.
[0068] Specifically, based on the size of the second code segment, the memory allocation function malloc can be used to allocate memory space of the same size as the code segment, and then the memory copy function memcpy can be used to copy the second code segment into the memory space. After the copy is completed, the two code segments can be compared to extract the machine code that is different from the first code segment.
[0069] Of course, to ensure reliable comparison results, the library file can also be checked for modifications before extracting the code segments. Specifically, the digital signature can be extracted from the library file's NT header and used to verify the library file's integrity. If the library file has been tampered with, it will be unusable for code segment comparison and must be repaired.
[0070] In one possible case, before comparing the first code segment in the function library file and the second code segment in the module file, the following steps may also be performed:
[0071] Step 41: Extract the digital signature from the first NT header and use the digital signature to detect whether the function library file has been tampered with; if so, proceed to step 42; if not, proceed to step 43.
[0072] Specifically, the PE optional header in the NT header contains the member IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY], which points to the digital signature.
[0073] Step 42: Repair the function library file.
[0074] It should be noted that the embodiment of the present invention does not limit the specific repair process of the function library file, and reference may be made to the relevant technology of DLL files.
[0075] Step 43: Entering the step of comparing the first code segment in the function library file and the second code segment in the module file.
[0076] S103: When it is determined that the machine code includes a preset instruction, the module file is determined to be a malicious file; the preset instructions include jmp, push, pop and int3.
[0077] After extracting the different machine codes, the present invention further checks whether the machine codes contain pre-set instructions commonly used for inline hooking, such as jmp (jump instruction), push (stack push instruction), pop (pop instruction), and int3 (breakpoint instruction). If so, it can be determined that the module file contains malicious inline hooks. Of course, inline hooks may also use other instructions besides these four instructions. For more information, please refer to the relevant inline hook technology.
[0078] Furthermore, after determining that the module file is a malicious file, its corresponding file on the disk can be further deleted. Specifically, the disk path corresponding to the module file on the disk can be searched, and then all files under the path can be deleted and uninstalled. In an embodiment of the present invention, a process snapshot can be used to find the path of the module file on the disk. This is because the process snapshot can record the loading base address in the memory and the path on the disk of each module loaded into the memory. It is only necessary to match the base address of the module file with the loading base address in the process snapshot to determine the disk path of the module file. Further, considering that the disk file corresponding to the module file may be set in the system folder, the file deletion and uninstallation work in the system folder needs to be performed by the system administrator, which generally requires higher permissions. In order to achieve effective deletion, the embodiment of the present invention can further preset a system service main program, and the program performs the file deletion and uninstallation work. The malicious file detection device (i.e., the device that executes the various steps of the embodiment of the present invention) only needs to send the disk path to the system service main program. Among them, the system service program (Microsoft Windows service, formerly known as NT service) allows users to create executable applications that can run for a long time in a Windows session. This service can effectively solve the deletion and uninstallation problems caused by permission restrictions. In addition, it can automatically start when the computer starts, can be paused and restarted, and does not display any user interface. It is suitable for settings in servers and long-running scenarios.
[0079] In one possible scenario, after determining that the module file is a malicious file, the following steps may also be performed:
[0080] Step 51: Get the base address of the module file in the memory, and use the process snapshot to get the loading base address of all modules in the memory and the disk path corresponding to the module on the disk;
[0081] Step 52: Match the base address with the loading base address, and determine the target disk path of the module file according to the matching result;
[0082] Step 53: Send the target disk path to the default system service main program, so that the default system service main program deletes the file stored in the target disk path.
[0083] It should be noted that the embodiments of the present invention do not limit the communication method between the malicious file detection device and the preset system service main program. For example, the preset system service main program may use a callback function to receive the disk path returned by the malicious file detection device, while the main program and the detection device communicate using a pipe. Of course, after determining that the function library file has been tampered with, the malicious file detection device may also send instructions to the system service main program to cause the system service main program to repair the function library file. Furthermore, the system service main program may also have a scheduling function, that is, to control the malicious file detection device to begin executing the malicious file detection process.
[0084] In one possible case, before obtaining the function library file used by the input method program, the following may also be included:
[0085] Step 61: When a startup instruction is received from the preset system service main program, the process proceeds to the step of obtaining the function library file used by the input method program.
[0086] Specifically, a dedicated function may also be set in the preset system service main program to start the scheduling thread, and then send a startup instruction to the malicious file detection device through the scheduling thread. This function may be set according to actual application requirements.
[0087] Finally, to ensure the proper functioning of the malicious file detection device, a hook process can be installed via the SetWindowsHookExW function. This process monitors messages before they are sent to the target window process. This way, every program with a window process will automatically load the malicious file detection device for the Windows input method. SetWindowsHookExW is a platform for the Windows message processing mechanism.
[0088] Based on the above embodiment, the present invention first obtains the function library file of the input method program on the disk and the module file corresponding to the function library file in the memory, and determines whether the function library file and the module file are PE files. This is to ensure that the function library file and the module file meet the detection conditions, and can use the function library file to extract the code segment with malicious added inline hooks from the module file; after determining that the function library file and the module file are both PE files, the present invention extracts the first code segment and the second code segment from the two files respectively, and compares these code segments to obtain the machine code in the second code segment that is different from the machine code in the first code segment, and then determines whether there are malicious inline hooks in the module file by determining whether the machine code contains jmp, push, pop and int3, which are commonly used instructions for inline hooks. This can effectively detect malicious files with malicious inline hooks in the input method program, and avoid the situation where existing hook detection means cannot detect inline hooks.
[0089] The following describes a malicious file detection device, an electronic device, and a storage medium provided in embodiments of the present invention. The malicious file detection device, electronic device, and storage medium described below can be referenced in correspondence with the malicious file detection method described above.
[0090] Please refer to Figure 2 , Figure 2 This is a structural block diagram of a malicious file detection device provided by an embodiment of the present invention. The device may include:
[0091] The acquisition module 201 is used to acquire the function library file used by the input method program and the module file corresponding to the function library file in the memory;
[0092] A comparison module 202 is configured to compare the first code segment in the function library file with the second code segment in the module file when it is determined that both the function library file and the module file are PE files, and to determine machine codes in the second code segment that are different from those in the first code segment;
[0093] The malicious determination module 203 is configured to determine that the module file is a malicious file when it is determined that the machine code contains preset instructions; the preset instructions include jmp, push, pop, and int3.
[0094] Optionally, the device may further include:
[0095] An extraction module is used to extract a DOS header and an NT header from a function library file and a module file; the DOS header includes a first DOS header of a function library file and a second DOS header of a module file, and the NT header includes a first NT header of a function library file and a second NT header of a module file;
[0096] The judgment module is used to judge whether both the DOS header and the NT header contain a preset PE file identifier; if so, it is determined that the function library file and the module file are both PE files.
[0097] Optionally, the device may further include:
[0098] a tampering detection module, configured to extract a digital signature from the first NT header and use the digital signature to detect whether the function library file has been tampered with;
[0099] Repair module, used to repair the function library file if so;
[0100] The comparison module 202 may also be configured to, if not, proceed to the step of comparing the first code segment in the function library file with the second code segment in the module file.
[0101] Optionally, the extraction module may include:
[0102] The address acquisition submodule is used to write the function library file into the memory according to the size of the function library file, obtain the memory address corresponding to the function library file in the memory, and obtain the base address of the module file in the memory;
[0103] A DOS header extraction submodule, configured to obtain a first DOS header in the memory using a memory address and to obtain a second DOS header using a base address;
[0104] The NT header extraction submodule is used to obtain the first NT header in the memory according to the offset information of the first DOS header, and to obtain the second NT header according to the offset information of the second DOS header.
[0105] Optionally, the comparison module 202 may include:
[0106] The section table extraction submodule is used to extract the code segment section table from the function library file and the module file in the memory according to the offset information in the NT header; the code segment section table includes the first code segment section table of the function library file and the second code segment section table of the module file;
[0107] a code segment extraction submodule, configured to extract a first code segment from the first code segment section table and extract a second code segment from the second code segment section table;
[0108] The comparison submodule is used to copy the second code segment to another area of the memory and compare the first code segment with the copied second code segment.
[0109] Optionally, the device may further include:
[0110] The second acquisition module is used to obtain the base address of the module file in the memory, and use the process snapshot to obtain the loading base address of all modules in the memory and the disk path corresponding to the module on the disk;
[0111] A matching module is used to match the base address with the loading base address and determine the target disk path of the module file based on the matching result;
[0112] The deletion module is used to send the target disk path to the preset system service main program, so that the preset system service main program deletes the files stored in the target disk path.
[0113] Optionally, the acquisition module 201 may also be configured to enter the step of acquiring a function library file used by the input method program when receiving a startup instruction sent by a preset system service main program.
[0114] An embodiment of the present invention further provides an electronic device, including:
[0115] Memory for storing computer programs;
[0116] A processor is used to implement the steps of the malicious file detection method as described above when executing a computer program.
[0117] Since the embodiments of the electronic device part correspond to the embodiments of the malicious file detection method part, the embodiments of the electronic device part refer to the description of the embodiments of the malicious file detection method part, which will not be repeated here.
[0118] An embodiment of the present invention further provides a storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the malicious file detection method of any of the above embodiments are implemented.
[0119] Since the embodiments of the storage medium part correspond to the embodiments of the malicious file detection method part, the embodiments of the storage medium part refer to the description of the embodiments of the malicious file detection method part, and are not repeated here.
[0120] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Reference can be made to the common and similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method description.
[0121] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present invention.
[0122] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
[0123] The above is a detailed introduction to the malicious file detection method, device, electronic device and storage medium provided by the present invention. This article uses specific examples to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core ideas. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present invention, the present invention can also be improved and modified in several ways, and these improvements and modifications also fall within the scope of protection of the claims of the present invention.
Claims
1. A malicious file detection method, characterized in that: include: Obtaining the function library file used by the input method program and the module file corresponding to the function library file in the memory; When it is determined that the function library file and the module file are both PE files, comparing the first code segment in the function library file with the second code segment in the module file to determine a machine code in the second code segment that is different from that in the first code segment; When it is determined that the machine code includes a preset instruction, the module file is determined to be a malicious file; the preset instruction includes jmp, push, pop and int3; Before determining that the function library file and the module file are both PE files, the method further includes: Extracting a DOS header and an NT header from the function library file and the module file; the DOS header includes a first DOS header of the function library file and a second DOS header of the module file, and the NT header includes a first NT header of the function library file and a second NT header of the module file; Accordingly, comparing the first code segment in the function library file and the second code segment in the module file includes: Extracting a code segment section table from the function library file and the module file in the memory according to the offset information in the NT header; the code segment section table includes a first code segment section table of the function library file and a second code segment section table of the module file; extracting the first code segment from the first code segment section table, and extracting the second code segment from the second code segment section table; The second code segment is copied to another area of the memory, and the first code segment is compared with the copied second code segment.
2. The malicious file detection method according to claim 1, characterized in that: Before determining that the function library file and the module file are both PE files, the method further includes: Extracting a DOS header and an NT header from the function library file and the module file; the DOS header includes a first DOS header of the function library file and a second DOS header of the module file, and the NT header includes a first NT header of the function library file and a second NT header of the module file; Determine whether both the DOS header and the NT header contain a preset PE file identifier; If so, it is determined that the function library file and the module file are both the PE files.
3. The malicious file detection method according to claim 2, characterized in that: Before comparing the first code segment in the function library file and the second code segment in the module file, the method further includes: Extracting a digital signature from the first NT header, and using the digital signature to detect whether the function library file has been tampered with; If so, repair the function library file; If not, the process proceeds to the step of comparing the first code segment in the function library file with the second code segment in the module file.
4. The malicious file detection method according to claim 2, wherein: The step of extracting the DOS header and the NT header from the function library file and the module file comprises: The function library file is written into the memory according to the size of the function library file, and a memory address corresponding to the function library file in the memory is obtained, and a base address of the module file in the memory is obtained; Obtaining the first DOS header in the memory using the memory address, and obtaining the second DOS header using the base address; The first NT header is obtained in the memory according to the offset information of the first DOS header, and the second NT header is obtained according to the offset information of the second DOS header.
5. The malicious file detection method according to any one of claims 1 to 4, characterized in that: After determining that the module file is a malicious file, the method further includes: Obtaining a base address of the module file in the memory, and using a process snapshot to obtain loading base addresses of all modules in the memory and disk paths corresponding to the modules on disk; Matching the base address with the loading base address, and determining the target disk path of the module file according to the matching result; The target disk path is sent to a preset system service main program, so that the preset system service main program deletes the file stored in the target disk path.
6. The malicious file detection method according to claim 5, characterized in that: Before obtaining the function library file used by the input method program, it also includes: When the startup instruction sent by the preset system service main program is received, the step of obtaining the function library file used by the input method program is entered.
7. A malicious file detection device, characterized in that: include: An acquisition module is used to acquire the function library file used by the input method program and the module file corresponding to the function library file in the memory; a comparison module, configured to, when it is determined that both the function library file and the module file are PE files, compare the first code segment in the function library file with the second code segment in the module file to determine a machine code in the second code segment that is different from that in the first code segment; a malicious determination module, configured to determine that the module file is a malicious file when it is determined that the machine code contains a preset instruction; the preset instruction includes jmp, push, pop, and int3; The malicious file detection device also includes: An extraction module is used to extract a DOS header and an NT header from the function library file and the module file; the DOS header includes a first DOS header of the function library file and a second DOS header of the module file, and the NT header includes a first NT header of the function library file and a second NT header of the module file; Correspondingly, the comparison module includes: a section table extraction submodule, configured to extract, in the memory, code segment section tables from the function library file and the module file according to the offset information in the NT header; the code segment section tables including the first code segment section table of the function library file and the second code segment section table of the module file; a code segment extraction submodule, configured to extract the first code segment from the first code segment section table, and extract the second code segment from the second code segment section table; The comparison submodule is configured to copy the second code segment to another area of the memory and compare the first code segment with the copied second code segment.
8. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the malicious file detection method according to any one of claims 1 to 6 when executing the computer program.
9. A storage medium, characterized in that: The storage medium stores a computer program, which, when executed by a processor, implements the steps of the malicious file detection method according to any one of claims 1 to 6.